CN115002219B - 服务调用方法、装置、设备、系统、存储介质及产品 - Google Patents

Abstract

本申请实施例公开了服务调用方法、装置、设备、存储介质及产品。其中，该方法包括：通过第一线程根据目标调用任务的目标调用请求数量，向预设队列中写入预设标识数据，预设队列的容量为预设数值，被写入预设队列中的预设标识数据的总数量与目标调用请求数量一致，通过预设数量的第二线程以竞争方式从预设队列中取出预设标识数据，通过成功取出预设标识数据的第二线程向目标调用任务对应的下游服务发送调用请求。通过采用上述技术方案，可以在存在批量的下游服务调用需求时，节省调用方资源，并兼顾下游服务的稳定性和可用性。

Description

服务调用方法、装置、设备、系统、存储介质及产品

技术领域

本申请实施例涉及计算机技术领域，尤其涉及服务调用方法、装置、设备、存储介质及产品。

背景技术

在数据规模越来越庞大、以及程序响应速度要求越来越来高的条件下，微服务分布式架构应运而生，服务以模块化分别部署在不同的计算平台，通过通信协议来进行通信，如远程过程调用(Remote Procedure Call，RPC)协议等，系统与系统之间的通信一般需要通过互联网，如采用超文本传输协议(Hyper Text Transfer Protocol，HTTP)协议等。

在实际业务中，可能有很多场景存在短时间内处理大批用户任务的需求，为了满足该需求，往往需要短时间内对下游服务发起批量调用，需考虑到能及时发送业务需要的信息，且要防止请求集中在某段时间内导致下游服务负担过重，进而导致整个业务需求无法完成。

发明内容

本申请实施例提供了服务调用方法、装置、设备、存储介质及产品，可以更加合理地进行服务调用。

第一方面，本申请提供了一种服务调用方法，该方法包括：

通过第一线程根据目标调用任务的目标调用请求数量，向预设队列中写入预设标识数据，其中，所述预设队列的容量为预设数值，被写入所述预设队列中的预设标识数据的总数量与所述目标调用请求数量一致；

通过预设数量的第二线程以竞争方式从所述预设队列中取出所述预设标识数据；

通过成功取出所述预设标识数据的第二线程向所述目标调用任务对应的下游服务发送调用请求。

第二方面，本申请提供了一种服务调用方法，应用于服务调用系统，所述服务调用系统中包括主节点和至少一个从节点，所述方法包括：

通过所述主节点根据所述从节点的属性信息将总调用任务拆分为至少一个目标调用任务，并将所述至少一个目标调用任务分配至所述从节点；

通过所述从节点基于所接收到的目标调用任务执行如本申请第一方面所提供的服务调用方法。

第三方面，本申请提供了一种服务调用装置，该装置包括：

标识数据写入模块，用于通过第一线程根据目标调用任务的目标调用请求数量，向预设队列中写入预设标识数据，其中，所述预设队列的容量为预设数值，被写入所述预设队列中的预设标识数据的总数量与所述目标调用请求数量一致；

标识数据取出模块，用于通过预设数量的第二线程以竞争方式从所述预设队列中取出所述预设标识数据；

调用请求发送模块，用于通过成功取出所述预设标识数据的第二线程向所述目标调用任务对应的下游服务发送调用请求。

第四方面，本申请提供了一种服务调用设备，所述服务调用设备包括：

至少一个处理器；以及

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的计算机程序，所述计算机程序被所述至少一个处理器执行，以使所述至少一个处理器能够执行本申请第一方面提供的服务调用方法，或者，执行本申请第二方面提供的服务调用方法中由所述主节点或所述从节点执行的相应步骤。

第五方面，本申请提供了一种服务调用系统，包括主节点和至少一个从节点；

所述主节点，用于根据所述从节点的属性信息将总调用任务拆分为至少一个目标调用任务，并将所述至少一个目标调用任务分配至所述从节点；

所述从节点，用于基于所接收到的目标调用任务执行本申请第一方面提供的服务调用方法。

第六方面，本申请提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序用于使处理器执行时实现本申请第一方面提供的服务调用方法，或者，实现本申请第二方面提供的服务调用方法中由所述主节点或所述从节点执行的相应步骤。

第七方面，本申请提供了一种计算机程序产品，所述计算机程序产品包括计算机程序，所述计算机程序在被处理器执行时实现本申请第一方面提供的服务调用方法，或者，实现本申请第二方面提供的服务调用方法中由所述主节点或所述从节点执行的相应步骤。

本申请实施例中提供的服务调用方案，通过第一线程根据目标调用任务的目标调用请求数量，向预设队列中写入预设标识数据，预设队列的容量为预设数值，被写入预设队列中的预设标识数据的总数量与目标调用请求数量一致，通过预设数量的第二线程以竞争方式从预设队列中取出预设标识数据，通过成功取出预设标识数据的第二线程向目标调用任务对应的下游服务发送调用请求。通过采用上述技术方案，由第一线程以向预设队列中写入标识数据的方式决定第二线程是否能够发送调用请求，有利于对调用请求的发送数量以及发送速率等进行整体控制，而一定数量的第二线程采用竞争方式从队列中取出标识数据，若取出成功，则可对下游服务发起调用，增加线程利用率，因此，可以在存在批量的下游服务调用需求时，节省调用方资源，并兼顾下游服务的稳定性和可用性。

