CN110351345A - 用于业务请求处理的方法及装置 - Google Patents

Abstract

本公开提供了一种用于业务请求处理的方法及装置，其中所述用于业务请求处理的方法包括：确定业务请求处理需要调用的多个服务提供方，然后对各个服务提供方的服务能力进行评估，并基于所得到的服务能力评估结果来确定各个服务提供方的调用顺序，进而按照调用顺序调用多个服务提供方来提供对应的服务。利用该方法，能够优先调用服务能力更佳的服务提供方来提供服务，整体上提高了业务响应性能容量和业务处理效率。

Description

用于业务请求处理的方法及装置

技术领域

本公开涉及计算机技术领域，具体地，涉及一种用于业务请求处理的方法及装置。

背景技术

随着互联网技术的不断发展，应用产品也在朝着更加多元化的方向去发展，故通过接口化实现接入不同服务提供方的多功能集成化应用已成为目前应用的普遍发展方向。

在应用产品的一些业务中，其可能会需要进行多个外接服务，从而保障业务的正常进行；例如，在基于程序应用的开户注册业务中，管理装置可能需要与多个认证服务提供方分别进行认证交互，才能完成开户注册业务。

然而，不同服务提供方的服务能力之间会存在差异，并且从管理装置所接收的海量业务请求整体上进行考虑，在对多个服务提供方进行调用时，不当的服务提供方调用顺序可能会因排位靠前的服务提供方的服务能力不足而影响业务整体的响应性能容量，并还会导致业务处理效率的降低。

发明内容

鉴于上述问题，本公开提供了一种用于业务请求处理的方法及装置，利用该方法及装置，可以根据不同服务提供方的服务能力评估结果来确定各个服务提供方的调用顺序，能够优先调用性能更强的服务提供方进行服务，整体上提高了业务响应性能容量和业务处理效率。

根据本公开的一个方面，提供了一种用于业务请求处理的方法，包括：确定业务请求处理需要调用的多个服务提供方；对各个所述服务提供方的服务能力进行评估；基于各个所述服务提供方的服务能力评估结果来确定所述各个服务提供方的调用顺序；按照所确定的调用顺序调用所述多个服务提供方来提供对应的服务。

可选地，在上述方面的一个示例中，所述方法还可以包括：根据针对所述多个服务提供方调用的响应结果来处理所述业务请求。

可选地，在上述方面的一个示例中，所述对各个服务提供方的服务能力进行评估包括：获取所述各个服务提供方的响应性能指标；以及基于所述响应性能指标，来对所述各个服务提供方的服务能力进行评估。

可选地，在上述方面的一个示例中，所述响应性能指标包括响应成功率指标和/或响应时长指标。

可选地，在上述方面的一个示例中，所述对各个服务提供方的服务能力进行评估还包括：获取所述各个服务提供方的当前处理资源信息，以及基于所述响应性能指标，对所述各个服务提供方的服务能力进行评估包括：基于所述响应性能指标和各个服务提供方的当前处理资源信息，对所述各个服务提供方的服务能力进行评估。

可选地，在上述方面的一个示例中，所述处理资源信息和所述响应性能指标分别具有对应的权重因子，所述基于所述响应性能指标和各个服务提供方的当前处理资源信息，对所述各个服务提供方的服务能力进行评估包括：基于所述响应性能指标、各个服务提供方的当前处理资源信息以及对应的权重因子，对所述各个服务提供方的服务能力进行评估。

可选地，在上述方面的一个示例中，所述对各个所述服务提供方的服务能力进行评估包括：周期或非周期地对所述各个服务提供方的服务能力进行评估。

可选地，在上述方面的一个示例中，所述方法还包括：获取所述各个服务提供方的待处理业务请求数量；以及基于各个所述服务提供方的服务能力评估结果来确定所述各个服务提供方的调用顺序包括：基于所述各个服务提供方的待处理业务请求数量和服务能力评估结果，确定所述各个服务提供方的调用顺序。

可选地，在上述方面的一个示例中，所述获取所述各个服务提供方的待处理业务请求数量包括：在当前业务处理模型是排队优先模式时，获取所述各个服务提供方的待处理业务请求数量。

可选地，在上述方面的一个示例中，基于所述各个所述服务提供方的服务能力评估结果来确定所述各个服务提供方的调用顺序包括：基于所述各个所述服务提供方的服务能力评估结果和预定调用规则来确定所述各个服务提供方的调用顺序。

根据本公开的另一方面，提供一种用于业务请求处理的装置，包括：服务提供方确定单元，被配置为确定业务请求处理需要调用的多个服务提供方；服务能力评估单元，被配置为对各个所述服务提供方的服务能力进行评估；调用顺序确定单元，被配置为基于各个所述服务提供方的服务能力评估结果来确定所述各个服务提供方的调用顺序；调用单元，被配置为按照所确定的调用顺序调用所述多个服务提供方来提供对应的服务。

可选地，在上述方面的一个示例中，所述装置还包括：业务请求处理单元，被配置为根据针对所述多个服务提供方调用的响应结果来处理所述业务请求。

