专利名称:业务变更处理方法、装置、设备及存储介质
专利类型:实用新型专利
专利申请号:CN202211738692.0
专利申请(专利权)人:支付宝(杭州)信息技术有限公司
权利人地址:浙江省杭州市西湖区西溪路556号8层B段801-11
专利发明(设计)人:袁孟
专利摘要:本说明书一个或多个实施例提供了一种业务变更处理方法、装置、设备及存储介质,其中方法包括:第一应用获取业务定义信息,根据业务定义信息,确定待监控的目标业务,第一应用为应用调用链路上的最顶层应用,目标业务为第一应用基于应用调用链路所能够提供的业务。在应用调用链路上的第二应用变更之后,第一应用基于应用调用链路上的各个应用之间的调用关系,获取变更后的第二应用透传上来的第二应用的变更信息和变更后的第二应用执行目标业务的中间结果数据,第二应用为应用调用链路上的最底层应用。第一应用基于中间结果数据,确定目标业务的执行结果,并根据执行结果,确定第二应用的变更信息与目标业务的执行成功率之间的关联关系。
主权利要求:
1.一种应用变更处理方法,包括:
第一应用获取业务定义信息,根据所述业务定义信息,确定待监控的目标业务;所述第一应用为应用调用链路上的最顶层应用;所述目标业务为所述第一应用基于所述应用调用链路所能够提供的业务;
在所述应用调用链路上的第二应用变更之后,所述第一应用基于所述应用调用链路上的各个应用之间的调用关系,获取变更后的所述第二应用透传上来的所述第二应用的变更信息和变更后的所述第二应用执行所述目标业务的中间结果数据;所述第二应用为所述应用调用链路上的最底层应用;
所述第一应用基于所述中间结果数据,确定所述目标业务的执行结果,并根据所述执行结果,确定所述第二应用的变更信息与所述目标业务的执行成功率之间的关联关系;所述目标业务的执行成功率包括:根据所述目标业务的多次执行结果确定得到的所述第二应用变更之后所述目标业务的执行成功率。
2.根据权利要求1所述的方法,
所述第一应用获取业务定义信息,根据所述业务定义信息,确定待监控的目标业务,包括:所述第一应用获取工作人员通过业务运维平台上报的业务定义信息;所述业务定义信息中携带有待监控的业务接口的接口标识和待监控的方法的方法标识;所述待监控的方法从属于所述待监控的业务接口;
所述第一应用根据所述待监控的业务接口的接口标识和所述待监控的方法的方法标识,将所述待监控的业务接口和所述待监控的方法所属的业务作为待监控的目标业务。
3.根据权利要求1所述的方法,所述第一应用根据所述执行结果,确定所述第二应用的变更信息与所述目标业务的执行成功率之间的关联关系,包括:所述第一应用根据所述执行结果,确定所述第二应用变更之后所述目标业务的执行成功率,并输出记载有所述第二应用的变更信息和所述第二应用变更之后所述目标业务的执行成功率的第一日志;
所述第一日志用于表示所述第二应用的变更信息与所述第二应用变更之后所述目标业务的执行成功率之间的关联关系。
4.根据权利要求3所述的方法,所述第一应用根据所述执行结果,确定所述第二应用变更之后所述目标业务的执行成功率,包括:所述第一应用根据所述执行结果与预先设定的执行结果与业务执行码之间的对应关系,生成与所述执行结果相对应的业务执行码;所述业务执行码用于表示所述执行结果;
所述第一应用对所述业务执行码进行统计分析,确定所述第二应用变更之后所述目标业务的执行成功率;所述第一日志中还记载有所述业务执行码。
5.根据权利要求1所述的方法,所述第一应用根据所述执行结果,确定所述第二应用的变更信息与所述目标业务的执行成功率之间的关联关系,包括:所述第一应用输出记载有所述执行结果和所述第二应用的变更信息的第二日志给监控平台;
所述监控平台用于根据所述执行结果,确定所述第二应用变更之后所述目标业务的执行成功率;所述第二日志用于表示所述第二应用的变更信息与所述第二应用变更之后所述目标业务的执行成功率之间的关联关系。
6.根据权利要求1所述的方法,所述第一应用根据所述执行结果,确定所述第二应用的变更信息与所述目标业务的执行成功率之间的关联关系,包括:所述第一应用根据所述执行结果与预先设定的执行结果与业务执行码之间的对应关系,生成与所述执行结果相对应的业务执行码;所述业务执行码用于表示所述执行结果;
所述第一应用输出记载有所述业务执行码和所述第二应用的变更信息的第三日志给监控平台;
所述监控平台用于根据所述业务执行码,确定所述第二应用变更之后所述目标业务的执行成功率;所述第三日志用于表示所述第二应用的变更信息与所述第二应用变更之后所述目标业务的执行成功率之间的关联关系。
7.根据权利要求1所述的方法,所述第一应用根据所述执行结果,确定所述第二应用的变更信息与所述目标业务的执行成功率之间的关联关系,包括:所述第一应用基于所述执行结果,确定所述第二应用变更之后所述目标业务的执行成功率;
所述第一应用获取所述第二应用变更之前所述目标业务的执行成功率;
所述第一应用对所述第二应用变更之后所述目标业务的执行成功率和所述第二应用变更之前所述目标业务的执行成功率进行比对分析,以确定所述第二应用的变更信息与所述目标业务的执行成功率之间的关联关系。
8.根据权利要求1所述的方法,所述第一应用确定待监控的目标业务之后,还包括:所述第一应用获取所述目标业务的业务信息,基于所述应用调用链路上的各个应用之间的调用关系,将所述目标业务的业务信息透传至所述应用调用链路上的各个应用;
所述目标业务的业务信息用于使所述应用调用链路上的各个应用生成执行所述目标业务的执行日志;所述执行日志用于恢复所述目标业务的执行过程。
9.一种应用变更处理方法,包括:
在应用调用链路上的第二应用变更之后,变更后的所述第二应用获取所述第二应用的待透传的变更信息和变更后的所述第二应用执行目标业务的中间结果数据;
变更后的所述第二应用基于所述应用调用链路上的各个应用之间的调用关系,向所述应用调用链路上的第一应用透传所述第二应用的所述变更信息和所述中间结果数据;
其中,所述第二应用为所述应用调用链路上的最底层应用;所述第一应用为应用调用链路上的最顶层应用;所述目标业务为所述第一应用基于所述应用调用链路所能够提供的业务;所述中间结果数据用于所述第一应用确定所述目标业务的执行结果,并根据所述执行结果,确定所述第二应用的所述变更信息与所述目标业务的执行成功率之间的关联关系;所述目标业务的执行成功率包括:根据所述目标业务的多次执行结果确定得到的所述第二应用变更之后所述目标业务的执行成功率。
10.根据权利要求9所述的方法,还包括:
在所述第二应用变更之前,所述第二应用获取业务运维平台上报的所述第二应用的变更标记;所述业务运维平台基于从变更平台处获取的所述第二应用的变更通知消息生成所述第二应用的变更标记;
在所述第二应用变更之后,变更后的所述第二应用获取所述第二应用的待透传的变更信息之前,变更后的所述第二应用将所述第二应用的变更标记作为所述第二应用的待透传的变更信息。
11.根据权利要求9所述的方法,还包括:
在所述第二应用变更之前,所述第二应用基于所述应用调用链路上的各个应用之间的调用关系,获取所述第一应用透传过来的所述目标业务的业务信息;
在所述第二应用变更之后,所述第二应用基于所述目标业务的业务信息,生成执行所述目标业务的执行日志;所述执行日志用于恢复所述目标业务的执行过程。
12.根据权利要求9所述的方法,还包括:
在所述第二应用变更完成预设时长之后,变更后的所述第二应用基于所述应用调用链路上的各个应用之间的调用关系,向所述第一应用透传操作取消消息;所述操作取消消息用于所述第一应用取消执行确定所述第二应用的所述变更信息与所述目标业务的执行成功率之间的关联关系的操作。
13.根据权利要求12所述的方法,在变更后的所述第二应用基于所述应用调用链路上的各个应用之间的调用关系,向所述第一应用透传操作取消消息之前,还包括:在所述第二应用变更完成预设时长之后,变更后的所述第二应用获取业务运维平台上报的所述操作取消消息;所述业务运维平台基于从变更平台处获取的所述第二应用的变更完成通知消息生成所述操作取消消息。
14.一种应用变更处理装置,包括:
业务确定单元,被配置为第一应用获取业务定义信息,根据所述业务定义信息,确定待监控的目标业务;所述第一应用为应用调用链路上的最顶层应用;所述目标业务为所述第一应用基于所述应用调用链路所能够提供的业务;
数据获取单元,被配置为在所述应用调用链路上的第二应用变更之后,所述第一应用基于所述应用调用链路上的各个应用之间的调用关系,获取变更后的所述第二应用透传上来的所述第二应用的变更信息和变更后的所述第二应用执行所述目标业务的中间结果数据;所述第二应用为所述应用调用链路上的最底层应用;
结果确定单元,被配置为所述第一应用基于所述中间结果数据,确定所述目标业务的执行结果,并根据所述执行结果,确定所述第二应用的变更信息与所述目标业务的执行成功率之间的关联关系;所述目标业务的执行成功率包括:根据所述目标业务的多次执行结果确定得到的所述第二应用变更之后所述目标业务的执行成功率。
15.一种应用变更处理装置,包括:
变更获取单元,被配置为在应用调用链路上的第二应用变更之后,变更后的所述第二应用获取所述第二应用的待透传的变更信息和变更后的所述第二应用执行目标业务的中间结果数据;
数据透传单元,被配置为变更后的所述第二应用基于所述应用调用链路上的各个应用之间的调用关系,向所述应用调用链路上的第一应用透传所述第二应用的所述变更信息和所述中间结果数据;
其中,所述第二应用为所述应用调用链路上的最底层应用;所述第一应用为应用调用链路上的最顶层应用;所述目标业务为所述第一应用基于所述应用调用链路所能够提供的业务;所述中间结果数据用于所述第一应用确定所述目标业务的执行结果,并根据所述执行结果,确定所述第二应用的所述变更信息与所述目标业务的执行成功率之间的关联关系;所述目标业务的执行成功率包括:根据所述目标业务的多次执行结果确定得到的所述第二应用变更之后所述目标业务的执行成功率。
16.一种应用变更处理设备,包括:
处理器;以及
被安排成存储计算机可执行指令的存储器,所述计算机可执行指令在被所述处理器执行时使所述处理器实现上述权利要求1‑8任一项所述的方法的步骤。
17.一种应用变更处理设备,包括:
处理器;以及
被安排成存储计算机可执行指令的存储器,所述计算机可执行指令在被所述处理器执行时使所述处理器实现上述权利要求9‑13任一项所述的方法的步骤。
18.一种存储介质,用于存储计算机可执行指令,所述计算机可执行指令在被处理器执行时使处理器实现上述权利要求1‑8任一项所述的方法的步骤。
19.一种存储介质,用于存储计算机可执行指令,所述计算机可执行指令在被处理器执行时使处理器实现上述权利要求9‑13任一项所述的方法的步骤。 说明书 : 业务变更处理方法、装置、设备及存储介质技术领域[0001] 本文件涉及计算机技术领域,尤其涉及一种业务变更处理方法、装置、设备及存储介质。背景技术[0002] 随着业务场景的发展,应用之间的调用链路越来越长也越来越复杂,这就导致底层应用发布变更后对于上层应用造成的影响难以准确评估。比如,在一条应用调用链路中,应用A调用应用B,应用B调用应用C,若应用C发布变更,应用C本身不会因为变更出现异常,但是若应用C的输出数据随着变更发生了变化,则可能会引起应用A在执行业务时出现异常。发明内容[0003] 第一方面,本说明书一实施例提供了一种应用变更处理方法,包括:第一应用获取业务定义信息。根据所述业务定义信息,确定待监控的目标业务。所述第一应用为应用调用链路上的最顶层应用。所述目标业务为所述第一应用基于所述应用调用链路所能够提供的业务。在所述应用调用链路上的第二应用变更之后,所述第一应用基于所述应用调用链路上的各个应用之间的调用关系,获取变更后的所述第二应用透传上来的所述第二应用的变更信息和变更后的所述第二应用执行所述目标业务的中间结果数据。所述第二应用为所述应用调用链路上的最底层应用。所述第一应用基于所述中间结果数据,确定所述目标业务的执行结果。并根据所述执行结果,确定所述第二应用的变更信息与所述目标业务的执行成功率之间的关联关系。[0004] 第二方面,本说明书一实施例提供了一种应用变更处理方法,包括:在应用调用链路上的第二应用变更之后,变更后的所述第二应用获取所述第二应用的待透传的变更信息和变更后的所述第二应用执行目标业务的中间结果数据。变更后的所述第二应用基于所述应用调用链路上的各个应用之间的调用关系,向所述应用调用链路上的第一应用透传所述第二应用的所述变更信息和所述中间结果数据。其中,所述第二应用为所述应用调用链路上的最底层应用。所述第一应用为应用调用链路上的最顶层应用。所述目标业务为所述第一应用基于所述应用调用链路所能够提供的业务。所述中间结果数据用于所述第一应用确定所述目标业务的执行结果。并根据所述执行结果,确定所述第二应用的所述变更信息与所述目标业务的执行成功率之间的关联关系。[0005] 第三方面,本说明书一实施例提供了一种应用变更处理装置,包括:业务确定单元,被配置为第一应用获取业务定义信息。根据所述业务定义信息,确定待监控的目标业务。所述第一应用为应用调用链路上的最顶层应用。所述目标业务为所述第一应用基于所述应用调用链路所能够提供的业务。数据获取单元,被配置为在所述应用调用链路上的第二应用变更之后,所述第一应用基于所述应用调用链路上的各个应用之间的调用关系,获取变更后的所述第二应用透传上来的所述第二应用的变更信息和变更后的所述第二应用执行所述目标业务的中间结果数据。所述第二应用为所述应用调用链路上的最底层应用。结果确定单元,被配置为所述第一应用基于所述中间结果数据,确定所述目标业务的执行结果。并根据所述执行结果,确定所述第二应用的变更信息与所述目标业务的执行成功率之间的关联关系。[0006] 第四方面,本说明书一实施例提供了一种应用变更处理装置,包括:变更获取单元,被配置为在应用调用链路上的第二应用变更之后,变更后的所述第二应用获取所述第二应用的待透传的变更信息和变更后的所述第二应用执行目标业务的中间结果数据。数据透传单元,被配置为变更后的所述第二应用基于所述应用调用链路上的各个应用之间的调用关系,向所述应用调用链路上的第一应用透传所述第二应用的所述变更信息和所述中间结果数据。其中,所述第二应用为所述应用调用链路上的最底层应用。所述第一应用为应用调用链路上的最顶层应用。所述目标业务为所述第一应用基于所述应用调用链路所能够提供的业务。所述中间结果数据用于所述第一应用确定所述目标业务的执行结果。并根据所述执行结果,确定所述第二应用的所述变更信息与所述目标业务的执行成功率之间的关联关系。[0007] 第五方面,本说明书一实施例提供了一种应用变更处理设备,包括:处理器;以及被安排成存储计算机可执行指令的存储器。所述计算机可执行指令在被所述处理器执行时使所述处理器实现上述第一方面所述的方法的步骤。[0008] 第六方面,本说明书一实施例提供了一种应用变更处理设备,包括:处理器;以及被安排成存储计算机可执行指令的存储器。所述计算机可执行指令在被所述处理器执行时使所述处理器实现上述第二方面所述的方法的步骤。[0009] 第七方面,本说明书一实施例提供了一种存储介质,用于存储计算机可执行指令。所述计算机可执行指令在被处理器执行时使处理器实现上述第一方面所述的方法的步骤。[0010] 第八方面,本说明书一实施例提供了一种存储介质,用于存储计算机可执行指令。所述计算机可执行指令在被处理器执行时使处理器实现上述第二方面所述的方法的步骤。附图说明[0011] 为了更清楚地说明本说明书一个或多个实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本说明书一个或多个中记载的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动性的前提下,还可以根据这些附图获得其他的附图。[0012] 图1为本说明书一实施例提供的应用变更的场景示意图;[0013] 图2为本说明书一实施例提供的应用变更处理方法的流程示意图;[0014] 图3为本说明书另一实施例提供的应用变更处理方法的流程示意图;[0015] 图4为本说明书一实施例提供的向上透传第二应用的变更信息和向下透传第一应用的目标业务的业务信息的场景示意图;[0016] 图5为本说明书一实施例提供的业务运维平台、变更平台和监控平台的功能示意图;[0017] 图6为本说明书另一实施例提供的应用变更处理方法的流程示意图;[0018] 图7为本说明书一实施例提供的应用变更处理装置的结构示意图;[0019] 图8为本说明书另一实施例提供的应用变更处理装置的结构示意图;[0020] 图9为本说明书一实施提供的应用变更处理设备的结构示意图。具体实施方式[0021] 为了使本技术领域的人员更好地理解本说明书一个或多个中的技术方案,下面将结合本说明书一个或多个实施例中的附图,对本说明书一个或多个实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本说明书一个或多个一部分实施例,而不是全部的实施例。基于本说明书一个或多个中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都应当属于本文件的保护范围。[0022] 需要说明的是,在不冲突的情况下,本说明书中的一个或多个实施例以及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本说明书一个或多个实施例。[0023] 图1为本说明书一实施例提供的应用变更的场景示意图,如图1所示,该场景包括多个应用,图1中以应用1、应用2、应用3……应用n为例进行示意,n为大于等于4的正整数。在图1中,应用1调用应用2,应用2调用应用3,以此类推直至应用n‑1调用应用n,应用1为应用调用链路上的最顶层应用,应用n为应用调用链路上的最底层应用。[0024] 在一个具体的例子中,应用1为面向用户的业务入口应用,用户可以在应用1中执行余额查询操作以查询账户余额,应用n为对接数据库的应用,能够从数据库中查询到用户的账户余额并通过应用调用链路上的各个应用依次向上传递账户余额直至将账户余额传递给应用1,使得用户基于应用1看到账户余额。在一次应用变更中,应用n上发布变更,将用户的账户余额的获取地址由之前的地址A改为地址B,应用n基于变更后的地址可以查询到用户的账户余额,但是应用1根据用户操作生成余额查询请求时,依旧将地址B作为参数封装到余额查询请求内,使得应用n无法从地址B中查询到用户的账户余额,导致应用1向用户返回的账户余额为空。[0025] 从上面的例子可以看出,在一条应用调用链路上,当最底层应用发布变更后,最底层应用可能没有发生异常,但是最顶层的应用可能在执行业务时出现异常,比如业务执行失败。基于此,本说明书一个或多个实施例提供了一种应用变更处理方法,能够在底层应用发布变更后,准确衡量该变更对顶层应用的业务执行结果的影响,从而及时对底层应用发布的变更进行调整。[0026] 图2为本说明书一实施例提供的应用变更处理方法的流程示意图,该流程可以由第一应用执行,在硬件方面可以理解为由提供第一应用的第一应用服务器执行,如图2所示,该流程包括:[0027] 步骤S202,第一应用获取业务定义信息,根据业务定义信息,确定待监控的目标业务;第一应用为应用调用链路上的最顶层应用;目标业务为第一应用基于应用调用链路所能够提供的业务;[0028] 步骤S204,在应用调用链路上的第二应用变更之后,第一应用基于应用调用链路上的各个应用之间的调用关系,获取变更后的第二应用透传上来的第二应用的变更信息和变更后的第二应用执行目标业务的中间结果数据;第二应用为应用调用链路上的最底层应用;[0029] 步骤S206,第一应用基于中间结果数据,确定目标业务的执行结果,并根据执行结果,确定第二应用的变更信息与目标业务的执行成功率之间的关联关系。[0030] 第一应用是应用调用链路上的最顶层应用,比如图1中的应用1。第二应用是应用调用链路上的最底层应用,比如图1中的应用n。第一应用上安装有业务运维中间件,比如ServerlessSDK。ServerlessSDK是面向sofaserverless能力体系建设,作用于应用近端,对业务流量进行染色、统计、定位、应急等业务级运维的中间件。第一应用中的业务运维中间件可以执行图2中的方法流程。[0031] 在上述步骤S202中,第一应用中的业务运维中间件获取业务定义信息,根据业务定义信息,确定待监控的目标业务。目标业务是第一应用基于应用调用链路所能够提供的业务。比如,第一应用基于应用调用链路所能够提供的业务包括“查询用户账户余额”、“查询用户个人信息”、“查询用户银行卡账号”这三个业务,目标业务可以是其中的“查询用户账户余额”这一业务,或者是其中的“查询用户账户余额”和“查询用户银行卡账号”这两个业务。[0032] 在一个实施例中,第一应用获取业务定义信息,根据业务定义信息,确定待监控的目标业务,具体为:第一应用获取工作人员通过业务运维平台上报的业务定义信息;业务定义信息中携带有待监控的业务接口的接口标识和待监控的方法的方法标识;待监控的方法从属于待监控的业务接口;第一应用根据待监控的业务接口的接口标识和待监控的方法的方法标识,将待监控的业务接口和待监控的方法所属的业务作为待监控的目标业务。[0033] 业务运维平台可以是bizOps平台。Bizops平台是针对线上复杂业务流量导致的稳定性、效率、容量等一系列问题提供的轻量级、业务几乎无感知的业务运维解决方案。工作人员在业务运维平台上输入业务定义信息,业务运维平台将业务定义信息上报给第一应用,由第一应用中的业务运维中间件接收。业务定义信息包括待监控的业务接口的接口标识和待监控的方法的方法标识,而且待监控的方法从属于待监控的业务接口。待监控的业务接口和待监控的方法,可以理解为实现某个业务的代码中所涉及到的业务接口和方法,方法从属于接口,通过方法和接口获取该业务的返回值。在前面提到过的查询用户账户余额的例子中,待监控的业务接口的接口标识,可以为获取用户账户余额的接口的标识,待监控的方法的方法标识,可以为获取用户账户余额的方法的标识。[0034] 第一应用中的业务运维中间件在接收到业务定义信息之后,根据业务定义信息中的待监控的业务接口的接口标识和待监控的方法的方法标识,将待监控的业务接口和待监控的方法所属的业务作为待监控的目标业务。在前面的例子中,第一应用接收到获取用户账户余额的接口的标识和获取用户账户余额的方法的标识之后,将获取用户账户余额这一业务作为待监控的目标业务。[0035] 在一个具体的例子中,假设第一应用为应用1,为应用调用链路上的最上游应用,则工作人员在业务运维平台中输入应用1的标识,应用1中的某个业务接口的接口标识,该业务接口下的某个方法的方法标识,而且要求该方法从属于该业务接口。则业务运维平台将获取到的应用1的标识、业务接口的接口标识和方法的方法标识组合为业务定义信息并发送至第一应用,由第一应用中的业务运维中间件接收。第一应用中的业务运维中间件在接收到业务定义信息之后,确定业务接口的接口标识和方法的方法标识所从属的业务,该业务为第一应用基于应用调用链路所能够提供的业务,将该业务作为待监控的目标业务。[0036] 可见,通过本实施例,工作人员可以在业务运维平台上根据工作需求自定义待监控的业务,在应用变更场景实现监控业务的自定义。在其他实施例中,业务运维平台也可以直接接收工作人员输入的待监控业务的业务标识,并将该业务标识作为业务定义信息传输至第一应用,从而第一应用确定待监控的目标业务。[0037] 在上述步骤S204中,在应用调用链路上的第二应用变更之后,第一应用基于应用调用链路上的各个应用之间的调用关系,获取变更后的第二应用透传上来的第二应用的变更信息和变更后的第二应用执行目标业务的中间结果数据。[0038] 如图1所示,第二应用作为应用调用链路上的最底层应用,可以基于应用调用链路上的各个应用之间的调用关系,向上透传第二应用的变更信息和变更后的第二应用执行目标业务的中间结果数据,直至将第二应用的变更信息和变更后的第二应用执行目标业务的中间结果数据透传到第一应用,由第一应用中的业务运维中间件接收。为了实现在整个应用调用链路上的信息的透传,应用调用链路上的每个应用都可以安装有相同的业务运维中间件,比如都安装有ServerlessSDK,通过每个应用上的相同的业务运维中间件实现信息的向上和向下透传。[0039] 第二应用的变更信息包括但不限于第二应用的应用标识和第二应用的具体变更内容中的一项或多项。第二应用的具体变更内容包括但不限于第二应用所变更的代码片段的片段标识,变更前的代码和变更后的代码。由于目标业务为第一应用基于应用调用链路所能够提供的业务,因此目标业务需要应用调用链路上的各个应用相互调用实现,第二应用执行目标业务之后,得到的是中间结果数据,该中间结果数据透传到第一应用后,第一应用基于该中间结果数据才能够得到目标业务的执行结果。比如在查询用户账户余额的例子中,第二应用执行业务后得到的是从银行数据库中获取的账户余额,该账户余额透传到第一应用后,第一应用基于该账户余额加上从其他数据库中获取的用户的利息,得到用户的最终的账户余额并显示给用户。该例子中,第二应用透传给第一应用的是从银行数据库中获取的账户余额这一中间结果数据。[0040] 在上述步骤S206中,第一应用基于第二应用透传上来的目标业务的中间结果数据,确定目标业务的执行结果。接着根据目标业务的执行结果,确定第二应用的变更信息与目标业务的执行成功率之间的关联关系。第一应用基于第二应用透传上来的目标业务的中间结果数据,确定得到目标业务的执行结果包括执行成功和执行失败两个结果。比如在查询用户账户余额的例子中,第一应用接收到第二应用透传上来的从银行数据库中获取的账户余额这一中间结果数据之后,加上从其他数据库中获取的用户的利息,就能够得到用户最终的账户余额,此时目标业务的执行结果即为执行成功,若第一应用接收到第二应用透传上来的从银行数据库中获取的账户余额为非法值,也即第二应用获取用户在银行中的余额失败,则第一应用无法计算得到用户最终的账户余额,此时目标业务的执行结果即为执行失败。[0041] 在步骤S206中,根据中间结果数据确定目标业务的执行结果的过程,可以由第一应用中的业务执行模块执行,在业务执行模块得到目标业务的执行结果之后,第一应用中的业务运维中间件根据目标业务的执行结果,确定第二应用的变更信息与目标业务的执行成功率之间的关联关系。[0042] 在一个实施例中,第一应用根据目标业务的执行结果,确定第二应用的变更信息与目标业务的执行成功率之间的关联关系,具体为:第一应用根据目标业务的执行结果,确定第二应用变更之后目标业务的执行成功率,并输出记载有第二应用的变更信息和第二应用变更之后目标业务的执行成功率的第一日志;第一日志用于表示第二应用的变更信息与第二应用变更之后目标业务的执行成功率之间的关联关系。[0043] 具体而言,第一应用可以在第二应用变更之后,统计多次目标业务的执行结果,每次统计时都是根据第二应用透传上来的目标业务的中间结果数据确定目标业务的执行结果并统计。根据目标业务的多次的执行结果,确定第二应用变更之后目标业务的执行成功率,执行成功率等于执行成功的次数除以总的目标业务的执行次数。接着,第一应用通过业务运维中间件输出第一日志,第一日志中记录有第二应用的变更信息和第二应用变更之后目标业务的执行成功率,第一日志用于表示第二应用的变更信息与第二应用变更之后目标业务的执行成功率之间的关联关系。[0044] 在一个例子中,第一应用在第二应用变更之后,首先在第一日志中打印第二应用的变更信息,接着每隔一段时间统计一次目标业务的执行结果以确定执行成功率,并在第一日志中每隔一段时间打印一次目标业务的执行成功率。[0045] 在一个实施例中,第一应用根据目标业务的执行结果,确定第二应用变更之后目标业务的执行成功率,具体为:第一应用根据目标业务的执行结果与预先设定的执行结果与业务执行码之间的对应关系,生成与目标业务的执行结果相对应的业务执行码,业务执行码用于表示目标业务的执行结果;第一应用对业务执行码进行统计分析,确定第二应用变更之后目标业务的执行成功率,第一日志中还记载有业务执行码。[0046] 具体而言,预先设置有目标业务的执行结果与业务执行码之间的对应关系,比如,执行成功对应业务执行码“1”,执行失败对应业务执行码“0”,第一应用根据目标业务的执行结果和该对应关系,生成与目标业务的执行结果相对应的业务执行码,对多次执行目标业务后得到的多个业务执行码进行统计分析,得到第二应用变更之后目标业务的执行成功率。第一应用还可以把每次执行目标业务后得到的每个业务执行码打印到第一日志中,以通过第一日志表示每次执行目标业务后的执行结果。[0047] 在一个例子中,第一应用在第二应用变更之后,首先在第一日志中打印第二应用的变更信息,接着在每次执行目标业务后,将执行结果相对应的业务执行码打印到第一日志中,并且每隔一段时间统计一次目标业务的执行结果以确定执行成功率,并在第一日志中每隔一段时间打印一次目标业务的执行成功率。[0048] 可见,通过本实施例,第一应用可以通过打印第一日志的方式,在第一日志中打印第二应用的变更信息和第二应用变更之后目标业务的执行成功率,开发人员通过分析第一日志即可确定第二应用的变更信息与第二应用变更之后目标业务的执行成功率之间的关联关系,该关联关系包括第二应用变更之后,目标业务的执行成功率提高,或者,第二应用变更之后,目标业务的执行成功率降低。并且,还可以在第一日志中打印每次执行目标业务后与执行结果相对应的业务执行码,从而丰富第一日志的内容,使得开发人员从第一日志中得到更多的有关于业务执行情况的内容。并且,第一应用将目标业务的执行结果转变为业务执行码,再统计业务执行码得到目标业务的执行成功率,可以提高统计执行成功率的效率。[0049] 在另一个实施例中,第一应用根据目标业务的执行结果,确定第二应用的变更信息与目标业务的执行成功率之间的关联关系,具体为:第一应用输出记载有目标业务的执行结果和第二应用的变更信息的第二日志给监控平台,监控平台用于根据目标业务的执行结果,确定第二应用变更之后目标业务的执行成功率。第二日志用于表示第二应用的变更信息与第二应用变更之后目标业务的执行成功率之间的关联关系。[0050] 本实施例中,第一应用直接将每次执行目标业务后,目标业务的执行结果和第二应用的变更信息打印到第二日志中,第二日志通过业务运维中间件生成,第二日志被监控平台获取后,监控平台根据多次执行目标业务后目标业务的执行结果确定目标业务的执行成功率并打印到第二日志中,从而监控平台确定第二应用的变更信息与第二应用变更之后目标业务的执行成功率之间的关联关系。[0051] 在一个例子中,第一应用在第二应用变更之后,首先在第二日志中打印第二应用的变更信息,接着在每次执行目标业务后,将执行结果打印到第二日志中,监控平台根据多次执行目标业务后目标业务的执行结果确定目标业务的执行成功率并打印到第二日志中,从而第二日志表示第二应用的变更信息与第二应用变更之后目标业务的执行成功率之间的关联关系。[0052] 可见,通过本实施例,第一应用无需统计目标业务的执行成功率,由监控平台统计目标业务的执行成功率并打印到第二日志中,开发人员通过分析第二日志即可确定第二应用的变更信息与第二应用变更之后目标业务的执行成功率之间的关联关系,该关联关系包括第二应用变更之后,目标业务的执行成功率提高,或者,第二应用变更之后,目标业务的执行成功率降低。[0053] 在另一个实施例中,第一应用根据目标业务的执行结果,确定第二应用的变更信息与目标业务的执行成功率之间的关联关系,具体为:第一应用根据目标业务的执行结果与预先设定的执行结果与业务执行码之间的对应关系,生成与目标业务的执行结果相对应的业务执行码。业务执行码用于表示执行结果。第一应用输出记载有业务执行码和第二应用的变更信息的第三日志给监控平台;监控平台用于根据业务执行码,确定第二应用变更之后目标业务的执行成功率。第三日志用于表示第二应用的变更信息与第二应用变更之后目标业务的执行成功率之间的关联关系。[0054] 具体而言,预先设置有目标业务的执行结果与业务执行码之间的对应关系,比如,执行成功对应业务执行码“1”,执行失败对应业务执行码“0”,第一应用在每次执行目标业务后,根据目标业务的执行结果和该对应关系,生成与目标业务的执行结果相对应的业务执行码,并将第二应用的变更信息和多次执行目标业务后得到的业务执行码打印到第三日志中。第三日志被监控平台获取后,监控平台对多次执行目标业务后得到的多个业务执行码进行统计分析,得到第二应用变更之后目标业务的执行成功率,并将该执行成功率也打印到第三日志中,第三日志通过业务运维中间件生成,从而第三日志用于表示第二应用的变更信息与第二应用变更之后目标业务的执行成功率之间的关联关系。[0055] 在一个例子中,第一应用在第二应用变更之后,首先在第三日志中打印第二应用的变更信息,接着在每次执行目标业务后,确定执行结果对应的业务执行码,将业务执行码打印到第三日志中,监控平台根据多次执行目标业务后目标业务的业务执行码确定目标业务的执行成功率并打印到第三日志中。[0056] 可见,通过本实施例,第一应用无需统计目标业务的执行成功率,由监控平台统计目标业务的执行成功率并打印到第三日志中,开发人员通过分析第三日志即可确定第二应用的变更信息与第二应用变更之后目标业务的执行成功率之间的关联关系,该关联关系包括第二应用变更之后,目标业务的执行成功率提高,或者,第二应用变更之后,目标业务的执行成功率降低。[0057] 在又一个实施例中,第一应用根据目标业务的执行结果,确定第二应用的变更信息与目标业务的执行成功率之间的关联关系,具体为:第一应用基于目标业务的执行结果,确定第二应用变更之后目标业务的执行成功率,第一应用获取第二应用变更之前目标业务的执行成功率,第一应用对第二应用变更之后目标业务的执行成功率和第二应用变更之前目标业务的执行成功率进行比对分析,以确定第二应用的变更信息与目标业务的执行成功率之间的关联关系。[0058] 具体而言,第一应用在第二应用变更之后,对多次执行目标业务后目标业务的执行结果进行统计分析,得到第二应用变更之后目标业务的执行成功率。第一应用还可以获取第二应用变更之前目标业务的执行成功率,接着,将第二应用变更之后目标业务的执行成功率和第二应用变更之前目标业务的执行成功率进行比对分析,以确定第二应用的变更信息与目标业务的执行成功率之间的关联关系,该关联关系包括第二应用变更之后,目标业务的执行成功率提高,或者,第二应用变更之后,目标业务的执行成功率降低。[0059] 第一应用获取第二应用变更之前目标业务的执行成功率的过程具体为:通过业务运维中间件输出日志并在日志中打印第二应用的应用标识,在第二应用变更之前,统计目标业务的执行成功率并打印在日志上。[0060] 可见,通过本实施例,可以将第二应用变更之后目标业务的执行成功率和第二应用变更之前目标业务的执行成功率进行比对分析,以确定第二应用的变更信息与目标业务的执行成功率之间的关联关系,帮助开发人员判断是否需要对第二应用的变更进行调整。[0061] 在一个实施例中,在第一应用确定待监控的目标业务之后,上述方法流程还包括:第一应用获取目标业务的业务信息,基于应用调用链路上的各个应用之间的调用关系,将目标业务的业务信息透传至应用调用链路上的各个应用;目标业务的业务信息用于应用调用链路上的各个应用生成执行标业务的执行日志;执行日志用于恢复目标业务的执行过程。[0062] 首先,第一应用获取目标业务的业务信息,比如获取目标业务的业务标识,然后,通过业务运维中间件,基于应用调用链路上的各个应用之间的调用关系,将目标业务的业务信息透传至应用调用链路上的各个应用。由于目标业务是需要应用调用链路上的各个应用共同执行完成的业务,因此应用调用链路上的各个应用可以基于目标业务的业务标识,生成执行目标业务的执行日志,应用调用链路上的每个应用生成的目标业务的执行日志,可以用于恢复目标业务的执行过程。[0063] 比如,应用1调用应用2,应用2调用应用3,目标业务为获取用户的账户余额的业务,应用1、2、3根据目标业务的业务标识,生成各自执行目标业务的执行日志,应用1的执行日志用于记录获取用户的账户余额查询请求并传输给应用2的过程,应用2的执行日志用于记录应用2将用户的账户余额查询请求传输给应用3的过程,应用3的执行日志用于记录从数据库查找账户余额的过程。通过应用1、2、3的执行日志,可以恢复完整的目标业务的执行过程。[0064] 需要说明的是,第一应用可以在第二应用变更之前透传目标业务的业务信息,也可以在第二应用变更之后透传目标业务的业务信息。若在第二应用变更之前透传,则每个应用记录第二应用变更之前的目标业务的执行日志,可以恢复得到第二应用变更之前的目标业务的执行过程,并且,透传的业务信息在第二应用变更之后也生效,因此若第二应用发生变更,则每个应用也记录第二应用变更之后的目标业务的执行日志,从而得到第二应用变更之后的目标业务的执行过程。若在第二应用变更之后透传,则每个应用记录第二应用变更之后的目标业务的执行日志,从而得到第二应用变更之后的目标业务的执行过程,但是无法得到第二应用变更之前的目标业务的执行日志和执行过程。具体选择在第二应用变更之前透传标业务的业务信息还是在第二应用变更之后透传目标业务的业务信息,可以根据需求确定。[0065] 可见,通过本实施例,能够基于应用调用链路上的各个应用之间的调用关系,恢复目标业务的完整的执行过程,从而帮助开发人员分析目标业务的执行过程。[0066] 在一个实施例中,应用调用链路上的各个应用都安装有业务运维中间件,在一些实施例中,所述的运维中间件是ServerlessSDK。ServerlessSDK是能够作用于应用近端,具有对业务流量进行染色、统计、定位、应急等能力的中间件。[0067] ServerlessSDK的sofa框架提供有baggage字段,baggage字段的内容可以由开发人员进行编辑。在一些实施例中,baggage字段具有透传,染色的功能。在一些实施例中,第二应用可以将需要透传的第二应用的变更信息和变更后的第二应用执行目标业务的中间结果数据写在baggage字段中,通过RPC(RemoteProcedureCall,远程过程调用)的方式,将baggage字段从第二应用开始经过应用调用链路上的各个应用透传到第一应用。在本实施例中,第一应用也可以将目标业务的业务信息写到baggage字段,再通过RPC调用的方式,将baggage字段从第一应用开始经过应用调用链路上的各个应用透传到第二应用。[0068] 为了便于通过baggage字段在应用调用链路上实现信息的上下透传,可以通过调整格式的方式设置需要透传的信息的长度为统一长度,从而使得在baggage字段中始终写入长度统一的信息,方便实现信息的上下透传。其中,需要透传的信息包括但不限于第二应用的变更信息、变更后的第二应用执行目标业务的中间结果数据、目标业务的业务信息等。本领域的技术人员也可以通过其他具有染色功能的中间件及其字段实现上述功能,此处不再赘述。[0069] 综上,通过以上的方法流程,能够在最底层应用发生变更后,确定待监控的目标业务的执行成功率与应用变更信息之间的关联关系,从而量化性的评估底层应用变更对业务的影响,帮助开发人员及时优化底层应用的变更。[0070] 上述方法流程从第一应用的角度出发进行介绍,图3为本说明书另一实施例提供的应用变更处理方法的流程示意图,该方法流程由第二应用执行,在硬件方面可以理解为由提供第二应用的第二应用服务器执行,如图3所示,该方法流程包括:[0071] 步骤S302,在应用调用链路上的第二应用变更之后,变更后的第二应用获取第二应用的待透传的变更信息和变更后的第二应用执行目标业务的中间结果数据;[0072] 步骤S304,变更后的第二应用基于应用调用链路上的各个应用之间的调用关系,向应用调用链路上的第一应用透传第二应用的所述变更信息和中间结果数据;[0073] 其中,第二应用为应用调用链路上的最底层应用;第一应用为应用调用链路上的最顶层应用;目标业务为第一应用基于应用调用链路所能够提供的业务;中间结果数据用于第一应用确定目标业务的执行结果,并根据执行结果,确定第二应用的变更信息与目标业务的执行成功率之间的关联关系。[0074] 上述步骤S302和步骤S304的具体过程,可以参考前面针对图2中的方法流程的描述。需要说明的是,第二应用的变更信息包括但不限于第二应用的应用标识和第二应用的具体变更内容中的一项或多项。第二应用的具体变更内容包括但不限于第二应用所变更的代码片段的片段标识,变更前的代码和变更后的代码。在一个实施例中,在第二应用变更之后,变更后的第二应用获取变更信息并透传到第一应用,当然,在其他实施例中,第二应用也可以在变更之前获取变更信息并透传到第一应用。第一应用接收到第二应用透传过来的变更信息之后,即可通过业务运维中间件生成日志并将变更信息打印到日志中,并开始统计目标业务的执行成功率。因此,若第二应用在变更之前将变更信息透传到第一应用,则第一应用会在第二应用变更之前,统计变更前的目标业务的执行成功率,当第二应用发生变更后,也会继续统计变更后的目标业务的执行成功率。若在第二应用在变更之后将变更信息透传到第一应用,则第一应用会在第二应用变更之后,统计变更后的目标业务的执行成功率,无法统计变更前的目标业务的执行成功率。[0075] 在一个实施例中,在图3的方法流程中,在第二应用变更之前,第二应用获取业务运维平台上报的第二应用的变更标记;业务运维平台基于从变更平台处获取的第二应用的变更通知消息生成第二应用的变更标记;在第二应用变更之后,变更后的第二应用获取第二应用的待透传的变更信息之前,变更后的第二应用将第二应用的变更标记作为第二应用的待透传的变更信息。当然,也可以在第二应用变更之前,将第二应用的变更标记作为第二应用的待透传的变更信息并透传给第一应用。[0076] 具体而言,在第二应用变更之前,变更平台生成第二应用的变更通知消息,并将该消息发送至业务运维平台,业务运维平台根据第二应用的变更通知消息,生成第二应用的变更标记,并将第二应用的变更标记发送至第二应用中的业务运维中间件。第二应用中的业务运维中间件接收到第二应用的变更标记,在第二应用变更之后或者变更之前,将第二应用的变更标记作为第二应用的待透传的变更信息。因此,第二应用的变更标记的内容与第二应用的变更消息的内容相同。[0077] 在一个实施例中,在图3的方法流程中,在第二应用变更之前,第二应用基于应用调用链路上的各个应用之间的调用关系,获取第一应用透传过来的目标业务的业务信息,在第二应用变更之后,第二应用基于目标业务的业务信息,生成执行目标业务的执行日志;执行日志用于恢复目标业务的执行过程。[0078] 如前所述,第一应用可以在第二应用变更之前透传目标业务的业务信息,也可以在第二应用变更之后透传目标业务的业务信息。若在第二应用变更之前透传业务信息,则第二应用在变更之前就向上透传目标业务的执行日志,若在第二应用变更之后透传业务信息,则第二应用变更之后,第二应用基于目标业务的业务信息,生成执行目标业务的执行日志并向上透传。每个应用都可以在接收到业务信息后向上透传目标业务的执行日志,以便于第一应用根据各个应用透传的日志,恢复目标业务的执行过程。[0079] 在一个实施例中,在图3的流程中,在第二应用变更完成预设时长之后,变更后的第二应用基于应用调用链路上的各个应用之间的调用关系,向第一应用透传操作取消消息;操作取消消息用于第一应用取消执行确定第二应用的变更信息与目标业务的执行成功率之间的关联关系的操作。[0080] 具体而言,在第二应用变更完一定时长如一周后,变更后的第二应用基于应用调用链路上的各个应用之间的调用关系,向第一应用透传操作取消消息,第一应用接收到操作取消消息之后,取消执行确定第二应用的变更信息与目标业务的执行成功率之间的关联关系的操作,不再统计目标业务的执行成功率。[0081] 由于第二应用变更完一定时长后,根据这一定时长内的目标业务的执行结果,已经确定得到第二应用的变更信息与目标业务的执行成功率之间的关联关系,因此第二应用通过向上透传操作取消消息的方式通知第一应用无需再确定上述的关联关系。[0082] 在一个实施例中,在变更后的第二应用基于应用调用链路上的各个应用之间的调用关系,向第一应用透传操作取消消息之前,在第二应用变更完成预设时长之后,变更后的第二应用获取业务运维平台上报的上述的操作取消消息;业务运维平台基于从变更平台处获取的第二应用的变更完成通知消息生成操作取消消息。[0083] 具体而言,在第二应用变更完一定时长之后,变更平台生成第二应用的变更完成通知消息并发送至业务运维平台,业务运维平台根据该变更完成通知消息生成操作取消消息,并将操作取消消息发送至第二应用,由第二应用中的业务运维中间件接收。[0084] 综上,通过以上图3中的方法流程,能够在最底层应用发生变更后,向上透传第二应用的变更信息和目标业务的中间结果数据,以确定待监控的目标业务的执行成功率与应用变更信息之间的关联关系,从而量化性的评估底层应用变更对业务的影响,帮助开发人员及时优化底层应用的变更。[0085] 前面提到了变更平台、业务运维平台、监控平台和应用调用链路上的各个应用,并且提到了以下几个透传有关的数据流:[0086] 1、在第二应用变更之后向上透传第二应用执行目标业务的中间结果数据的过程:在第二应用变更之后,第二应用基于应用调用链路上的各个应用之间的调用关系,向第一应用透传第二应用执行目标业务的中间结果数据;[0087] 2、在第二应用变更之后向上透传操作取消消息的过程:在第二应用变更完一定时长之后,变更平台生成第二应用的变更完成通知消息并发送至业务运维平台,业务运维平台根据该变更完成通知消息生成操作取消消息,并将操作取消消息发送至第二应用,由第二应用中的业务运维中间件接收,第二应用基于应用调用链路上的各个应用之间的调用关系,向第一应用透传将操作取消消息;[0088] 3、在第二应用变更之前或者变更之后,向上透传第二应用的变更信息的过程:变更平台生成第二应用的变更通知消息,并将该消息发送至业务运维平台,业务运维平台根据第二应用的变更通知消息,生成第二应用的变更标记,并将第二应用的变更标记发送至第二应用中的业务运维中间件。第二应用中的业务运维中间件接收到第二应用的变更标记,在第二应用变更之前或者变更之后,将第二应用的变更标记作为第二应用的变更信息透传到第一应用;[0089] 4、在第二应用变更之前或者变更之后,向下透传第一应用的目标业务的业务信息的过程:在第二应用变更之前或者变更之后,第一应用获取目标业务的业务信息,基于应用调用链路上的各个应用之间的调用关系,将目标业务的业务信息透传至应用调用链路上的各个应用,使各个应用生成执行目标业务的执行日志以便于恢复目标业务的执行过程。[0090] 下面结合附图更加详细的说明应用变更处理方法和以上的几种数据流。[0091] 图4为本说明书一实施例提供的向上透传第二应用的变更信息和向下透传第一应用的目标业务的业务信息的场景示意图,如图4所示,以应用调用链路包括应用1‑应用4共4个应用为例进行说明。应用1为最顶层应用,应用4为最底层应用,应用1和应用4分别与业务运维平台连接,业务运维平台与变更平台连接。应用1‑应用4中的每个应用都安装有业务运维中间件。[0092] 在应用4变更之前或者变更之后,变更平台生成应用4的变更通知消息,并将该消息发送至业务运维平台,业务运维平台根据应用4的变更通知消息,生成应用4的变更标记,并将应用4的变更标记发送至应用4中的业务运维中间件,应用4中的业务运维中间件接收到应用4的变更标记,在应用4变更之前或者变更之后,将应用4的变更标记作为应用4的变更信息透传到应用1。[0093] 在应用4变更之前或者变更之后,应用1获取业务运维平台发送的目标业务的业务信息,基于应用调用链路上的各个应用之间的调用关系,将目标业务的业务信息透传至应用调用链路上的各个应用,使各个应用生成执行目标业务的执行日志以便于恢复目标业务的执行过程。在图4中,开发人员预先在业务运维平台定义业务定义信息,该业务定义信息可以是上述的业务信息,业务运维平台将定义好的目标业务的业务信息发送至应用1。[0094] 图5为本说明书一实施例提供的业务运维平台、变更平台和监控平台的功能示意图,如图5所示,业务运维平台可以供开发人员定义目标业务的业务信息,也即定义图1中的业务定义信息,并在第二应用变更前或者变更后,将目标业务的业务信息向下透传至应用调用链路上的每个应用。[0095] 在第二应用变更前或者变更后,变更平台可以向业务运维平台发送第二应用的变更通知消息,业务运维平台基于该变更通知消息,生成第二应用的变更标记并发送至第二应用,第二应用在变更前或者变更后,将第二应用的变更标记作为第二应用的变更信息透传到第一应用。[0096] 在第二应用变更过程中,监控平台可以从第一应用处获取上述提到的第一日志、第二日志或者第三日志,以确定第二应用的变更信息与目标业务的执行成功率之间的关联关系,并在目标业务的执行成功率降低时发出报警。[0097] 在第二应用变更完一定时长之后,变更平台生成第二应用的变更完成通知消息并发送至业务运维平台,业务运维平台根据该变更完成通知消息生成操作取消消息,并将操作取消消息发送至第二应用,由第二应用中的业务运维中间件接收,第二应用基于应用调用链路上的各个应用之间的调用关系,向第一应用透传操作取消消息。[0098] 图6为本说明书另一实施例提供的应用变更处理方法的流程示意图,如图6所示,该流程中涉及第一应用、第二应用、业务运维平台、变更平台和监控平台,未示出第一应用和第二应用之间的各个应用,每个应用中都安装有业务运维中间件。如图6所示,该流程包括以下步骤:[0099] 1、在第二应用变更之前,开发人员在业务运维平台配置业务定义信息;[0100] 2、业务运维平台将业务定义信息发送给第一应用;[0101] 3、第一应用将业务定义信息作为目标业务的业务信息,在第二应用变更之前透传给应用调用链路上的每个应用;本步骤可以替换为,第一应用将目标业务的标识作为目标业务的业务信息,在第二应用变更之前透传给应用调用链路上的每个应用;[0102] 4、工作人员在变更平台配置第二应用的变更;[0103] 5、第二应用变更之前,变更平台根据工作人员的配置向业务运维平台发送变更通知消息;[0104] 6、业务运维平台根据变更通知消息生成变更标记并发送给第二应用;[0105] 7、第二应用将变更标记作为变更信息,在变更之前透传给应用调用链路上的第一应用;本步骤可以替换为,第二应用根据变更标记,生成变更信息,在变更之前透传给应用调用链路上的第一应用;[0106] 8、第二应用变更之后,将目标业务的中间结果数据透传给第一应用;[0107] 9、第一应用根据中间结果数据,确定目标业务的执行结果,向监控平台输出第一日志或者第二日志或者第三日志,输出的日志用于表示第二应用的变更信息与目标业务的执行成功率之间的关联关系;[0108] 10、监控平台将日志传输给变更平台;[0109] 11、工作人员基于日志,判断是否停止第二应用的变更。[0110] 12、若工作人员不停止变更,则变更完成一段时间之后,变更平台生成变更完成通知消息并发送至业务运维平台;[0111] 13、业务运维平台根据变更完成通知消息生成操作取消消息并发送至第二应用;[0112] 14、第二应用向第一应用透传将操作取消消息。[0113] 综上,通过以上介绍方法流程,能够在最底层应用发生变更后,向上透传最底层应用的变更信息和目标业务的中间结果数据,并确定待监控的目标业务的执行成功率与应用变更信息之间的关联关系,从而量化性的评估底层应用变更对业务的影响,帮助开发人员及时优化底层应用的变更。[0114] 在一个实施例中,应用于第一应用侧的应用变更处理方法可以包括以下步骤:[0115] 第一应用确定待监控的目标业务;第一应用为应用调用链路上的最顶层应用;目标业务为第一应用基于应用调用链路所能够提供的业务;[0116] 在应用调用链路上的第二应用变更之后,第一应用获取变更后的第二应用透传上来的第二应用的变更信息和变更后的第二应用执行目标业务的中间结果数据;第二应用为应用调用链路上的最底层应用;[0117] 第一应用基于中间结果数据,确定第二应用的变更信息与目标业务的执行成功率之间的关联关系。[0118] 其中,确定待监控的目标业务,包括:获取业务定义信息,根据业务定义信息,确定待监控的目标业务。[0119] 其中,获取变更后的第二应用透传上来的第二应用的变更信息和变更后的第二应用执行目标业务的中间结果数据,包括:基于应用调用链路上的各个应用之间的调用关系,获取变更后的第二应用透传上来的第二应用的变更信息和变更后的第二应用执行目标业务的中间结果数据。[0120] 其中,基于中间结果数据,确定第二应用的变更信息与目标业务的执行成功率之间的关联关系,包括:基于中间结果数据,确定目标业务的执行结果,并根据执行结果,确定第二应用的变更信息与目标业务的执行成功率之间的关联关系。[0121] 在一个实施例中,应用于第二应用侧的应用变更处理方法可以包括以下步骤:[0122] 第二应用获取第二应用的变更信息和变更后的第二应用执行目标业务的中间结果数据;[0123] 第二应用向应用调用链路上的第一应用透传第二应用的变更信息和中间结果数据;[0124] 其中,第二应用为应用调用链路上的最底层应用;第一应用为应用调用链路上的最顶层应用;目标业务为第一应用基于应用调用链路所能够提供的业务;中间结果数据用于第一应用确定第二应用的变更信息与目标业务的执行成功率之间的关联关系。[0125] 其中,第二应用可以在变更之前或者变更之后获取第二应用的变更信息。[0126] 其中,第二应用可以在变更之前或者变更之后向应用调用链路上的第一应用透传第二应用的变更信息。[0127] 其中,第二应用在变更之后获取执行目标业务的中间结果数据并向应用调用链路上的第一应用透传中间结果数据。[0128] 其中,数据透传时基于应用调用链路上的各个应用之间的调用关系进行透传。[0129] 综上,已经对本主题的特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下,在权利要求书中记载的动作可以按照不同的顺序来执行并且仍然可以实现期望的结果。另外,在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序,以实现期望的结果。在某些实施方式中,多任务处理和并行处理可以是有利的。[0130] 以上为本说明书一个或多个实施例提供的应用变更处理方法,基于同样的思路,本说明书一个或多个实施例还提供一种应用变更处理装置。图7为本说明书一实施例提供的应用变更处理装置的结构示意图,如图7所示,该装置包括:[0131] 业务确定单元71,被配置为第一应用获取业务定义信息,根据所述业务定义信息,确定待监控的目标业务;所述第一应用为应用调用链路上的最顶层应用;所述目标业务为所述第一应用基于所述应用调用链路所能够提供的业务;[0132] 数据获取单元72,被配置为在所述应用调用链路上的第二应用变更之后,所述第一应用基于所述应用调用链路上的各个应用之间的调用关系,获取变更后的所述第二应用透传上来的所述第二应用的变更信息和变更后的所述第二应用执行所述目标业务的中间结果数据;所述第二应用为所述应用调用链路上的最底层应用;[0133] 结果确定单元73,被配置为所述第一应用基于所述中间结果数据,确定所述目标业务的执行结果,并根据所述执行结果,确定所述第二应用的变更信息与所述目标业务的执行成功率之间的关联关系。[0134] 可选地,业务确定单元71具体被配置为:所述第一应用获取工作人员通过业务运维平台上报的业务定义信息;所述业务定义信息中携带有待监控的业务接口的接口标识和待监控的方法的方法标识;所述待监控的方法从属于所述待监控的业务接口;所述第一应用根据所述待监控的业务接口的接口标识和所述待监控的方法的方法标识,将所述待监控的业务接口和所述待监控的方法所属的业务作为待监控的目标业务。[0135] 可选地,结果确定单元73具体被配置为:所述第一应用根据所述执行结果,确定所述第二应用变更之后所述目标业务的执行成功率,并输出记载有所述第二应用的变更信息和所述第二应用变更之后所述目标业务的执行成功率的第一日志;所述第一日志用于表示所述第二应用的变更信息与所述第二应用变更之后所述目标业务的执行成功率之间的关联关系。[0136] 可选地,结果确定单元73具体被配置为:所述第一应用根据所述执行结果与预先设定的执行结果与业务执行码之间的对应关系,生成与所述执行结果相对应的业务执行码;所述业务执行码用于表示所述执行结果;所述第一应用对所述业务执行码进行统计分析,确定所述第二应用变更之后所述目标业务的执行成功率;所述第一日志中还记载有所述业务执行码。[0137] 可选地,结果确定单元73具体被配置为:所述第一应用输出记载有所述执行结果和所述第二应用的变更信息的第二日志给监控平台;所述监控平台用于根据所述执行结果,确定所述第二应用变更之后所述目标业务的执行成功率;所述第二日志用于表示所述第二应用的变更信息与所述第二应用变更之后所述目标业务的执行成功率之间的关联关系。[0138] 可选地,结果确定单元73具体被配置为:所述第一应用根据所述执行结果与预先设定的执行结果与业务执行码之间的对应关系,生成与所述执行结果相对应的业务执行码;所述业务执行码用于表示所述执行结果;所述第一应用输出记载有所述业务执行码和所述第二应用的变更信息的第三日志给监控平台;所述监控平台用于根据所述业务执行码,确定所述第二应用变更之后所述目标业务的执行成功率;所述第三日志用于表示所述第二应用的变更信息与所述第二应用变更之后所述目标业务的执行成功率之间的关联关系。[0139] 可选地,结果确定单元73具体被配置为:所述第一应用基于所述执行结果,确定所述第二应用变更之后所述目标业务的执行成功率;所述第一应用获取所述第二应用变更之前所述目标业务的执行成功率;所述第一应用对所述第二应用变更之后所述目标业务的执行成功率和所述第二应用变更之前所述目标业务的执行成功率进行比对分析,以确定所述第二应用的变更信息与所述目标业务的执行成功率之间的关联关系。[0140] 可选地,还包括信息透传单元,被配置为第一应用确定待监控的目标业务之后,所述第一应用获取所述目标业务的业务信息,基于所述应用调用链路上的各个应用之间的调用关系,将所述目标业务的业务信息透传至所述应用调用链路上的各个应用;所述目标业务的业务信息用于使所述应用调用链路上的各个应用生成执行所述目标业务的执行日志;所述执行日志用于恢复所述目标业务的执行过程。[0141] 本实施例中的应用变更处理装置,能够实现前述的应用在第一应用侧的应用变更处理方法实施例的各个过程,并达到相同的效果和功能,这不再重复。[0142] 以上为本说明书一个或多个实施例提供的应用变更处理方法,基于同样的思路,本说明书一个或多个实施例还提供一种应用变更处理装置。图8为本说明书另一实施例提供的应用变更处理装置的结构示意图,如图8所示,该装置包括:[0143] 变更获取单元81,被配置为在应用调用链路上的第二应用变更之后,变更后的所述第二应用获取所述第二应用的待透传的变更信息和变更后的所述第二应用执行目标业务的中间结果数据;[0144] 数据透传单元82,被配置为变更后的所述第二应用基于所述应用调用链路上的各个应用之间的调用关系,向所述应用调用链路上的第一应用透传所述第二应用的所述变更信息和所述中间结果数据;[0145] 其中,所述第二应用为所述应用调用链路上的最底层应用;所述第一应用为应用调用链路上的最顶层应用;所述目标业务为所述第一应用基于所述应用调用链路所能够提供的业务;所述中间结果数据用于所述第一应用确定所述目标业务的执行结果,并根据所述执行结果,确定所述第二应用的所述变更信息与所述目标业务的执行成功率之间的关联关系。[0146] 可选地,还包括信息确定单元,被配置为:在所述第二应用变更之前,所述第二应用获取业务运维平台上报的所述第二应用的变更标记;所述业务运维平台基于从变更平台处获取的所述第二应用的变更通知消息生成所述第二应用的变更标记;在所述第二应用变更之后,变更后的所述第二应用获取所述第二应用的待透传的变更信息之前,变更后的所述第二应用将所述第二应用的变更标记作为所述第二应用的待透传的变更信息。[0147] 可选地,还包括日志透传单元,被配置为在所述第二应用变更之前,所述第二应用基于所述应用调用链路上的各个应用之间的调用关系,获取所述第一应用透传过来的所述目标业务的业务信息;在所述第二应用变更之后,所述第二应用基于所述目标业务的业务信息,生成执行所述目标业务的执行日志;所述执行日志用于恢复所述目标业务的执行过程。[0148] 可选地,还包括消息透传单元,被配置为在所述第二应用变更完成预设时长之后,变更后的所述第二应用基于所述应用调用链路上的各个应用之间的调用关系,向所述第一应用透传操作取消消息;所述操作取消消息用于所述第一应用取消执行确定所述第二应用的所述变更信息与所述目标业务的执行成功率之间的关联关系的操作。[0149] 可选地,还包括消息获取单元,被配置为在变更后的所述第二应用基于所述应用调用链路上的各个应用之间的调用关系,向所述第一应用透传操作取消消息之前,在所述第二应用变更完成预设时长之后,变更后的所述第二应用获取业务运维平台上报的所述操作取消消息;所述业务运维平台基于从变更平台处获取的所述第二应用的变更完成通知消息生成所述操作取消消息。[0150] 本实施例中的应用变更处理装置,能够实现前述的应用在第二应用侧的应用变更处理方法实施例的各个过程,并达到相同的效果和功能,这不再重复。[0151] 基于同样的思路,本说明书一个或多个实施例还提供一种应用变更处理设备,图9为本说明书一实施提供的应用变更处理设备的结构示意图,如图9所示,应用变更处理设备可因配置或性能不同而产生比较大的差异,可以包括一个或一个以上的处理器1201和存储器1202,存储器1202中可以存储有一个或一个以上存储应用程序或数据。其中,存储器1202可以是短暂存储或持久存储。存储在存储器1202的应用程序可以包括一个或一个以上模块(图示未示出),每个模块可以包括对应用变更处理设备中的一系列计算机可执行指令。更进一步地,处理器1201可以设置为与存储器1202通信,在应用变更处理设备上执行存储器1202中的一系列计算机可执行指令。应用变更处理设备还可以包括一个或一个以上电源1203,一个或一个以上有线或无线网络接口1204,一个或一个以上输入输出接口1205,一个或一个以上键盘1206。[0152] 在一个实施例中,应用变更处理设备包括有处理器;以及,被安排成存储计算机可执行指令的存储器,所述计算机可执行指令在被所述处理器执行时使所述处理器实现以下流程:[0153] 第一应用获取业务定义信息,根据所述业务定义信息,确定待监控的目标业务;所述第一应用为应用调用链路上的最顶层应用;所述目标业务为所述第一应用基于所述应用调用链路所能够提供的业务;[0154] 在所述应用调用链路上的第二应用变更之后,所述第一应用基于所述应用调用链路上的各个应用之间的调用关系,获取变更后的所述第二应用透传上来的所述第二应用的变更信息和变更后的所述第二应用执行所述目标业务的中间结果数据;所述第二应用为所述应用调用链路上的最底层应用;[0155] 所述第一应用基于所述中间结果数据,确定所述目标业务的执行结果,并根据所述执行结果,确定所述第二应用的变更信息与所述目标业务的执行成功率之间的关联关系。[0156] 本实施例中的应用变更处理设备,能够实现前述的应用于第一应用侧的应用变更处理方法实施例的各个过程,并达到相同的效果和功能,这不再重复。[0157] 在一个实施例中,应用变更处理设备包括有处理器;以及,被安排成存储计算机可执行指令的存储器,所述计算机可执行指令在被所述处理器执行时使所述处理器实现以下流程:[0158] 在应用调用链路上的第二应用变更之后,变更后的所述第二应用获取所述第二应用的待透传的变更信息和变更后的所述第二应用执行目标业务的中间结果数据;[0159] 变更后的所述第二应用基于所述应用调用链路上的各个应用之间的调用关系,向所述应用调用链路上的第一应用透传所述第二应用的所述变更信息和所述中间结果数据;[0160] 其中,所述第二应用为所述应用调用链路上的最底层应用;所述第一应用为应用调用链路上的最顶层应用;所述目标业务为所述第一应用基于所述应用调用链路所能够提供的业务;所述中间结果数据用于所述第一应用确定所述目标业务的执行结果,并根据所述执行结果,确定所述第二应用的所述变更信息与所述目标业务的执行成功率之间的关联关系。[0161] 本实施例中的应用变更处理设备,能够实现前述的应用于第二应用侧的应用变更处理方法实施例的各个过程,并达到相同的效果和功能,这不再重复。[0162] 本说明书一实施例还提供了一种存储介质,用于存储计算机可执行指令,所述计算机可执行指令在被处理器执行时使处理器实现以下流程:[0163] 第一应用获取业务定义信息,根据所述业务定义信息,确定待监控的目标业务;所述第一应用为应用调用链路上的最顶层应用;所述目标业务为所述第一应用基于所述应用调用链路所能够提供的业务;[0164] 在所述应用调用链路上的第二应用变更之后,所述第一应用基于所述应用调用链路上的各个应用之间的调用关系,获取变更后的所述第二应用透传上来的所述第二应用的变更信息和变更后的所述第二应用执行所述目标业务的中间结果数据;所述第二应用为所述应用调用链路上的最底层应用;[0165] 所述第一应用基于所述中间结果数据,确定所述目标业务的执行结果,并根据所述执行结果,确定所述第二应用的变更信息与所述目标业务的执行成功率之间的关联关系。[0166] 本实施例中的存储介质,能够实现前述的应用于第一应用侧的应用变更处理方法实施例的各个过程,并达到相同的效果和功能,这不再重复。[0167] 本说明书一实施例还提供了一种存储介质,用于存储计算机可执行指令,所述计算机可执行指令在被处理器执行时使处理器实现以下流程:[0168] 在应用调用链路上的第二应用变更之后,变更后的所述第二应用获取所述第二应用的待透传的变更信息和变更后的所述第二应用执行目标业务的中间结果数据;[0169] 变更后的所述第二应用基于所述应用调用链路上的各个应用之间的调用关系,向所述应用调用链路上的第一应用透传所述第二应用的所述变更信息和所述中间结果数据;[0170] 其中,所述第二应用为所述应用调用链路上的最底层应用;所述第一应用为应用调用链路上的最顶层应用;所述目标业务为所述第一应用基于所述应用调用链路所能够提供的业务;所述中间结果数据用于所述第一应用确定所述目标业务的执行结果,并根据所述执行结果,确定所述第二应用的所述变更信息与所述目标业务的执行成功率之间的关联关系。[0171] 本实施例中的存储介质,能够实现前述的应用于第二应用侧的应用变更处理方法实施例的各个过程,并达到相同的效果和功能,这不再重复。[0172] 上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下,在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外,在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中,多任务处理和并行处理也是可以的或者可能是有利的。[0173] 在20世纪90年代,对于一个技术的改进可以很明显地区分是硬件上的改进(例如,对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而,随着技术的发展,当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此,不能说一个方法流程的改进就不能用硬件实体模块来实现。例如,可编程逻辑器件(ProgrammableLogicDevice,PLD)(例如现场可编程门阵列(FieldProgrammableGateArray,FPGA))就是这样一种集成电路,其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片PLD上,而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且,如今,取代手工地制作集成电路芯片,这种编程也多半改用“逻辑编译器(logiccompiler)”软件来实现,它与程序开发撰写时所用的软件编译器相类似,而要编译之前的原始代码也得用特定的编程语言来撰写,此称之为硬件描述语言(HardwareDescriptionLanguage,HDL),而HDL也并非仅有一种,而是有许多种,如ABEL(AdvancedBooleanExpressionLanguage)、AHDL(AlteraHardwareDescriptionLanguage)、Confluence、CUPL(CornellUniversityProgrammingLanguage)、HDCal、JHDL(JavaHardwareDescriptionLanguage)、Lava、Lola、MyHDL、PALASM、RHDL(RubyHardwareDescriptionLanguage)等,目前最普遍使用的是VHDL(Very‑High‑SpeedIntegratedCircuitHardwareDescriptionLanguage)与Verilog。本领域技术人员也应该清楚,只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中,就可以很容易得到实现该逻辑方法流程的硬件电路。[0174] 控制器可以按任何适当的方式实现,例如,控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(ApplicationSpecificIntegratedCircuit,ASIC)、可编程逻辑控制器和嵌入微控制器的形式,控制器的例子包括但不限于以下微控制器:ARC625D、AtmelAT91SAM、MicrochipPIC18F26K20以及SiliconeLabsC8051F320,存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道,除了以纯计算机可读程序代码方式实现控制器以外,完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件,而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至,可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。[0175] 上述实施例阐明的系统、装置、模块或单元,具体可以由计算机芯片或实体实现,或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的,计算机例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。[0176] 为了描述的方便,描述以上装置时以功能分为各种单元分别描述。当然,在实施本说明书一个或多个时可以把各单元的功能在同一个或多个软件和/或硬件中实现。[0177] 本领域内的技术人员应明白,本说明书一个或多个的实施例可提供为方法、系统、或计算机程序产品。因此,本说明书一个或多个可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本说明书一个或多个可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD‑ROM、光学存储器等)上实施的计算机程序产品的形式。[0178] 本说明书一个或多个是参照根据本说明书一个或多个实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。[0179] 这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。[0180] 这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。[0181] 在一个典型的配置中,计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。[0182] 内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器(RAM)和/或非易失性内存等形式,如只读存储器(ROM)或闪存(flashRAM)。内存是计算机可读介质的示例。[0183] 计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD‑ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带,磁带磁盘存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括暂存电脑可读媒体(transitorymedia),如调制的数据信号和载波。[0184] 还需要说明的是,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。[0185] 本领域技术人员应明白,本说明书一个或多个的实施例可提供为方法、系统或计算机程序产品。因此,本说明书一个或多个可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且,本说明书一个或多个可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD‑ROM、光学存储器等)上实施的计算机程序产品的形式。[0186] 本说明书一个或多个可以在由计算机执行的计算机可执行指令的一般上下文中描述,例如程序模块。一般地,程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本说明书一个或多个,在这些分布式计算环境中,由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中,程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。[0187] 本说明书中的各个实施例均采用递进的方式描述,各个实施例之间相同相似的部分互相参见即可,每个实施例重点说明的都是与其他实施例的不同之处。尤其,对于系统实施例而言,由于其基本相似于方法实施例,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。[0188] 以上所述仅为本说明书一个或多个的实施例而已,并不用于限制本说明书一个或多个。对于本领域技术人员来说,本说明书一个或多个可以有各种更改和变化。凡在本说明书一个或多个的精神和原理之内所作的任何修改、等同替换、改进等,均应包含在本说明书一个或多个的权利要求范围之内。
专利地区:浙江
专利申请日期:2022-12-30
专利公开日期:2024-09-03
专利公告号:CN115904878B