CN105933444A - 基于注册中心和缓存机制协同的服务发现方法 - Google Patents

Abstract

一种基于注册中心和缓存机制协同的服务发现方法，通过在服务调用端配置缓存，将服务提供端所提供服务的相关信息存入服务调用端的本地缓存中，使服务调用端的本地缓存和注册中心在服务发现过程中协同工作；步骤1：缓存的设置及初始化，当服务调用端启动时，根据调用端的服务订阅数量最大值和本地缓存占用内存的最大值，在服务调用端的内存中开辟相应的空间，作为服务订阅注册信息的存储区；步骤2：为服务调用端配置好本地缓存后，服务提供端所提供服务的注册信息分别存于注册中心中和服务调用端的本地缓存中；在服务发现过程中，注册中心和服务调用端的缓存协同合作，使服务调用者能脱离注册中心调用需要的服务。

Description

基于注册中心和缓存机制协同的服务发现方法

技术领域

本发明属于计算机处理技术的服务发现领域，具体涉及一种基于注册中心和缓存机制协同的服务发现方法。

背景技术

随着软件设计尤其是分布式软件设计理论与实践的发展，面向服务的软件设计思想逐渐被各大中型软件系统设计人员所接受，成为软件设计的主流趋势之一。软件设计服务化区别于传统的软件设计模式，强调功能的模块化和独立化，它将通用的功能抽象为单一的服务实体，供其它服务或应用来调用，避免了在软件开发过程中“重复发明轮子”，以增强服务的可扩展性，提高资源的利用率，增强系统的整体稳定性。

由于现有的服务发现都是基于注册中心，从而所有的服务调用客户端都依赖于一个注册中心，在性能上存在一定的瓶颈。注册中心的稳定性将很大地制约服务发现的发展。

服务发现机制是以最大限度提高资源和服务的访问有用性及有效性的解决方案，包括资源和服务的注册、访问、管理和维护等。服务发现记录了大规模分布式系统中所有服务的信息，是服务框架所面临的一个基础问题。高效的服务发现机制是衡量服务框架好坏的标志之一。服务状态一般包括上线、下线、重新上线、异常等。服务状态维护是指由系统识别并跟踪服务的状态变化，根据状态的变化触发相应的处理逻辑，使得系统各参与方对服务状态变化进行感知。传统的服务状态维护方式一般是通过轮询，即由服务提供者周期性地向注册中心汇报自身状态，或注册中心周期性地向服务提供者探测状态，再由服务调用者周期性地向注册中心检查服务提供者的状态，然而这种仅依靠“轮询方式”维护服务状态存在俩种缺陷：

其一，状态实时性存在一定局限性。轮询间隔(也称“心跳”)期间，存在延时间隙。当某服务A不可用时，在下一次服务调用者想要调用服务A时，由于服务调用者无法及时感知服务A的状态更新，继续调用将导致这段期间内对A的服务调用错误；

其二，服务调用的稳定性依赖于注册中心。第三方的注册中心可能由于自身的软件bug或网络环境等原因，容易出现不稳定的情况。而服务提供者和服务调用者因时刻维护服务状态，两者均与注册中心交互频繁，这样容易导致服务调用的可靠性受限于第三方组件。

发明内容

为解决上述的问题，本发明的目的是通过在服务调用端配置缓存，将服务提供端所提供服务的相关信息存入服务调用端的本地缓存中，使服务调用端的本地缓存和注册中心在服务发现过程中协同工作。当服务调用者在调用所需服务时，不仅可以通过注册中心获取服务状态信息，也可以从缓存中直接调用获取。本发明能减少服务提供者和服务调用者对注册中心的依赖，有利于提高服务调用的效率。

一种基于注册中心和缓存机制协同的服务发现方法，技术方案具体如下：

首先，缓存的设置及初始化，具体为当服务调用端启动时，根据调用端的服务订阅数量最大值和本地缓存占用内存的最大值，在服务调用端的内存中开辟相应的空间，作为订阅服务注册信息的存储区；

特别地，与以往的服务调用端不同，本发明中的服务调用端是一个包含缓存装置的服务调用者，它能缓存自身所订阅服务的相关信息。

