CN112769945B - 分布式服务调用方法及装置 - Google Patents

Abstract

本申请提供了一种分布式服务调用方法及装置，可用于金融领域或其他领域，该方法，包括：向目标注册中心发送服务订阅信息；接收目标注册中心发送的服务信息；若所述服务信息对应的场景为预设的场景并且本地存在所述服务信息对应的全量服务信息，则在所述全量服务信息中添加所述服务信息对应的引用，以根据添加引用后的全量服务信息完成目标服务的调用。本申请能够降低客户端内存压力，进而能够保证客户端的稳定运行。

Description

分布式服务调用方法及装置

技术领域

本申请涉及分布式服务技术领域，尤其涉及一种分布式服务调用方法及装置。

背景技术

随着互联网的不断发展和普及，传统的垂直架构体系已经无法满足日益增长的用户压力对系统容量及高可用的需求。越来越多的业务系统基于开放平台及分布式服务架构开展业务研发。在分布式服务调用技术领域，当客户端调用服务端的服务的时候，会将服务端的服务信息加载到客户端内存中，以便服务的进一步调用交易。此时，会涉及到客户端内存消耗的问题。

随着业务的不断发展，各业务系统的设备规模及对外暴露服务数量也与日剧增。当服务端的服务不断上线时，客户端会面临着内存消耗持续增加的问题，当服务数量不断增加时，会给客户端的内存带来特别大的压力，甚至进一步影响到业务的正常交易运行。针对客户端内存消耗问题，从技术角度来看，业界目前没有一个切实有效的解决方案，尤其是当服务端数量特别庞大的时候，客户端内存将会持续高水位运行，给客户端的稳定运行带来的潜在的风险。

发明内容

针对现有技术中的问题，本申请提出了一种分布式服务调用方法及装置，能够降低客户端内存压力，进而能够保证客户端的稳定运行。

为了解决上述技术问题，本申请提供以下技术方案：

第一方面，本申请提供一种分布式服务调用方法，包括：

接收目标注册中心发送的服务信息；

若所述服务信息对应的场景为预设的场景并且本地存在所述服务信息对应的全量服务信息，则在所述全量服务信息中添加所述服务信息对应的引用，以根据添加引用后的全量服务信息完成目标服务的调用。

进一步地，所述根据添加引用后的全量服务信息完成目标服务的调用，包括：

根据接收的服务调用请求和预设的动态计算方法，从当前的全量服务信息中获得该服务调用请求对应的目标服务信息，以根据该目标服务信息完成目标服务的调用。

进一步地，所述根据该目标服务信息完成目标服务的调用，包括：

根据多条目标服务信息和软负载均衡算法，确定唯一的目标服务，以完成目标服务的调用。

进一步地，所述的分布式服务调用方法，还包括：

根据所述服务调用请求，更新本地的累计调用次数和调用时间；

定时将所述累计调用次数和调用时间发送至目标监控中心。

第二方面，本申请提供一种分布式服务调用装置，包括：

接收模块，用于接收目标注册中心发送的服务信息；

调用模块，用于若所述服务信息对应的场景为预设的场景并且本地存在所述服务信息对应的全量服务信息，则在所述全量服务信息中添加所述服务信息对应的引用，以根据添加引用后的全量服务信息完成目标服务的调用。

进一步地，所述调用模块，包括：

调用单元，用于根据接收的服务调用请求和预设的动态计算方法，从当前的全量服务信息中获得该服务调用请求对应的目标服务信息，以根据该目标服务信息完成目标服务的调用。

进一步地，所述调用单元，包括：

确定子单元，用于根据多条目标服务信息和软负载均衡算法，确定唯一的目标服务，以完成目标服务的调用。

进一步地，所述的分布式服务调用装置，还包括：

更新模块，用于根据所述服务调用请求，更新本地的累计调用次数和调用时间；

监控模块，用于定时将所述累计调用次数和调用时间发送至目标监控中心。

第三方面，本申请提供一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现所述的分布式服务调用方法。

第四方面，本申请提供一种计算机可读存储介质，其上存储有计算机指令，所述指令被执行时实现所述的分布式服务调用方法。