可选地，在上述方面的一个示例中，所述服务能力评估单元包括：性能指标获取模块，被配置为获取所述各个服务提供方的响应性能指标；以及服务能力评估模块，被配置为基于所述响应性能指标，来对所述各个服务提供方的服务能力进行评估。

可选地，在上述方面的一个示例中，所述服务能力评估单元还包括：处理资源信息获取模块，被配置为获取所述各个服务提供方的当前处理资源信息，以及，所述服务能力评估模块被配置为：基于所述响应性能指标和各个服务提供方的当前处理资源信息，对所述各个服务提供方的服务能力进行评估。

可选地，在上述方面的一个示例中，所述处理资源信息和所述响应性能指标分别具有对应的权重因子，所述服务能力评估模块被配置为：基于所述响应性能指标、各个服务提供方的当前处理资源信息以及对应的权重因子，对所述各个服务提供方的服务能力进行评估。

可选地，在上述方面的一个示例中，所述装置还包括：业务请求数量获取单元，被配置为获取所述各个服务提供方的待处理业务请求数量；以及，所述调用顺序确定单元被配置为：基于所述各个服务提供方的待处理业务请求数量和服务能力评估结果，确定所述各个服务提供方的调用顺序。

可选地，所述业务请求数量获取单元被配置为：在当前业务处理模式是排队优先模式时，获取所述各个服务提供方的待处理业务请求数量。

可选地，所述调用顺序确定单元被配置为：基于所述各个所述服务提供方的服务能力评估结果和预定调用规则来确定所述各个服务提供方的调用顺序。

根据本公开的另一方面，提供一种计算设备，包括：至少一个处理器；以及，存储器，所述存储器存储指令，当所述指令被所述至少一个处理器执行时，使得所述至少一个处理器执行如上所述的用于业务请求处理的方法。

根据本公开的另一方面，提供一种机器可读存储介质，其存储有可执行指令，所述指令当被执行时使得所述机器执行如上所述的用于业务请求处理的方法。

附图说明

通过参照下面的附图，可以实现对于本公开内容的本质和优点的进一步理解。在附图中，类似组件或特征可以具有相同的附图标记。附图是用来提供对本发明实施例的进一步理解，并且构成说明书的一部分，与下面的具体实施方式一起用于解释本公开的实施例，但并不构成对本公开的实施例的限制。在附图中：

图1示出了适于应用本公开的实施例的用于业务请求处理的方法的系统架构示意图；

图2示出了根据本公开的实施例的用于业务请求处理的方法的流程图；

图3示出了根据本公开的实施例的用于确定服务能力的一示例的原理流程图；

图4示出了根据本公开的实施例的用于确定调用顺序的一示例的流程图；

图5示出了根据本公开的实施例的用于确定调用顺序的另一示例的流程图；

图6示出了根据本公开的实施例的用于业务请求处理的方法应用于账户开户场景时的信号时序图；

图7示出了根据本公开的另一实施例的用于业务请求处理的装置的方框图；

图8示出了根据本公开的实施例的用于业务请求处理的计算设备的方框图。

具体实施方式

以下将参考示例实施方式讨论本文描述的主题。应该理解，讨论这些实施方式只是为了使得本领域技术人员能够更好地理解从而实现本文描述的主题，并非是对权利要求书中所阐述的保护范围、适用性或者示例的限制。可以在不脱离本公开内容的保护范围的情况下，对所讨论的元素的功能和排列进行改变。各个示例可以根据需要，省略、替代或者添加各种过程或组件。另外，相对一些示例所描述的特征在其它例子中也可以进行组合。

如本文中使用的，术语“包括”及其变型表示开放的术语，含义是“包括但不限于”。术语“基于”表示“至少部分地基于”。术语“一个实施例”和“一实施例”表示“至少一个实施例”。术语“另一个实施例”表示“至少一个其他实施例”。术语“第一”、“第二”等可以指代不同的或相同的对象。下面可以包括其他的定义，无论是明确的还是隐含的。除非上下文中明确地指明，否则一个术语的定义在整个说明书中是一致的。

此外，如本文中使用的，术语“服务能力”可以是表示服务提供方用于服务响应来自业务处理装置的请求的性能度量指标。示例性地，若服务提供方的服务能力越高，则其响应处理业务请求的效率就越快和响应处理业务请求的容量就越大等。另外，“服务能力”可以是指示服务提供方的某一个性能参数或指标(例如响应时长)或多个性能参数或指标(例如响应时长、当前处理资源信息等)的组合。相应地，术语“服务能力评估结果”可以是表示“服务能力”所对应的量化值或能力档次，例如业务处理装置依据上述的性能参数或指标来确定的最终的服务能力的评估值。

现在结合附图来描述本公开的实施例的业务处理方法及装置在实现过程中的相关细节和相应的目的。

图1示出的是适于应用本公开的实施例的用于业务请求处理的方法的系统架构示意图。

