SOA系统架构下的系统调用方法、装置、设备及SOA系统架构与流程

本发明涉及soa系统技术领域，尤其涉及一种soa系统架构下的系统调用方法、装置、设备及soa系统架构。

背景技术：

soa(service-orientedarchitecture)是一种面向服务的架构，在soa环境中，系统之间存在着相互依赖的关系，当一个系统收到一个服务请求后，往往需要调用另一个系统去完成这个服务请求，比如a系统收到用户发起的一个服务请求后，调用b系统去完成这个服务请求，相对于服务请求的发起方，我们称a系统为服务请求响应系统，b系统为被a系统调用的系统。需要对系统调度的方案进行改进，保证系统稳定性。

技术实现要素：

为克服相关技术中存在的问题，本说明书提供了一种soa架构下的系统调用方法、装置、设备及soa系统架构。

首先，本说明书提供了一种soa系统架构下的系统调用方法，包括：

当收到服务请求时，根据被调用系统的响应时间确定是否对服务请求进行筛选；

如果是，则对所述服务请求进行筛选，并基于筛选获得的目标服务请求获取针对被调用系统的调用结果，以响应所述目标服务请求。

其次，一种soa系统架构下的系统调用装置，所述装置包括：

判断模块，当收到服务请求时，根据被调用系统的响应时间确定是否对服务请求进行筛选；

筛选模块，如果是，则对所述服务请求进行筛选；

获取模块，基于筛选获得的目标服务请求获取针对被调用系统的调用结果，以响应所述目标服务请求。

另外，本申请还提供了一种设备，所述设备包括：

存储器，用于存储可执行的计算机指令；

处理器，用于执行所述计算机指令时实现以下步骤：

当收到服务请求时，根据被调用系统的响应时间确定是否对服务请求进行筛选；

如果是，则对所述服务请求进行筛选，并基于筛选获得的目标服务请求获取针对被调用系统的调用结果，以响应所述目标服务请求。

进一步地，本申请还提供一种soa系统架构，包括服务请求响应系统和被调用系统，

服务请求响应系统用于在收到服务请求时，根据被调用系统的响应时间确定是否对服务请求进行筛选；如果是，则对所述服务请求进行筛选，并基于筛选获得的目标服务请求获取针对被调用系统的调用结果，以响应所述目标服务请求；

所述被调用系统用于在被服务请求响应系统的调用时，返回与所述目标服务请求对应的调用结果。

本申请的有益效果：服务请求响应系统在接收到服务请求时，根据被调用系统的响应时间确定是否对服务请求进行筛选；如果是，则对所述服务请求进行筛选，并基于筛选获得的目标服务请求获取针对被调用系统的调用结果，以响应所述目标服务请求。可以根据被调用系统的响应时间动态的调整服务请求响应系统给被调用系统发送服务请求的流量，避免因被调用系统响应时间过长占用服务请求响应系统的资源，对服务请求响应系统资源造成浪费，保证了服务请求响应系统的系统稳定性，此外，还可以筛选出需要优先处理的请求，保证这些服务请求被及时处理。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本发明。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本发明的实施例，并与说明书一起用于解释本发明的原理。

图1为本说明书一示例性实施例示出的一种soa系统架构的示意图；

图2为本说明书一示例性实施例示出的一种soa系统架构下的系统调用方法流程图；

图3为本说明书一示例性实施例示出的一种soa系统架构下的系统调用方法流程图；

图4为本说明书一示例性实施例示出的一种soa系统架构示意图；

图5为本说明书一示例性实施例示出的一种soa系统架构下的系统调用方法流程图；

图6为本说明书一示例性实施例示出的一种soa系统架构下的系统调用装置逻辑框图；

图7为本说明书一示例性实施例示出的一种设备的结构逻辑框图；

图8为本说明书一示例性实施例示出的一种soa系统架构示意图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本发明相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本发明的一些方面相一致的装置和方法的例子。

在本发明使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本发明。在本发明和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本发明可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本发明范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