由上述技术方案可知，本申请提供一种分布式服务调用方法及装置。其中，该方法包括：向目标注册中心发送服务订阅信息；接收目标注册中心发送的服务信息；若所述服务信息对应的场景为预设的场景并且本地存在所述服务信息对应的全量服务信息，则在所述全量服务信息中添加所述服务信息对应的引用，以根据添加引用后的全量服务信息完成目标服务的调用，能够降低客户端内存压力，进而能够保证客户端的稳定运行；能够解决在分布式服务调用过程中，当服务端服务数增加时，服务信息通过注册中心同步后，客户端内存不断增长的问题，能够提高分布式服务高效稳定运行，通过特定场景下的全量服务信息共享和增加定时清理等手段，在客户端无感知的场景下，能够最大限度的降低分布式服务框架在服务数量骤增时，客户端内存消耗的问题，能够确保客户端的内存消耗占比能够低水位运行，能够降低服务框架因服务数量增加带来的潜在风险。具体优点如下：1、设置定时清理机制，能够确保不会因时间不断积累导致内存泄露发生；2、信息共享，通过全量信息的共享，能够极大复用能够利用的信息载体资源，减少信息的冗余；3、无需客户端参与任何配置，仅需升级jar包，能够提高客户端的可靠性。

附图说明

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

图1是本申请实施例中分布式服务调用方法的流程示意图；

图2是本申请实施例中分布式服务调用装置的结构示意图；

图3是本申请应用实例中分布式服务调用系统的结构示意图；

图4是本申请应用实例中客户端与注册中心的关系示意图；

图5是本申请应用实例中监控中心的结构示意图；

图6是本申请应用实例中静态数据模块的结构示意图；

图7是本申请应用实例中服务信息载体对象单元的结构示意图；

图8是本申请应用实例中服务信息动态构建的原理示意图；

图9是本申请应用实例中分布式服务调用方法的流程示意图；

图10为本申请实施例的电子设备9600的系统构成示意框图。

具体实施方式

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

当服务端的服务数量不断增加时，客户端内存消耗将持续增加。目前没有合理的解决这个问题的方案，因此，如何从技术角度提供一种新的方案，解决上述问题是分布式框架领域亟待解决的技术难题。为解决在分布式服务调用过程中，当服务端服务数增加时，服务信息通过注册中心同步后，客户端内存不断增长的问题，本申请提供了一种分布式服务调用方法及装置，能够保证分布式服务的高效稳定运行，通过优化分布式服务信息传递的载体结构，以动态计算及特殊场景加载等手段，在客户端无感知的情况下，有效地减小客户端内存消耗。

为了降低客户端内存压力，进而保证客户端的稳定运行，本申请实施例提供一种分布式服务调用装置，该装置可以是一客户端设备，所述客户端设备可以包括智能手机、平板电子设备、网络机顶盒、便携式计算机、台式电脑、个人数字助理(PDA)、车载设备和智能穿戴设备等。其中，所述智能穿戴设备可以包括智能眼镜、智能手表和智能手环等。

在实际应用中，进行分布式服务调用的部分可以在如上述内容所述的客户端设备中完成。具体可以根据所述客户端设备的处理能力，以及用户使用场景的限制等进行选择。本申请对此不作限定。若所有的操作都在所述客户端设备中完成，所述客户端设备还可以包括处理器。

上述的客户端设备可以具有通信模块(即通信单元)，可以与远程的服务器进行通信连接，实现与所述服务器的数据传输。所述服务器可以包括任务调度中心一侧的服务器，其他的实施场景中也可以包括中间平台的服务器，例如与任务调度中心服务器有通信链接的第三方服务器平台的服务器。所述的服务器可以包括单台计算机设备，也可以包括多个服务器组成的服务器集群，或者分布式装置的服务器结构。

所述服务器与所述客户端设备之间可以使用任何合适的网络协议进行通信，包括在本申请提交日尚未开发出的网络协议。所述网络协议例如可以包括TCP/IP协议、UDP/IP协议、HTTP协议、HTTPS协议等。当然，所述网络协议例如还可以包括在上述协议之上使用的RPC协议(Remote Procedure Call Protocol，远程过程调用协议)、REST协议(Representational State Transfer，表述性状态转移协议)等。

需要说明的是，本申请公开的分布式服务调用方法及装置可用于金融技术领域，也可用于除金融技术领域之外的任意领域，本申请公开的分布式服务调用方法及装置的应用领域不做限定。

