CN112286698A - 远程过程调用方法、装置以及远程过程调用执行方法 - Google Patents

Abstract

本申请实施例提供了一种远程过程调用方法、装置、远程过程调用执行方法、电子设备和计算机可读存储介质，解决了现有远程过程客户端式维护成本高、通信效率低的问题。该远程过程调用方法包括：将业务数据进行序列化处理，得到第一序列化数据；将远程过程调用配置信息和所述第一序列化数据进行序列化处理，得到第二序列化数据；将所述第二序列化数据存储在发送缓冲区；以及将所述发送缓冲区的所述第二序列化数据发送至目标服务器。

Description

远程过程调用方法、装置以及远程过程调用执行方法

技术领域

本申请涉及计算机通信技术领域，具体涉及一种远程过程调用方法、装置、远程过程调用执行方法、电子设备和计算机可读存储介质。

背景技术

在分布式***中，远程过程调用(RPC，Remote Procedure Call)技术作为进程间通信技术的一种，被广泛应用于网络通信中。RPC隐藏了底层网络通信细节，并且提供接口描述语言以及相应的编译器，方便了用户的使用。业内的一些软件公司，例如Apache和Google都推出了自己的分布式RPC框架，如Apache的thrift，Google的gRPC。但这些分布式RPC框架都无法支持负载均衡、下游服务发现、服务健康状态监控、调用链跟踪分析等分布式管理功能，因而通信效率低。此外，这些分布式RPC框架由于与具体业务关联较大，使用难度较大，对开发人员要求较高。由于这些框架的底层通信和应用层代码较为相关，一旦底层框架发生变化，例如由thrift切换为gRPC时，就不得不修改较多的应用层代码；同时由于通信过程基于实际的业务数据进行，一旦通信双方约定的业务数据发生了变化，也需要修改较多的应用层代码。这种需要修改很多应用层代码才能适应不同业务场景需求，不仅会显著提高维护正常通信的人力成本，还会显著影响通信效率。

发明内容

有鉴于此，本申请实施例提供了一种远程过程调用方法、装置、远程过程调用执行方法、电子设备和计算机可读存储介质，解决了现有远程过程客户端式维护成本高和通信效率低的问题。

根据本申请的一方面，本申请一实施例提供的一种远程过程调用方法包括：将业务数据进行序列化处理，得到第一序列化数据；将远程过程调用配置信息和所述第一序列化数据进行序列化处理，得到第二序列化数据；将所述第二序列化数据存储在发送缓冲区；以及将所述发送缓冲区的所述第二序列化数据发送至目标服务器。

根据本申请的另一方面，本申请一实施例提供的一种远程过程调用执行方法包括：接收到来自客户端的发送缓冲区的第二序列化数据；以及对所述第二序列化数据进行反序列化以获取业务数据，并基于业务数据执行所述客户端所调用的远程过程；其中，所述第二序列化数据由所述客户端基于以下步骤生成：将所述业务数据进行序列化处理，得到第一序列化数据；将远程过程调用配置信息和所述第一序列化数据进行序列化处理，得到所述第二序列化数据。

根据本申请的一方面，本申请一实施例提供的一种远程过程调用装置包括：第一序列化模块，配置为将业务数据进行序列化处理，得到第一序列化数据；第二序列化模块，配置为将远程过程调用配置信息和所述第一序列化数据进行序列化处理，得到第二序列化数据；存储模块，配置为将所述第二序列化数据存储在发送缓冲区；以及传输模块，配置为将所述发送缓冲区的所述第二序列化数据发送至目标服务器。

根据本申请的另一方面，提供了一种电子设备，包括：处理器；存储器；以及存储在存储器中的计算机程序指令，计算机程序指令在被处理器运行时使得处理器执行如上述任一项所述的远程过程调用方法。

根据本申请的另一方面，提供了一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序指令，所述计算机程序指令在被处理器运行时使得所述处理器执行如前任一所述的远程过程调用方法。

根据本申请的另一方面，提供了一种计算机程序产品，包括计算机程序指令，所述计算机程序指令在被处理器运行时使得处理器执行如上述任一所述的远程过程调用方法。

本申请实施例提供的一种远程过程调用方法、装置、远程过程调用执行方法、电子设备和计算机可读存储介质，在对通信双方约定的业务数据进行序列化时，采用了两步序列化。第一步是将业务数据序列化为第一序列化数据以实现消息序列化，第二步是将第一序列化数据和远程过程调用配置信息一起序列化为第二序列化数据以实现接口序列化，由此实现了消息序列化和接口序列化的分离。这样当底层框架发送变化时，仅需要对接口序列化的应用层代码进行修改即可，而消息序列化的应用层代码可保持不动；当业务数据发生变化时，仅需要对消息序列化的应用层代码进行修改即可，而接口序列化的应用层代码可保持不动。由此可见，通过这种序列化处理的方式，可显著减少为了适应不同业务场景需求时的应用层代码修改，从而可有效降低维护正常通信的人力成本，并提高通信效率。

附图说明

图1所示为本申请一实施例提供的一种远程过程调用方法的流程示意图。

图2所示为本申请一实施例提供的一种远程过程调用方法的流程示意图。

图3所示为本申请一实施例提供的一种远程过程调用方法中确定目标服务器的流程示意图。

图4所示为本申请一实施例提供的远程过程调用方法中确定调度策略的流程示意图。