应当理解，本部分所描述的内容并非旨在标识本申请的实施例的关键或重要特征，也不用于限制本申请的范围。本申请的其它特征将通过以下的说明书而变得容易理解。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例提供的一种服务调用方法的流程示意图；

图2为相关技术中的一种服务调用方案原理示意图；

图3为相关技术中的另一种服务调用方案原理示意图；

图4为本申请实施例提供的一种服务调用方案原理示意图；

图5为本申请实施例提供的又一种服务调用方法的流程示意图；

图6为本申请实施例提供的一种调用请求发送过程示意图；

图7为本申请实施例提供的一种调用请求发送速率变化示意图；

图8为本申请实施例提供的一种应用场景示意图；

图9为本申请实施例提供的另一种服务调用方法的流程示意图；

图10为本申请实施例提供的一种服务调用装置的结构框图；

图11为本申请实施例提供的一种服务调用设备的结构框图；

图12为本申请实施例提供的一种服务调用系统的结构框图。

具体实施方式

为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分的实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

为了便于理解本申请实施例的技术方案，下面对相关应用场景进行介绍。本申请实施例可适用于上游服务(调用方)对下游服务(被调用方)进行调用的情况，通常为批量调用，具体的应用场景不做限定。下面以一个具体的应用场景为例，如直播系统中，直播平台可能存在短时间内批量向用户发送即时通信(Instant Messaging，IM)消息或发放虚拟资源等需求，需要短时间内对下游的直播IM消息服务或资源发放服务进行批量调用，可能导致下游服务负担过重，进而导致整个业务需求无法完成。

图1为本申请实施例提供的一种服务调用方法的流程示意图，该方法可以由服务调用装置执行，该服务调用装置可以采用硬件和/或软件的形式实现，该服务调用装置可配置于服务调用设备中。如图1所示，该方法包括：

步骤101、通过第一线程根据目标调用任务的目标调用请求数量，向预设队列中写入预设标识数据，其中，所述预设队列的容量为预设数值，被写入所述预设队列中的预设标识数据的总数量与所述目标调用请求数量一致。

示例性的，目标调用任务可以根据实际的业务需求设定，目标调用任务中可以包含需要调用的下游服务、需要发送的调用请求的数量(可记为目标调用请求数量)、以及目标完成时间(可以理解为在多长时间之内发送完成目标调用请求数量的调用请求的发送)等相关信息。如上述举例，目标调用任务可以是直播平台向用户发送IM消息，需要调用的下游服务为直播IM消息服务，目标调用请求数量可以是需要接收到IM消息的用户的数量，目标完成时间例如可以是2分钟等。

示例性的，服务调用设备接收到目标调用任务之后，可以启动第一线程和预设数量的第二线程，具体的启动时机以及先后顺序等不做限定。预设数量可以在服务调用设备中预先设置，也可以由服务调用设备从对应的配置中心获取，还可以根据目标调用任务中包含的信息(如目标调用请求数量或目标完成时间等)动态确定，具体不做限定，例如可以是50个。第一线程的数量一般为1个。

示例性的，预设队列可以理解为用于流通预设标识数据的管道，第一线程向预设队列中写入预设标识数据，而第二线程从预设队列中取出预设标识数据，实现预设标识数据的动态流动。预设标识数据的作用在于，一个预设标识数据可以代表由第一线程释放的一个调用请求的发送额度，预设标识数据的总数量一般等于总的发送额度，而总的发送额度一般等于目标调用请求数量，预设标识数据可以是任意数据，可根据实际需求设置，不同的预设标识数据的数据内容可以相同或不同。第一线程在确定可以允许发送下一个调用请求时，可以向预设队列中写入一个预设标识数据。预设队列的容量可以理解为预设队列中能够同时存储的预设标识数据的数量，若预设队列的长度与预设队列的容量相等，则说明预设队列已满，第一线程暂时无法写入新的预设标识数据，需要第二线程从预设队列中取出至少一个预设标识数据后，方可继续写入。其中，预设数值可以根据实际需求设置，一般小于目标调用请求数量，例如可以设置为1，这样，可以理解为预设队列为一个没有缓存(buffer)的管道，第一线程可以更好地确定已发送的调用请求的数量。

步骤102、通过预设数量的第二线程以竞争方式从所述预设队列中取出所述预设标识数据。

示例性的，预设数量的第二线程均可以对预设队列进行监听，当预设队列中有预设标识数据写入后，即可以竞争方式从预设队列中取出预设标识数据。其中，竞争方式可以理解为各第二线程均具备从预设队列中取出预设标识数据的能力，对于一个预设标识数据，哪个第二线程最先取出该预设标识数据，则认为该第二线程竞争成功，也即成功取出该预设标识数据。其中，若某个第二线程已成功取出一个预设标识数据，并在根据该预设标识数据进行如调用请求信息获取操作、调用请求发送操作或等待下游服务响应调用请求等，暂时不参与竞争，若已得到下游服务的响应，可重新参与竞争，从而有效利用线程资源。

