基于SOA架构的系统调用方法及装置
技术领域
本申请涉及计算机应用领域,尤其涉及一种基于SOA架构的系统调用方法及装置。
背景技术
SOA(Service-Oriented Architecture,面向服务的体系结构)架构是一种通用的组件模型。在SOA架构中,可以将应用程序的不同功能单元(称为服务)组件化,通过这些组件之间定义的中立接口实现相互调用。其中,中立接口是指采用中立的方式进行定义的,可以独立于实现服务的硬件平台、操作系统和编程语言的接口,这使得SOA架构中的各组件之间,可以使用一种统一和通用的方式进行交互。
在相关技术中,通常可以利用SOA架构对应用程序的服务进行组件化的特性,来实现组件化的业务平台。在组件化的业务平台中,将包含若干组件化的业务系统,业务人员可以基于实际的业务需求,对构成业务平台的各组件化的业务系统进行分布式部署、组合和使用,确定调用路径,继而可以依次调用该调用路径上的各业务系统,来完成相应的业务流程。
然而,在传统的基于SOA架构的业务平台中,业务调用通常是针对调用路径上的业务系统的串行调用,因而当一次业务调用需要调用多个业务系统时,可能会影响业务平台的稳定性。
发明内容
本申请提出一种基于SOA架构的系统调用方法,所述SOA架构包含由若干旁路系统和若干核心系统构成的调用路径;所述方法应用于所述调用路径中的任一旁路系统,包括:
接收到所述调用路径中的核心系统发起的调用请求;
响应于所述核心系统发起的调用请求,生成对应于所述调用请求的调用凭据,并将该调用凭据返回至所述核心系统,以使所述核心系统继续向下游核心系统发起调用请求,并将该调用凭据传递至向下游核心系统;
在本地异步执行与所述调用请求对应的调用任务,并将该调用任务的执行结果与所述调用凭据的对应关系存储至预设缓存,以使所述调用路径中的末端核心系统基于传递至其本地的调用凭据从该预设缓存中读取对应的执行结果。
可选的,所述调用凭据为唯一标识所述调用请求的字符串;
其中,所述调用凭据包括与所述调用请求对应的调用接口和随机字符串组成的字符串。
可选的,所述将该调用任务的执行结果与所述调用凭据的对应关系存储至预设缓存,包括:
创建所述调用凭据与所述调用任务的执行结果之间的对应关系,并将该对应关系存储至预设缓存;
或者,将所述调用任务的执行结果返回至所述核心系统,以由所述核心系统创建所述调用凭据与所述调用任务的执行结果之间的对应关系,并将该对应关系存储至预设缓存。
本申请还提出一种基于SOA架构的系统调用方法,所述SOA架构包含由若干旁路系统和若干核心系统构成的调用路径;所述方法应用于所述调用路径中的任一核心系统,包括:
向所述调用路径中关联的旁路系统发起调用请求;
接收到所述旁路系统返回的对应于所述调用请求的调用凭据;
继续向下游核心系统发起调用请求,并将所述调用凭据传递至下游核心系统,以使所述调用路径中的末端核心系统基于传递至其本地的调用凭据,从预设缓存中读取与所述调用请求对应的调用任务的执行结果;
其中,所述预设缓存中存储了所述旁路系统在其本地异步执行与所述调用请求对应的调用任务得到的执行结果与所述调用凭据的对应关系。
可选的,当所述任一核心系统为所述调用路径中的末端核心系统,所述方法还包括:
所述任一核心系统基于传递至本地的调用凭据,从预设缓存中读取与所述调用请求对应的调用任务的执行结果。
本申请还提出一种基于SOA架构的系统调用装置,所述SOA架构包含由若干旁路系统和若干核心系统构成的调用路径;所述装置应用于所述调用路径中的任一旁路系统,包括:
第一接收模块,接收到所述调用路径中的核心系统发起的调用请求;
生成模块,响应于所述核心系统发起的调用请求,生成对应于所述调用请求的调用凭据,并将该调用凭据返回至所述核心系统,以使所述核心系统继续向下游核心系统发起调用请求,并将该调用凭据传递至向下游核心系统;
执行模块,在本地异步执行与所述调用请求对应的调用任务,并将该调用任务的执行结果与所述调用凭据的对应关系存储至预设缓存,以使所述调用路径中的末端核心系统基于传递至其本地的调用凭据从该预设缓存中读取对应的执行结果。
可选的,所述调用凭据为唯一标识所述调用请求的字符串;
其中,所述调用凭据包括与所述调用请求对应的调用接口和随机字符串组成的字符串。
可选的,所述执行模块具体:
创建所述调用凭据与所述调用任务的执行结果之间的对应关系,并将该对应关系存储至预设缓存;
或者,将所述调用任务的执行结果返回至所述核心系统,以由所述核心系统创建所述调用凭据与所述调用任务的执行结果之间的对应关系,并将该对应关系存储至预设缓存。
本申请还提出一种基于SOA架构的系统调用装置,所述SOA架构包含由若干旁路系统和若干核心系统构成的调用路径;所述装置应用于所述调用路径中的任一核心系统,包括:
发起模块,向所述调用路径中关联的旁路系统发起调用请求;
第二接收模块,接收到所述旁路系统返回的对应于所述调用请求的调用凭据;
所述发起模块,继续向下游核心系统发起调用请求,并将所述调用凭据传递至下游核心系统,以使所述调用路径中的末端核心系统基于传递至其本地的调用凭据,从预设缓存中读取与所述调用请求对应的调用任务的执行结果;
其中,所述预设缓存中存储了所述旁路系统在其本地异步执行与所述调用请求对应的调用任务得到的执行结果与所述调用凭据的对应关系。
可选的,当所述任一核心系统为所述调用路径中的末端核心系统,所述发起模块进一步:
基于传递至本地的调用凭据,从预设缓存中读取与所述调用请求对应的调用任务的执行结果。
本申请中,通过对SOA架构中的系统调用流程进行改进,当调用路径中的核心系统在针对调用路径中的旁路系统发起调用时,旁路系统可以生成调用凭据返回给核心系统,并异步执行对应的调用任务;核心系统收到旁落系统返回的调用凭据后,可以继续向下游的核心系统发起调用,并将该调用凭据传递至向下游核心系统,实现了在系统调用流程中,核心系统不再需要等待旁路系统返回相应的调用结果,就可以继续向下游核心系统发起调用,从而可以降低由于旁路系统调用超时而造成的调用失败的概率,提升业务平台的业务稳定性。
附图说明
图1是本申请一实施例示出的一种基于SOA架构的系统调用方法的流程图;
图2是本申请一实施例示出的相关技术中在基于SOA架构的支付业务平台中执行支付业务调用的处理流程图;
图3是本申请一实施例示出的一种基于SOA架构的支付业务平台中执行支付业务调用的处理流程图;
图4是本申请一实施例示出的一种基于SOA架构的系统调用装置的逻辑框图;
图5是本申请一实施例提供的承载所述一种基于SOA架构的系统调用装置的旁路系统的硬件结构图;
图6是本申请一实施例示出的另一种基于SOA架构的系统调用装置的逻辑框图;
图7是本申请一实施例提供的承载所述另一种基于SOA架构的系统调用装置的核心系统的硬件结构图。
具体实施方式
在相关技术中,通常可以利用SOA架构对应用程序的服务进行组件化的特性,来实现组件化的业务平台。在组件化的业务平台中,将包含若干组件化的业务系统,业务人员可以基于实际的业务需求,对构成业务平台的各组件化的业务系统进行分布式部署、组合和使用,确定调用路径,继而可以依次调用该调用路径上的各业务系统,来完成相应的业务流程。
例如,上述业务平台可以是基于SOA架构的支付业务平台,在该支付业务平台中可以包括收银系统、支付系统、安全验证系统、交易系统、额度验证系统、账务系统等业务系统,该支付业务平台可以根据需求确定调用路径,并在执行用户通过与支付业务平台对接的支付应用(APP)发起的支付业务流程时,可以按顺序依次调用该调用路径上的各业务系统,来完成相应的支付流程。
在基于SOA架构的业务平台中,其所包含的若干组件化的业务系统,都能够独立的设计缓存,来加快业务处理的速度。然而,在传统的基于SOA架构的业务系统中,业务调用通常是针对调用路径上的业务系统的串行调用,即需要被调用的业务系统将相应的调用任务执行完毕,并且返回相应的执行结果后,才会继续向该调用路径中的下游业务系统发起调用。
因而,在这种串行调用机制下,一旦调用路径中的某一被调用的业务系统调用超时,通常会直接向上游的调用发起方返回调用失败的结果,从而可能会影响业务平台的稳定性,造成调用失败率过高的问题;
例如,基于SOA架构的业务平台中的业务系统,通常包括核心系统和旁路系统,核心系统被上游核心系统调用后,会调用旁路系统执行相应的辅助业务流程,并在旁路系统在预设时长内成功返回了调用结果后,再接续向下游核心系统发起调用。由于旁路系统通常是一些比较耗时的业务系统,因此一旦旁路系统在预设时长内未成功向该核心系统返回调用结果(即调用超时),则该核心系统通常会向其上游的核心系统返回调用失败的消息,从而会造成业务平台不稳定,调用失败率过高的问题。
有鉴于此,本申请提出一种基于SOA架构的系统调用方法,通过对SOA架构中的系统调用流程进行改进,当调用路径中的核心系统在针对调用路径中的旁路系统发起调用时,旁路系统可以生成调用凭据返回给核心系统,并异步执行对应的调用任务;核心系统收到旁落系统返回的调用凭据后,可以继续向下游的核心系统发起调用,并将该调用凭据传递至向下游核心系统,实现了在系统调用流程中,核心系统不再需要等待旁路系统返回相应的调用结果,就可以继续向下游核心系统发起调用,从而可以降低由于旁路系统调用超时而造成的调用失败的概率,提升业务平台的业务稳定性。
下面通过具体实施例并结合具体的应用场景对本申请进行描述。
请参考图1,图1是本申请一实施例提供的基于SOA架构的系统调用方法,应用于基于SOA架构的业务平台,其中,所述SOA架构包含由若干旁路系统和若干核心系统构成的调用路径,所述调用路径中的任一核心系统,与其关联的旁路系统进行交互,执行以下步骤:
步骤101,核心系统向所述调用路径中关联的旁路系统发起调用请求;
步骤102,所述旁路系统响应于所述核心系统发起的调用请求,生成对应于所述调用请求的调用凭据,并将该调用凭据返回至所述核心系统;
步骤103,所述旁路系统在本地异步执行与所述调用请求对应的调用任务,并将该调用任务的执行结果与所述调用凭据的对应关系存储至预设缓存;
步骤104,所述核心系统接收到所述旁路系统返回的对应于所述调用请求的调用凭据,继续向下游核心系统发起调用请求,并将所述调用凭据传递至下游核心系统,以使所述调用路径中的末端核心系统基于传递至其本地的调用凭据,从所述预设缓存中读取与所述调用请求对应的调用任务的执行结果。
上述基于SOA架构的业务平台中的业务系统,通常可以包括核心系统和旁路系统。核心系统,对应于上述业务平台中的核心业务流程;而上述旁路系统,对应于上述业务平台中的辅助业务流程。
例如,在基于SOA架构的支付业务平台中,通常可以包括收银系统、支付系统、安全验证系统、交易系统、额度验证系统、账务系统等业务系统。以上示出的收银系统、支付系统、交易系统、账务系统,分别对应于支付业务中的收银、支付、交易以及登账等核心业务环节,因而收银系统、支付系统、账务系统为上述支付业务平台中的核心系统;而上述安全验证系统通常用于配合支付系统的业务流程,在支付系统执行支付流程时,对支付流程的发起方进行相应的安全验证以及对支付环境进行安全检查,因而安全验证系统为与上述支付系统关联的旁路系统;上述额度验证系统通常用于配合交易系统的业务流程,在交易系统执行交易流程时,对支付流程的发起方进行相应的额度检查,因而额度验证系统为与上述交易系统关联的旁路系统。
在实际应用中,业务人员可以基于实际的业务需求,对上述业务平台中的各组件化的业务系统进行分布式部署、组合和使用,对上述业务平台中各业务系统的调用顺序进行定制,以确定出一个业务系统的调用路径,继而业务平台可以依次调用该调用路径上的各业务系统,来完成相应的业务流程。
例如,仍以基于SOA架构的支付业务平台为例,由于一次完整的支付操作,通常需要按顺序执行“收银1-支付2-安全检查3-交易4-额度检查5-登账6”等支付环节,因此业务人员可以基于上述支付需求,基于上述支付业务平台中的各业务系统确定出一条“收银系统1-支付系统2-安全验证系统3-交易系统4-额度验证系统5-账务系统6”的调用路径,上述支付业务平台在响应用户通过支付应用发起的支付流程时,可以按照上述调用路径指示的调用顺序,依次调用以上示出的各业务系统,来完成该支付流程。
其中,需要说明的是,上述基于SOA架构的业务平台的硬件架构,具体可以是一服务器集群或者基于服务器集群构建的云平台,上述业务平台中的各业务系统,可以分别对应上述服务器集群或者基于服务器集群构建的云平台中的一物理服务器。
在本例中,为了提升上述业务平台的系统稳定性,可以对基于SOA架构的业务平台(以下简称业务平台)传统的串行调用机制进行改进,调用路径中的核心系统仍然采用同步的执行调用任务的机制,而调用路径中的旁路系统将不再同步的执行调用任务,而是采用一种异步执行调用任务的机制。
当核心系统在调用关联的旁路系统时,旁路系统可以实时的生成调用凭据返回给核心系统,并在本地异步的执行调用任务;核心系统在收到旁路系统返回的调用凭据后,可以不再需要等待旁路系统返回相应的调用结果,就可以继续向下游核心系统发起调用,从而可以降低由于旁路系统调用超时而造成的调用失败的概率,提升业务平台的稳定性。
其中,上述业务平台中各系统之间的调用方式,在本例中不进行特别限定;例如,在实际应用中,业务系统之间的调用可以是基于RPC(Remote Procedure Call Protocol,远程过程调用协议)的调用、也可以是基于web service的调用,或者也可以通过交互http消息来完成调用,在本例中不再进行一一列举,本领域技术人员在将本例中的技术方案付诸实现时,可以参考相关技术中的记载。
在本例中,用户可以通过与上述业务平台对接的业务应用发起相应的业务流程(比如用户可以通过支付APP向支付业务平台发起一笔支付交易),而上述业务平台在响应用户发起的业务流程时,可以基于业务人员确定的调用路径,按顺序依次执行该调用路径中的各业务系统,来完成整个的业务流程。
当上述调用中的任一业务核心系统,被上游核心系统调用后,如果该核心系统存在关联的旁路系统,则该核心系统可以调用该旁路系统,向旁路系统发起调用请求。当然,如果该核心系统不存在关联的旁路系统,那么可以继续调用该调用路径上的下游核心系统即可。
当旁路系统接收到核心系统发起的调用请求后:
一方面,可以立即响应该调用请求,实时的生成一个调用凭据,返回给该核心系统。
另一方面,该旁路系统可以在其本地异步执行与上述调用请求对应的调用任务,并在该调用任务执行完成后,将该调用任务的执行结果与生成的上述调用凭据的对应关系,存储至预设的缓存中。例如,可以将该调用凭据作为查询索引,保存与上述执行结果的对应关系,然后将该对应关系存储至上述预设的缓存中。
当然,在实际应用中,上述旁路系统也可以将上述执行结果返回给关联的核心系统,由该核心系统在其本地创建上述执行结果与上述调用凭据的对应关系,然后由该核心系统将该对应关系存执至上述预设的缓存中。
其中,在示出的一种实施方式中,上述调用凭据可以是一个能够唯一标识上述调用请求的字符串。
例如,在一种实现方式中,上述旁路系统在接收到核心系统发起的调用请求后,可以基于该调用请求获取对应的调用接口,然后基于一定的随机算法随机生成一个随机字符串,然后将调用接口和生成的该随机字符串进一步进行组合,生成一个字符串。此时生成的该字符串,则可以是与上述调用请求对应的调用接口和生成的上述随机字符串组成的一个可以唯一标识上述调用请求的字符串。当然,在实际应用中,上述调用凭据也可以采用其它形式的字符串,其原则上能够唯一标识上述调用请求即可,在本例中不再一一列举。
上述预设的缓存,具体可以是一上述调用路径中各业务系统均能够访问到的存储设备;例如,可以是一个上述调用路径中各业务系统均能够访问到的存储服务器。
在本例中,当上述核心系统接收到关联的旁路系统返回的调用凭据后,由于旁路系统将在其本地异步执行与上述调用请求对应的调用任务,在这种情况下,该核心系统可以不再需要等待该旁路系统返回对应的调用结果,而是继续向上述调用路径中的下游核心系统发起调用请求,并将上述调用凭据也一并传递至下游核心系统。
其中,该核心系统在向下游核心系统传递该调用凭据时,该调用凭据可以携带在上述调用请求中,一并传递给下游核心系统,也可以通过创建独立的请求消息传递至下游核心系统,在本例中不进行特别限定。
当该核心系统向上述调用路径中的下游核心系统发起调用请求后,该下游核心系统在收到该调用请求后,如果该下游核心系统同样存在关联的旁路系统,此时可以重复以上示出的调用过程,对旁路系统发起调用请求,并在接收到该旁路系统返回的调用凭据后,继续向上述调用路径中的下游的核心系统发起调用请求,以及将该调用凭据继续向下游核心系统传递,直到上述调用路径中的各业务系统均调用完成,不再赘述。
在本例中,当上述调用路径中的各业务系统均调用完成后,此时上述调用路径中最末端的核心系统,可以调用上述预设的缓存对应的存储设备,基于传递至其本地的调用凭据,从该存储设备中读取与该调用凭据对应的被调用任务的执行结果。
其中,如果上述调用路径中的多个核心系统均存在关联的旁路系统,此时上述调用路径中最末端的核心系统,将会收到传递至其本地的多个调用凭据;在这种情况下,为了降低调用上述存储设备的次数,该最末端的核心系统,可以基于该多个调用凭据,通过启用多线程的方式,并发的调用上述存储设备,从存储设备上读取与该多个调用凭据对应的被调用任务的执行结果。
在本例中,当上述调用路径中最末端的核心系统,通过调用与上述预设的缓存对应的存储设备,分别读取到了与传递至其本地的调用凭据对应的被调用任务的执行结果后,此时与上述调用路径对应的完整的业务流程执行完毕。
在这种情况下,上述最末端的核心系统可以基于读取到的执行结果,来确认与上述调用路径对应的业务流程,是否执行成功;如果执行成功,可以向与上述业务平台对接的业务应用返回执行成功的通知消息;如果执行失败,可以向上述业务应用返回执行失败的通知消息。
通过以上例子可见,在本例中,通过对基于SOA架构的业务平台传统的串行调用机制进行改进,调用路径中的旁路系统可以异步的执行调用任务,并在接收到核心系统返回的调用凭据后,继续向下游核心系统发起调用请求,而不再需要等待旁路系统返回的调用结果,从而可以实现调用路径中的核心系统和旁路系统,并发的执行业务流程,可以提升整个业务平台业务调用的处理速度,以及系统稳定性。
以下结合具体的应用场景对以上实施例中的技术方案进行详述。
在本例中,将以上述基于SOA架构的业务平台为基于SOA架构的支付业务平台为例进行说明。
其中,以上述基于SOA架构的业务平台为基于SOA架构的支付业务平台为例,仅为示例性的,在实际应用中,上述基于SOA架构的业务平台显然也可以是其它类型的基于SOA架构的业务平台,在本例中不再进行一一详述。
请参见图2,图2为相关技术中在基于SOA架构的支付业务平台中执行支付业务调用的处理流程图。
在如图2所示出的支付平台中,支付业务的调用路径为:
收银系统1-支付系统2-安全验证系统3-交易系统4-额度验证系统5-账务系统6;其中,收银系统、支付系统、账务系统为上述调用路径上的核心系统;安全验证系统为与支付系统关联的旁路系统,用于在支付系统被调用时,响应支付系统的调用,对支付发起方进行安全验证以及对支付环境进行安全检查;额度验证系统为与交易系统关联的旁路系统,用于在交易系统被调用时,响应支付系统的调用,对支付发起方进行额度检查。
在相关技术中,业务平台可以响应用户通过支付APP发起的支付流程,按照上述调用路径中的调用顺序,依次串行调用以上示出的各业务系统,来完成一次支付流程。
对于支付系统而言,当接收到上游的收银系统发起的调用后,可以继续调用安全验证系统,由安全验证系统执行对应的安全验证任务,对支付的发起方进行安全验证,以及对支付环境进行安全检查,并在完全验证完毕后,向支付系统返回执行结果。在这种情况下,支付系统只有在收到安全验证系统返回的执行结果,并在该执行结果指示支付发起方通过安全验证时,才能够继续向下游的交易系统发起调用。
相似的,当交易系统接收到上游的支付系统发起的调用后,可以继续调用额度验证系统,由额度验证系统执行对应的额度验证任务,对支付的发起方进行额度检查,并在额度检查完毕后,向交易系统返回执行结果。在这种情况下,交易系统只有在收到安全验证系统返回的执行结果后,并在该执行结果指示支付发起方通过额度检查,具有足够的支付额度时,才能够继续向下游的账务系统发起调用。
然而,在相关技术中,作为旁路系统的安全验证系统以及额度验证系统,通常是比较耗时的业务系统,因而一旦安全验证系统或者额度验证系统发生调用超时,作为调用发起方的支付系统或者交易系统,将会向其上游的业务系统返回调用失败的结果,从而会造成上述业务平台调用失败率过高,整体业务不够稳定的问题。
请参见图3,图3为本例示出的一种基于SOA架构的支付业务平台中执行支付业务调用的处理流程图。图3所示出的支付业务调用的处理流程,在图2所示出的处理流程的基础上进行了改进,旁路系统将不再需要同步的执行上游核心系统发起的调用任务,而是采用异步执行调用任务的机制。
如图3所示,业务平台在响应用户通过支付APP发起的支付流程时,首先可以调用上述调用路径中的收银系统,由收银系统执行相应的收银任务,当收银系统在执行完毕响应的收银任务时,可以继续调用下游的支付系统。
支付系统在接收到上游的收银系统发起的调用后,可以响应该调用,继续调用安全验证系统,由安全验证系统执行对应的安全验证任务。安全验证系统响应支付系统发起的调用,一方面,可以实时的生成一个第一调用凭据,然后将该第一调用凭据返回给支付系统;另一方面,可以在本地异步的执行上述安全验证任务,并在执行完毕后将执行结果存储至预设的缓存。
支付系统在收到安全验证系统返回的第一调用凭据后,不需要等待安全验证系统返回调用结果,继续向下游的交易系统发起调用,并将该第一调用凭据传递给下游的交易系统。
交易系统在接收到上游的支付系统发起的调用后,可以响应该调用,继续调用额度验证系统,由额度验证系统执行对应的额度验证任务。额度验证系统响应支付系统发起的调用,一方面,可以实时的生成一个第二调用凭据,然后将该第二调用凭据返回给交易系统;另一方面,可以在本地异步的执行上述额度验证任务,并在执行完毕后将执行结果存储至预设的缓存。
交易系统在收到额度验证系统返回的第二调用凭据后,不需要等待额度验证系统返回调用结果,继续向下游的账务系统发起调用,并将支付系统传递过来的第一调用凭据和额度验证系统返回的该第二调用凭据继续传递给下游的账务系统。
账务系统在接收到上游的收银系统发起的调用后,可以响应该调用,基于传递至本地的第一调用凭据和第二调用凭据,并行调用上述预设的缓存,从上述预设的缓存中读取与该第一调用凭据和该第二调用凭据对应的执行结果。
如果与该第一调用凭据和该第二调用凭据对应的执行结果,指示支付流程的发起方用户通过了安全验证,并且支付额度充足时,此时可以向上述支付APP返回支付成功的通知消息。相反的,如果与该第一调用凭据和该第二调用凭据对应的执行结果,指示支付流程的发起方用户未通过安全验证,或者支付额度不充足时,此时可以向上述支付APP返回支付失败的通知消息。
当然,如果账务系统在响应上游的收银系统发起的调用时,如果此时仍未从上述预设的缓存中读取到对应的执行结果,并且在预设的调用超时时间超时后,上述安全验证系统以及额度验证系统,仍然未将执行结果存储至上述预设的缓存,此时调用超时,此时账务系统可以直接向上游的交易系统返回调用失败的消息。
可见,在本例中,收银系统、支付系统以及账务系统等核心系统,仍然采用同步执行调用任务的机制,而安全验证系统以及额度验证系统,将采用异步执行调用任务的机制。
一方面,对于安全验证系统以及额度验证系统的调用结果,将由上述调用路径上的最末端的账务系统,一次性从上述预设的缓存中并发的进行读取,因此相当于将基于SOA架构的业务平台传统的串行调用机制并行化,从而使得核心系统与旁路系统可以并行的执行调用任务,可以优化上述业务流程的处理速度。而且,当上述调用路径上的旁路系统越多,上述业务流程的处理速度的优化结果越显著。
例如,假设上述安全验证系统执行安全验证任务需要耗时100ms,上述额度验证系统执行额度验证任务需要耗时500ms,如果基于传统的串行调用机制,那么上述业务流程在旁路系统上的等待时长是600ms。而采用本例中示出的旁路系统异步执行调用任务的机制,相当于核心系统和旁路系统并发执行调用任务,因此上述业务流程在旁路系统上的等待时长将是安全验证任务需要的耗时和上述额度验证任务需要的耗时的最大值500ms,因此可以有效的提升上述业务流程的处理速度。
另一方面,由于支付业务流程的调用路径将采用旁路设计,安全验证系统以及额度验证系统等比较耗时的业务系统将被设置在旁路,而且旁路系统将异步执行调用任务,因此使得上述调用路径的主路径将会变短,同时通过旁路系统和核心系统并发执行调用任务,以及由上述调用路径中最末端的核心系统一次性并发的读取所有旁路系统的调用结果,可以给旁路系统预留出了更多的任务处理时间,从而可以有效降低由于旁路系统调用超时,而造成的调用失败的概率,提升业务平台的业务稳定性。
例如,由于上述安全验证系统以及额度验证系统等旁路系统,将与上述收银系统、支付系统以及账务系统等核心系统,并发的执行调用任务,因此当最末端的账务系统从预设的缓存中未读取到任何执行结果,触发了调用超时的计时时,上述安全验证系统以及额度验证系统响应的调用任务已经处理了一段时间,因此可以有效的降低上述安全验证系统以及额度验证系统调用超时的概率,提升业务平台的业务稳定性。
与上述方法实施例相对应,本申请还提供了装置的实施例。
请参见图4,本申请提出一种基于SOA架构的系统调用装置40,所述SOA架构包含由若干旁路系统和若干核心系统构成的调用路径;所述装置40应用于所述调用路径中的任一旁路系统;请参见图5,作为承载所述基于SOA架构的系统调用装置40的旁路系统所涉及的硬件架构中,通常包括CPU、内存、非易失性存储器、网络接口以及内部总线等;以软件实现为例,所述基于SOA架构的系统调用装置40通常可以理解为加载在内存中的计算机程序,通过CPU运行之后形成的软硬件相结合的逻辑装置,所述装置40包括:
第一接收模块401,接收到所述调用路径中的核心系统发起的调用请求;
生成模块402,响应于所述核心系统发起的调用请求,生成对应于所述调用请求的调用凭据,并将该调用凭据返回至所述核心系统,以使所述核心系统继续向下游核心系统发起调用请求,并将该调用凭据传递至向下游核心系统;
执行模块403,在本地异步执行与所述调用请求对应的调用任务,并将该调用任务的执行结果与所述调用凭据的对应关系存储至预设缓存,以使所述调用路径中的末端核心系统基于传递至其本地的调用凭据从该预设缓存中读取对应的执行结果。
在本例中,所述调用凭据为唯一标识所述调用请求的字符串;
其中,所述调用凭据包括与所述调用请求对应的调用接口和随机字符串组成的字符串。
在本例中,所述执行模块403具体:
创建所述调用凭据与所述调用任务的执行结果之间的对应关系,并将该对应关系存储至预设缓存;
或者,将所述调用任务的执行结果返回至所述核心系统,以由所述核心系统创建所述调用凭据与所述调用任务的执行结果之间的对应关系,并将该对应关系存储至预设缓存。
请参见图6,本申请提出另一种基于SOA架构的系统调用装置60,所述SOA架构包含由若干旁路系统和若干核心系统构成的调用路径;所述装置60应用于所述调用路径中的任一核心系统;请参见图7,作为承载所述基于SOA架构的系统调用装置60的核心系统所涉及的硬件架构中,通常包括CPU、内存、非易失性存储器、网络接口以及内部总线等;以软件实现为例,所述基于SOA架构的系统调用装置60通常可以理解为加载在内存中的计算机程序,通过CPU运行之后形成的软硬件相结合的逻辑装置,所述装置60包括:
发起模块601,向所述调用路径中关联的旁路系统发起调用请求;
第二接收模块602,接收到所述旁路系统返回的对应于所述调用请求的调用凭据;
所述发起模块601,继续向下游核心系统发起调用请求,并将所述调用凭据传递至下游核心系统,以使所述调用路径中的末端核心系统基于传递至其本地的调用凭据,从预设缓存中读取与所述调用请求对应的调用任务的执行结果;
其中,所述预设缓存中存储了所述旁路系统在其本地异步执行与所述调用请求对应的调用任务得到的执行结果与所述调用凭据的对应关系。
在本例中,当所述任一核心系统为所述调用路径中的末端核心系统,所述发起模块603进一步:
基于传递至本地的调用凭据,从预设缓存中读取与所述调用请求对应的调用任务的执行结果。
本领域技术人员在考虑说明书及实践这里公开的发明后,将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化,这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的,本申请的真正范围和精神由下面的权利要求指出。
应当理解的是,本申请并不局限于上面已经描述并在附图中示出的精确结构,并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求来限制。
以上所述仅为本申请的较佳实施例而已,并不用以限制本申请,凡在本申请的精神和原则之内,所做的任何修改、等同替换、改进等,均应包含在本申请保护的范围之内。