图5所示为本申请一实施例提供的远程过程调用方法中无状态轮询调度策略的流程示意图。

图6所示为本申请一实施例提供的远程过程调用方法中有状态调度策略的流程示意图。

图7所示为本申请一实施例提供的远程过程调用方法中基于响应时间调度策略的流程示意图。

图8所示为本申请一实施例提供的远程过程调用方法中基于剩余计算能力调度策略的流程示意图。

图9所示为本申请一实施例提供的远程过程调用方法中获取可用服务器列表的过程的原理示意图。

图10所示为本申请一实施例提供的一种远程过程调用装置的结构示意图。

图11所示为本申请另一实施例提供的一种远程过程调用装置的结构示意图。

图12所示为本申请一实施例提供的电子设备的结构示意图。

具体实施方式

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

申请概述

如上，传统的远程过程调用方法虽然能够起到远程过程调用的目的，但由于与具体业务关联较大，一旦所应用的具体业务场景发生变化，就需要对应用层代码做较大的调整，从而提高了维护正常通信的人力成本，且降低了通信效率。

针对上述的技术问题，本申请的基本构思是提出一种远程过程调用方法、装置、远程过程调用执行方法、电子设备和计算机可读存储介质，在底层框架的序列化之上再做一层抽象，将消息序列化过程和接口序列化过程分离。这样业务信息的更新和底层框架的更新不会互相干扰，以使得该远程过程调用框架能够适用于不同场景需求。

需要说明的是，本申请所提供的远程过程调用方法可以应用于任何场景下的远程过程调用过程。具体而言，远程调用过程就是客户端通过调用目标服务器上的资源来进行特定操作的过程，该资源可为用于完成任何应用场景下的特定操作的计算资源或存储资源。本申请对该远程过程调用方法所适用的具体应用场景并不做限定。

在介绍了本申请的基本原理之后，下面将参考附图来具体介绍本申请的各种非限制性实施例。

示例性远程过程调用方法

图1所示为本申请一实施例提供的一种远程过程调用方法的流程示意图。如图1所示，该远程过程调用方法包括如下步骤：

步骤101：将业务数据进行序列化处理，得到第一序列化数据。

业务数据为远程调用目标服务器上的过程所需要的数据，客户端需要将该业务数据发送给目标服务器，目标服务器在接收到该业务数据后，即可基于该业务数据执行客户端所调用的远程过程。应当理解，业务数据的具体内容与客户端所调用的远程过程的业务场景有关，本申请对业务数据的具体内容不做限定。

为了使得业务数据能够满足远程通信的传输要求，需要将业务数据进行序列化处理，以转化成可传输的形式。经过序列化处理后得到的第一序列化数据可以通过反序列化过程再还原为业务数据。在本申请一实施例中，第一序列化数据可为二进制数据，然而本申请对第一序列化数据的具体数据形式并不做限定。

步骤102：将远程过程调用配置信息和第一序列化数据进行序列化处理，得到第二序列化数据。

远程过程调用配置信息为执行远程过程调用的通信过程所需要的一些通信配置信息，例如可包括客户端和服务器端的版本信息、以及远程过程调用的上下文信息。客户端和服务器端的版本信息用于在远程通信的过程中核对客户端和服务器端是否对应。远程过程调用的上下文信息用于进行链路调用分析。具体地，客户端和服务器端的版本信息可以被序列化为发送缓冲区(SendBuffer)的版本(version)字段；远程过程调用的上下文信息可以被序列化为发送缓冲区的信息(info)字段；而第一序列化数据则被再次序列化以作为发送缓冲区的内容(content)字段，内容字段代表发送缓冲区中要传输的实际数据。这样第二序列化数据则满足了发送缓冲区的数据结构，可被存储在发送缓冲区中，以被客户端发送给目标服务器。

在本申请一实施例中，第二序列化数据可为二进制数据，然而本申请对第二序列化数据的具体数据形式并不做限定。

步骤103：将第二序列化数据存储在发送缓冲区。

发送缓冲区为客户端向目标服务器发送数据的缓冲区，当根据客户端和服务器端之间的通信协议满足发送时机时，客户端便会将发送缓冲区中的数据发送给目标服务器。发送缓冲区一般存在于与处理器电连接的缓冲存储器中。

步骤104：将发送缓冲区的第二序列化数据发送至目标服务器。

目标服务器在收到来自客户端的发送缓冲区中的数据后，对接收到的第二序列化数据进行反序列化以获取业务数据，并基于所述业务数据执行所调用的远程过程。由于业务数据是经过了两次序列化过程才得到了第二序列化数据，因此目标服务器也是要经过两步反序列化才能够获取业务数据，具体而言，首先将第二序列化数据进行反序列化以获得第一序列化数据，然后再对第一序列化数据进行反序列化以获取业务数据。

由此可见，本申请实施例提供的一种远程过程调用方法，在对通信双方约定的业务数据进行序列化时，采用了两步序列化。第一步是将业务数据序列化为第一序列化数据以实现消息序列化，第二步是将第一序列化数据和远程过程调用配置信息一起序列化为第二序列化数据以实现接口序列化，由此实现了消息序列化和接口序列化的分离。这样当底层框架发送变化时，仅需要对接口序列化的应用层代码进行修改即可，而消息序列化的应用层代码可保持不动；当业务数据发生变化时，仅需要对消息序列化的应用层代码进行修改即可，而接口序列化的应用层代码可保持不动。由此可见，通过这种序列化处理的方式，可显著减少为了适应不同业务场景需求时的应用层代码修改，从而可有效降低维护正常通信的人力成本，并提高通信效率。