步骤103、通过成功取出所述预设标识数据的第二线程向所述目标调用任务对应的下游服务发送调用请求。

示例性的，成功取出预设标识数据的第二线程可以认为通过赢得竞争而获得了发送一个调用请求的权限，该第二线程可以从业务侧设备、存储服务(如Redis等)或数据库中获取用于发送调用请求的相关信息(可理解为业务数据)，如下游服务的地址或请求内容等，向所述目标调用任务对应的下游服务发送调用请求，以完成一次服务调用。需要说明的是，对于不同的预设标识数据来说，可能被同一个第二线程或不同的第二线程取出。

示例性的，在写入的预设标识数据的总数量未达到目标调用请求数量之前，第一线程可以持续写入预设标识数据，第二线程可以不断地取出预设标识数据并发送调用请求，在所有写入的预设标识数据均被取出并由相应第二线程完成调用请求的发送后，可认为目标调用任务的所有调用请求发送完毕。

本申请实施例中提供的服务调用方法，通过第一线程根据目标调用任务的目标调用请求数量，向预设队列中写入预设标识数据，预设队列的容量为预设数值，被写入预设队列中的预设标识数据的总数量与目标调用请求数量一致，通过预设数量的第二线程以竞争方式从预设队列中取出预设标识数据，通过成功取出预设标识数据的第二线程向目标调用任务对应的下游服务发送调用请求。通过采用上述技术方案，由第一线程以向预设队列中写入标识数据的方式决定第二线程是否能够发送调用请求，有利于对调用请求的发送数量以及发送速率等进行整体控制，而一定数量的第二线程采用竞争方式从队列中取出标识数据，若取出成功，则可对下游服务发起调用，增加线程利用率，因此，可以在存在批量的下游服务调用需求时，节省调用方资源，并兼顾下游服务的稳定性和可用性。

在一些使用场景中，需要在规定的时间内完成调用任务，也即对上述的目标完成时间有一定的要求。相关技术中，服务间定时批量调用方案主要有两种模式。

第一种是固定线程数模式，图2为相关技术中的一种服务调用方案原理示意图，如图2所示，G表示一个线程，这种模式使用固定的线程数(C)，在指定的时间内对下游服务进行不断的调用以处理业务需求，需要发送的请求数量为N，每个线程需要发送N/C个请求。这种方式可能无法达到业务指定的时效要求，原因是调用方的并发数是固定的，如果某个请求因为网络原因导致响应很慢，会导致调用方阻塞，从而无法在指定的时间内把所有业务请求都处理完，比如为满足业务需求所预先指定的速率是100/s(如2分钟内对12000个用户发送IM消息等)，也就是1秒内处理100个请求，但是由于这100个线程不一定在1s内就释放了，因为可能下游服务端1s内还没有响应返回这个请求，所以导致第2秒的时候，并发数无法达到100/s。

第二种是固定每一秒都新开固定数量的线程去发起请求，图3为相关技术中的另一种服务调用方案原理示意图，如图3所示，比如第1秒的时候开启100个线程去发起100个请求，第2秒的时候再开起100个线程，这种方案的实现相当于把1秒划分成100份，也就是100个10毫秒(ms)，每隔10ms就开启一个线程发起请求。然而，这种方式存在两个个问题，第一个问题是可能用户需要的速率很大，比如是1w，那第一秒就要开启1w个线程，这会消耗调用方服务的大量资源，第二个问题是需要多大的速率，就需要将1s划分成对应的份数，这种方式，会因为操作系统的上下文切换时间导致大约达到切割成1000份以上的时候，也就是每次间隔时间小于1ms时，操作系统无法在指定时间内迅速切换回来，比如间隔时间0.5ms,0.5ms过后需要唤醒，但由于操作系统切换上下文需要时间，无法很快唤醒，实际上可能需要间隔0.3ms才能达到0.5ms的速率，导致无法在1秒内发出对应数量的请求。因此，相关技术中的方案无法很好地满足既能保证在指定时间内完成对应的业务请求数，又要保证下游服务的稳定和可用性。

在本申请的一些实施例中，该方法还可包括：在通过所述第一线程向所述预设队列中写入所述预设标识数据的过程中，若写入失败，则启动新的第二线程；通过所述新的第二线程从所述预设队列中取出所述预设标识数据，并向所述目标调用任务对应的下游服务发送调用请求。这样设置的好处在于，当出现第一线程暂时无法写入预设标识数据的情况时，说明预设数量的第二线程目前均处于忙碌状态，正在发送调用请求，没有空闲的第二线程可以从预设队列中取出预设标识数据，通过创建新的第二线程参与调用请求的发送，可以有效保证目标调用任务的执行效率，从而有利于保证在目标完成时间内完成目标调用任务。

其中，在启动新的第二线程时，启动数量不做限定，可以是一个或多个，可以根据实际需求设置。在启动新的第二线程后，新的第二线程也可以参与后续的预设标识数据获取的竞争，这样，预设数量可以进行更新，也即在当前的预设数量基础上增加新的第二线程的数量。

