CN112732456A - 微服务调用方法、装置、电子设备和存储介质 - Google Patents

Abstract

本申请提出一种微服务调用方法、装置、电子设备和存储介质，其中，方法包括：获取本地存储的服务端列表；按照预设的负载均衡规则，从服务端列表中选取目标服务端；向目标服务端发送服务调用请求。该方法通过本地存储的服务端列表，客户端可以高效快速的获取可用的目标服务端，并通过预设的负载均衡规则达到对目标服务端的调用，从而实现了微服务调用中的服务发现和负载均衡。

Description

微服务调用方法、装置、电子设备和存储介质

技术领域

本申请涉及计算机技术领域，尤其涉及一种微服务调用方法、装置、电子设备和存储介质。

背景技术

微服务是一种开发软件的架构和组织方法，其中软件由通过明确定义的API进行通信的小型独立服务组成，这些服务由各个小型独立团队负责。

gRPC(Google Remote Procedure Call，Google远程过程调用)是一款语言中立、平台独立、开源的远程调用框架。目前在使用gRPC提供Python服务时，gRPC对点对点的C/S(客户端/服务器)架构支持比较好，但尚未实现微服务的服务发现、负载均衡等。

发明内容

本申请提出一种微服务调用方法、装置、电子设备和存储介质。

本申请一方面实施例提出了一种微服务调用方法，包括：

获取本地存储的服务端列表；

按照预设的负载均衡规则，从所述服务端列表中选取目标服务端；

向所述目标服务端发送服务调用请求。

本申请实施例的微服务调用方法，通过获取本地存储的服务端列表，并按照预设的负载均衡规则，从服务端列表中选取目标服务端，向目标服务端发送服务调用请求。由此，通过本地存储的服务端列表，客户端可以高效快速的获取可用的目标服务端，并通过预设的负载均衡规则达到对目标服务端的调用，从而实现了微服务调用中的服务发现和负载均衡。

在本申请的一方面实施例一种可能的实现方式中，在所述获取本地存储的服务端列表之前，还包括：

获取微服务中心发送的服务端更新通知，其中，所述更新通知中包括所述服务端列表；

存储所述服务端列表。

在本申请的一方面实施例一种可能的实现方式中，在所述获取微服务中心发送的服务端更新通知之前，还包括：

向所述微服务中心发送服务端列表订阅请求。

在本申请的一方面实施例一种可能的实现方式中，本地存储的服务端列表有多个、且每个服务端列表对应的服务类型不同，所述获取本地存储的服务端列表，包括：

根据当前待处理的源数据类型，确定待获取的目标服务类型；

获取本地存储的与所述目标服务类型对应的目标服务端列表。

本申请另一方面实施例提出了一种微服务调用方法，包括：

在监听任一服务端状态发生变更时，更新服务端列表；

向客户端发送服务端列表变更通知，以使所述客户端更新本地的服务端列表。

本申请实施例的微服务调用方法，通过在监听任一服务端状态发生变更时，更新服务端列表，并向客户端发送服务端列表变更通知，以使客户端更新本地的服务端列表。由此，实现了微服务调用中动态监听服务端的变化。

在本申请的另一方面实施例一种可能的实现方式中，所述监听到任一服务端发生变更，包括：

在连续的时段内，未监听到所述任一服务端的心跳包；

或者，

获取到所述任一服务端发送的注册请求。

在本申请的另一方面实施例一种可能的实现方式中，所述更新服务端列表，包括：

确定所述任一服务端所属的服务类型；

更新与所述服务类型对应的服务端列表。

本申请另一方面实施例提出了一种微服务调用装置，包括：

第一获取模块，用于获取本地存储的服务端列表；

选取模块，用按照预设的负载均衡规则，从所述服务端列表中选取目标服务端；

发送模块，用于向所述目标服务端发送服务调用请求。