在本申请一实施例中，远程过程调用的上下文信息可包括：调用链追踪标识(traceid)和调用信息标识(spanid)。在远程过程调用的调用链路中，每个中间节点的两端分别关联一个客户端和一个服务器端，调用链追踪标识贯穿整个调用链传递，从而可以通过调用链追踪标识一次性取出所有相关日志。调用信息标识根据预设规则表征调用层级和调用时序，从而可实现调用过程的完整记录和追踪。例如，调用信息标识为0.1.1时，0.1.1可以是0.1的子调用，0.1是0.1.1的父调用，因此0.1.1自身完整的描述了调用路径为调用信息标识为0的节点、调用信息标识为0.1的节点、调用信息标识为0.1.1的节点。此外，0.1.1还可表示了0.1发起的第1次调用，0.1.2表示了0.1发起的第二次调用。然而应当理解，设置调用信息标识的预设规则可根据实际场景需求而调整，本申请对该预设规则不做限定。

由此可见，通过调用链追踪标识和调用信息标识，可以帮助技术人员快速定位问题，确保单个业务或者节点的故障问题能够得到及时解决，从而大大提升整个调用链路上的远程过程调用的服务质量。

如前所述，远程过程调用的调用链路由多个节点构成，每个中间节点的两端分别关联一个客户端和一个服务器端，即，每个中间节点为上一个节点的服务器端，同时也是下一个节点的客户端。而首节点则只能作为下一个节点的客户端，尾节点则只能作为上一个节点的服务器端。为了能够对整个远程过程调用的调用链路的健康状况进行监控，就有必要查看其中每个节点的工作情况和相关耗时，以对调用链路中节点的性能进行分析。因此，在本申请一实施例中，当该远程过程调用方法适用在调用链路的首节点时，可在将发送缓冲区中的数据发送至目标服务器之后，记录一下收到目标服务器的反馈数据所用的时间；当该远程过程调用方法适用在调用链路的中间节点时，可在将发送缓冲区中的数据发送至目标服务器之后，记录收到目标服务器的反馈数据所用的时间，以及记录目标服务器从接收到发送缓冲区中的数据到返回反馈数据所用的时间；而当该远程过程调用方法适用在调用链路的尾节点时，可记录从接收到第二序列化数据到返回反馈数据所用的时间。基于上述记录时间便可分析出整个调用链路中每个节点的性能，从而可有针对性地对调用链路中的节点进行有针对性地优化。

在本申请一实施例中，为了使得远程过程调用的通信过程能够正常信息，有必要在通信开始之前进行一些配置工作。如图2所示，在将业务数据进行序列化处理之前，该远程过程调用方法可进一步包括：

步骤100：加载配置文件，其中配置文件包括与目标服务器之间通信过程所执行的通信协议和通信模式。通信协议可包括以下通信协议中的一种：gRPC、thrift和用户自定义通信协议；通信模式包括以下模式中的一种：同步模式和异步模式。然而应当理解，通信协议和通信模式的具体内容和形式是可根据具体的应用场景而调整的，本申请对通信协议和通信模式的具体内容和形式不做限定。

在本申请另一实施例中，如图3所示，在将业务数据进行序列化处理之前，该远程过程调用方法可进一步包括：

步骤301：加载配置文件，其中配置文件包括用户指定的调度策略。

配置文件中包括调度策略，该调度策略可体现为一个基于预设调度规则维护的目标服务器列表，依据该目标服务器列表即可确定分配给当前处理请求的目标服务器。配置文件中用户指定的调度策略可以是从预设的多个调度策略中选择的一个调度策略，也可以是用户根据实际场景需求而自定义的调度策略，本申请对调度策略的具体内容并不做限定。

步骤302：根据用户指定的调度策略确定目标服务器。

目标服务器则对应为当前处理请求分配的服务器，用于执行当前处理请求的具体计算任务。应当理解，当获取到新的处理请求时，该目标服务器需要根据用户指定的调度策略而更新。前述的配置文件加载和确定目标服务器的过程可被认为是由位于上层的调度策略层完成，调度策略层将所确定的目标服务器输出给位于底层的调度框架层。

在确定了目标服务器后，便可将当前处理请求分配给目标服务器执行，即，将与当前处理请求对应的业务数据通过本申请实施例所提供的远程过程调用方法发送给目标服务器。将当前处理请求分配给目标服务器的过程可被认为是由位于底层的调度框架层完成，调度框架层负责在将当前的处理请求分配给该目标服务器时的通信交互实现。调度框架层从调度策略层获取到对应当前处理请求的目标服务器，而并不直接参与调度策略的确定过程。应当理解，除了将当前处理请求分配给目标服务器以执行对当前处理请求的处理过程外，还可能需要完成一些调度框架层的初始化配置以适应具体的应用场景需求，用户可以通过调整这些初始化配置来完成调度框架层的配置。

应当理解，虽然在上面的描述中将集群调度的执行逻辑划分为位于上层的调度策略层和位于底层的调度框架层，但这种逻辑划分并不意味着调度策略层和调度框架层一定位于两个不同的软件程序实体，实际上调度策略层和调度框架层可集成在同一个软件程序实体中。