图4为本申请实施例提供的一种服务调用方案原理示意图，如图4所示，G1表示第一线程，G2表示第二线程，假设初始的预设数量为50，也即，服务调用设备在接收到目标调用任务后，可启动50个初始的第二线程(如图中的初始线程)，第一线程可以按照预设写入策略(如写入间隔或写入频率等)向预设队列中写入预设标识数据，由50个G2通过竞争方式获取预设标识数据，并在成功获取后向下游服务发送调用请求，若G1写入预设标识数据失败，则可以创建新的G2(如图中的新增线程)，由新增的G2获取预设标识数据并进行调用请求的发送。

在一些实施例中，该方法还可包括：在通过所述第一线程向所述预设队列中写入第一预设标识数据后，基于预设方式确定目标等待时长，并在经过所述目标等待时长后，向所述预设队列中写入第二预设标识数据。这样设置的好处在于，可以灵活地确定每两个预设标识数据的写入间隔时间，从而更加精准地控制目标调用任务的执行速率和总执行时长。其中，第一预设标识数据可以是任意的预设标识数据(最后一个预设标识数据除外)，第二预设标识数据为第一预设标识数据的下一个预设标识数据。预设方式的具体内容不做限定，可以根据实际需求设置。

在一些实施例中，在所述基于预设方式确定目标等待时长之前，还包括：确定预期发送请求数量；若已发送请求数量小于所述预期发送请求数量，则即时向所述预设队列中写入所述第二预设标识数据。其中，预期发送请求数量可以理解为根据目标调用任务所确定的当前时刻理论上需要已经发送的调用请求的数量，可以根据目标调用请求数量和目标完成时间等目标调用任务的相关信息确定；已发送请求数量可以理解为当前时刻已经成功发送的调用请求的数量，可以根据已经写入预设队列的预设标识数据的数量确定，也可以根据第二线程已经发送出去的调用请求的数量确定，还可以根据第二线程接收到下游服务的响应的数量确定等。若已发送请求数量小于预期发送请求数量，则说明当前目标调用任务的执行进度落后，通过立即向预设队列中写入第二预设标识数据，可以有效提高调用请求的发送速度，进而提高在目标完成时间内发送目标调用请求数量的调用请求的需求。

示例性的，第一线程可以理解为在被写入预设队列中的预设标识数据的总数量达到目标调用请求数量之前，执行死循环，每次循环，先确定写入下一个预设标识数据的时机，是即时写入还是等待目标等待时长后写入，达到写入时机后，尝试写入下一个预设标识数据，若写入失败，则新建第二线程，并再次尝试写入。

在一些实施例中，所述基于预设方式确定目标等待时长，包括：基于第一预设方式，根据预期速率、已消耗时长和已发送请求数量，确定目标等待时长，其中，所述预期速率根据所述目标调用任务的目标完成时长与所述目标调用请求数量的商确定，所述已消耗时长根据当前时刻与所述目标调用任务的开始执行时刻的差确定。这样设置的好处在于，可以准确地确定目标等待时长，更好地对调用请求的发送速率进行控制，有利于在目标完成时长之内相对均匀地发出调用请求，有利于发挥服务调用设备的更高的性能，有效提高了调用方单机的请求能力，也可以有效缓解下游服务的压力。

示例性的，预期速率可以等于目标完成时长与目标调用请求数量的商，已消耗时长可以等于当前时刻与开始执行时刻的差。

在一些实施例中，所述基于第一预设方式，根据预期速率、已消耗时长和已发送请求数量，确定目标等待时长，包括：根据已发送请求数量确定目标发送数量，其中，所述目标发送数量为所述已发送请求数量与1的和；根据所述目标发送数量与所述预期速率的商，确定目标时长；根据所述目标时长与所述已消耗时长的差，确定目标等待时长。这样设置的好处在于，可以精准地确定目标等待时长。

示例性的，目标发送数量＝已发送请求数+1，目标发送数量与预期速率的商可以用于表示按照预期速率进行调用请求发送的情况下，发送完下一个调用请求需要消耗的预期时长，也即目标时长。在目标时长基础上减去已消耗时长，则可以得到发送下一个调用请求的时刻距离当前时刻的时长，也即目标等待时长，这样，可以使得调用请求的实时发送速率的变化更加平缓，且接近预期速率。

在一些应用场景中，可以更加灵活地对发送速率进行控制，例如，随着系统用户数的增长，需要在一段时间处理越来越多的请求数，可能需要在这个过程中递增请求的发送速率。

在一些实施例中，所述基于预设方式确定目标等待时长，包括：基于第二预设方式，根据初始速率、预设增长率、已消耗时长和已发送请求数量，确定目标等待时长，其中，所述初始速率和所述预设增长率根据所述目标调用任务设定，所述已消耗时长根据当前时刻与所述目标调用任务的开始执行时刻的差确定。这样设置的好处在于，可以更加灵活地控制调用请求的发送速率动态增长，满足更加丰富的应用场景。其中，速率增长方式可以匀速增长，还可以是指数增长，预设增长率可以是预先设定的固定值，也可以动态变化的值，具体不做限定。