如图1所示，该架构包括用户终端10、业务处理装置20和诸如服务提供方A、B和C的多个服务提供方，其中，用户终端10用于将业务请求发送至业务处理装置20。这里，业务请求可以是由用户终端10接收用户操作后生成的。业务处理装置20可以分别经由接口a、接口b和接口c与服务提供方A、服务提供方B和服务提供方C进行通信连接。在本公开中，该业务请求可以是指需要由在业务处理装置20之外的多个外接服务提供方(例如在服务提供方A、B和C之间)轮流进行处理响应的业务请求，也就是，在对业务请求进行处理时，业务处理装置20需要调用多个(例如至少两个)服务提供方来提供服务，并且基于多个服务提供方所提供的调用响应结果来进行业务处理。

在本公开的一个示例中，该业务请求可以是开户认证请求。在业务处理装置20接收到用户的开户认证请求后，业务处理装置20需要经过公安部门服务提供方识别该用户的身份信息，银行服务提供方识别银行卡信息等，然后业务处理装置20在得到了来自多个服务提供方的服务响应结果之后，再决策是否能够为该用户开户。在本公开的另一示例中，该业务请求也可以是其他任意类型的需要与多个外接的服务提供方进行交互的请求，比如网络消费请求，其需要验证是否能成功消费，故其需求与付款方式验证服务提供方来认证付款方式是否属于授权付款方式，以及向银行服务提供方询问卡内余额是否充足等。

另外，该业务处理装置20可以是任意的管理设备，例如中心通信网络中的服务器或对等通信网络中用于提供服务的主节点等，其在执行特定业务请求处理时需要与多个服务提供方轮流进行请求交互，并基于从各个服务提供方所得到的响应结果完成相应的针对业务请求的处理，例如是决策允许或不予开户、能够或不能进行扣款等。

在一些情况下，当处理此类需求多个外接服务提供方(诸如服务提供方A、B和C)协助的业务请求时，业务处理装置20与服务提供方A、B和C之间进行交互的顺序是固设的，例如按照固定的A→B→C的顺序来响应执行业务请求。但是，服务提供方A、B和C的性能容量可能是不同的，并且在实际工作过程中服务提供方A、B和C的访问量也可能是不同的，另外服务提供方A、B和C可能还会在工作过程中存在性能抖动(例如短时间某一服务提供方的性能低下)的情况。

此时，假设按照固设的A→B→C的方式进行调用，若此时位于初始的服务提供方A存在服务能力低下的问题，则会导致服务请求中被响应的请求容量较低，突出了服务响应的短板效应，使得业务的整体处理效率低下。

需说明的是，各个服务提供方可以是分别具有不同的拦截率，例如服务提供方A、B和C的拦截率分别是10％、20％和30％。此时，假如仍按照固设的A→B→C对各个服务提供方进行调用且当业务处理装置20接收到1000个业务请求时的，则会导致业务处理装置20的实际业务请求服务响应容量只有180。但是，若能利用服务提供方C来优先处理业务请求，例如按照C→B→A的调用顺序来依次进行调用以提供服务，则能使得实际业务请求服务响应容量提高到400，优化了业务处理装置的实际QPS，并提升业务处理效率。

举例来讲，当用户在金融类应用(例如手机银行、炒股软件或支付宝等)上进行账户开户操作时，服务器在收到开户请求之后需要与公安认证系统、实名认证系统及年龄认证系统都进行交互，并从其得到相应的认证结果之后，才能够分析用户是否可以开户。此时，若各个认证系统的认证顺序被预先固设为公安认证系统→实名认证系统→年龄认证系统，则可能会出现一种情况：在公安认证系统的性能不如(包括持续不如或短期不如)其他两个认证系统时，使得排在首位的公安认证系统的认证会影响后续外接系统的认证操作，降低了整体开户容量。

图2示出了根据本公开的实施例的用于业务请求处理的方法200的流程图。

如图2所示，在块210中，业务处理装置20确定业务请求处理需要调用的多个服务提供方。这里，该业务请求可以是如图1所示的来自于用户终端10。在一个示例中，该业务请求中可以包括服务提供方标识信息，该服务提供方标识信息用于指示该业务请求所需要调用的多个服务提供方。相应地，业务处理装置20可以通过对该业务请求进行解析以得到该服务服务方标识信息，由此确定业务请求处理需要调用的服务提供方。在另一示例中，在业务处理装置20中可以存储业务请求与需要调用的服务提供方列表之间的对应关系表。在接收到业务请求后，可以通过查询该对应关系表来确定出需要调用的服务提供方，例如，通过使用业务请求的业务标识来查询该对应关系表，以确定出需要调用的服务提供方。或者，在另一示例中，业务处理装置20可以通过分析业务请求的业务属性来确定业务请求处理需要调用的服务提供方。

接着，在块220，对各个服务提供方的服务能力进行评估。在一个示例中，业务处理装置20可以直接从各个服务提供方接收针对服务提供方的一个(或多个)性能参数或指标，并利用该一个(或多个)性能参数或指标来对服务提供方的服务能力进行评估。例如，可以是直接将一个性能参数或指标作为服务能力的评估指标。可替换地，也还可以是考虑多个性能参数或指标来综合评估服务提供方的服务能力。其中，性能参数或指标可以是响应性能指标、当前处理资源信息等。