本申请实施例的微服务调用装置，通过获取本地存储的服务端列表，并按照预设的负载均衡规则，从服务端列表中选取目标服务端，向目标服务端发送服务调用请求。由此，通过本地存储的服务端列表，客户端可以高效快速的获取可用的目标服务端，并通过预设的负载均衡规则达到对目标服务端的调用，从而实现了微服务调用中的服务发现和负载均衡。

在本申请的另一方面实施例一种可能的实现方式中，该装置还包括：

第二获取模块，用于获取微服务中心发送的服务端更新通知，其中，所述更新通知中包括所述服务端列表；

存储模块，用于存储所述服务端列表。

在本申请的另一方面实施例一种可能的实现方式中，所述发送模块，还用于向所述微服务中心发送服务端列表订阅请求。

在本申请的另一方面实施例一种可能的实现方式中，本地存储的服务端列表有多个、且每个服务端列表对应的服务类型不同，所述第一获取模块，用于：

根据当前待处理的源数据类型，确定待获取的目标服务类型；

获取本地存储的与所述目标服务类型对应的目标服务端列表。

本申请另一方面实施例提出了一种微服务调用装置，包括：

更新模块，用于在监听任一服务端状态发生变更时，更新服务端列表；

发送模块，用于向客户端发送服务端列表变更通知，以使所述客户端更新本地的服务端列表。

本申请实施例的微服务调用装置，通过在监听任一服务端状态发生变更时，更新服务端列表，并向客户端发送服务端列表变更通知，以使客户端更新本地的服务端列表。由此，实现了微服务调用中动态监听服务端的变化。

在本申请的另一方面实施例一种可能的实现方式中，所述监听到任一服务端发生变更，包括：

在连续的时段内，未监听到所述任一服务端的心跳包；

或者，

获取到所述任一服务端发送的注册请求。

在本申请的另一方面实施例一种可能的实现方式中，所述更新模块，用于：

确定所述任一服务端所属的服务类型；

更新与所述服务类型对应的服务端列表。

本申请另一方面实施例提出了一种电子设备，包括处理器和存储器；

其中，所述处理器通过读取所述存储器中存储的可执行程序代码来运行与所述可执行程序代码对应的程序，以用于实现如上述一方面实施例所述的微服务调用方法，或者实现如上述另一方面实施例所述的微服务调用方法。

本申请另一方面实施例提出了一种非临时性计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如上述一方面实施例所述的微服务调用方法，或者实现如上述另一方面实施例所述的微服务调用方法。

本申请附加的方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本申请的实践了解到。

附图说明

本申请上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：

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

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

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

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

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

图6为本申请实施例提供的一种微服务调用的过程示意图；

图7为本申请实施例提供的一种微服务调用装置的结构示意图；

图8为本申请实施例提供的另一种微服务调用装置的结构示意图。

具体实施方式

下面详细描述本申请的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，旨在用于解释本申请，而不能理解为对本申请的限制。

下面参考附图描述本申请实施例的微服务调用方法、装置、电子设备和存储介质。

本申请实施例提供的一种微服务调用方法，通过本地存储的服务端列表，可以高效快速的获取可用的目标服务端，并通过预设的负载均衡规则达到对目标服务端的调用，从而实现微服务调用中的服务发现和负载均衡。

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

本申请实施例的微服务调用方法，可应用于客户端，比如应用于Java客户端，可由本申请实施例的客户端侧的微服务调用装置执行，该装置可配置于电子设备中，比如手机、可穿戴式设备等中，以实现高效快速的获取可用的目标服务端，并通过预设的负载均衡规则达到对目标服务端的调用，从而实现服务发现和负载均衡。

如图1所示，该微服务调用方法包括：

步骤101，获取本地存储的服务端列表。

本实施例中，当客户端需要进行服务调用时，可读取本地配置文件，以获取本地存储的服务端列表。其中，服务端列表中可包括服务端的标识、服务端的IP地址、服务端提供的服务类型等，若一个服务端提供多种服务，还可包括每种服务类型对应的接口。