在一些实施例中，所述基于第二预设方式，根据初始速率、预设增长率、已消耗时长和已发送请求数量，确定目标等待时长，包括：根据已发送请求数量和预期发送请求数量确定目标数量差值，其中，所述目标数量差值为所述已发送请求数量与1的和，减去所述预期发送请求数量；根据所述初始速率、所述预设增长率以及所述已消耗时长，确定目标速率；根据所述目标速率与所述目标数量差值的乘积，确定目标等待时长。这样设置的好处在于，可以更加精准地计算满足调用请求的实时发送速率动态增长的目标等待时长。

图5为本申请实施例提供的又一种服务调用方法的流程示意图，本申请实施例在上述各可选实施例基础上进行优化，如图5所示，该方法包括：

步骤501、接收到目标调用任务，创建第一线程和预设数量的第二线程，执行步骤502和步骤503。

示例性的，服务调用设备在接收到目标调用任务后，可以创建第一线程和预设数量的第二线程，随后分别通过第一线程和第二线程执行步骤502和步骤503，需要说明的是，步骤502和步骤503的执行顺序不做限定。

步骤502、通过第一线程向预设队列中写入当前预设标识数据，执行步骤504。

步骤503、通过第二线程以竞争方式从预设队列中取出预设标识数据，并通过成功取出预设标识数据的第二线程向目标调用任务对应的下游服务发送调用请求。

需要说明的是，步骤503在流程结束之前可以重复执行。

步骤504、通过第一线程判断是否写入成功，若是，则执行步骤505；否则，执行步骤508以及返回执行步骤502。

需要说明的是，在启动新的第二线程后，该新的第二线程处于空闲状态，可以快速从预设队列中取出预设标识数据，第一线程可以重新尝试写入当前需要写入的预设标识数据。

步骤505、通过第一线程判断已写入的预设标识数据的数量是否达到目标调用任务的目标调用请求数量，若是，则结束流程；否则，执行步骤506。

示例性的，若已写入的预设标识数据的数量已达到目标调用请求数量，则说明不需要继续写入，第一线程的任务结束，此时第二线程若未完成全部调用请求的发送，则需要完成发送后，结束整个流程。

步骤506、通过第一线程确定预期发送请求数量，并判断已发送请求数量是否小于预期发送请求数量，若是，则返回执行步骤502；否则，执行步骤507。

示例性的，预期发送请求数量的确定方式可以与下述预设方式相关，也即与发送速率的控制方式相关，具体确定方式将在下文中介绍。

步骤507、通过第一线程基于预设方式确定目标等待时长，并等待目标等待时长，返回执行步骤502。

其中，预设方式可以根据实际的目标调用任务的需求设定。

示例性的，第一预设方式对应于近似匀速地控制调用请求的发送速率。假设目标调用请求数量为30万，目标完成时长为5分钟，预期速率记为rate，则rate＝300000/(60*5)＝1000，也即1秒内需要发送1000个调用请求，也即1ms发出1个请求。预期发送请求数量记为expectedCnt，已消耗时长记为costTime，则：

expectedCnt＝rate*costTime

若已发送请求数量记为cnt，则在cnt<expectedCnt时，即时写入下一个预设标识数据，否则，计算目标等待时长。若目标等待时长sleepTime，则可以通过以下表达式计算sleepTime：

sleepTime＝(1/rate*(cnt+1))-costTime

也即相当于，根据下一次请求的时间减去当前的时间，得到目标等待时长。

图6为本申请实施例提供的一种调用请求发送过程示意图，如图6所示，白色方框代表发送调用请求的时间长度，数字代表第几次，也即第几个调用请求，阴影方框代表目标等待时长，可理解为休眠(sleep)时间。第1个请求和第2个请求发送完毕后，均可以等待目标等待时长(分别为a和b)之后再写入下一个预设标识数据，而第3个请求的消耗时间较长，到第3毫秒时，已经发送请求数量小于预期发送请求数量，则可立即向预设队列中写入下一个预设标识数据，以追赶任务进度。

示例性的，第二预设方式对应于控制调用请求的发送速率近似均匀地增长。假设预期发送请求数量和已消耗时长满足一元二次方程，某一时刻的预期发送请求数量可以表示为：

expectedCnt＝slope*costTime²+startRate*costTime

其中，startRate表示初始速率，slope表示预设增长率。

若已发送请求数量记为cnt，则在cnt<expectedCnt时，即时写入下一个预设标识数据，否则，计算目标等待时长。具体可以通过以下表达式计算sleepTime：sleepTime＝(cnt+1-expectedCnt)*(1/(slope*costTime+startRate))

图7为本申请实施例提供的一种调用请求发送速率变化示意图，如图7所示，发送速率可以线性增长。记某一时刻的速率为queryRate，则queryRate＝slope*costTime+startRate。

步骤508、启动新的第二线程，通过新的第二线程从预设队列中取出预设标识数据，并向目标调用任务对应的下游服务发送调用请求，返回执行步骤503。