具体通过下述各个实施例进行说明。

为了降低客户端内存压力，进而保证客户端的稳定运行，本实施例提供一种执行主体是分布式服务调用装置的分布式服务调用方法，如图1所示，该方法具体包含有如下内容：

步骤101：接收目标注册中心发送的服务信息。

具体地，可以是订阅方即服务端将服务信息注册至目标注册中心，客户端向目标注册中心发送服务订阅信息，该服务订阅信息可以包含有：订阅方的机器ip、端口和超时时间等配置信息；接收目标注册中心发送的服务信息；所述服务信息可以包括：服务名、机器ip、用户名、端口和版本等信息；另外，也可以是在服务端的服务信息发生变更后，服务端将变更后的服务信息发送至目标注册中心，目标注册中心将变更后的服务信息推送给对应的客户端。

步骤102：若所述服务信息对应的场景为预设的场景并且本地存在所述服务信息对应的全量服务信息，则在所述全量服务信息中添加所述服务信息对应的引用，以根据添加引用后的全量服务信息完成目标服务的调用。

具体地，可以根据所述服务信息判断所述服务信息对应的场景是否为预设的场景，所述预设的场景可以包含有：用户名为空的场景，举例来说，若所述服务信息中的用户名为空，则确定所述服务信息对应的场景为预设的场景。所述本地可以是指客户端本地；引用可以表示某一个变量或对象的别名，对引用的操作与对其所绑定的变量或对象的操作完全等价。

进一步地，若本地不存在所述服务信息对应的全量服务信息，则将所述服务信息作为全量服务信息存储，以提高全量服务信息的可靠性；所述全量服务信息是指所有的服务相关的信息，服务信息主要是服务调用时需要用到的信息，每个全量服务信息包含有：同一个服务的所有历史服务信息。所述服务信息对应的全量服务信息可以是指服务标识与该服务信息中的服务标识相同的全量服务信息，服务标识用于区分不同的服务，可以是服务名等。

举例来说，若订阅方接收到的服务信息A包括：服务名、机器ip、用户名、端口和版本信息；本地存在全量服务信息B，B与A中的服务名和机器ip相同，用户名、端口和版本信息不同；则将用户名、端口和版本信息存储至全量服务信息B中，并在全量服务信息B中的服务名处设置服务信息A的引用，在机器ip处设置服务信息A的引用。

为了进一步降低客户端的内存消耗，提高服务调用的灵活度和自动化程度，在本申请一个实施例中，步骤103中的所述根据添加引用后的全量服务信息完成目标服务的调用，包括：

步骤201：根据接收的服务调用请求和预设的动态计算方法，从当前的全量服务信息中获得该服务调用请求对应的目标服务信息，以根据该目标服务信息完成目标服务的调用。

具体地，所述动态计算方法可以用于根据本地当前存储的多个全量服务信息和一定的规则动态拼接成可供框架调用的服务调用请求对应的服务信息。目标服务信息可以为一条或多条，服务信息和服务一一对应。

其中，全量服务信息是分布式服务的最完整的信息，包括服务端的地址信息和端口信息、服务监控信息、配置信息、路由信息等等的信息。服务信息载体是统一资源定位符，在分布式服务体系中，无论是服务端、客户端、还是注册中心，都是通过统一资源定位符进行资源定位的。组成部分包括为分布式服务中的各种协议、用户名及密码、主机地址及端口、服务接口信息、参数键值对。服务端在将服务导出的时候会将对应的对象转换为统一资源定位符格式，此时，统一资源定位符会将信息传给协议扩展点，根据统一资源定位符中的协议的值，使服务框架的自适应机制进行不同协议的服务暴露或引用。

为了提高服务调用的效率和可靠性，在本申请一个实施例中，步骤201中所述的根据该服务信息完成目标服务的调用，包括：

步骤301：根据多条目标服务信息和软负载均衡算法，确定唯一的目标服务，以完成目标服务的调用。

具体地，可以将所述服务调用请求发送至所述目标服务对应的设备地址，以根据该服务调用请求调用所述目标服务；如果调用失败，再选另一台调用。