在一示例中，响应性能指标可以是表示用于表征服务提供方在执行响应操作过程中的性能参数，例如响应时长指标和/或响应成功率指标等。然后，基于响应性能指标，来对各个服务提供方的服务能力进行评估。例如，在评估服务能力的过程中，业务处理装置20可以是直接利用响应性能指标来确定各个服务提供方的服务能力评估结果。

接着，在块230，基于各个所服务提供方的服务能力评估结果来确定各个服务提供方的调用顺序。

其中，可以是根据所评估的服务能力的高低来确定调用顺序的先后，例如将对应服务能力高的服务提供方排在调用顺序中靠前的位置，并将对应服务能力低的服务提供方排在调用顺序中靠后的位置。

接着，在块240，按照所确定的调用顺序调用多个服务提供方来提供对应的服务。

在本公开实施例中，可以依据调用顺序使得服务能力强的服务提供方优先被调用以进行服务，从业务处理装置20所接收的海量业务请求整体上考虑，避免出现大量业务请求得不到及时的服务响应，因此降低了短板效应并提高了业务请求的服务响应性能容量，在整体上提升了业务处理效率。结合如上文图1中的示例，可以是将服务能力最高的服务提供方C排在调用顺序的最前面，这样在业务处理装置20待处理的1000个用户请求中，会有400个被实时服务响应，而不是180个，因此增大了业务处理装置的实际QPS。

图3示出了根据本公开的实施例的用于对服务提供方的服务能力进行评估的一个示例的流程图。

如图3所示，服务能力可以是基于响应性能指标和处理资源信息共同来进行评估和确定的。可以理解的是，图3所示的实施例仅用于示例，而并不旨在限制，例如可以仅基于响应性能指标来对服务能力进行评估，或者可以仅基于处理资源信息来对服务能力进行评估。

其中，可以是通过服务提供方的压力测试结果来得到对应的响应性能指标。在一个示例中，可以获取各个服务提供方第一压力测试结果(例如针对业务请求)，其中该压力测试结果可以是静态预配置的或动态更新的，并且在压力测试的过程中可以是对业务请求的响应结果(成功或失败)、响应时间和最大QPS等进行统计。然后，解析第一压力测试结果，以确定在预设的第一数量的业务请求中被成功响应的第一业务请求数量和/或被失败响应的第二业务请求数量。之后，基于第一业务请求数量和第二业务请求数量，确定响应成功率指标。举例来说，当业务处理装置20得到了关于a个业务请求的压力测试结果，并统计在随机选择的第一数量为1000个的业务请求中被成功响应的数量b，进而可以得出响应成功率指标为b/1000。

示例性地，在另一示例中，还可以是获取各个服务提供方的第二压力测试结果(例如针对业务请求)，其中该第二压力测试结果也可以是静态预配置的或动态更新的。然后，解析第二压力测试结果，以确定预设的第二数量的业务请求分别被处理所对应的测试响应时间。以及，根据测试响应时间，确定响应时长指标。举例来说，当业务处理装置20得到了关于m个业务请求的压力测试结果，并统计在随机选择的第二数量为1000个的业务请求的测试响应时间的总和为T，进而可以得出响应时长指标为T/1000。

在本公开的一个示例中，可以是如图3所示的结合响应成功率指标和响应时长指标来确定响应性能指标。优选地，响应成功率指标和响应时长指标还可以是分别存在针对响应性能指标的权重w1和w2，进而可以是利用w1和w2来分配响应成功率指标和响应时长指标分别对响应性能指标的影响，以适应业务处理装置20对不同业务应用场景的需求。示例性地，在一些期望较短的响应时长的业务应用场景下，可以是赋予较高的w1和较低的w2。可替换地，在另一些期望较高的成功率的业务应用场景下，可以是赋予较低的w1和较高的w2。

在本公开的一个示例中，可以是如图3所示的将响应性能指标结合处理资源信息来评估服务能力。具体的，业务处理装置20可以是获取各个服务提供方的当前处理资源信息，其中该当前处理资源信息可以是表示当前服务提供方的诸如CPU信息、内存信息或内存余量等的信息；然后基于响应性能指标和各个服务提供方的处理资源信息，对各个服务提供方的服务能力进行评估。优选地，处理资源信息和响应性能指标分别具有对应的权重因子，并可以是基于响应性能指标、各个服务提供方的当前处理资源信息以及对应的权重因子，对各个服务提供方的服务能力进行评估。示例性地，响应性能指标和当前处理资源信息分别存在针对服务能力的权重因子w3和w4，当为了给响应性能指标赋予针对服务能力更高的影响程度时，可以是设置w3大于w4。

