一种可扩展的异步服务mock方法与流程

1.本发明属于信息技术服务领域，具体涉及一种可扩展的异步服务mock方法。


背景技术：

2.异步服务是跟同步服务相对应的，发送一个请求,等待返回,然后再发送下一个请求就是同步服务，发送一个请求,不等待返回,随时可以再发送下一个请求就是异步服务，在真实的测试场景中含有大量异步的场景是通过异步服务来实现的，比如经典的支付场景，发送了一个支付请求出去，并不是一定要等到真正支付成功才返回结果。
3.现有异步回调服务方案由于未解耦异步调用的发起方和处理方，所以只支持基于http/https的接口回调，并且还存在回调参数只能使用请求参数内容直接生成，回调过程也不可见，无法设置回调优先级，无法设置回调触发条件等问题。


技术实现要素：

4.本发明公开了一种可扩展的异步服务mock方法，用以解决上述现有技术中的存在的问题。
5.本发明采用的技术方案如下：
6.一种可扩展的异步服务mock方法，具体包括以下步骤：
7.步骤1：通过请求报文判断是否需要路由到挡板服务，实现了由请求发起方动态控制走挡板服务还是真实服务；
8.步骤2：挡板服务同步响应业务系统，组装回调参数，并将把组装好的回调参数发给消息队列，实现了同步响应异步处理，实现了多种回调参数的组装；
9.步骤3：回调服务从消息队列获取并解析回调消息，判断解析结果是否满足回调条件，如不满足进入等待状态，如果条件满足，向被回调服务发送回调请求，实现业务系统回调，实现了回调服务的优先级设置、间隔时间的设置、回调触发条件的设置；
10.步骤4：记录调用结果并可视化展示回调链路，通过对日志的收集和分析，将回调过程进行可视化展示，极大提高了问题排查的效率。
11.所述步骤1具体包括：
12.步骤1.1：业务系统发起请求，请求内容为sofa、dubbo、http、socket、mq、rpc等多种类型的异步回调服务；
13.步骤1.2：微服务控制台判断请求是否带有mock标识；
14.步骤1.3：将请求中无mock标识的业务请求路由到真实服务；
15.步骤1.4：将请求中有mock标识的业务请求路由到挡板服务。
16.所述步骤2具体包括：
17.步骤2.1：挡板服务根据请求特征从数据库中获取预设的响应模版；
18.步骤2.2：挡板服务解析响应模板，获取同步响应报文脚本，回调初始脚本，外部服务调用脚本；
19.步骤2.3：挡板服务根据获取到的同步响应脚本对业务系统发起同步响应；
20.步骤2.4：挡板服务判断响应模板中是否包含外部服务调用脚本，如果包含则通过外部服务调用脚本发起外部请求，获取外部参数，如入不包含则跳过该步骤；
21.步骤2.5：挡板服务根据回调初始脚本、挡板服务接收到的业务请求、外部参数完成回调参数的组装；
22.步骤2.6：挡板服务发送回调消息到消息队列。
23.所述步骤2.5具体包括：
24.2.51：挡板服务先判断业务请求中是否包含某key的值，如有则将回调初始脚本中该key的值替换成业务请求中的值；
25.2.52：挡板服务判断回调初始脚本中是否有需要从外部参数获取的值，如有则替换成外部服务获取到的值；
26.进一步的，所述回调参数的生成方式具体包括通过请求参数内容直接生成、通过执行javascript脚本对请求参数进行运算后生成、调用第三方业务系统来获取需要数据来生成。
27.所述步骤3具体包括：
28.步骤3.1：回调服务从消息队列获取回调消息，不同的回调服务分别监听不同的消息队列；
29.步骤3.2：回调服务解析消息队列，回调服务收到回调消息后会解析出用户发送回调的请求内容并将解析出的内容组装成一个完整的请求，该请求将会发送到目标的被回调服务；
30.步骤3.3：回调服务本身设置触发条件，根据设定的具体回调触发条件来判断是否需要立即执行回调任务，如不满足进入等待状态；
31.步骤3.4：如果条件满足，根据步骤3.2解析出的请求内容向被回调服务发送回调请求。
32.进一步的，所述请求内容包括请求头，请求方法，请求参数，请求目标地址，请求体。
33.进一步的，回调触发条件可以设定为：(1)定时的回调，比如下午17：00进行回调；(2)对于有多个接口回调的场景，可以指定接口回调的顺序，比如先a回调，等a回调完成以后，再b回调。(3)当业务数据库发生状态值变更以后再进行回调。
34.综上所述，由于采用了上述技术方案，本发明的有益效果是：
35.1.通过整体的异步回调方案，完成了异步回调场景的mock，实现了无人值守联调，极大的降低了人力成本，提高了多系统联调的测试效率。
36.2.通过在业务请求中添加mock标识，实现了真实的业务系统调用和挡板服务调用的随意切换。
37.3.通过预设的脚本配置，可以从第三方服务的获取外部服务信息，实现复杂场景下的异步回调场景。
38.4.通过“消息队列 回调服务”，支持多种类型的异步服务回调，比如http/https、socket、mq、rpc、sofa、dubbo等。
39.5.设置回调服务的优先级和调用的间隔，模仿真实服务发生时服务的调用顺序，
实现了更加真实业务场景模拟。
40.6.可以设置触发条件，在进行回调时对回调触发条件进行判断，比如可以判断数据库中关键数据发生改变或是下游业务系统关键状态发生改变以后再进行回调，更加真实模拟了生产环境服务的调用情况。
41.7.通过对日志的收集和分析，将回调过程进行可视化展示，实现了问题排查效率的极大提升。
42.8.通过加入消息队列和定义回调服务的消息内容，可以动态添加回调服务解析对应的消息内容来进行不同类型的回调请求发送，使其具有可扩展性。
附图说明
43.本发明将通过例子并参照附图的方式说明，其中：
44.图1为本发明实施例提供的异步服务mock方法的流程示意图；
45.图2为本发明实施例提供的异步服务mock方法的实现逻辑图；
46.图3为本发明实施例中步骤1的流程示意图；
47.图4为本发明实施例中步骤2的流程示意图；
48.图5为本发明实施例中步骤3的流程示意图。
49.名词解释
50.mock：所在测试或者研发过程中，对于某些不容易构造或者不容易获取的对象，创建一个虚拟的对象以便测试，而这个虚拟的对象就是mock对象，mock对象就是真实对象在调试期间的代替品。
具体实施方式
51.为使本技术实施例的目的、技术方案和优点更加清楚，下面将结合本技术实施例中附图，对本技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本技术一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本技术实施例的组件可以各种不同的配置来布置和设计。因此，以下对在附图中提供的本技术的实施例的详细描述并非旨在限制要求保护的本技术的范围，而是仅仅表示本技术的选定实施例。基于本技术的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本技术保护的范围。
52.在本技术实施例的描述中，需要说明的是，术语“第一”、“第二”、“第三”等仅用于区分描述，而不能理解为指示或暗示相对重要性。
53.下面结合图1～图5对本发明作详细说明。
54.步骤1：通过请求报文判断是否需要路由到挡板服务，实现了由请求发起方动态控制走挡板服务还是真实服务，其具体包括如下步骤：
55.步骤1.1：业务系统发起请求，请求内容为sofa、dubbo、http、socket、mq、rpc多种类型的异步回调服务；
56.步骤1.2：微服务控制台判断请求是否带有mock标识；
57.步骤1.3：将请求中无mock标识的业务请求路由到真实服务；
58.步骤1.4：将请求中有mock标识的业务请求路由到挡板服务。
59.步骤2：挡板服务同步响应业务系统，组装回调参数，并将把组装好的回调参数发给消息队列，实现了同步响应异步处理，实现了多种回调参数的组装，其中回调参数的生成方式具体包括通过请求参数内容直接生成、通过执行javascript脚本对请求参数进行运算后生成、调用第三方业务系统来获取需要数据来生成；通过该步骤，实现了同步响应异步处理，实现了多种回调参数的组装，其具体包括如下步骤：
60.步骤2.1：挡板服务根据请求特征从数据库中获取预设的响应模版；
61.步骤2.2：挡板服务解析响应模板，获取同步响应报文脚本，回调初始脚本，外部服务调用脚本；
62.以下是同步响应报文脚本示例：
[0063][0064][0065]
以下是模板中的初始回调脚本示例：
[0066][0067]
以下下是外部服务调用脚本示例：
[0068]
[0069][0070]
步骤2.3：挡板服务根据获取到的同步响应脚本对业务系统发起同步响应；
[0071]
步骤2.4：挡板服务判断响应模板中是否包含外部服务调用脚本，如果包含则通过外部服务调用脚本发起外部请求，获取外部参数，如入不包含则跳过该步骤；
[0072]
步骤2.5：挡板服务根据回调初始脚本、挡板服务接收到的业务请求、外部参数完成回调参数的组装；具体为：
[0073]
a：挡板服务先判断业务请求中是否包含某key的值，如有则将回调初始脚本中该key的值替换成业务请求中的值；
[0074]
b：挡板服务判断回调初始脚本中是否有需要从外部参数获取的值，如有则替换成外部服务获取到的值；
[0075]
步骤2.6：挡板服务发送回调消息到消息队列。
[0076]
步骤3：回调服务从消息队列获取并解析回调消息，判断解析结果是否满足回调条件，如不满足进入等待状态，如果条件满足，向被回调服务发送回调请求，通过该步骤，实现了http/https、socket、mq、rpc等多种不同类型的回调，实现了回调过程的可视化。实现了回调服务的优先级设置、间隔时间的设置、回调触发条件的设置。具体步骤如下：
[0077]
步骤3.1：回调服务从消息队列获取回调消息，不同的回调服务(sofa、dubbo、http、socket)分别监听不同的消息队列；
[0078]
步骤3.2：回调服务解析消息队列，以http回调为例，回调服务收到回调消息后会解析出用户发送http回调的请求头(headers)，请求方法(method)，请求参数(parameters)，请求目标地址(url)，请求体(body)，并将解析出的内容组装成一个完整的http请求，该请求将会发送到目标url的被回调服务；
[0079]
步骤3.3：回调服务本身可以设计触发条件，根据设定的具体回调触发条件判断其是否需要执行回调任务；本实施例中回调触发条件可以根据实际场景来设定，设计的回调触发条件为定时触发来判断是否需要等待执行，所述回调触发条件可以设定为：(1)定时的回调，比如下午17：00进行回调；(2)对于有多个接口回调的场景，可以指定接口回调的顺序，比如先a回调，等a回调完成以后，再b回调。(3)当业务数据库发生状态值变更以后再进行回调。
[0080]
具体步骤如下：
[0081]
步骤3.31：判断请求是否需要等待执行，
[0082]
步骤3.32：若判断结果为是则进行等待执行状态，继续判断是否超时，若是则结束，若否则返回步骤3.31继续判断是否需要等待执行；
[0083]
步骤3.33：若判断结果为否则不需要等待执行，则继续判断是否满足回调条件，
[0084]
步骤3.34：若不满足则判断其是否超时，若是则结束，若否则返回步骤3.31继续判断是否需要等待执行；
[0085]
步骤3.35：若满足回调条件，根据步骤3.2解析出的请求内容向被回调服务发送回调请求，立即执行回调任务。
[0086]
步骤4：记录调用结果并可视化展示回调链路，通过对日志的收集和分析，将回调过程进行可视化展示，极大提高了问题排查的效率。
[0087]
以上所述实施例仅表达了本技术的具体实施方式，其描述较为具体和详细，但并不能因此而理解为对本技术保护范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本技术技术方案构思的前提下，还可以做出若干变形和改进，这些都属于本技术的保护范围。