为了实现对服务调度的监控，提高服务调度的可靠性，在本申请一个实施例中，所述的分布式服务调用方法，还包括：

步骤401：根据所述服务调用请求，更新本地的累计调用次数和调用时间。

具体地，可以每进行一次服务调用，则将累计调用次数加1，同时记录当前调用时间。

步骤402：定时将所述累计调用次数和调用时间发送至目标监控中心。

具体地，服务端同样在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心，可用于观察统计服务调用情况；进而可以判断监控中心存储的各个服务端的总调用次数和各个客户端的总调用次数是否一致，若是，则调用正常，若否，可以根据调用时间推测调用异常时间和异常位置。

为了进一步说明本方案，本申请提供一种分布式服务调用方法的应用实例，具体描述如下：

S1：客户端接收注册中心发送的服务信息。

S2：客户端判断客户端本地的全量服务信息中是否存在服务信息并且该服务信息对应的场景为特定场景，若是，则在全量服务信息中添加服务信息对应的引用。

S3：客户端根据接收的服务调用请求和动态计算方法，从客户端当前的全量服务信息中获得该服务调用请求对应的多条目标服务信息。

S4：根据多条目标服务信息和软负载均衡算法，确定唯一的目标服务，以完成目标服务的调用。

为了提高分布式服务高效稳定运行，本申请还提供另一种分布式服务调用方法的应用实例，具体描述如下：

步骤1)：服务端在启动过程中，将服务信息注册至注册中心；服务端支持懒加载注册和启动注册。

步骤2)：客户端在启动的过程中，会从注册中心订阅对应的服务信息，将服务端的服务信息加载到客户端的内存中，以便交易调用使用，在调用的过程中通过动态计算的方式获取到需要的服务信息，无需将对应信息保存下来；动态计算为根据一定的规则从客户端的全量服务信息中动态拼接成可供框架调用的服务信息。

步骤3)：注册中心保存服务端的服务信息及客户端的订阅信息，当有服务上下线时，动态通知客户端服务的变动信息。监控中心则负责服务注册及调用过程中的变动，按照设置的指标监控，触发指标则发送报警信息至对应平台；订阅信息包含有订阅方的机器ip、端口、超时时间等配置信息。

从软件层面来说，为了降低客户端内存压力，进而保证客户端的稳定运行，本申请提供一种用于实现所述分布式服务调用方法中全部或部分内容的分布式服务调用装置的实施例，参见图2，所述分布式服务调用装置具体包含有如下内容：

接收模块01，用于接收目标注册中心发送的服务信息。

调用模块02，用于若所述服务信息对应的场景为预设的场景并且本地存在所述服务信息对应的全量服务信息，则在所述全量服务信息中添加所述服务信息对应的引用，以根据添加引用后的全量服务信息完成目标服务的调用。

在本申请一个实施例中，所述调用模块，包括：

调用单元，用于根据接收的服务调用请求和预设的动态计算方法，从当前的全量服务信息中获得该服务调用请求对应的目标服务信息，以根据该目标服务信息完成目标服务的调用。

在本申请一个实施例中，所述调用单元，包括：

确定子单元，用于根据多条目标服务信息和软负载均衡算法，确定唯一的目标服务，以完成目标服务的调用。

在本申请一个实施例中，所述的分布式服务调用装置，还包括：

更新模块，用于根据所述服务调用请求，更新本地的累计调用次数和调用时间；

监控模块，用于定时将所述累计调用次数和调用时间发送至目标监控中心。

本说明书提供的分布式服务调用装置的实施例具体可以用于执行上述分布式服务调用方法的实施例的处理流程，其功能在此不再赘述，可以参照上述分布式服务调用方法实施例的详细描述。

为了进一步说明本方案，本申请提供一种分布式服务调用系统的应用实例，参见图3，该分布式服务调用系统包含有服务端1、注册中心2、客户端3、监控中心4。服务端1与注册中心2相连；注册中心2与客户端3相连；客户端3与监控中心4相连、监控中心4与服务端1相连；具体描述如下：

服务端1：交易逻辑的处理方，在服务端启动的时候，将服务信息注册至注册中心，收到交易请求后，按照具体业务设定的逻辑进行校验，处理交易，返回对应请求给客户端。