比如，服务端列表中包括某个服务端提供的语音识别服务、图像处理服务、语音合成服务等多种服务，以及每种服务对应的接口。

步骤102，按照预设的负载均衡规则，从服务端列表中选取目标服务端。

为了实现负载均衡，本实施例中，客户端可按照预设的负载均衡规则，从服务端列表中选取服务提供者即目标服务端。

其中，预设的负载均衡规则可以是预先设置的。比如使用随机选取的策略，从服务端列表中选取目标服务端，又如，根据服务端使用顺序，确定目标服务端。

或者，也可根据客户端所在设备当前的处理能力，确定负载均衡规则。由此，根据设备的处理能力，动态确定负载均衡规则，从而在实现负责均衡的同时，提高了处理效率。

步骤103，向目标服务端发送服务调用请求。

在确定目标服务端之后，客户端可根据目标服务端的IP地址和调用的服务对应的接口等，向目标服务端发送服务调用请求。

其中，服务调用请求中可包括客户端的标识、客户端所在设备的标识、调用的服务的标识、服务所需的参数等等。由此，目标服务端在获取到服务调用请求后，执行相应的调用服务，并将结果返回给客户端。

服务发现是指当客户端访问某个服务时，需要发现现在有哪些节点可以提供该服务。

本实施例中，按照预设的负载均衡规则，从服务端列表中选取目标服务端，并向目标服务端发送服务调用请求，从而实现了微服务调用中的服务发现和负载均衡。

在具体实现时，服务端可以是基于Python语言实现的，Python服务端提供的服务也是Python语言实现的。由于Python语言属于解释性语音，无需编译，代码更新后无需重启，因此可以实现热更新，热加载。所以基于Python语言的服务在启动时，会复制一个子进程，子进程负责监控文件是否有更新。当有更新时，子进程退出，从而向父进程发送一个特殊标识，从而父进程会重新派生一个子进程，来运行更新后的文件，从而由子进程根据更新后的文件提供服务。

客户端可以是基于Python语言，或者也可以是其他语言，比如Java语言实现的。由此，本申请实施例的微服务调用方法，可以实现微服务跨语言调用下的服务发现、负载均衡、热更新、热加载等。

本申请实施例中，通过获取本地存储的服务端列表，并按照预设的负载均衡规则，从服务端列表中选取目标服务端，向目标服务端发送服务调用请求。由此，通过本地存储的服务端列表，可以高效快速的获取可用的目标服务端，并通过预设的负载均衡规则达到对目标服务端的调用，从而实现了微服务调用中的服务发现和负载均衡。

在实际应用中，可能会出现服务端增加或减少的情况，为了提高服务调用的准确性，在本申请的一个实施例中，可从微服务中心获取服务端更新通知，根据服务端更新通知更新服务端列表。下面结合图2进行说明，图2为本申请实施例提供的另一种微服务调用方法的流程示意图。

如图2所示，该微服务调用方法包括：

步骤201，获取微服务中心发送的服务端更新通知，其中，更新通知中包括服务端列表。

本实施例中，可通过微服务中心对各个服务端的状态进行监听，在监听到服务端的状态发生变化时，比如服务端发生故障或者增加了新的服务端等，微服务中心可更新对应的服务端列表，并向客户端发送服务端更新通知，由此客户端获取微服务中心发送的服务端更新通知。其中，服务端更新通知中包括服务端列表，该服务端列表中的服务端是当前正常运行的、可提供服务的服务端。

为了减少数据传输量，当增加或减少服务端时，微服务中心也可向客户端发送相应的更新通知，由客户端根据更新通知对本地存储的服务端列表进行更新。其中，更新通知包括的是新增或者减少的服务端的信息。

比如，当微服务中心监听到服务端A的注册请求，那么微服务中心可向客户端发送客服务端更新通知，其中，更新通知中包括服务端A加入的时间、服务端A的标识、服务端提供的服务等，以通知客户端新增了客户端A，那么客户端接收到更新通知后，可根据服务端更新通知，将服务端A的信息增加至与所提供的服务对应的服务端列表中。