其次，为服务调用端配置好本地缓存后，服务提供端所提供服务的注册信息分别存于注册中心中和服务调用端的本地缓存中，注册中心和服务调用端通过与服务提供端建立长连接执行周期性探测服务提供端的运行情况；在服务发现过程中，注册中心和服务调用端的缓存能协同合作，能使服务调用者能脱离注册中心调用需要的服务，具体步骤包括：

步骤1：发布服务；服务提供端启动后，在注册中心注册服务信息并发布，服务的注册信息包括服务名称、类型、与该服务相关的函数接口信息、服务节点地址信息(含IP地址和端口号)、版本信息等。

通过服务的发布，注册中心能根据该服务的注册信息完成对该服务记录和存储，同时建立与服务提供端之间的长连接关系，并能周期性探测该服务的状态变化；当服务提供端出现故障或异常时，注册中心能即时发现并更新该服务在注册中心的服务状态；

步骤2：订阅服务；服务调用端从注册中心中订阅自己需要的服务，若注册中心已注册该服务，服务调用端直接从注册中心获取该服务的注册信息，同时将该服务的注册信息存入本地缓存中；

当服务调用端订阅服务的注册信息存入服务调用端的缓存中时，服务调用端和服务提供端建立长连接，服务调用端能周期性对服务提供端运行状态及健康状况的进行探测，一旦服务调用端检测到服务提供者的状态异常(比如服务下线)，则更新该服务在服务调用端本地缓存中的服务状态，并将该状态更新情况通知给注册中心。

步骤3：调用服务；当服务调用端需要使用某项服务时，服务调用端能完全脱离注册中心，直接通过读取本地缓存中服务提供者所提供服务的注册信息，选择最佳的服务提供端，并通过远程过程调用协议调用远程服务的接口，进而一直使用服务；

步骤4：更新服务的状态；所述服务状态更新，按照服务状态条件，可分为三种：服务提供端的服务新上线、服务提供端的服务下线、服务提供端的服务重新上线；

在服务发现过程中，每一次服务调用端的服务状态变化，相应地，注册中心和服务调用端的服务状态信息同时更新变化，具体为：

步骤4-1：服务提供端的服务状态变更，服务提供端主动向注册中心发送服务状态变更的消息，注册中心根据消息内容识别服务，修改该服务存储在注册中心中的服务状态；

步骤4-2：注册中心寻找所有调用该服务的服务调用端，逐一向各服务调用端发送服务状态变更的消息；

特别地，服务提供端发送给注册中心的有关服务状态变更的通知消息和注册中心发送给服务调用端的有关服务状态变更的通知消息，内容包括但不限于：

(1)服务名称及服务类型；

(2)与该项服务相关的函数接口信息；

(3)服务地址信息，包含IP地址和端口；

(4)服务版本信息：服务更新前的状态、服务当前状态等；

步骤4-3：服务调用端接收到注册中心的消息，根据消息内容检查并校验本地缓存中该服务提供者的当前状态后，立即修改该服务的注册信息，更新该服务的服务状态。

当服务调用端的缓存中的服务状态更新完毕后，之后服务调用端针对该项服务的调用，完全脱离对注册中心的依赖，均通过读取本地缓存中最新的服务信息，利用远程过程调用协议调用该远程服务的接口。

本发明与现有技术相比，其有益效果：

(1)本发明通过为服务调用端配置缓存，将服务提供者所提供服务的信息存入服务调用端，在服务调用过程中，服务调用端可完全脱离对注册中心的依赖，直接通过调用本地缓存内的服务信息获取服务，减少服务提供端及服务调用端对注册中心的依赖，提升服务调用的效率；

(2)本发明通过利用缓存机制，使注册中心和服务调用端的本地缓存协同工作，当注册中心因故障不可用时，在服务调用端与注册中心不能正常通信的前提下，服务调用端可从本地缓存获取服务提供者的相关信息，避免了因注册中心不稳定而导致的服务调用异常。

附图说明

图1为本发明实施例中一种基于注册中心和缓存机制协同的服务发现方法流程图

图2为本发明实施例中一种基于注册中心和缓存机制协同的服务方法

具体实施方式

为使本发明的目的、技术方案和优点更加清楚明白，以下结合具体实施例，并参照附图，对本发明进一步详细说明。

本发明是通过在服务调用端设置缓存区，将服务提供端所提供服务的相关信息存入服务调用端的本地缓存中，使服务调用端的本地缓存和注册中心在服务发现过程中协同工作。当服务调用者在调用所需服务时，不仅可以通过注册中心获取服务状态信息，也可以从缓存中直接调用获取。