在一些实施方式中，针对服务能力的评估过程可以是动态进行的，示例性地，可以是周期或非周期地对各个服务提供方的服务能力进行评估，进而能够基于周期或非周期所获取的服务能力评估结果更新针对各个服务提供方的排序。其中，周期可以是表示按照预定周期执行，由此能够实现定时评估各个服务提供方的服务能力。另外，非周期可以是表示随机时间或实时。示例性地，业务处理装置20可以是周期或非周期地探活服务提供方以获取处理资源信息，并基于所动态获取的处理资源信息来更新对应的服务能力评估结果。可附加或可替换地，业务处理装置20也还可以是周期或非周期地获取压力测试结果，并基于所动态获取的压力测试结果重新计算响应成功率指标或响应时长指标，进而更新服务能力评估结果。

关于在多个服务提供方之间的调用顺序，除了如图2所示的仅依据服务能力的评估结果的高低来确定对应的调用顺序之外，还可以是结合服务能力的评估结果和其他参考指标来共同确定调用顺序，从而适应多样化的应用场景。

图4所示出的是根据本公开的实施例的用于确定调用顺序的一示例的流程图。

如图4所示，在业务处理装置20对不同服务提供方进行排序时，可以是考虑到各个服务提供方的服务能力和待处理业务请求数量。

在块410中，对服务提供方的服务能力进行评估，其评估过程和细节可以具体参照上述如图3的描述。

接着，在块420中，判断当前业务处理模式是否为排队优先模式。在一些应用场景下，业务处理装置20可以被配置为具有多种业务处理模式，例如排队优先模式和服务能力优先模式等。其中，排队优先模式可以表示排队的待处理业务请求应当被优先处理，并且还可以通过接收业务运营商的操作来对当前业务处理模式(例如通过模式切换开关)进行切换和调整的。

在块430中，当确定当前业务处理模式为排队优先模式时，可以是获取各个服务提供方的待处理业务请求数量，例如可以是从各个服务提供方处接收到相应的待处理业务请求数量。

在块440中，可以是利用所获取的待处理业务请求数量对各个服务提供方的调用顺序进行调整。优选地，还可以是基于各个服务提供方的待处理业务请求数量和服务能力评估结果，来确定各个服务提供方的调用顺序，因此同时考虑到各个服务提供方的服务能力和评估结果，能够实现针对业务请求的服务响应的销峰处理，更加保障了业务整体的处理体验。

需说明的是，利用待处理业务请求数量调整调用顺序的过程细节可以是多样化的，例如当待处理业务请求数量超过预设置的排队阈值时，便可以将对应的服务提供方顺序提到最前面。另外，也还可以是设置对应于唯一次序的多个排队区间，而当待处理业务请求数量处于排队区间时，将对应的待处理业务请求数量排在对应次序。举例来说，假如依据服务能力的排序是C→B→A，但服务提供方A的待处理业务请求数量最大且已经超过了预设排队阈值，则可以是将排序变更为A→C→B，从而实现销峰的效果。

图5示出了根据本公开的实施例的用于确定调用顺序的另一示例的流程图。

在块510中，对服务提供方的服务能力进行评估，其评估过程和细节可以具体参照上述如图3的描述。

在块520中，判断是否存在预定调用规则。其中，该预定调用规则也可以是由业务运营商所自行设定的，例如可以是基于运营需求而预定要将服务提供方A排在最靠前的位置等。

在块530中，基于各个服务提供方的服务能力评估结果和预定调用规则来确定各个服务提供方的调用顺序，由此实现了在符合预定调用规则的同时还能够兼顾业务的整体处理体验。

举例来说，当预定调用规则是将A排在调用顺序的最前位置，且基于服务能力评估结果的排序为C→B→A时，可以是将排序变更为A→C→B，从而满足运营商所需求的更多的个性化业务场景。

此外，业务处理装置20需要从多个服务提供方都拿到了服务的响应结果之后才会作出相应的业务处理操作(例如决策)。示例性地，在开户应用场景中，只有在针对业务请求的各个服务提供方的认证结果都是通过的情况下，业务处理装置20才会决策确定该用户符合开户条件。

图6示出了根据本公开的实施例的用于业务请求处理的方法应用于账户开户场景时的信号交互图。

如图6所示，在块601中，用户终端10向业务处理装置20发送开户指令。在块602中，业务处理装置20根据开户指令确定服务需求信息和查找开户指令所指向的外部服务提供方(例如A和B)的地址信息，进而生成相应的业务请求。

在块6031中，服务提供方A向业务处理装置20反馈压力测试结果。在块6032中，服务提供方B向业务处理装置20反馈压力测试结果。在一示例中，该压力测试结果的获取动作可以是由业务请求所触发的。在另一示例中，该压力测试结果也还可以是由服务提供方定期自主上传的。

在块6041中，业务处理装置20探活服务提供方A。在块6042中，业务处理装置20探活服务提供方B。在一示例中，业务处理装置20可以是基于业务请求探活(例如间隔性地多次探活)服务提供方A和B。

在块6051中，业务处理装置20可以得到由服务提供方A所反馈的资源消耗信息。在块6052中，业务处理装置20还可以得到由服务提供方B所反馈的资源消耗信息。在一示例中，可以是基于探活操作而得到相应的资源消耗信息，其中该资源消耗信息可以是诸如处理器消耗剩余量、内存余量等类型的信息，从而得到各个服务提供方的实时硬件指标。