本申请实施例提供的服务调用方法，由第一线程以向预设队列中写入标识数据的方式决定第二线程是否能够发送调用请求，且能够动态地决定写入下一个标识数据的时机，可以对调用请求的发送数量以及发送速率等进行合理地整体控制，而一定数量的第二线程采用竞争方式从队列中取出标识数据，若取出成功，则可对下游服务发起调用，增加线程利用率，若第一线程在尝试写入标识数据时发现写入失败，则可启动新的第二线程参与调用请求的发送，可以在存在限时的批量的下游服务调用需求时，避免一次性创建大量线程，通过预设队列以及消费竞争模式实现柔性扩展线程，极大地节约了调用方资源的同时，动态调整发送速率，保证在规定时间内完成服务调用任务，并保证了下游服务的稳定性和可用性，此外，提供多种速率控制方式，可以灵活的处理业务中的特定需求以及验证下游服务的并发能力等。

本申请实施例中，调用服务可以采用分布式部署方式，可以应对较多的请求任务在指定时间内完成业务的需求。调用服务可以由服务调用系统实现，服务调用系统中可以包括主节点和至少一个从节点，可选的，可以包括一个主节点和至少两个从节点。图8为本申请实施例提供的一种应用场景示意图，该场景中包括1个主节点和n个从节点，n的具体数量不做限定，主节点将接收到的总调用任务拆分成n个目标调用任务，并分配至n个从节点。

图9为本申请实施例提供的另一种服务调用方法的流程示意图，如图9所示，该方法可包括：

步骤901、通过主节点根据从节点的属性信息将总调用任务拆分为至少一个目标调用任务，并将至少一个目标调用任务分配至所述从节点。

在进行总调用任务拆分时，所考虑的从节点的属性信息可以包括从节点的处理能力信息以及工作状态信息等。示例性的，拆分后的目标调用任务的数量一般与从节点的数量相同，若服务调用系统中存在异常从节点，导致其无法正常接收目标调用任务，则拆分后的目标调用任务的数量可以与处于正常状态的从节点的数量相同。示例性的，可以根据各从节点的处理能力信息确定对应的目标调用任务中的目标调用请求数量，其中，处理能力信息可以包括负载情况，如处理器负载率以及内存负载率等等。

步骤902、通过所述从节点基于所接收到的目标调用任务执行服务调用方法。

示例性的，从节点所执行的服务调用方法的具体过程可参见前文相关描述，此处不再赘述。

本申请实施例提供的服务调用方法，采用分布式服务调用系统实现，由主节点根据从节点的属性信息对总调用任务进行合理拆分并分配给各从节点，由从节点分别执行接收到的目标调用任务，可更加高效合理地执行调用任务，其可以节省分布式环境中的调用方服务器资源。

可选的，在通过所述主节点将所述至少一个目标调用任务分配至所述从节点之后，还可包括：通过所述主节点对所述从节点的工作状态进行探测，在探测到异常从节点后，确定当前的正常从节点，并根据所述正常从节点的属性信息将剩余调用任务拆分为至少一个新的目标调用任务，并将所述至少一个新的目标调用任务重新分配至所述正常从节点。其中，剩余调用任务可根据总调用任务对应的总调用请求数量与各从节点反馈的已发送请求数量的差确定。这样设置的好处在于，可以及时发现异常从节点，并对任务进行重新分配，保证任务的正常执行。

在一些实施例中，还可包括：通过所述主节点向所述从节点下发调用策略信息，用于指示对应的从节点根据所述调用策略信息执行服务调用方法，其中，所述调用策略信息包括所述预设数值、所述预设数量以及所述预设方式的类型中的至少一项。其中，所述预设方式的类型包括第一预设方式和第二预设方式。这样设置的好处在于，可以更加灵活地控制从节点的任务执行，从整体上更加高效合理地完成调用任务。

图10为本申请实施例提供的一种服务调用装置的结构框图，该装置可由软件和/或硬件实现，一般可集成在服务调用设备中，可通过执行服务调用方法来进行服务调用请求的发送。如图10所示，该装置包括：

标识数据写入模块1001，用于通过第一线程根据目标调用任务的目标调用请求数量，向预设队列中写入预设标识数据，其中，所述预设队列的容量为预设数值，被写入所述预设队列中的预设标识数据的总数量与所述目标调用请求数量一致；

标识数据取出模块1002，用于通过预设数量的第二线程以竞争方式从所述预设队列中取出所述预设标识数据；

调用请求发送模块1003，用于通过成功取出所述预设标识数据的第二线程向所述目标调用任务对应的下游服务发送调用请求。

本申请实施例提供的服务调用装置，通过第一线程根据目标调用任务的目标调用请求数量，向预设队列中写入预设标识数据，预设队列的容量为预设数值，被写入预设队列中的预设标识数据的总数量与目标调用请求数量一致，通过预设数量的第二线程以竞争方式从预设队列中取出预设标识数据，通过成功取出预设标识数据的第二线程向目标调用任务对应的下游服务发送调用请求。通过采用上述技术方案，由第一线程以向预设队列中写入标识数据的方式决定第二线程是否能够发送调用请求，有利于对调用请求的发送数量以及发送速率等进行整体控制，而一定数量的第二线程采用竞争方式从队列中取出标识数据，若取出成功，则可对下游服务发起调用，增加线程利用率，因此，可以在存在批量的下游服务调用需求时，节省调用方资源，并兼顾下游服务的稳定性和可用性。