由此可见，本申请实施例提供的一种远程过程调用方法中的集群调度方法，通过设置可加载的配置文件以获取用户指定的调度策略，将集群调度的执行逻辑划分为位于上层的调度策略层和位于底层的调度框架层，实现了一种调度策略的配置/执行和调度框架的配置/执行完全解耦的集群调度方式。这样用户可以通过调度框架层建立通用的通信交互框架配置，而不必考虑调度框架层的配置变化对于调度策略的影响，使得调度过程的执行摆脱了对应用场景的组件依赖和环境依赖，减少了额外的***性能开销。同时，用户还可通过加载配置文件对调度策略进行自由配置，不必考虑对调度框架层已有配置的影响，从而大大提高了调度策略的可移植性和可扩展性。此外，由于用户还可根据实际场景需求对调度策略进行自定义配置，这样也节省掉了用户的学习和使用成本。

图4所示为本申请一实施例提供的远程过程调用方法中确定调度策略的流程示意图。如图4所示，该远程过程调用方法还可包括如下步骤：

步骤401：确定业务数据的数据包构成方式。

步骤402：基于业务数据的数据包构成方式，从至少一种预设调度策略中选择一个作为用户指定的调度策略。

为了进一步提高集群调度的效率和质量，需要根据当前处理请求所对应的业务数据的数据结构来确定合适的调度策略。具体而言，业务数据可能由多个数据包构成，根据应用场景的不同，所获取到的业务数据的数据包之间可能存在一定逻辑连接关系，也可能并不存在逻辑连接关系，需要根据数据包之间是否存在一定逻辑连接关系来确定合适的调度策略。因此可先确定业务数据的数据包构成方式，然后基于业务数据的数据包构成方式，从至少一种预设调度策略中选择一个作为用户指定的调度策略。

在本申请一实施例中，业务数据包括多个数据包，但这些数据包之间可能并没有必然的逻辑连接关系，例如大流量高并发的大型网站的数据处理场景，此时用户指定的调度策略可为无状态轮询调度策略以保证数据处理的效率。

在本申请另一实施例中，业务数据包括依次连接的多个数据包，用户指定的调度策略为有状态调度策略。如图5所示，该无状态轮询调度策略可包括：

步骤501：当处理业务数据的第一个数据包时，从可用服务器列表中随机选取一个作为处理第一个数据包的目标服务器。

可用服务器列表为集群中可以用于完成处理请求的服务器的列表。如前所述，当要处理第一个数据包时，由于此时可用服务器列表中的服务器可能都是空闲的，因此可从可用服务器列表中随机选择一个作为处理该第一个数据包的目标服务器。

在本申请一实施例中，该随机选择的方式可通过如下步骤实现：首先获取第一个数据包的摘要信息，将该摘要信息转为整数值，然后基于整数值与可用服务器列表中的可用服务器的数量，从可用服务器列表中确定一个可用服务器作为处理该第一个数据包的目标服务器。在一进一步实施例中，可将整数值对可用服务器列表中的可用服务器的数量进行取余，以获取第一余数；然后根据第一余数确定可用服务器列表中的一个可用服务器作为处理第一个数据包的目标服务器。例如，获取到的第一个数据包的摘要信息可以是字符串的形式，根据字符串的类型可选择通过如下函数中的一种转为十进制的整数值：BKDRHash、APHash、DJBHash、JSHash、RSHash、SDBMHash、PJWHash和ELFHash等。例如，当转化得到的十进制的整数值为13，而可用服务器的数量为10时，取余获得的第一余数就是3，此时则可选择可用服务器列表中的第三个可用服务器作为处理第一个数据包的目标服务器。由于数据包的摘要信息有随机性，因此摘要信息转化为的整数值也有一定随机性，进而使得该第一余数也有随机性，由此实现了随机选择。然而本申请对随机选择第一个数据包的目标服务器的方式并不做严格限定。

步骤502：当处理业务数据的其他数据包时，按照其他数据包的连接顺序从可用服务器列表中轮询选择可用服务器作为处理其他数据包的目标服务器。

具体而言，由于第一个数据包所对应的目标服务器已经处于工作状态，此时可按照其他数据包的连接顺序，以轮询的方式从可用服务器列表中选择下一个服务器作为处理下一个数据包的目标服务器。当可用服务器列表中的服务器被轮询完毕时，若还有数据包需要处理，可再循环至可用服务器列表中与第一个数据包对应的目标服务器，直至业务数据的所有数据包都被处理完毕。

在本申请一实施例中，当处理业务数据的其他数据包时，若第一个数据包采用前述的基于摘要信息的整数转化值对可用服务器的数量取余的方式选择目标服务器，可将上一个其他数据包的摘要信息对应的整数值进行自增，自增的步长为1；然后将自增后的整数值对可用服务器列表中的可用服务器数量进行取余，以获取第二余数；根据该第二余数确定可用服务器列表中的一个可用服务器作为处理当前其他数据包的目标服务器。自增的过程使得该第二余数也实现了自增，由此实现了对可用服务器列表的轮询选择机制。

由此可见，当业务数据的数据包之间并无必然的逻辑连接关系时，通过无状态轮询调度策略可方便地实现集群中服务器间的负载均衡。例如在人脸识别领域，当工业摄像机抓拍到一张人脸的抓拍图时，便可将该抓拍图的抓拍帧信息作为当前处理请求的一个数据包，随机向集群中的一台目标服务器请求基于该抓拍帧信息识别人脸。当抓拍到下一张抓拍图时，则可以轮询的方式从可用服务器列表选择下一个可用服务器作为基于该下一张抓拍图进行人脸识别的目标服务器。