又如，各服务端可周期性的向微服务中心发送心跳包，若微服务中心在连续的时段内，未监听到服务端B的心跳包，那么微服务中心可认为服务端B被删除，则向客户端发送服务端更新通知。其中，更新通知中包括服务端B的标识，以通知客户端新增了服务端B。客户端接收到更新通知后，可根据服务端更新通知，将服务端B的信息从本地的服务端列表中删除。

在具体实现时，可将Zookeeper或者Zookeeper集群作为微服务中心。其中，zookeeper是一个分布式的、开放源码的分布式应用程序协调服务，是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。

步骤202，存储服务端列表。

本实施例中，客户端在获取到微服务中心发送的服务端列表后，可将服务端列表中存储在本地。若客户端本地存储了服务端列表，可将从微服务中心获取的最新的服务端列表，替换本地对应旧的服务端列表。

步骤203，获取本地存储的服务端列表。

本实施例中，当客户端需要进行服务调用时，可读取本地配置文件，以获取本地存储的服务端列表。具体地，如上述实施例所述，在此不再赘述。

步骤204，按照预设的负载均衡规则，从服务端列表中选取目标服务端。

步骤205，向目标服务端发送服务调用请求。

本实施例中，步骤203-步骤205与上述步骤101-步骤103类似，故在此不再赘述。

本申请实施例中，在获取本地存储的服务端列表之前，还可获取微服务中心发送的服务端更新通知，其中，更新通知中包括服务端列表，并存储服务端列表，在需要调用服务时，可获取本地存储的服务端列表，并根据预设的负载均衡规则，选取目标服务端，向目标服务端发送服务调用请求。由此，通过获取微服务中心发送的服务端更新通知，可实时对本地的服务端列表进行更新，利用最新的服务端列表进行服务调用，提高了服务调用的准确性。

在实际应用中，为了避免微服务中心频繁地向各个客户端发送服务端列表更新通知，打扰客户端。基于此，在本申请的一个实施例中，在获取微服务中心发送的服务端更新通知之前，可向微服务中心发送服务端列表订阅请求。

本实施例中，各个客户端可根据需要向微服务中心发送服务端列表订阅请求，其中，服务端列表订阅请求中包括客户端的标识、客户端所在设备的标识等。由此，微服务中心根据接收的服务端列表订阅请求，可以获取发送了服务端列表订阅请求的各客户端的信息，由此微服务中心可以确定哪些客户端订阅了服务端列表更新通知。

当任一服务端的状态发送变化时，微服务中心可向订阅了服务端更新通知的客户端发送服务端更新通知，从而避免向所有客户端发送服务端更新通知，对其他客户端造成打扰。

由于各个服务端可能提供不同的服务，一个服务端也可能提供多种服务，为了提高个性化需求，进一步地，当微服务中心有多种类型的服务时，客户端在订阅服务端列表更新通知时，可以指定要订阅的服务类型。其中，向微服务中心发送的服务端列表订阅请求可包括订阅的服务类型的标识。由此，当服务端提供的某服务类型发生变化时，比如删除了该服务类型等，微服务中心可向订阅了该服务类型的客户端发送服务端列表更新通知，以通知客户端当前提供该服务类型的服务端列表。

本申请实施例中，在获取微服务中心发送的服务端更新通知之前，还可向微服务中心发送服务端列表订阅请求。由此，通过向微服务中心发送服务端列表订阅请求，微服务中心可根据订阅请求可向相应的客户端发送服务端列表更新通知，避免向所有客户端发送更新通知，减少了对其他客户端的打扰。

为了进一步提高服务调用效率，在本申请的一个实施例中，若客户端本地存储的服务端列表有多个，每个服务端列表对应不同的服务类型，这时可从本地存储的服务端列表中，获取目标服务端列表，从目标服务端列表中，选取目标服务端。下面结合图3进行说明，图3为本申请实施例提供的另一种微服务调用方法的流程示意图。