soa(service-orientedarchitecture)是一种面向服务的架构，如图1所示，在soa环境中，系统之间存在着相互依赖的关系，当一个系统收到一个服务请求后，往往需要调用另一个系统去完成这个服务请求，相对于服务请求的发起方，我们称收到服务请求的系统为服务请求响应系统，被调用去完成这个服务请求的系统为被调用系统。比如系统a10收到用户13发送的服务请求4和系统b14发起服务请求1、服务请求2和服务请求3后，需要调用系统c11去完成服务请求1、服务请求2和服务请求4，需要调用系统d12去完成服务请求3，所以系统a10可以称为服务请求响应系统，系统c11和系统d12为被调用系统。

当服务请求响应系统收到的服务请求很多时，可能需要多次调用被调用系统去响应这个服务请求，比如系统a10为了响应服务请求1、服务请求2、服务请求4，需要多次调用系统c11。如果被调用系统c11的响应时间由于网络或系统容量等原因延长，那么服务请求响应系统a10就需要占用更多的资源来调用系统c，在服务请求响应系统a10的系统资源一定的情况下，可能会影响系统a10的其他服务，比如服务请求3，导致服务请求响应系统a10的服务能力下降。因此，我们需要对系统a调度的方案进行改进，以保证系统a的稳定性。

为了保证系统在调用一个系统去完成服务请求时，不会因为被调用系统的响应延时而导致资源占用，影响本系统的稳定性和其他服务。本说明书提供了一种soa系统架构下的系统调用方法，图2为所述方法的流程图，包括步骤s202-s206：

s202、当收到服务请求时，根据被调用系统的响应时间确定是否对服务请求进行筛选；

s204、如果是，则对所述服务请求进行筛选；

s206、基于筛选获得的目标服务请求获取针对被调用系统的调用结果，以响应所述目标服务请求。

一般在soa系统架构下，系统的分工可以比较精细，某种类型的业务都可以统一由某个特定的系统来处理，因而一个系统收到服务请求时，往往需要调用其他的系统去完成这个服务请求。比如，在淘宝系统下单购买某件商品，淘宝系统会调用专门的订单管理系统去管理订单业务，调用专门的支付系统的完成付款业务。服务响应系统可以是，比如淘宝系统，而被调用系统可以是，比如订单管理系统、支付系统。而在同一时间淘宝系统可能收到的用户下单的服务请求会比较多，这时就需要多次调用订单管理系统去管理多个服务请求的订单业务，调用支付系统去完成多个服务请求的付款业务。当然，在某些情况如果被调用的系统状态比较好，可以快速的响应所有的服务请求，就可以将所有服务请求发给被调用系统，以便被调用系统返回响应结果。在某些时候，被调用系统也有可能由于网络的原因或者是自身系统容量不够的原因，导致响应时间延长，这样服务请求响应系统得一直占用资源去等被调用系统返回响应结果，会占用服务请求响应系统的大量资源。这种情况下，服务请求响应系统可以不将所有服务请求都发送给被调用系统，而只向被调用系统发送一部分服务请求，以免系统资源被浪费。

在接收到服务请求后，当然，这个请求可以是用户发送的请求，也可以是其他系统自动发送的请求，服务请求响应系统可以先根据服务请求的内容确定该服务请求需要调用哪个系统处理，然后根据被调用系统的响应时间确定是否需要对服务请求进行筛选。比如，被调用系统原本处理一个请求只需300ms便可以返回处理结果，而近段时间内针对每个调用请求，都需要3s才会返回处理结果，说明，被调用系统的响应时间过长，因而在服务请求响应系统收到多个服务请求时，根据响应时间可以确定需要对服务请求进行筛选。在某个实施例中，为了更准确和客观地去判断是否需要对服务请求进行筛选，可以采用如图3所示的方法去确定是否需要对服务请求进行筛选，具体包括以下步骤：

s302、针对预设时间内收到的各服务请求，确定被调用系统的平均响应时间；

s304、根据所述平均响应时间和预设固定梯度算法计算调用所述被调用系统的目标流量；

s306、根据所述目标流量确定是否对服务请求进行筛选。