在本申请另一实施例中，考虑到在一些应用场景下，业务数据包括依次连接的多个数据包，这些数据包之间存在着一定的逻辑连接关系时，可通过一个有状态调度策略以将这些数据包需要发送给同一个服务器进行处理，以提高数据处理的效果和准确性。例如在语音识别等与人工智能相关的技术领域，视频或语音信息经常是分成多个片段的，而这些片段之间一般在时间维度上是存在前后联系的。在对这些片段进行智能处理时往往要结合上一个片段和/或下一个片段才能够做出综合判断，因此需要将这些片段发送给同一个服务器处理。如图6所示，该有状态调度策略可包括：

步骤601：当处理业务数据的第一个数据包时，从可用服务器列表中随机选取一个作为处理第一个数据包的目标服务器。

虽然数据包之间存在一定的逻辑连接关系，但当要处理第一个数据包时，由于此时可用服务器列表中的服务器可能都是空闲的，因此仍可从可用服务器列表中随机选择一个作为处理该第一个数据包的目标服务器。随机选择的方式仍可采用前述的基于摘要信息的整数转化值对可用服务器的数量取余的选择方式，在此不再赘述。

步骤602：当处理业务数据的其他数据包时，选择处理第一个数据包的目标服务器作为处理其他数据包的目标服务器。

由于数据包之间存在逻辑连接关系，因此需要将其他数据包的处理请求都分配给该处理第一个数据包的目标服务器，这样该目标服务器才能连续地获取到所有的数据包，以完成对业务数据的处理。

由此可见，当业务数据的数据包之间存在一定的逻辑连接关系时，通过有状态轮询调度策略可更好地保证业务数据处理的准确性。例如，在语音识别领域，往往需要对一个人的一段话进行语音识别。然而，一段话可能很长，会被语音的客户端拆分成多个语音片段，此时便可每次将一个片段的语音信息作为当前处理请求的一个数据包，将同一段话的所有语音片段发往集群的同一台服务器请求语音识别，这样这台服务器会收到所有完整的语音片段，就能更准确地识别出说话人身份。

在本申请另一实施例中，用户指定的调度策略也可为基于响应时间调度策略。如图7所示，该基于响应时间调度策略包括：

步骤701：获取可用服务器列表中每个可用服务器的平均响应请求时间。

可用服务器每接收到一次处理请求，响应请求时间就会被累计。平均响应请求时间由累计响应请求时间除以总响应请求次数计算得到。

步骤702：选择可用服务器列表中平均响应请求时间最短的作为目标服务器。

平均响应请求时间最短的可用服务器的计算能力相对较强。随着更多处理请求的进行，各可用服务器的平均响应请求时间也是不断更新的。如果一个计算能力很强的可用服务器接收到了过多的处理请求，平均响应请求时间也会增长，那么该可用服务器在可用服务器列表中被选择的优先级也会降低，因此可总是选择可用服务器列表中平均响应请求时间最短的作为处理当前处理请求的目标服务器。

在本申请一实施例中，当一个过往处理请求对应的目标服务器的反馈信息中包括处理未成功的信息时，则可将该目标服务器对该过往处理请求的响应请求时间作为该目标服务器的平均响应请求时间。由于处理未成功，该目标服务器的平均响应请求时间会更新为无限大，因而保证有故障的服务器不会再被选择为目标服务器。

由此可见，通过基于响应时间调度策略可更合理且高效地实现集群间服务器的负载均衡。例如在搜索领域，当用户发起一个网页请求，搜索客户端可将本次搜索条件作为当前处理请求的内容，选取集群中响应速度最快的服务器作为目标服务器，由该响应速度最快的服务器为用户提供本次搜索查询服务。

在本申请另一实施例中，用户指定的调度策略也可为基于剩余计算能力调度策略。如图8所示，该基于剩余计算能力调度策略包括：

步骤801：获取可用服务器列表中每个可用服务器的剩余计算能力参数。

剩余计算能力参数用于表征可用服务器的剩余计算能力。在本申请一实施例中，可用服务器列表中可包括CPU服务器和GPU服务器任一类型的服务器。CPU服务器的剩余计算能力参数可为CPU服务器的线程池中的空闲线程数量，GPU服务器的剩余计算能力参数可为GPU服务器能够处理的视频信号路数。然而，本申请对剩余计算能力参数的具体内容不做限定。

步骤802：选择可用服务器列表中剩余计算能力参数最大的作为目标服务器。

通过基于剩余计算能力调度策略可更合理且高效地实现集群间服务器的负载均衡，充分调用集群中相对空闲的服务器的计算能力。例如，在视频信号处理领域，有些视频信号处理部分需要CPU来处理，有些视频信号处理部分需要GPU来计算。此时可将视频信号信息的处理作为当前处理请求，视频信号处理客户端可以选取集群中最空闲的CPU和最空闲的GPU来完成该当前处理请求，以获得最快的处理速度。由此可见，本申请所提供的远程过程调用方法中的集群调度方法其实支持同构和异构两种工作模式。当处于异构工作模式时，CPU可实时上报线程池可用空闲资源，GPU可实时上报计算资源，通过获取CPU和GPU的剩余计算能力参数，可实现异构工作模式下处理请求的动态调度。