可选的，该装置还可包括：

新线程启动模块，用于在通过所述第一线程向所述预设队列中写入所述预设标识数据的过程中，若写入失败，则启动新的第二线程；

发送模块，用于通过所述新的第二线程从所述预设队列中取出所述预设标识数据，并向所述目标调用任务对应的下游服务发送调用请求。

可选的，该装置还可包括：

等待模块，用于在通过所述第一线程向所述预设队列中写入第一预设标识数据后，基于预设方式确定目标等待时长，并在经过所述目标等待时长后，向所述预设队列中写入第二预设标识数据。

可选的，该装置还可包括：

预期发送请求数量确定模块，用于在所述基于预设方式确定目标等待时长之前，确定预期发送请求数量；

即时写入模块，用于在已发送请求数量小于所述预期发送请求数量的情况下，即时向所述预设队列中写入所述第二预设标识数据。

可选的，所述基于预设方式确定目标等待时长，包括：

基于第一预设方式，根据预期速率、已消耗时长和已发送请求数量，确定目标等待时长，其中，所述预期速率根据所述目标调用任务的目标完成时长与所述目标调用请求数量的商确定，所述已消耗时长根据当前时刻与所述目标调用任务的开始执行时刻的差确定。

可选的，所述基于第一预设方式，根据预期速率、已消耗时长和已发送请求数量，确定目标等待时长，包括：

根据已发送请求数量确定目标发送数量，其中，所述目标发送数量为所述已发送请求数量与1的和；

根据所述目标发送数量与所述预期速率的商，确定目标时长；

根据所述目标时长与所述已消耗时长的差，确定目标等待时长。

可选的，所述基于预设方式确定目标等待时长，包括：

基于第二预设方式，根据初始速率、预设增长率、已消耗时长和已发送请求数量，确定目标等待时长，其中，所述初始速率和所述预设增长率根据所述目标调用任务设定，所述已消耗时长根据当前时刻与所述目标调用任务的开始执行时刻的差确定。

可选的，所述基于第二预设方式，根据初始速率、预设增长率、已消耗时长和已发送请求数量，确定目标等待时长，包括：

根据已发送请求数量和预期发送请求数量确定目标数量差值，其中，所述目标数量差值为所述已发送请求数量与1的和，减去所述预期发送请求数量；

根据所述初始速率、所述预设增长率以及所述已消耗时长，确定目标速率；

根据所述目标速率与所述目标数量差值的乘积，确定目标等待时长。

本申请实施例提供了一种服务调用设备，该服务调用设备中可集成本申请实施例提供的服务调用装置。图11为本申请实施例提供的一种服务调用设备的结构框图。服务调用设备1100包括处理器1101，以及与处理器1101通信连接的存储器1102，其中，存储器1102存储有可被处理器1101执行的计算机程序，计算机程序被处理器1101执行，以使所述处理器1101能够执行本申请任一实施例所述的服务调用方法中的相应步骤。其中，处理器的数量可以是一个或多个，图11中以一个处理器为例。

图12为本申请实施例提供的一种服务调用系统的结构框图，如图12所示，该系统中包括主节点1201和至少一个从节点1202。其中，图中以2个从节点为例，具体数量不做限定。

所述主节点1201，用于根据所述从节点的属性信息将总调用任务拆分为至少一个目标调用任务，并将所述至少一个目标调用任务分配至所述从节点；

所述从节点1202，用于基于所接收到的目标调用任务执行服务调用方法。

本申请实施例提供的服务调用系统，采用分布式系统实现，由主节点根据从节点的属性信息对总调用任务进行合理拆分并分配给各从节点，由从节点分别执行接收到的目标调用任务，可更加高效合理地执行调用任务。

可选的，主节点还用于：向所述从节点下发调用策略信息，用于指示对应的从节点根据所述调用策略信息执行服务调用方法，其中，所述调用策略信息包括所述预设数值、所述预设数量以及所述预设方式的类型中的至少一项。

本申请实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序用于使处理器执行时实现本申请任一实施例所述的服务调用方法中的相应步骤。

本申请实施例还提供一种计算机程序产品，所述计算机程序产品包括计算机程序，所述计算机程序在被处理器执行时实现如本申请实施例提供的服务调用方法中的相应步骤。

上述实施例中提供的服务调用装置、设备、系统、存储介质及产品可执行本申请任意实施例所提供的服务调用方法，具备执行该方法相应的功能模块和有益效果。未在上述实施例中详尽描述的技术细节，可参见本申请任意实施例所提供的服务调用方法。

Claims (14)

1.一种服务调用方法，其特征在于，包括：