注册中心2：主要用来保存服务相关的信息，当服务端启动的时候，注册中心会将服务端的服务信息以特定的格式保存下来。当客户端启动后，客户端会从注册中心订阅相关的服务，此时，注册中心会将客户端的信息以服务维度也保存一份。当客户端或者服务端发生变化时，将变化信息推送给客户端，并更新自身存储信息。

客户端3：客户端启动时，从注册中心订阅对应服务信息，缓存在本地内存中，当客户有交易请求时，通过客户端发起交易，客户端会从本地内存中获取到服务端地址等信息，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用；其中，分布式服务通常可以有多个服务提供者，对消费者来说是无差别的，最终调用可以选择其中的一个服务提供者发生交易。

监控中心4：客户端和服务端，都会在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心，可用于观察统计服务调用情况。

图4是客户端与注册中心的关系示意图，如图4所示，所述客户端3包括Invoker缓存(注册中心31)、Invoker缓存(注册中心32)，注册中心2分别与注册中心31和注册中心32连接，注册中心31和注册中心32是指客户端本地缓存的内存结构，

其中：

Invoker缓存(注册中心31)用于存储注册在注册中心31的服务信息。

Invoker缓存(注册中心32)用于存储注册在注册中心32的服务信息。

客户端3在会从各个注册中心2里获取对应的服务信息，并将服务信息加载到本地内存中。

图5是监控中心的结构示意图，如图5所示，所述监控中心4包括静态数据模块41和静定时清理模块42，所述监控中心和注册中心可以部署在同一服务器中，也可以部署在独立的服务器中，其中：

静态数据模块41：用于存储服务监控所用的数据，组装成监控所需要运行时的元数据信息，元数据信息可以包含有累计调用次数、调用时间、客户端、服务端的ip和端口等信息。

静定时清理模块42：监控中心在服务端和客户端不断发生变化的情况下，该装置会将所发生的变化信息存储下来，如果长时间不清理，则会因为监控中心中存储的监控信息越来越多而导致内存占用较高平，甚至发生内存溢出等风险。通过静定时清理模块，每个固定单位时间后，触发一次清理任务，执行清理动作，完成存量数据的定时清理，确保监控中心在整个体系中所消耗内存保持在低水平。

图6是静态数据模块的结构示意图，如图6所示，所述静态数据模块包括服务信息载体对象单元411、字符串载体单元412。其中：

服务信息载体对象单元411：用于获取当前服务端的服务的服务端地址信息的载体，该载体对象是客户端获取提供者地址列表，完成交易的关键信息要素。一般来讲，服务信息载体对象是存储在注册中心，每当服务端有新的服务上线时，都会在注册中心里新增新的服务信息。

字符串载体单元412：字符串载体为服务信息载体的另一种存在形式。适用于服务监控，服务解析等关键环节，以字符串的形式存在。

图7是服务信息载体对象单元411的结构示意图，所述服务信息载体对象单元411包括全量信息子单元4111、特定场景下的全量信息子单元4112和通信地址等其他子单元4113，根据调用服务需要的固定规则构建(如dubbo/servicename/version？par1＝var1&par2＝var2....)，不同的服务构建后对应的全量服务信息不同，其中：

全量信息子单元4111：服务全量信息是分布式服务交易的最完整的信息，包括服务端的地址信息和端口信息、服务监控信息、配置信息、路由信息等等的信息。服务信息载体是统一资源定位符，在分布式服务体系中，无论是服务端、客户端、还是注册中心，都是通过统一资源定位符进行资源定位的。组成部分包括为分布式服务中的各种协议、用户名及密码、主机地址及端口、服务接口信息、参数键值对。服务端在将服务导出的时候会将对应的对象转换为统一资源定位符格式，此时，统一资源定位符会将信息传给协议扩展点，根据统一资源定位符中的协议的值，使服务框架的自适应机制进行不同协议的服务暴露或引用。

特定场景下的全量信息子单元4112：在没有注册中心时，服务配置解析出的统一资源定位符格式为：协议类型://服务地址信息/服务信息(接口信息)版本信息。基于分布式服务框架的自适应扩展机制，通过统一资源定位符的协议：//协议头识别，这时候就调用分布式服务协议的导出方法进行暴露服务端口。有注册中心时，服务配置解析出的统一资源定位符格式类似：注册标示://注册的主机地址/服务信息+端口信息？导出标志＝由统一资源定位符解析服务协议信息。再传给协议扩展点进行暴露，这时候就剩下：协议头识别://服务信息+版本信息。同样的基于协议头识别通过服务框架协议的导出方法打开服务端口。