如图3所示，该微服务调用方法包括：

步骤301，根据当前待处理的源数据类型，确定待获取的目标服务类型。

本实施例中，客户端本地可存储多个服务端列表，每个服务端列表对应不同的服务类型，比如有图像处理服务、语音识别服务、语音合成服务等等。

比如，某服务端列表对应的是语音识别服务，说明该服务端列表中包括的是能够提供语音识别服务的服务端的列表。

当客户端需要向服务端发送调用请求时，客户端可先根据当前待处理的源数据类型，确定待获取的目标服务类型。比如，待处理的源数据类型为图像类型，那么可以确定对应的服务类型为图像处理服务；又如，待处理的源数据类型为语音类型，可以确定目标服务类型为语音识别服务。

步骤302，获取本地存储的与目标服务类型对应的目标服务端列表。

在获取目标服务类型后，可根据本地存储的每个服务端列表对应的服务类型，从多个服务端列表中，获取与目标服务类型对应的目标服务端列表。

步骤303，按照预设的负载均衡规则，从目标服务端列表中选取目标服务端。

在获取目标服务端列表后，可按照预设的负载均衡规则，从目标服务端列表中选取目标服务端。比如，从目标服务端列表中随机选择一个服务端，作为目标服务端。

本实施例中，选取目标服务端的方法与上述步骤102类似，故在此不再赘述。

步骤304，向目标服务端发送服务调用请求。

本实施例中，步骤304与上述步骤103类似故在此不再赘述。

本申请实施例中，若本地存储的服务端列表有多个、且每个服务端列表对应的服务类型不同，在获取本地存储的服务端列表时，可根据当前待处理的源数据类型，确定待获取的目标服务类型，获取本地存储的与目标服务类型对应的目标服务端列表，以从目标服务端列表中选出目标服务端，向目标服务端发送服务调用请求。由此，当本地存储的服务端列表有多个时，通过根据当前待处理的源数据类型，确定待获取的目标服务类型，根据目标服务类型，确定目标服务端列表，从而提高了服务调用效率。

为了实现上述实施例，本申请实施例还提出一种微服务调用方法。图4为本申请实施例提供的另一种微服务调用方法的流程示意图。

本申请实施例的微服务调用方法，可由微服务中心执行，比如，由Zookeeper或Zookeeper集群执行，以实现对服务端进行动态监听。

如图4所示，该微服务调用方法包括：

步骤401，在监听任一服务端状态发生变更时，更新服务端列表。

本实施例中，微服务中心可对每个已在微服务中心注册的服务端进行监听，在监听到任一服务端状态发生变更时，更新服务端列表。

作为一种可能的实现方式，可每隔预设时间向各服务端发送监听消息，若在预设时间内未收到反馈消息，可以认为服务端停止提供服务，则可将该服务端从服务端列表中删除。

作为另一种可能的实现方式，各服务端可每隔预设时间向微服务中心发送心跳包，若微服务中心在连续时间段内，比如连续5分钟或者10分钟等，未监听到任一服务端的心跳包，可认为该服务端停止提供服务，则可将该服务端从服务端列表中删除。

需要说明的是，连续时间段可以根据需要确定，本申请对此不作限定。

作为再一种可能的实现方式，服务端可向微服务中心发送注册请求，以在微服务中心进行注册。其中，注册请求中可包括服务端的标识、提供的服务类型及对应的接口等信息。

当微服务中心获取任一服务端发送的注册请求时，微服务中心可根据任一服务端提供的服务类型，将任一服务端添加至对应的服务端列表中，以对服务端列表进行更新。

在具体实现时，可Zookeeper或Zookeeper集群作为微服务中心，可以对Python服务端在启动时进行注册。具体地，Python服务端启动成功后，首先在启动Python父进程服务时，同时派生一个子进程，当子进程监控到文件改变后，会先调用自己的退出方法，退出该进程，并向父进程发送一个特殊标识，同时父进程获取特殊标识后，再次启动子进程。最后，向微服务中心发送服务信息，进行服务注册。