通过第一线程根据目标调用任务的目标调用请求数量，向预设队列中写入预设标识数据，其中，所述预设队列的容量为预设数值，被写入所述预设队列中的预设标识数据的总数量与所述目标调用请求数量一致；

通过预设数量的第二线程以竞争方式从所述预设队列中取出所述预设标识数据；

通过成功取出所述预设标识数据的第二线程向所述目标调用任务对应的下游服务发送调用请求。

2.根据权利要求1所述的方法，其特征在于，还包括：

在通过所述第一线程向所述预设队列中写入所述预设标识数据的过程中，若写入失败，则启动新的第二线程；

通过所述新的第二线程从所述预设队列中取出所述预设标识数据，并向所述目标调用任务对应的下游服务发送调用请求。

3.根据权利要求1所述的方法，其特征在于，还包括：

在通过所述第一线程向所述预设队列中写入第一预设标识数据后，基于预设方式确定目标等待时长，并在经过所述目标等待时长后，向所述预设队列中写入第二预设标识数据。

4.根据权利要求3所述的方法，其特征在于，在所述基于预设方式确定目标等待时长之前，还包括：

确定预期发送请求数量；

若已发送请求数量小于所述预期发送请求数量，则即时向所述预设队列中写入所述第二预设标识数据。

5.根据权利要求3所述的方法，其特征在于，所述基于预设方式确定目标等待时长，包括：

基于第一预设方式，根据预期速率、已消耗时长和已发送请求数量，确定目标等待时长，其中，所述预期速率根据所述目标调用任务的目标完成时长与所述目标调用请求数量的商确定，所述已消耗时长根据当前时刻与所述目标调用任务的开始执行时刻的差确定。

6.根据权利要求5所述的方法，其特征在于，所述基于第一预设方式，根据预期速率、已消耗时长和已发送请求数量，确定目标等待时长，包括：

根据已发送请求数量确定目标发送数量，其中，所述目标发送数量为所述已发送请求数量与1的和；

根据所述目标发送数量与所述预期速率的商，确定目标时长；

根据所述目标时长与所述已消耗时长的差，确定目标等待时长。

7.根据权利要求3所述的方法，其特征在于，所述基于预设方式确定目标等待时长，包括：

基于第二预设方式，根据初始速率、预设增长率、已消耗时长和已发送请求数量，确定目标等待时长，其中，所述初始速率和所述预设增长率根据所述目标调用任务设定，所述已消耗时长根据当前时刻与所述目标调用任务的开始执行时刻的差确定。

8.根据权利要求7所述的方法，其特征在于，所述基于第二预设方式，根据初始速率、预设增长率、已消耗时长和已发送请求数量，确定目标等待时长，包括：

根据已发送请求数量和预期发送请求数量确定目标数量差值，其中，所述目标数量差值为所述已发送请求数量与1的和，减去所述预期发送请求数量；

根据所述初始速率、所述预设增长率以及所述已消耗时长，确定目标速率；

根据所述目标速率与所述目标数量差值的乘积，确定目标等待时长。

9.一种服务调用方法，其特征在于，应用于服务调用系统，所述服务调用系统中包括主节点和至少一个从节点，所述方法包括：

通过所述主节点根据所述从节点的属性信息将总调用任务拆分为至少一个目标调用任务，并将所述至少一个目标调用任务分配至所述从节点；

通过所述从节点基于所接收到的目标调用任务执行如权利要求1-8任一所述的服务调用方法。

10.根据权利要求9所述的方法，其特征在于，还包括：

通过所述主节点向所述从节点下发调用策略信息，其中，所述调用策略信息包括所述预设数值、所述预设数量以及预设方式的类型中的至少一项。

11.一种服务调用装置，其特征在于，包括：

标识数据写入模块，用于通过第一线程根据目标调用任务的目标调用请求数量，向预设队列中写入预设标识数据，其中，所述预设队列的容量为预设数值，被写入所述预设队列中的预设标识数据的总数量与所述目标调用请求数量一致；

标识数据取出模块，用于通过预设数量的第二线程以竞争方式从所述预设队列中取出所述预设标识数据；

调用请求发送模块，用于通过成功取出所述预设标识数据的第二线程向所述目标调用任务对应的下游服务发送调用请求。

12.一种服务调用设备，其特征在于，所述服务调用设备包括：

至少一个处理器；以及

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的计算机程序，所述计算机程序被所述至少一个处理器执行，以使所述至少一个处理器能够执行权利要求1-8任一项所述的服务调用方法，或者，执行如权利要求9-10任一项所述的服务调用方法中由所述主节点或所述从节点执行的相应步骤。

13.一种服务调用系统，其特征在于，包括主节点和至少一个从节点；

所述主节点，用于根据所述从节点的属性信息将总调用任务拆分为至少一个目标调用任务，并将所述至少一个目标调用任务分配至所述从节点；

所述从节点，用于基于所接收到的目标调用任务执行如权利要求1-8任一所述的服务调用方法。

14.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机程序，所述计算机程序用于使处理器执行时实现权利要求1-8中任一所述的服务调用方法，或者，实现如权利要求9-10任一项所述的服务调用方法中由所述主节点或所述从节点执行的相应步骤。