在本申请一实施例中，用户指定的调度策略也可为自定义调度策略，基于用户自定义配置的服务器获取接口函数来确定目标服务器。具体而言，可基于用户自定义配置的反馈获取接口函数StrategyFeedback()获取过往处理请求的反馈信息，然后将反馈信息输入服务器获取接口函数GetServer()，以确定目标服务器。这样用户只需对该上述接口函数做逻辑功能实现，然后调用调度框架层的开放API接口并指定调度策略，即可完成新的调度策略的集成。

在本申请一实施例中，配置文件可包括外部服务注册中心的预设监控路径，通过监控外部服务注册中心的预设监控路径即可获取实时更新的可用服务器列表，然后根据用户指定的调度策略从可用服务器列表中选取目标服务器。该外部服务注册中心根据所获取的集群中各服务器的心跳信息实时更新可用服务器列表。

具体而言，如图9所示，本申请实施例所提供的远程过程调用方法中的获取可用服务器列表的过程可通过SDK(软件开发工具包)的形式实现，该SDK可被安装在服务消费端902(例如，智能移动终端)以使得服务消费端902具备执行该远程过程调用方法中的集群调度方法的功能，例如，该SDK可在开发针对服务消费端902的操作***的智能应用时被采用，开发完成的智能应用可被安装在服务消费端902的操作***中。集群中的所有服务器作为服务提供者903向该外部服务注册中心上报心跳信息；服务消费端902通过监听外部服务注册中心901的预设监控路径以获取实时更新的可用服务器列表；当服务消费端902确定了对应当前处理请求的目标服务器时，便会将当前处理请求分配给集群中的该目标服务器处理。

应当理解，外部服务注册中心可通过单个服务器或集群的形式实现，服务消费端的具体设备形态跟具体的应用场景有关。例如对于人脸识别或视频信号处理应用场景，服务消费端的设备形态就可以是摄像机、安装有摄像头的手机或个人电脑等，集群中的服务器则配置为可执行人脸识别任务。例如对于语音识别领域，服务消费端就可为安装有收音装置的智能移动终端，集群中的服务器则配置为可执行声纹识别任务。再例如对于搜索应用场景，服务消费端就可为带有供用户输入搜索条件的装置的智能移动终端，集群中的服务器则配置为可执行互联网搜索任务。然而，本申请对服务消费端的具体设备形态不做限定。

在一进一步实施例中，该外部服务注册中心可通过单个服务器或集群的形式实现，通过在该单个服务器或集群上安装zookeeper组件，便可实现对用于提供请求处理服务的集群中各服务器的心跳信息的监听功能。zookeeper组件是一个为分布式应用提供一致***的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。

示例性远程过程调用装置

图10是本申请一实施例提供的一种远程过程调用装置的结构示意图。如图10所示，该远程过程调用装置1000包括：

第一序列化模块1001，配置为将业务数据进行序列化处理，得到第一序列化数据；

第二序列化模块1002，配置为将远程过程调用配置信息和所述第一序列化数据进行序列化处理，得到第二序列化数据；

存储模块1003，配置为将所述第二序列化数据存储在发送缓冲区；以及

传输模块1004，配置为将所述发送缓冲区的所述第二序列化数据发送至目标服务器。

在本申请一实施例中，远程过程调用配置信息包括：客户端和服务器端的版本信息、以及远程过程调用的上下文信息。

在本申请一实施例中，远程过程调用的上下文信息包括：调用链追踪标识和调用信息标识，其中调用信息标识根据预设规则表征调用层级和调用时序。

在本申请一实施例中，如图11所示，该远程过程调用装置1000进一步包括：第一记录模块1005，配置为在将发送缓冲区中的数据发送至目标服务器之后，记录收到目标服务器的反馈数据所用的时间。

在本申请另一实施例中，如图11所示，该远程过程调用装置1000进一步包括：第二记录模块1006，配置为在将发送缓冲区中的数据发送至目标服务器之后，记录收到目标服务器的反馈数据所用的时间；以及记录目标服务器从接收到发送缓冲区中的数据到返回反馈数据所用的时间。

在本申请一实施例中，第一序列化数据和/或第二序列化数据为二进制数据。

在本申请一实施例中，如图11所示，该远程过程调用装置1000进一步包括：第一加载模块1007，配置为在将业务数据进行序列化处理之前，加载配置文件，其中配置文件包括与目标服务器之间通信过程所执行的通信协议和通信模式。

在本申请一实施例中，通信协议包括以下通信协议中的一种：gRPC、thrift和用户自定义通信协议；通信模式包括以下模式中的一种：同步模式和异步模式。

在本申请一实施例中，如图11所示，该远程过程调用装置1000进一步包括：第二加载模块1008，配置为在将业务数据进行序列化处理之前加载配置文件，其中配置文件包括用户指定的调度策略；以及目标服务器确定模块1009，配置为根据用户指定的调度策略确定目标服务器。

在本申请一实施例中，如图11所示，该远程过程调用装置1000进一步包括：数据构成确定模块1010，配置为确定业务数据的数据包构成方式；以及选择模块1011，配置为基于业务数据的数据包构成方式，从至少一种预设调度策略中选择一个作为用户指定的调度策略。

在本申请一实施例中，业务数据包括多个数据包，用户指定的调度策略为无状态轮询调度策略；或，业务数据包括依次连接的多个数据包，用户指定的调度策略为有状态调度策略。