步骤402，向客户端发送服务端列表变更通知，以使客户端更新本地的服务端列表。

在更新服务端列表后，微服务中心可向客户端发送服务端列表变更通知，以使客户端更新本地的服务端列表。其中，服务端列表变更通知中可包括最新的服务端列表，使客户端用最新的服务端列表替换本地存储的服务端列表。或者，服务端列表变更通知中也可包括状态发生变更的服务端信息，使客户端根据状态发生变更的服务端信息，对本地存储的服务端列表进行更新。

比如，在连续的时段内，未监听到某服务端的心跳包，那么微服务中心可将该服务端从服务端列表中删除，并向客户端发送服务端列表更新通知，其中，更新通知中可包括更新后的服务端列表，更新后的服务端列表中不包括该服务端。或者，更新通知中也可包括该服务端的信息，以使客户端根据该服务端的信息，将该服务端从本地的服务端列表中删除。

若有新注册的服务端，那么微服务中心可向客户端发送服务端列表更新通知。其中，更新通知中可包括具有新增加的服务端的服务端列表，也即包括最新的服务端列表，使客户端用最新的服务端列表替换本地存储的服务端列。或者，更新通知也可包括新增加的服务端的信息，以使客户端根据该服务端的信息，在本地服务端列表中增加该服务端的信息。

本申请实施例中，通过在监听任一服务端状态发生变更时，更新服务端列表，并向客户端发送服务端列表变更通知，以使客户端更新本地的服务端列表。由此，可以实现对服务端进行动态监控，并在服务端状态发生变化时，向客户端发送更新通知，以使客户端对本地存储的服务端列表进行实时更新。

为了提高服务端列表更新的准确性，在本申请的一个实施例中，可将状态发生变更的服务端，更新至其所属的服务类型对应的服务端列表中。下面结合图5进行说明，图5为本申请实施例提供的另一种微服务调用方法的流程示意图。

如图5所示，该微服务调用方法包括：

步骤501，在监听任一服务端状态发生变更时，确定任一服务端所属的服务类型。

本实施例中，每个服务端可能提供一种或多种类型的服务，在监听到任一服务端状态发生变更时，可确定任一服务端所属的服务类型。其中，任一服务端所属的服务类型，可能是一个，也可能是多个。

步骤502，更新与服务类型对应的服务端列表。

在确定任一服务端所属的服务类型后，可根据任一服务端所属的服务类型，及每个服务端列表所对应的服务类型，确定与所属服务类型对应的服务端列表，并进行更新。这里服务端所属的服务类型，可以认为是服务端能够提供的服务类型。

比如，某状态发生变更的服务端所属的服务类型为S1和S2两种类型，则分别对服务类型S1对应的服务端列表进行更新，和对服务类型S2对应的服务端列表进行更新。

本实施例中，通过根据状态发生变更的服务端所属的服务类型，对所属的服务类型对应的服务端列表进行更新，从而提高了更新的准确性。

步骤503，向客户端发送服务端列表变更通知，以使客户端更新本地的服务端列表。

本实施例中，步骤503与上述步骤402类似故在此不再赘述。

本申请实施例中，在监听到任一服务端状态发生变更，更新服务端列表时，可确定任一服务端所属的服务类型，并更新与服务类型对应的服务端列表，向客户端发送服务端列表变更通知，以使客户端更新本地的服务端列表。由此，通过根据状态发生变更的服务端所属的服务类型，对所属的服务类型对应的服务端列表进行更新，提高了更新的准确性。

下面以基于Java语言实现的客户端、基于Python语言实现的服务端、微服务中心zookeeper集群为例，结合图6，对本申请实施例的微服务调用方法进一步说明。图6为本申请实施例提供的一种微服务调用的过程示意图。