在块6061中，业务处理装置20可以得到由服务提供方A所反馈的排队请求数量。在块6062中，业务处理装置20还可以得到由服务提供方B所反馈的排队请求数量。其中，排队请求数量用于指示各个服务提供方处等待进行服务响应的请求的数量。

在块607中，业务处理装置20评估服务能力。其中，业务处理装置20可以是依据所获取的上述压力测试结果和处理资源消耗信息来评估服务提供方A和B的服务能力，并还可以是考虑是否存在本地预配置的预定调用规则和排队请求数量。

在块608中，检测是否存在预定调用规则。示例性地，当存在预定调用规则时，业务处理装置20相比于服务能力评估结果能更优先考虑预定调用规则，最终确定针对服务提供方A和B的调用顺序。

在块6091中，业务处理装置20向服务提供方A发送业务请求。在块6092中，业务处理装置20从服务提供方A接收针对该业务请求所反馈的服务响应结果。

在块6093中，业务处理装置20向服务提供方B发送业务请求。在块6094中，业务处理装置20从服务提供方B接收针对该业务请求所反馈的服务响应结果。

在块610中，业务处理装置20根据从服务提供方A和B所反馈的服务响应结果来判断用户是否满足开户条件，以决策是否进行开户。

应理解的是，由于应用了探活机制来动态收集来自不同服务提供方的实时处理资源消耗信息和排队请求数量，使得对不同服务提供方的调用顺序可以实现按照需求或服务提供方实时的服务能力而进行动态调整，例如动态调整以保证拦截效果最好的服务提供方能够处于调用顺序的第一顺位，保障了开户业务的稳定性，并提高了整体开户容量和在整体上降低了对下游服务提供方的压力。

需要说明的是，图6中的描述的部分操作也可以是可选的，比如压力测试结果获取操作、探活操作、处理资源消耗信息获取操作、排队请求数量获取操作和检测预定调用规则操作等。在本公开的其它示例中，也可以删除上述可选操作中的部分或全部。此外，在本公开的其它示例中，也可以对图6中描述的部分操作进行修改。

图7示出了根据本公开的实施例的用于业务请求处理的装置(在下文中也被称为“业务请求处理装置”)700的方框图。

如图7所示，业务请求处理装置700包括服务提供方确定单元710、服务能力评估单元720、调用顺序确定单元730、调用单元740、业务请求处理单元750和业务请求数量获取单元760。

服务提供方确定单元710被配置为确定业务请求处理需要调用的多个服务提供方。服务提供方确定单元710的操作可以参照上面参考图2描述的块210的操作。

服务能力评估单元720被配置为对各个所述服务提供方的服务能力进行评估。服务能力评估单元720的操作可以参照上面参考图2描述的块220的操作。

调用顺序确定单元730被配置为基于各个所述服务提供方的服务能力评估结果来确定所述各个服务提供方的调用顺序。服务能力评估单元730的操作可以参照上面参考图2描述的块230的操作。

调用单元740被配置为按照所确定的调用顺序调用所述多个服务提供方来提供对应的服务。调用单元730的操作可以参照上面参考图2描述的块240的操作。

业务请求处理单元750被配置为根据针对所述多个服务提供方调用的响应结果来处理所述业务请求。业务请求处理单元750的相关处理过程可以是参照图6中的依据响应结果来决策是否进行开户。

进一步地，服务能力评估单元720包括性能指标获取模块(未示出)和服务能力评估模块(未示出)，其中所述性能指标获取模块被配置为获取所述各个服务提供方的响应性能指标，以及所述服务能力评估模块被配置为基于所述响应性能指标，来对所述各个服务提供方的服务能力进行评估。

进一步地，服务能力评估单元720还包括处理资源信息获取模块(未示出)，该处理资源信息获取模块被配置为获取所述各个服务提供方的当前处理资源信息，以及，该服务能力评估模块被配置为基于所述响应性能指标和各个服务提供方的当前处理资源信息，对所述各个服务提供方的服务能力进行评估。

进一步地，所述处理资源信息和所述响应性能指标分别具有对应的权重因子，所述服务能力评估模块被配置为：基于所述响应性能指标、各个服务提供方的当前处理资源信息以及对应的权重因子，对所述各个服务提供方的服务能力进行评估。

以上服务能力评估单元720的针对服务能力的评估过程，具体可以参照结合图3所描述的操作示例。

业务请求数量获取单元760被配置为获取所述各个服务提供方的待处理业务请求数量，相应地，调用顺序确定单元740被配置为基于所述各个服务提供方的待处理业务请求数量和服务能力评估结果，确定所述各个服务提供方的调用顺序。

进一步地，业务请求数量获取单元760被配置为在当前业务处理模式是排队优先模式时，获取所述各个服务提供方的待处理业务请求数量。业务请求数量获取单元760的相关处理过程可以是参照图4中描述的操作。

进一步地，调用顺序确定单元730被配置为基于所述各个所述服务提供方的服务能力评估结果和预定调用规则来确定所述各个服务提供方的调用顺序。此处的调用顺序确定单元730的相关处理过程可以是参照图5中描述的操作。