由于一段时间内被调用系统响应服务请求的响应时间可以反映当前的网络状态和被调用系统的状态，所以可以针对预设时间内收到的各服务请求，以及被调用系统对这些请求的响应时间来确定被调用系统的平均响应时间；比如可以设置记录1min中内被调用系统响应服务请求响应系统发送的各个调用请求的响应时间，然后根据这些响应时间得到一个平均响应时间。当然时间可以根据被调用系统的实际业务情况去设置，本说明书不作具体限制。计算得到平均响应时间后，再根据平均响应时间和预设固定梯度算法计算调用所述被调用系统的目标流量。服务请求响应系统向被调用系统每发送一次请求，计作一次请求流量，服务请求响应系统向被调用系统发送的调用请求越多，需要的请求流量也就越多，占用服务请求响应系统的系统资源也越多。可基于大量试验得到一个通过被调用系统响应时间与目标流量之间的算法，用于计算目标流量。比如，可采用固定梯度算法，固定梯度算法为根据经验法则得到一个算法，其输入为被调用系统响应时间，输出为目标流量调整比例。计算得到目标流量后，根据目标流量以及服务请求的数量确定是否对服务请求进行筛选。例如，目标流量为2个调用请求流量，而服务请求响应系统收到的服务请求大于2个，则需要对服务请求进行筛选，而服务请求响应系统收到的服务请求小于2个，则不需要筛选。

在某个实施例中，所述固定梯度算法基于所述被调用系统的响应时间、目标流量与所述服务请求响应系统的稳定性指标的对应关系得到。比如，当被调用系统的响应时间为300ms时，服务请求响应系统向被调用系统发送了5个调用请求，服务请求响应系统的稳定性较好，而服务请求响应系统向被调用系统发送了10个调用请求，系统稳定性较差，而当被调用系统的响应时间为30ms时，服务请求响应系统向被调用系统发送了50个调用请求，系统稳定性较好，因此，可以根据调用系统的响应时间与所述服务请求响应系统的稳定性指标的对应关系得到服务请求响应系统向备用系统发送调用请求的请求流量。固定梯度算法为根据上述三个响应因素得到的一个基于大量试验的经验计算公式，基于一个固定的基准请求流量，当输入一个被调用系统的响应时间时，可以根据该计算公式计算得到一个目标流量调整比例，然后可以根据基准请求流量和目标流量调整比例得到目标流量。举个例子，基准请求流量为20个请求流量，计算公式如以下公式1：

其中，f(x)表示目标流量调整比例，x表示被调用系统对一条服务请求的响应时间，在确定被调用系统响应时间后，便可根据公式1计算得到目标流量调整比例，然后再基于基准请求流量，可计算得到目标流量。当然，上述公式只是一个示范性的例子，具体的公式可以根据每个被调用系统自身的状况去和大量实验数据得到。

在确定需要对服务请求进行筛选后，服务请求响应系统需要对服务请求进行筛选，以确定哪些请求需要调用被调用系统去处理，然后基于筛选得到的目标请求向被调用系统发起调用请求，以获得响应结果，并将响应结果返回给用户或者是系统。当然，将哪些请求筛选出来作为目标请求，并调用被调用系统去处理这些请求的筛选机制可以根据实际情况去限定。比如说在某些情况，可以基于用户的id去筛选目标请求，比如对于vip用户的请求，需要及时反馈，以提高用户的体验，这时可以优先调用被调用系统去处理这些请求。在某些情况，可以基于请求的紧急程度去筛选，比如，针对紧急程度高的请求，可以优先调用被调用系统去处理。当然在，所有请求差别不大的情况，也可以随机选择一部份请求作为目标请求，调用被调用系统去处理。

由于筛选出来的目标请求都是需要调用被调用系统去处理的，所以目标请求的数量可以由计算的目标了流量去确定。比如目标流量为3次调用请求的流量，就筛选出3个服务请求作为目标请求。这样就不会出现服务请求响应系统资源被占用、系统稳定性不够和服务能力下降的问题。另外，由于预设的固定梯度算法是根据以往的系统状态得到的一个经验公式，只是单纯的根据这个算法去计算目标流量，以此来确定是否筛选服务请求以及目标服务请求的数量可能会存在不太全面的缺陷，所以，在某个实施例中，在根据平均响应时间和预设固定梯度算法计算调用所述被调用系统的目标流量之后，还可以根据服务响应系统所在设备的cpu性能、内存和/或负载情况对目标流量进行调整，比如此时系统的负载严重，出现过载现象，则将目标流量调小一些，而如果此时负载较小，cpu性能也较好，则可以将目标流量调大一些。总之，可以根据当前服务请求响应系统的状态和被调用系统的状态去自动调整本端系统向被调用系统的发送调用请求的请求流量，既可以保证服务请求响应系统的稳定性，又可以在保证服务请求响应系统稳定性的同时将服务请求响应系统的利用率最大化。