通信地址等其他子单元4113：通信地址一般为服务端的主机地址和端口信息，是客户端发起交易的主要通信地址信息，也是服务监控等重点关注的服务信息。

图8为服务信息动态构建的原理示意图，服务信息包括：特定场景下的服务全量信息10、正常使用的服务全量信息20及动态构建后的第一服务全量信息30和第二服务全量信息40，其中，特定场景下的服务全量信息10与第一服务全量信息30通过动态构建相连，正常使用的服务全量信息20通过动态构建与第二服务全量信息40相连，特定场景下的服务全量信息10与第二服务全量信息40通过复用的方式相连。

第二服务全量信息40为特定场景下的服务全量信息10和正常使用的服务全量信息20所共享，这样在客户端服务加载的过程中通过复用的方式减小信息的存储，达到降低内存消耗的作用，进而起到提高分布式服务高效稳定运行的目的。

图9为服务调用实现工作原理图，如图9所示，结合上述分布式服务调用系统，本申请还提供一种分布式服务调用方法的应用实例，其步骤如下：

步骤S11：服务端和/或客户端启动。

步骤S12：分布式服务框架开始启动；服务端和/或客户端启动到服务框架层，开始启动分布式服务框架。

步骤S13：启动注册中心；分布式服务框架启动后，开始启动注册中心。

步骤S14：获取服务信息；当注册中心中的信息发生变化后，客户端可以开始获取服务信息。

步骤S15：推送服务信息；服务端将服务信息注册到注册中心后，注册中心会将服务信息推送至客户端。

其中，在服务框架启动的过程中，框架会从信息注册装置中获取服务信息，包括服务消费者地址列表，路由信息等，等所有信息都获取后，分布式服务框架启动成功。

步骤S16：动态计算；在客户端启动的过程中，如果客户端没有配置懒加载的方式，则会直接加载所有的服务信息至客户端内存中，该过程中的服务信息通过动态计算方法获取。

步骤S17：判断是否为特定场景下的服务信息，针对特定场景下的服务信息，进行特定场景加载，通过与通用的全量服务信息共享的方式来减小客户端内存的消耗。

步骤S18：分布式服务框架启动成功；在服务框架启动的过程中或注册中心中的信息发生变化后，框架会从注册中心中获取服务信息，包括服务消费者地址列表，路由信息等，等所有信息都获取后，分布式服务框架启动成功。

具体地，客户端会从注册中心获取自己想订阅的服务信息，将获取到的信息加载至内存后，根据场景使用不同的计算规则获取服务全量信息。例如，在无指定用户身份(用户名为空)时，通过与通用的全量服务信息共享信息(同一个字符串)，特定场景下的服务载体信息只是对全量服务信息增加了一个引用，实际并没有生成新的字符串，而增加引用是不会增大内存消耗的，所以也就达到了较小内存的作用。

步骤S19：开始交易；分布式服务框架启动成功后，即可进行具体的交易。

步骤S20：服务调用；如果客户端配置了懒加载，则在服务框架启动的过程中，并不会去加载服务端的服务信息，只有当客户端首次发起交易的时候，才会去加载服务信息，故此步骤发生在服务调用时。

由上述描述可知，本申请提供的分布式服务调用方法及装置，能够降低客户端内存压力，进而能够保证客户端的稳定运行；能够解决在分布式服务调用过程中，当服务端服务数增加时，服务信息通过注册中心同步后，客户端内存不断增长的问题，能够提高分布式服务高效稳定运行，通过特定场景下的全量服务信息共享和增加定时清理等手段，在客户端无感知的场景下，能够最大限度的降低分布式服务框架在服务数量骤增时，客户端内存消耗的问题，能够确保客户端的内存消耗占比能够低水位运行，能够降低服务框架因服务数量增加带来的潜在风险。具体优点如下：1、设置定时清理机制，能够确保不会因时间不断积累导致内存泄露发生；2、信息共享，通过全量信息的共享，能够极大复用能够利用的信息载体资源，减少信息的冗余；3、无需客户端参与任何配置，仅需升级jar包，能够提高客户端的可靠性。