如上参照图1到图7，对根据本公开的用于业务请求处理的方法及装置的实施例进行了描述。在以上对方法实施例的描述中所提及的细节，同样适用于本公开的装置的实施例。上面的用于业务请求处理的装置可以采用硬件实现，也可以采用软件或者硬件和软件的组合来实现。

图8示出了根据本公开的实施例的用于业务请求处理的计算设备800的硬件结构图。如图8所示，计算设备800可以包括至少一个处理器810、存储器(例如，非易失性存储器)820、内存830和通信接口840，并且至少一个处理器810、存储器820、内存830和通信接口840经由总线860连接在一起。至少一个处理器810执行在存储器中存储或编码的至少一个计算机可读指令(即，上述以软件形式实现的元素)。

在一个实施例中，在存储器中存储计算机可执行指令，其当执行时使得至少一个处理器810：确定业务请求处理需要调用的多个服务提供方；对各个所述服务提供方的服务能力进行评估；基于各个所述服务提供方的服务能力评估结果来确定所述各个服务提供方的调用顺序；按照所确定的调用顺序调用所述多个服务提供方来提供对应的服务。

应该理解，在存储器820中存储的计算机可执行指令当执行时使得至少一个处理器810进行本公开的各个实施例中以上结合图1-7描述的各种操作和功能。

在本公开中，计算设备800可以包括但不限于：个人计算机、服务器计算机、工作站、桌面型计算机、膝上型计算机、笔记本计算机、移动计算设备、智能电话、平板计算机、蜂窝电话、个人数字助理(PDA)、手持装置、消息收发设备、可佩戴计算设备、消费电子设备等等。

根据一个实施例，提供了一种比如机器可读介质的程序产品。机器可读介质可以具有指令(即，上述以软件形式实现的元素)，该指令当被机器执行时，使得机器执行本公开的各个实施例中以上结合图1-7描述的各种操作和功能。具体地，可以提供配有可读存储介质的系统或者装置，在该可读存储介质上存储着实现上述实施例中任一实施例的功能的软件程序代码，且使该系统或者装置的计算机或处理器读出并执行存储在该可读存储介质中的指令。

在这种情况下，从可读介质读取的程序代码本身可实现上述实施例中任何一项实施例的功能，因此机器可读代码和存储机器可读代码的可读存储介质构成了本发明的一部分。

可读存储介质的实施例包括软盘、硬盘、磁光盘、光盘(如CD-ROM、CD-R、CD-RW、DVD-ROM、DVD-RAM、DVD-RW、DVD-RW)、磁带、非易失性存储卡和ROM。可选择地，可以由通信网络从服务器计算机上或云上下载程序代码。

本领域技术人员应当理解，上面公开的各个实施例可以在不偏离发明实质的情况下做出各种变形和修改。因此，本发明的保护范围应当由所附的权利要求书来限定。

需要说明的是，上述各流程和各系统结构图中不是所有的步骤和单元都是必须的，可以根据实际的需要忽略某些步骤或单元。各步骤的执行顺序不是固定的，可以根据需要进行确定。上述各实施例中描述的装置结构可以是物理结构，也可以是逻辑结构，即，有些单元可能由同一物理实体实现，或者，有些单元可能分由多个物理实体实现，或者，可以由多个独立设备中的某些部件共同实现。

以上各实施例中，硬件单元或模块可以通过机械方式或电气方式实现。例如，一个硬件单元、模块或处理器可以包括永久性专用的电路或逻辑(如专门的处理器，FPGA或ASIC)来完成相应操作。硬件单元或处理器还可以包括可编程逻辑或电路(如通用处理器或其它可编程处理器)，可以由软件进行临时的设置以完成相应操作。具体的实现方式(机械方式、或专用的永久性电路、或者临时设置的电路)可以基于成本和时间上的考虑来确定。

上面结合附图阐述的具体实施方式描述了示例性实施例，但并不表示可以实现的或者落入权利要求书的保护范围的所有实施例。在整个本说明书中使用的术语“示例性”意味着“用作示例、实例或例示”，并不意味着比其它实施例“优选”或“具有优势”。出于提供对所描述技术的理解的目的，具体实施方式包括具体细节。然而，可以在没有这些具体细节的情况下实施这些技术。在一些实例中，为了避免对所描述的实施例的概念造成难以理解，公知的结构和装置以框图形式示出。

本公开内容的上述描述被提供来使得本领域任何普通技术人员能够实现或者使用本公开内容。对于本领域普通技术人员来说，对本公开内容进行的各种修改是显而易见的，并且，也可以在不脱离本公开内容的保护范围的情况下，将本文所定义的一般性原理应用于其它变型。因此，本公开内容并不限于本文所描述的示例和设计，而是与符合本文公开的原理和新颖性特征的最广范围相一致。

Claims (20)

1.一种用于业务请求处理的方法，包括：

确定业务请求处理需要调用的多个服务提供方；

对各个所述服务提供方的服务能力进行评估；