针对收到的每个服务请求，服务请求响应系统都必须做出回应。所以，对于筛选的服务请求，服务请求响应系统会调用被调用系统去处理，并将被调用系统返回的响应结果作为这些服务请求的回应结果。而针对这些服务请求中的非目标请求，服务请求响应系统也可以做回应。在某些情况下，可以预先设置响应结果，然后向这些请求返回预设的响应结果，比如，用户通过手机在某交流群里面发了一个支付宝红包，群里的多个用户都会去领取这个红包，当手机系统收到用户点击领取红包的服务请求后，会调用一个红包金额计算系统去计算每个服务请求的红包金额，然后再反馈给用户。如果红包金额计算系统由于网络或自身负载的问题导致计算系统响应时间很慢，这时手机系统会根据红包金额计算系统的响应时间确定是否需要对这些请求进行筛选，因此从用户发送的请求中筛选一部分目标服务请求，并调用红包金额计算系统去处理这些请求，并将得到红包金额返回给用户。对于剩下的服务请求，则根据预先设定的红包额返回给用户，而不需要调用红包金额计算系统去计算红包金额，以减小计算系统的压力。当然，在某些情况，如果每个请求的返回结果都是特定结果，必须依赖被调用系统去计算，则本端系统就会直接向这些非目标请求返回表征处理失败的结果，比如系统繁忙，或者报错。

此外，在一个实施例中，为了更好的根据被调用系统的响应时间去确定是否需要对服务请求进行筛选，服务请求响应系统每次调用被调用系统处理某个服务请求，被调用系统返回处理结果后，服务请求响应系统都会记录被调用系统的响应时间，以便基于这些响应时间去确定后面的服务请求是否需要进行筛选处理。

为了进一步解释本说明书提出的一种soa系统架构下的系统调用方法，以下结合图4和图5再以一个具体的实施例详细说明。

某个用户通过手机在某交流群里发一个红包，假设红包数量为100个，总共金额为100块，金额随机分配，这时群里的各用户都会点击该红包以领取红包。手机中集成了用户请求检测系统41和用户请求响应系统42，假设某个时刻有50个用户同时点击了红包，用户请求检测系统41在检测到用户的点击红包后，会将向用户请求响应系统42发送领红包服务请求(s401)，用户请求响应系统42会调用一个专门的红包金额计算系统43去计算用户领取红包的金额，即向红包金额计算系统43发送计算红包金额的请求(s402)，红包金额计算系统计算好红包金额后，将红包金额返回给用户请求响应系统42(s403)，用户请求响应系统42再将红包金额46返回给用户请求检测系统41，以显示给用户(s404)。由于红包计算系统还可能收到其他系统的调用请求，或者网络状况较差，这时候红包金额计算系统的响应时间可能会比较就长，比如正常300ms就可以响应，现在需要500ms。如果系统同时将这50个服务请求发送给红包计算系统，红包计算系统长时间不响应，就会占用系统很多资源去调用红包计算系统，也可以会影响系统的其他服务。所以用户请求响应系统在接收到用户请求检测系统发送的领红包服务请求后(s501)，会根据之前记录的前1min中内红包计算系统针对各服务请求的响应时间得到一个平均响应时间(s502)，然后根据平均响应时间和预先设置的固定梯度算法计算调用红包计算金额系统的目标流量(s503)，然后再根据当前系统的负载情况、cpu性能及内存情况架构对目标流量进行调整，比如当前负载较小，可调整大一些(s504)，然后根据目标流量确定是否要对这50个服务请求进行筛选(s505)，如果需要筛选则根据目标流量确定需要调用红包金额计算系统来处理的目标请求的数量，比如目标请求数量为35个(s506)，然后根据预设的机制确定哪35个服务请求作为目标请求(s507)，比如可以随机选取35个请求作为目标请求，然后调用红包金额计算去处理这35个请求(s508)，并获取红包金额计算系统的响应结果(s509)，记录红包金额计算系统响应这35个请求的响应时间并将响应结果返回给用户(s510)。对于剩余的15个非目标服务请求，则根据预先设置的红包金额作为结果返回给用户，比如0.1元(s511)。可以理解，对于目标服务请求和非目标服务请求结果的响应结果的返回给用户的这两个步骤是不分先后顺序，以上只是一个示范性实施例。当然，如果确定无需筛选服务请求，则将所有服务请求发送给红包金额计算系统，然后将红包金额计算系统返回的计算结果发送给用户(s512)。