所述服务状态，是预定义的一组关于服务当前能否正常提供服务的状态值，用于注册中心和服务调用者识别服务的可用状态，状态值包括“上线”、“下线”、“重新上线”等。其中，“上线”、“重新上线”状态意味着该服务当前可用，“下线”状态意味着该服务当前不可用；

图1是本发明实施例中基于注册中心和缓存机制协同的服务发现系统架构图，该系统架构中包含三个主体，即服务提供端、服务注册中心及服务调用端。

所述服务提供端，是指提供服务接口的软件程序；服务发布后，服务提供端与注册中心始终保持连接状态，每一次服务的上线或下线，服务提供端都会实时将服务状态变更的消息通过通知模块发送给服务注册中心；

所述服务注册中心，是已发布服务的信息聚合区；服务注册中心可以是基于第三方软件，比如采用分布式协调工具Zookeeper、etcd等，或采用NoSQL存储系统，比如Redis；也可以是通过开发的注册中心组件，并提供基本功能：(1)与服务调用端的通信；(2)服务注册信息的存储；

特别地，每一个服务状态的变化，服务注册中心都会将服务状态变更的消息通知给服务调用端，并将有关该服务的相关信息同时发送至服务调用端的本地缓存中存储；

所述服务调用端，是指需要调取服务的软件程序，既可以是独立的应用程序，也可以是其他服务的提供者；与以往的服务调用端不同，本发明实施例中的服务调用端会将自己部分内存开辟出来作为缓存区，用于实时存储服务提供者的服务信息；

图2是本发明实施例中基于注册中心和缓存机制协同的服务方法的实现步骤：

步骤101：缓存的设置及初始化，具体为当服务调用端启动时，根据调用端的服务订阅数量最大值和本地缓存占用内存的最大值，在服务调用端的内存中开辟相应的空间，作为订阅服务注册信息的存储区；

经过设置，服务调用端成为一个能缓存自身所订阅服务的相关信息的客户端；

步骤102：服务提供端启动，在服务注册中心进行服务的注册，并通过服务注册中心将服务发布；至此，服务提供端和服务注册中心通过心跳模块建立长连接，保证周期性的服务数据交互，维持服务状态信息的一致性；

服务提供端在服务注册中心中的注册信息包含服务名称、服务类型、与该服务相关的接口信息、服务地址信息(含IP地址和端口号)、服务版本信息等等；

步骤103：服务调用端从服务注册中心中订阅需要的服务。若此时服务注册中心已有该服务的注册记录，服务调用端在订阅服务的同时，服务注册中心将该服务的注册信息可以特定格式的数据包形式发送至服务调用端的缓存区；

当服务调用端订阅服务的注册信息存入本地缓存中后，服务调用端和服务提供端通过心跳模块建立长连接，服务调用端开始周期性地探测服务提供者的运行状态及健康状况，一旦检测到状态异常，包括服务的下线、服务异常中断等，服务调用端更新本地缓存中该服务的服务状态，同时将本地缓存区内服务状态更新情况报告给服务注册中心。

步骤104：当服务调用端需要使用某项服务时，服务调用端直接从本地缓存中获取该服务的注册信息，进而选择最佳的服务提供端，并可以通过远程过程调用协议调用该远程服务的接口；

步骤105：当服务调用端所提供服务的服务状态发生变更，服务提供端主动向服务注册中心发送“服务状态变更”的消息，消息内容包括服务名称、服务类型、与该服务相关的函数接口信息、服务地址信息及服务版本信息；其中，服务版本信息包括服务更新前的服务状态和服务当前状态；注册中心根据消息内容中的服务名称及服务类型识别服务，并更新其内部存储的服务状态为变更后的状态；

步骤106：注册中心寻找所有订阅该更新服务的服务调用端，依次向各服务调用端发送“服务状态变更”的消息，消息内容包括服务名称、服务类型、与该服务相关的函数接口信息、服务地址信息及服务版本信息；其中，服务版本信息包括服务更新前的服务状态和服务当前状态；

步骤107：当服务调用端接收到服务注册中心发送的“服务状态变更”消息，立即根据消息内容中的服务名称及服务类型识别服务，并更新本地缓存中该服务的服务状态为变更后的状态；