从硬件层面来说，为了降低客户端内存压力，进而保证客户端的稳定运行，本申请提供一种用于实现所述分布式服务调用方法中的全部或部分内容的电子设备的实施例所述电子设备具体包含有如下内容：

处理器(processor)、存储器(memory)、通信接口(Communications Interface)和总线；其中，所述处理器、存储器、通信接口通过所述总线完成相互间的通信；所述通信接口用于实现所述分布式服务调用装置以及用户终端等相关设备之间的信息传输；该电子设备可以是台式计算机、平板电脑及移动终端等，本实施例不限于此。在本实施例中，该电子设备可以参照实施例用于实现所述分布式服务调用方法的实施例及用于实现所述分布式服务调用装置的实施例进行实施，其内容被合并于此，重复之处不再赘述。

图10为本申请实施例的电子设备9600的系统构成的示意框图。如图10所示，该电子设备9600可以包括中央处理器9100和存储器9140；存储器9140耦合到中央处理器9100。值得注意的是，该图10是示例性的；还可以使用其他类型的结构，来补充或代替该结构，以实现电信功能或其他功能。

在本申请一个或多个实施例中，分布式服务调用功能可以被集成到中央处理器9100中。其中，中央处理器9100可以被配置为进行如下控制：

步骤101：接收目标注册中心发送的服务信息；

步骤102：若所述服务信息对应的场景为预设的场景并且本地存在所述服务信息对应的全量服务信息，则在所述全量服务信息中添加所述服务信息对应的引用，以根据添加引用后的全量服务信息完成目标服务的调用。

从上述描述可知，本申请的实施例提供的电子设备，能够降低客户端内存压力，进而保证客户端的稳定运行。

在另一个实施方式中，分布式服务调用装置可以与中央处理器9100分开配置，例如可以将分布式服务调用装置配置为与中央处理器9100连接的芯片，通过中央处理器的控制来实现分布式服务调用功能。

如图10所示，该电子设备9600还可以包括：通信模块9110、输入单元9120、音频处理器9130、显示器9160、电源9170。值得注意的是，电子设备9600也并不是必须要包括图10中所示的所有部件；此外，电子设备9600还可以包括图10中没有示出的部件，可以参考现有技术。

如图10所示，中央处理器9100有时也称为控制器或操作控件，可以包括微处理器或其他处理器装置和/或逻辑装置，该中央处理器9100接收输入并控制电子设备9600的各个部件的操作。

其中，存储器9140，例如可以是缓存器、闪存、硬驱、可移动介质、易失性存储器、非易失性存储器或其它合适装置中的一种或更多种。可储存上述与失败有关的信息，此外还可存储执行有关信息的程序。并且中央处理器9100可执行该存储器9140存储的该程序，以实现信息存储或处理等。

输入单元9120向中央处理器9100提供输入。该输入单元9120例如为按键或触摸输入装置。电源9170用于向电子设备9600提供电力。显示器9160用于进行图像和文字等显示对象的显示。该显示器例如可为LCD显示器，但并不限于此。

该存储器9140可以是固态存储器，例如，只读存储器(ROM)、随机存取存储器(RAM)、SIM卡等。还可以是这样的存储器，其即使在断电时也保存信息，可被选择性地擦除且设有更多数据，该存储器的示例有时被称为EPROM等。存储器9140还可以是某种其它类型的装置。存储器9140包括缓冲存储器9141(有时被称为缓冲器)。存储器9140可以包括应用/功能存储部9142，该应用/功能存储部9142用于存储应用程序和功能程序或用于通过中央处理器9100执行电子设备9600的操作的流程。

存储器9140还可以包括数据存储部9143，该数据存储部9143用于存储数据，例如联系人、数字数据、图片、声音和/或任何其他由电子设备使用的数据。存储器9140的驱动程序存储部9144可以包括电子设备的用于通信功能和/或用于执行电子设备的其他功能(如消息传送应用、通讯录应用等)的各种驱动程序。

通信模块9110即为经由天线9111发送和接收信号的发送机/接收机9110。通信模块(发送机/接收机)9110耦合到中央处理器9100，以提供输入信号和接收输出信号，这可以和常规移动通信终端的情况相同。