图6中示出了2个Java客户端，3个Python服务端，和1个zookeeper集群。如图6所示，第1步：3个Python服务端向zookeeper集群发送注册请求，zookeeper集群根据注册请求，可以确定有新增的服务端；第2步：2个Java客户端向zookeeper集群发送订阅请求；第3步：zookeeper集群在监听到服务端的状态发生变更时，向Java客户端发送服务端列表变更通知；第4步，Java客户端根据变更通知对本地配置文件进行更新，具体是更新本地存储的服务端列表；第5步，Java客户端在需要进行服务调用时，读取本地配置文件，获取本地存储的服务端列表；第6步，负载均衡器利用Java客户端中预设的负载均衡双机热备方案，确定目标服务端；第7步，向Python服务端发送服务调用请求。

为了实现上述实施例，本申请实施例还提出一种微服务调用装置。图7为本申请实施例提供的一种微服务调用装置的结构示意图。

本申请实施例的微服务调用装置，可配置于客户端中，以实现微服务调用中的服务发现和负载均衡。

如图7所示，该微服务调用装置700包括：第一获取模块710、选取模块720和发送模块730。

第一获取模块710，用于获取本地存储的服务端列表；

选取模块720，用按照预设的负载均衡规则，从服务端列表中选取目标服务端；

发送模块730，用于向目标服务端发送服务调用请求。

在本申请实施例一种可能的实现方式中，该装置还可包括：

第二获取模块，用于获取微服务中心发送的服务端更新通知，其中，更新通知中包括服务端列表；

存储模块，用于存储服务端列表。

在本申请实施例一种可能的实现方式中，发送模块730，还用于向微服务中心发送服务端列表订阅请求。

在本申请实施例一种可能的实现方式中，本地存储的服务端列表有多个、且每个服务端列表对应的服务类型不同，第一获取模块710，用于：

根据当前待处理的源数据类型，确定待获取的目标服务类型；

获取本地存储的与目标服务类型对应的目标服务端列表。

需要说明的是，上述对客户端侧微服务调用方法实施例的解释说明，也适用于该实施例的微服务调用装置，故在此不再赘述。

本申请实施例的微服务调用装置，通过获取本地存储的服务端列表，并按照预设的负载均衡规则，从服务端列表中选取目标服务端，向目标服务端发送服务调用请求。由此，通过本地存储的服务端列表，客户端可以高效快速的获取可用的目标服务端，并通过预设的负载均衡规则达到对目标服务端的调用，从而实现了微服务调用中的服务发现和负载均衡。

为了实现上述实施例，本申请实施例还提出一种微服务调用装置。图8为本申请实施例提供的另一种微服务调用装置的结构示意图。

本申请实施例的微服务调用装置，可配置于微服务中心，以实现对服务端的状态进行服务注册、动态监听等。

如图8所示，该微服务调用装置800包括：更新模块810和发送模块820。

更新模块810，用于在监听任一服务端状态发生变更时，更新服务端列表；

发送模块820，用于向客户端发送服务端列表变更通知，以使客户端更新本地的服务端列表。

在本申请实施例一种可能的实现方式中，监听到任一服务端发生变更，包括：

在连续的时段内，未监听到任一服务端的心跳包；

或者，

获取到任一服务端发送的注册请求。

在本申请实施例一种可能的实现方式中，更新模块820，用于：

确定任一服务端所属的服务类型；

更新与服务类型对应的服务端列表。

需要说明的是，上述对微服务中心侧微服务调用方法实施例的解释说明，也适用于该实施例的微服务调用装置，故在此不再赘述。

本申请实施例的微服务调用装置，通过在监听任一服务端状态发生变更时，更新服务端列表，并向客户端发送服务端列表变更通知，以使客户端更新本地的服务端列表。由此，实现了微服务调用中动态监听服务端的变化。

为了实现上述实施例，本申请实施例还提出一种电子设备，包括处理器和存储器；

其中，处理器通过读取存储器中存储的可执行程序代码来运行与所述可执行程序代码对应的程序，以用于实现如上述实施例所述的微服务调用方法。