整个RPC通信期间的服务状态更新不再依赖注册中心，只通过本地缓存。

实施例一

现有的服务发现环境是消息服务(记做message service)，提供服务包括：向用户发送消息。已将服务注册到Zookeeper注册中心的目录中，客户端为应用程序(记做UserClient)已从Zookeeper注册中心订阅服务message service，并将获得的服务注册信息缓存至本地。User Client通过长连接与消息服务的提供方message service保持正常通信，User Client可以通过RPC协议从服务提供方message service调用服务，并一直使用本地存储的该服务注册信息与message服务进行通信。

在现有的服务提供环境下，询盘服务预上线，该项服务的提供者inquiry service加入当前环境中，服务提供者inquiry service首先在Zookeeper注册中心进行如下注册，并将服务发布，以便被服务调用者订阅；

(1)服务名称：给客户发送消息；

(2)服务类型：函数；

(3)与服务相关的函数接口：sendInquiry,batchSendInquiry；

(4)服务地址：127.0.0.1:8181；

(5)服务版本：1.0.0。

Zookeeper注册中心完成对服务inquiry service的记录，客户端User Client通过从Zookeeper注册中心订阅服务获取inquiry service服务的注册信息，服务的注册信息以特定格式数据包的形式由Zookeeper注册中心传至客户端User Client，并存储在User Client的本地缓存中；当客户端需要使用服务时，直接从本地缓存中调用服务的注册信息，根据信息内容找到inquiry service的地址和函数接，通过RPC协议实现对inquiry service的sendInquiry函数和batchSendInquiry函数进行调用，进而能跨注册中心直接使用inquiryservice提供的函数调用服务；

实施例二

当服务提供端主动下线时，该服务提供端主动向Zookeeper服务注册中心通知服务下线事件，服务注册中心收到通知后即时检查该服务在注册中心内的服务状态，若当前的服务状态为“服务上线”，则将该服务的状态更新为“服务下线”；若当前的服务状态为下线，说明此前已经收到过“服务下线”通知，则不执行状态的修改；

当注册中心对服务状态做了更新后，注册中心获取已订阅此服务的所有客户端的注册信息。注册中心通过长连接，依次将相关服务状态变更的信息以特定的数据包形式传送至客户端，消息内容是该服务在Zookeeper注册中心的注册信息；当客户端接收到消息后，客户端的本地缓存按照消息内容中的消息名称寻找该服务并检测服务状态，完成检测后更新现有的服务状态“服务上线”为“服务下线”；

当客户端在和服务提供端通信过程中，探测到服务提供端异常下线时，客户端首先会立即检测并获取该服务在本地缓存中的服务状态，将当前的“服务上线”状态更新为“服务下线”状态，同时将本地缓存的状态更新情况与服务注册信息一并成数据包，传送至Zookeeper服务注册中心处理。

实施例三

当服务提供端重新上线时，服务提供端主动向Zookeeper注册中心通知上线事件。由于该服务在注册中心中已完成注册并发布，Zookeeper注册中心识别出上线事件后检查该服务的服务状态；

若当前该服务的状态为“服务下线”，则注册中心将该服务提供端的服务状态改为“服务下线”；同时将服务状态更新的消息传送至客户端，客户端接收到消息后，客户端的本地缓存按照消息内容中的消息名称寻找该服务并检测服务状态，完成检测后更新现有的服务状态“服务上线”为“服务下线”；

若当前该服务的状态为“服务上线”，则表明该服务提供端为短暂失联，并在心跳间隔期间自动恢复与Zookeeper注册中心的联系，Zookeeper注册中心记录日志，不执行状态修改。

所属领域的普通技术人员应当理解：以上所述仅为本发明的具体实施例而已，并不用于限制本发明，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (5)

1.一种基于注册中心和缓存机制协同的服务发现方法，其特征在于，通过在服务调用端配置缓存，将服务提供端所提供服务的相关信息存入服务调用端的本地缓存中，使服务调用端的本地缓存和注册中心在服务发现过程中协同工作；当服务调用者在调用所需服务时，不仅能通过注册中心获取服务状态信息，也能从缓存中直接调用获取，具体步骤包括为：