由于用户请求响应系统给红包金额计算系统发送的服务请求的请求流量是随着时间和当前系统的状态以及红包计算系统的状态动态调整的，所以，既可以保证系统的稳定性，又可以将对系统的利用最大化，来保证系统服务质量。

与本说明书提供的soa架构下的系统调用的方法实施例相对应，本说明还提供了一种soa架构下的系统调用装置，如图6所示，所述装置600包括：

判断模块601，当收到服务请求时，根据被调用系统的响应时间确定是否对服务请求进行筛选；

筛选模块602，如果是，则对所述服务请求进行筛选；

获取模块603，基于筛选获得的目标服务请求获取针对被调用系统的调用结果，以响应所述目标服务请求。

在一个实施例中，针对筛选后的非目标服务请求，返回预设响应结果，所述预设响应结果包括表征处理失败的结果。

在一个实施例中，所述目标服务请求基于用户id进行筛选；或

基于服务请求的紧急程度进行筛选。

在一个实施例中，所述根据被调用系统的响应时间确定是否对服务请求进行筛选具体包括：

针对预设时间内收到的各服务请求，确定被调用系统的平均响应时间；

根据所述平均响应时间和预设固定梯度算法计算调用所述被调用系统的目标流量；

根据所述目标流量确定是否对服务请求进行筛选。

在一个实施例中，根据所述平均响应时间和预设固定梯度算法计算调用所述被调用系统的目标流量之后，还包括：

根据所述本系统所在设备的cpu性能、内存和/或负载情况调整所述目标流量。

在一个实施例中，所述固定梯度算法基于所述被调用系统的响应时间与本系统的稳定性指标的对应关系得到。

在一个实施例中，所述目标服务请求的数量基于所述目标流量确定。

在一个实施例中，基于筛选获得的目标服务请求获取被调用系统的调用结果之后，还包括：

记录被调用系统响应所述目标服务请求的响应时间。

上述装置中各个单元的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

从硬件层面而言，如图7所示，为本说明书的预加载页面装置所在设备的一种硬件结构图，除了图7所示的处理器701、网络接口704、内存702以及非易失性存储器703之外，实施例中装置所在的设备通常还可以包括其他硬件，如负责处理报文的转发芯片等；从硬件结构上来讲该设备还可能是分布式的设备，可能包括多个接口卡，以便在硬件层面进行报文处理的扩展。

所述非易失性存储器703存储有用于存储可执行的计算机指令，处理器704执行所述计算机指令时实现以下步骤：

当收到服务请求时，根据被调用系统的响应时间确定是否对服务请求进行筛选；

如果是，则对所述服务请求进行筛选，并基于筛选获得的目标服务请求获取针对被调用系统的调用结果，以响应所述目标服务请求。

由于本申请对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台终端设备执行本申请各个实施例方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(read-onlymemory，rom)、随机存取存储器(randomaccessmemory，ram)、磁碟或者光盘等各种可以存储程序代码的介质。

进一步地本申请还提供了一种soa系统架构，如图8所示，所述soa系统包括服务请求响应系统801和被调用系统802；

服务请求响应系统801用于在收到服务请求803时，根据被调用系统802的响应时间确定是否对服务请求进行筛选；如果是，则对所述服务请求进行筛选，并基于筛选获得的目标服务请求804获取被调用系统的调用结果805，以响应所述目标服务请求804；

所述被调用系统802用于在被服务请求响应系统801的调用时，返回与所述目标服务请求804对应的调用结果805。

以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。