为了实现上述实施例，本申请实施例还提出一种非临时性计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如上述实施例所述的微服务调用方法。

在本说明书的描述中，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。在本申请的描述中，“多个”的含义是至少两个，例如两个，三个等，除非另有明确具体的限定。

尽管上面已经示出和描述了本申请的实施例，可以理解的是，上述实施例是示例性的，不能理解为对本申请的限制，本领域的普通技术人员在本申请的范围内可以对上述实施例进行变化、修改、替换和变型。

Claims (16)

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

获取本地存储的服务端列表；

按照预设的负载均衡规则，从所述服务端列表中选取目标服务端；

向所述目标服务端发送服务调用请求。

2.如权利要求1所述的方法，其特征在于，在所述获取本地存储的服务端列表之前，还包括：

获取微服务中心发送的服务端更新通知，其中，所述更新通知中包括所述服务端列表；

存储所述服务端列表。

3.如权利要求2所述的方法，其特征在于，在所述获取微服务中心发送的服务端更新通知之前，还包括：

向所述微服务中心发送服务端列表订阅请求。

4.如权利要求1-3任一所述的方法，其特征在于，本地存储的服务端列表有多个、且每个服务端列表对应的服务类型不同，所述获取本地存储的服务端列表，包括：

根据当前待处理的源数据类型，确定待获取的目标服务类型；

获取本地存储的与所述目标服务类型对应的目标服务端列表。

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

在监听任一服务端状态发生变更时，更新服务端列表；

向客户端发送服务端列表变更通知，以使所述客户端更新本地的服务端列表。

6.如权利要求5所述的方法，其特征在于，所述监听到任一服务端发生变更，包括：

在连续的时段内，未监听到所述任一服务端的心跳包；

或者，

获取到所述任一服务端发送的注册请求。

7.如权利要求5或6所述的方法，其特征在于，所述更新服务端列表，包括：

确定所述任一服务端所属的服务类型；

更新与所述服务类型对应的服务端列表。

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

第一获取模块，用于获取本地存储的服务端列表；

选取模块，用按照预设的负载均衡规则，从所述服务端列表中选取目标服务端；

发送模块，用于向所述目标服务端发送服务调用请求。

9.如权利要求8所述的装置，其特征在于，还包括：

第二获取模块，用于获取微服务中心发送的服务端更新通知，其中，所述更新通知中包括所述服务端列表；

存储模块，用于存储所述服务端列表。

10.如权利要求9所述的装置，其特征在于，所述发送模块，还用于向所述微服务中心发送服务端列表订阅请求。

11.如权利要求8-10任一所述的装置，其特征在于，本地存储的服务端列表有多个、且每个服务端列表对应的服务类型不同，所述第一获取模块，用于：

根据当前待处理的源数据类型，确定待获取的目标服务类型；

获取本地存储的与所述目标服务类型对应的目标服务端列表。

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

更新模块，用于在监听任一服务端状态发生变更时，更新服务端列表；

发送模块，用于向客户端发送服务端列表变更通知，以使所述客户端更新本地的服务端列表。

13.如权利要求12所述的装置，其特征在于，所述监听到任一服务端发生变更，包括：

在连续的时段内，未监听到所述任一服务端的心跳包；

或者，

获取到所述任一服务端发送的注册请求。

14.如权利要求12或13所述的装置，其特征在于，所述更新模块，用于：

确定所述任一服务端所属的服务类型；

更新与所述服务类型对应的服务端列表。

15.一种电子设备，其特征在于，包括处理器和存储器；

其中，所述处理器通过读取所述存储器中存储的可执行程序代码来运行与所述可执行程序代码对应的程序，以用于实现如权利要求1-4中任一所述的微服务调用方法或者实现如权利要求5-7中任一所述的微服务调用方法。

16.一种非临时性计算机可读存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行时实现如权利要求1-4中任一所述的微服务调用方法或者实现如权利要求5-7中任一所述的微服务调用方法。

Images