基于各个所述服务提供方的服务能力评估结果来确定所述各个服务提供方的调用顺序；

按照所确定的调用顺序调用所述多个服务提供方来提供对应的服务。

2.如权利要求1所述的方法，还包括：

根据针对所述多个服务提供方调用的响应结果来处理所述业务请求。

3.如权利要求1所述的方法，其中，所述对各个服务提供方的服务能力进行评估包括：

获取所述各个服务提供方的响应性能指标；以及

基于所述响应性能指标，来对所述各个服务提供方的服务能力进行评估。

4.如权利要求3所述的方法，其中，所述响应性能指标包括响应成功率指标和/或响应时长指标。

5.如权利要求3所述的方法，其中，所述对各个服务提供方的服务能力进行评估还包括：

获取所述各个服务提供方的当前处理资源信息，以及

基于所述响应性能指标，对所述各个服务提供方的服务能力进行评估包括：

基于所述响应性能指标和各个服务提供方的当前处理资源信息，对所述各个服务提供方的服务能力进行评估。

6.如权利要求5所述的方法，其中，所述处理资源信息和所述响应性能指标分别具有对应的权重因子，所述基于所述响应性能指标和各个服务提供方的当前处理资源信息，对所述各个服务提供方的服务能力进行评估包括：

基于所述响应性能指标、各个服务提供方的当前处理资源信息以及对应的权重因子，对所述各个服务提供方的服务能力进行评估。

7.如权利要求1-6中任一项所述的方法，其中，所述对各个所述服务提供方的服务能力进行评估包括：

周期或非周期地对所述各个服务提供方的服务能力进行评估。

8.如权利要求1所述的方法，还包括：

获取所述各个服务提供方的待处理业务请求数量；以及

基于各个所述服务提供方的服务能力评估结果来确定所述各个服务提供方的调用顺序包括：

基于所述各个服务提供方的待处理业务请求数量和服务能力评估结果，确定所述各个服务提供方的调用顺序。

9.如权利要求8所述的方法，其中，所述获取所述各个服务提供方的待处理业务请求数量包括：

在当前业务处理模式是排队优先模式时，获取所述各个服务提供方的待处理业务请求数量。

10.如权利要求1所述的方法，其中，基于所述各个所述服务提供方的服务能力评估结果来确定所述各个服务提供方的调用顺序包括：

基于所述各个所述服务提供方的服务能力评估结果和预定调用规则来确定所述各个服务提供方的调用顺序。

11.一种用于业务请求处理的装置，包括：

服务提供方确定单元，被配置为确定业务请求处理需要调用的多个服务提供方；

服务能力评估单元，被配置为对各个所述服务提供方的服务能力进行评估；

调用顺序确定单元，被配置为基于各个所述服务提供方的服务能力评估结果来确定所述各个服务提供方的调用顺序；

调用单元，被配置为按照所确定的调用顺序调用所述多个服务提供方来提供对应的服务。

12.如权利要求11所述的装置，还包括：

业务请求处理单元，被配置为根据针对所述多个服务提供方调用的响应结果来处理所述业务请求。

13.如权利要求11所述的装置，其中，所述服务能力评估单元包括：

性能指标获取模块，被配置为获取所述各个服务提供方的响应性能指标；以及

服务能力评估模块，被配置为基于所述响应性能指标，来对所述各个服务提供方的服务能力进行评估。

14.如权利要求13所述的装置，其中，所述服务能力评估单元还包括：

处理资源信息获取模块，被配置为获取所述各个服务提供方的当前处理资源信息，以及

所述服务能力评估模块被配置为：

基于所述响应性能指标和各个服务提供方的当前处理资源信息，对所述各个服务提供方的服务能力进行评估。

15.如权利要求14所述的装置，其中，所述处理资源信息和所述响应性能指标分别具有对应的权重因子，所述服务能力评估模块被配置为：

基于所述响应性能指标、各个服务提供方的当前处理资源信息以及对应的权重因子，对所述各个服务提供方的服务能力进行评估。

16.如权利要求11所述的装置，还包括：

业务请求数量获取单元，被配置为获取所述各个服务提供方的待处理业务请求数量；以及

所述调用顺序确定单元被配置为：

基于所述各个服务提供方的待处理业务请求数量和服务能力评估结果，确定所述各个服务提供方的调用顺序。

17.如权利要求16所述的装置，其中，所述业务请求数量获取单元被配置为：

在当前业务处理模式是排队优先模式时，获取所述各个服务提供方的待处理业务请求数量。

18.如权利要求11所述的装置，其中，所述调用顺序确定单元被配置为：

基于所述各个所述服务提供方的服务能力评估结果和预定调用规则来确定所述各个服务提供方的调用顺序。

19.一种计算设备，包括：

至少一个处理器；以及

存储器，所述存储器存储指令，当所述指令被所述至少一个处理器执行时，使得所述至少一个处理器执行如权利要求1到10中任一所述的方法。

20.一种机器可读存储介质，其存储有可执行指令，所述指令当被执行时使得所述机器执行如权利要求1到10中任一所述的方法。