步骤1：缓存的设置及初始化，具体为当服务调用端启动时，根据调用端的服务订阅数量最大值和本地缓存占用内存的最大值，在服务调用端的内存中开辟相应的空间，作为服务订阅注册信息的存储区；

步骤2：为服务调用端配置好本地缓存后，服务提供端所提供服务的注册信息分别存于注册中心中和服务调用端的本地缓存中，注册中心和服务调用端通过与服务提供端建立长连接执行周期性探测服务提供端的运行情况；在服务发现过程中，注册中心和服务调用端的缓存协同合作，能使服务调用者能脱离注册中心调用需要的服务。

2.根据权利要求1所述的基于注册中心和缓存机制协同的服务发现方法，其特征在于，经过本地缓存配置，所述服务调用端是一个能缓存自身所订阅服务的相关信息的终端。

3.根据权利要求1所述的一种基于注册中心和缓存机制协同的服务发现方法，其特征在于，在所述步骤2中，注册中心和服务调用端的本地缓存在服务发现过程中能协同工作，具体步骤包括：

步骤2-1：发布服务；服务提供端启动后，在注册中心注册服务信息并发布，服务的注册信息包括服务名称、类型、与该服务相关的函数接口信息、服务节点地址信息(含IP地址和端口号)、服务版本信息等；

通过服务信息的发布，注册中心能根据该服务的注册信息完成对该服务记录和存储，同时建立与服务提供端之间的长连接关系，并能周期性探测该服务的状态变化；当服务提供端出现故障或异常时，注册中心能即时发现并更新该服务在注册中心的服务状态；

步骤2-2：订阅服务；服务调用端从注册中心中订阅自己需要的服务，若注册中心已注册该服务，服务调用端直接从注册中心获取该服务的注册信息，同时将该服务的注册信息存入本地缓存中；

当服务调用端订阅服务的注册信息存入服务调用端的缓存中时，服务调用端和服务提供端建立长连接，服务调用端能周期性对服务提供端运行状态及健康状况的进行探测，一旦服务调用端检测到服务提供者的状态异常，即不能正常地提供服务，则更新该服务在服务调用端本地缓存中的服务状态，并将该状态更新情况通知给注册中心；

步骤2-3：调用服务；当服务调用端需要使用某项服务时，服务调用端能完全脱离注册中心，直接通过读取本地缓存中服务提供者所提供服务的注册信息，选择最佳的服务提供端，并通过远程过程调用协议调用远程服务的接口，进而一直使用服务；

步骤2-4：更新服务的状态；所述服务状态更新，按照服务状态条件，分为三种：服务提供端的服务新上线、服务提供端的服务下线、服务提供端的服务重新上线；每一次服务调用端的服务状态变化，相应地，注册中心和服务调用端的服务状态信息同时更新变化。

4.根据权利要求3所述的一种基于注册中心和缓存机制协同的服务发现方法，其特征在于，在所述的服务发现过程中，每一次服务调用端的服务状态变化，相应地，注册中心和服务调用端的服务状态信息同时更新变化，具体为：

步骤2-4-1：服务提供端的服务状态变更，服务提供端主动向注册中心发送服务状态变更的消息，注册中心根据消息内容识别服务，修改该服务存储在注册中心中的服务状态；

步骤2-4-2：注册中心寻找所有调用该服务的服务调用端，逐一向各服务调用端发送服务状态变更的消息；

特别地，服务提供端发送给注册中心的有关服务状态变更的通知消息和注册中心发送给服务调用端的有关服务状态变更的通知消息，内容包括但不限于：

(1)服务名称及服务类型；

(2)与该项服务相关的函数接口信息；

(3)服务地址信息，包含IP地址和端口；

(4)服务版本信息：服务更新前的状态、服务当前状态等；

步骤2-4-3：服务调用端接收到注册中心的消息，根据消息内容检查并校验本地缓存中该服务提供者的当前状态后，立即修改该服务的注册信息，更新该服务的服务状态。

5.根据权利要求4所述的一种基于注册中心和缓存机制协同的服务发现方法，其特征在于，当所述服务调用端的缓存中的服务状态更新完毕后，之后服务调用端针对该项服务的调用，完全能脱离对注册中心的依赖，均通过读取本地缓存中最新的服务信息，利用远程过程调用协议调用该远程服务的接口；整个通信期间的服务状态更新不再依赖注册中心，只通过本地缓存。