基于不同的通信技术，在同一电子设备中，可以设置有多个通信模块9110，如蜂窝网络模块、蓝牙模块和/或无线局域网模块等。通信模块(发送机/接收机)9110还经由音频处理器9130耦合到扬声器9131和麦克风9132，以经由扬声器9131提供音频输出，并接收来自麦克风9132的音频输入，从而实现通常的电信功能。音频处理器9130可以包括任何合适的缓冲器、解码器、放大器等。另外，音频处理器9130还耦合到中央处理器9100，从而使得可以通过麦克风9132能够在本机上录音，且使得可以通过扬声器9131来播放本机上存储的声音。

上述描述可知，本申请的实施例提供的电子设备，能够降低客户端内存压力，进而保证客户端的稳定运行。

本申请的实施例还提供能够实现上述实施例中的分布式服务调用方法中全部步骤的一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，该计算机程序被处理器执行时实现上述实施例中的分布式服务调用方法的全部步骤，例如，所述处理器执行所述计算机程序时实现下述步骤：

步骤101：接收目标注册中心发送的服务信息；

步骤102：若所述服务信息对应的场景为预设的场景并且本地存在所述服务信息对应的全量服务信息，则在所述全量服务信息中添加所述服务信息对应的引用，以根据添加引用后的全量服务信息完成目标服务的调用。

从上述描述可知，本申请实施例提供的计算机可读存储介质，能够降低客户端内存压力，进而保证客户端的稳定运行。

本申请中上述方法的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。相关之处参见方法实施例的部分说明即可。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

本申请中应用了具体实施例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims (8)

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

接收目标注册中心发送的服务信息；

若所述服务信息对应的场景为预设的场景并且本地存在所述服务信息对应的全量服务信息，则在所述全量服务信息中添加所述服务信息对应的引用，以根据添加引用后的全量服务信息完成目标服务的调用；

所述根据添加引用后的全量服务信息完成目标服务的调用，包括：

根据接收的服务调用请求和预设的动态计算方法，从当前的全量服务信息中获得该服务调用请求对应的目标服务信息，以根据该目标服务信息完成目标服务的调用，所述动态计算方法用于根据本地当前存储的多个全量服务信息动态拼接成所述服务调用请求对应的目标服务信息。

2.根据权利要求1所述的分布式服务调用方法，其特征在于，所述根据该目标服务信息完成目标服务的调用，包括：

根据多条目标服务信息和软负载均衡算法，确定唯一的目标服务，以完成目标服务的调用。

3.根据权利要求1所述的分布式服务调用方法，其特征在于，还包括：

根据所述服务调用请求，更新本地的累计调用次数和调用时间；

定时将所述累计调用次数和调用时间发送至目标监控中心。

4.一种分布式服务调用装置，其特征在于，包括：

接收模块，用于接收目标注册中心发送的服务信息；

调用模块，用于若所述服务信息对应的场景为预设的场景并且本地存在所述服务信息对应的全量服务信息，则在所述全量服务信息中添加所述服务信息对应的引用，以根据添加引用后的全量服务信息完成目标服务的调用；

所述调用模块，包括：

调用单元，用于根据接收的服务调用请求和预设的动态计算方法，从当前的全量服务信息中获得该服务调用请求对应的目标服务信息，以根据该目标服务信息完成目标服务的调用，所述动态计算方法用于根据本地当前存储的多个全量服务信息动态拼接成所述服务调用请求对应的目标服务信息。

5.根据权利要求4所述的分布式服务调用装置，其特征在于，所述调用单元，包括：

确定子单元，用于根据多条目标服务信息和软负载均衡算法，确定唯一的目标服务，以完成目标服务的调用。

6.根据权利要求4所述的分布式服务调用装置，其特征在于，还包括：

更新模块，用于根据所述服务调用请求，更新本地的累计调用次数和调用时间；

监控模块，用于定时将所述累计调用次数和调用时间发送至目标监控中心。

7.一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现权利要求1至3任一项所述的分布式服务调用方法。

8.一种计算机可读存储介质，其上存储有计算机指令，其特征在于，所述指令被执行时实现权利要求1至3任一项所述的分布式服务调用方法。

Images