在本申请一实施例中，用户指定的调度策略为基于响应时间调度策略；或，用户指定的调度策略为基于剩余计算能力调度策略。

在本申请一实施例中，配置文件包括外部服务注册中心的预设监控路径，如图11所示，该远程过程调用装置1000进一步包括：监控模块1012，配置为通过监控外部服务注册中心的预设监控路径以获取实时更新的可用服务器列表；其中，目标服务器确定模块1009进一步配置为：根据用户指定的调度策略从可用服务器列表中选取目标服务器。

上述远程过程调用装置1000中的各个模块的具体功能和操作已经在上面参考图1到图9描述的远程过程调用方法中进行了详细介绍，因此，这里将省略其重复描述。

需要说明的是，根据本申请实施例的远程过程调用装置1000可以作为一个软件模块和/或硬件模块而集成到电子设备120中，换言之，该电子设备120可以包括该远程过程调用装置1000。例如，该远程过程调用装置1000可以是该电子设备120的操作***中的一个软件模块，或者可以是针对于其所开发的一个应用程序；当然，该远程过程调用装置1000同样可以是该电子设备120的众多硬件模块之一。

在本申请另一实施例中，该远程过程调用装置1000与该电子设备120也可以是分立的设备(例如，服务器)，并且该远程过程调用装置1000可以通过有线和/或无线网络连接到该电子设备120，并且按照约定的数据格式来传输交互信息。

示例性电子设备

图12所示为本申请一实施例提供的电子设备的结构示意图。如图7所示，该电子设备120包括：一个或多个处理器1201和存储器1202；以及存储在存储器1202中的计算机程序指令，计算机程序指令在被处理器1201运行时使得处理器1201执行如上述任一实施例的远程过程调用方法。

处理器1201可以是中央处理单元(CPU)或者具有数据处理能力和/或指令执行能力的其他形式的处理单元，并且可以控制电子设备中的其他组件以执行期望的功能。

存储器1202可以包括一个或多个计算机程序产品，计算机程序产品可以包括各种形式的计算机可读存储介质，例如易失性存储器和/或非易失性存储器。易失性存储器例如可以包括随机存取存储器(RAM)和/或高速缓冲存储器(cache)等。非易失性存储器例如可以包括只读存储器(ROM)、硬盘、闪存等。在计算机可读存储介质上可以存储一个或多个计算机程序指令，处理器1201可以运行程序指令，以实现上文的本申请的各个实施例的远程过程调用方法中的步骤以及/或者其他期望的功能。在计算机可读存储介质中还可以存储诸如光线强度、补偿光强度、滤光片的位置等信息。

在一个示例中，电子设备120还可以包括：输入装置1203和输出装置1204，这些组件通过总线***和/或其他形式的连接机构(图12中未示出)互连。

例如，在该电子设备是如工业生产线上的机器人时，该输入装置1203可以是摄像头，用于捕捉待加工零件的位置。在该电子设备是单机设备时，该输入装置1203可以是通信网络连接器，用于从外部的可移动设备接收所采集的输入信号。此外，该输入装置1203还可以包括例如键盘、鼠标、麦克风等等。

该输出装置1204可以向外部输出各种信息，例如可以包括例如显示器、扬声器、打印机、以及通信网络及其所连接的远程输出设备等等。

当然，为了简化，图7中仅示出了该电子设备120中与本申请有关的组件中的一些，省略了诸如总线、输入装置/输出接口等组件。除此之外，根据具体应用情况，电子设备120还可以包括任何其他适当的组件。

示例性计算机程序产品和计算机可读存储介质

除了上述方法和设备以外，本申请的实施例还可以是计算机程序产品，包括计算机程序指令，计算机程序指令在被处理器运行时使得处理器执行如上述任一实施例的远程过程调用方法中的步骤。

计算机程序产品可以以一种或多种程序设计语言的任意组合来编写用于执行本申请实施例操作的程序代码，程序设计语言包括面向对象的程序设计语言，诸如Java、C++等，还包括常规的过程式程序设计语言，诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。

此外，本申请的实施例还可以是计算机可读存储介质，其上存储有计算机程序指令，计算机程序指令在被处理器运行时使得处理器执行本说明书上述“示例性远程过程调用方法”部分中描述的根据本申请各种实施例的远程过程调用方法中的步骤。

计算机可读存储介质可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以包括但不限于电、磁、光、电磁、红外线、或半导体的***、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器((RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

以上结合具体实施例描述了本申请的基本原理，但是，需要指出的是，在本申请中提及的优点、优势、效果等仅是示例而非限制，不能认为这些优点、优势、效果等是本申请的各个实施例必须具备的。另外，上述公开的具体细节仅是为了示例的作用和便于理解的作用，而非限制，上述细节并不限制本申请为必须采用上述具体的细节来实现。

本申请中涉及的器件、装置、设备、***的方框图仅作为例示性的例子并且不意图要求或暗示必须按照方框图示出的方式进行连接、布置、配置。如本领域技术人员将认识到的，可以按任意方式连接、布置、配置这些器件、装置、设备、***。诸如“包括”、“包含”、“具有”等等的词语是开放性词汇，指“包括但不限于”，且可与其互换使用。这里所使用的词汇“或”和“和”指词汇“和/或”，且可与其互换使用，除非上下文明确指示不是如此。这里所使用的词汇“诸如”指词组“诸如但不限于”，且可与其互换使用。

还需要指出的是，在本申请的装置、设备和方法中，各部件或各步骤是可以分解和/或重新组合的。这些分解和/或重新组合应视为本申请的等效方案。

提供所公开的方面的以上描述以使本领域的任何技术人员能够做出或者使用本申请。对这些方面的各种修改对于本领域技术人员而言是非常显而易见的，并且在此定义的一般原理可以应用于其他方面而不脱离本申请的范围。因此，本申请不意图被限制到在此示出的方面，而是按照与在此公开的原理和新颖的特征一致的最宽范围。

为了例示和描述的目的已经给出了以上描述。此外，此描述不意图将本申请的实施例限制到在此公开的形式。尽管以上已经讨论了多个示例方面和实施例，但是本领域技术人员将认识到其某些变型、修改、改变、添加和子组合。

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

Claims (18)

1.一种远程过程调用方法，包括：

将业务数据进行序列化处理，得到第一序列化数据；

将远程过程调用配置信息和所述第一序列化数据进行序列化处理，得到第二序列化数据；

将所述第二序列化数据存储在发送缓冲区；以及

将所述发送缓冲区的所述第二序列化数据发送至目标服务器。

2.根据权利要求1所述的远程过程调用方法，其中，所述远程过程调用配置信息包括：客户端和服务器端的版本信息、以及远程过程调用的上下文信息。

3.根据权利要求2所述的远程过程调用方法，其中，所述远程过程调用的上下文信息包括：调用链追踪标识和调用信息标识，其中所述调用信息标识根据预设规则表征调用层级和调用时序。

4.根据权利要求1所述的远程过程调用方法，其中，在将所述发送缓冲区中的数据发送至目标服务器之后，所述方法进一步包括：记录收到所述目标服务器的反馈数据所用的时间。

5.根据权利要求1所述的远程过程调用方法，其中，在将所述发送缓冲区中的数据发送至目标服务器之后，所述方法进一步包括：记录收到所述目标服务器的反馈数据所用的时间；以及记录所述目标服务器从接收到所述发送缓冲区中的数据到返回所述反馈数据所用的时间。

6.根据权利要求1所述的远程过程调用方法，其中，所述第一序列化数据和/或所述第二序列化数据为二进制数据。

7.根据权利要求1所述的远程过程调用方法，其中，在将业务数据进行序列化处理之前，进一步包括：

加载配置文件，其中所述配置文件包括与所述目标服务器之间通信过程所执行的通信协议和通信模式。

8.根据权利要求7所述的远程过程调用方法，其中，所述通信协议包括以下通信协议中的一种：gRPC、thrift和用户自定义通信协议；

所述通信模式包括以下模式中的一种：同步模式和异步模式。

9.根据权利要求1所述的远程过程调用方法，其中，在将业务数据进行序列化处理之前，进一步包括：

加载配置文件，其中所述配置文件包括用户指定的调度策略；以及

根据所述用户指定的调度策略确定所述目标服务器。

10.根据权利要求9所述的远程过程调用方法，其中，所述方法进一步包括：

确定所述业务数据的数据包构成方式；以及

基于所述业务数据的数据包构成方式，从至少一种预设调度策略中选择一个作为所述用户指定的调度策略。

11.根据权利要求10所述的远程过程调用方法，其中，业务数据包括多个数据包，所述用户指定的调度策略为无状态轮询调度策略；或，

业务数据包括依次连接的多个数据包，所述用户指定的调度策略为有状态调度策略。

12.根据权利要求9所述的远程过程调用方法，其中，所述用户指定的调度策略为基于响应时间调度策略；或，所述用户指定的调度策略为基于剩余计算能力调度策略。

13.根据权利要求9所述的远程过程调用方法，其中，所述配置文件包括外部服务注册中心的预设监控路径，所述方法进一步包括：

通过监控所述外部服务注册中心的预设监控路径以获取实时更新的可用服务器列表；

其中，所述根据所述用户指定的调度策略确定目标服务器包括：

根据所述用户指定的调度策略从所述可用服务器列表中选取所述目标服务器。

14.一种远程过程调用执行方法，包括：

接收到来自客户端的发送缓冲区的第二序列化数据；以及

对所述第二序列化数据进行反序列化以获取业务数据，并基于业务数据执行所述客户端所调用的远程过程；

其中，所述第二序列化数据由所述客户端基于以下步骤生成：

将所述业务数据进行序列化处理，得到第一序列化数据；

将远程过程调用配置信息和所述第一序列化数据进行序列化处理，得到所述第二序列化数据。

15.根据权利要求14所述的远程过程调用方法，其中，所述方法进一步包括：

记录从接收到所述第二序列化数据到返回反馈数据所用的时间。

16.一种远程过程调用装置，包括：

第一序列化模块，配置为将业务数据进行序列化处理，得到第一序列化数据；

第二序列化模块，配置为将远程过程调用配置信息和所述第一序列化数据进行序列化处理，得到第二序列化数据；

存储模块，配置为将所述第二序列化数据存储在发送缓冲区；以及

传输模块，配置为将所述发送缓冲区的所述第二序列化数据发送至目标服务器。

17.一种电子设备，包括：

处理器；以及

存储器，在所述存储器中存储有计算机程序指令，所述计算机程序指令在被所述处理器运行时使得所述处理器执行如权利要求1至13中任一所述的方法。

18.一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序指令，所述计算机程序指令在被处理器运行时使得所述处理器执行如权利要求1至13中任一所述的方法。

Images