分布式消息系统和分布式消息系统的服务状态检测方法

摘要

本发明提供了一种分布式消息系统，包括：服务端、客户端和Zookeeper集群，其中，服务端包括：服务器通讯单元，用于将服务进程的启动信息发送至Zookeeper集群；Zookeeper集群包括：节点管理单元，用于在已创建的根节点上，为启动的服务进程建立相应的子节点，该子节点为临时节点；客户端包括：客户端通讯单元，用于从Zookeeper集群获取子节点的建立情况；判断单元，用于根据子节点的建立情况，判断服务端当前可用的服务。相应地，本发明还提出了一种分布式消息系统的服务状态检测方法。通过本发明的技术方案，建立基于Zookeeper的高可用通讯平台，可以降低服务端在心跳检测上的资源消耗，从根本上解决了服务增多给管理上带来的巨大开销。

说明书

技术领域

本发明涉及通讯技术领域，具体而言，涉及一种分布式消息系统和一 种分布式消息系统的服务状态检测方法。

背景技术

编写分布式计算应用时，往往会出现“部分失败”（partial  failure），即当一条消息在网络中两个节点之间传输时，如果出现网络错 误，发送者无法知道接收者是否已经收到这条消息。接收者可能在出现网 络错误之前就已经收到消息，也有可能没有收到，又或者接收进程已经死 掉。发送者能够获得真实情况的唯一途径就是重新连接接收者，并向它发 出询问。这就是部分失败：即我们甚至不知道一个操作是否已经失败。

现在流行的解决方案主要是心跳检测，即服务的提供方和消费方保持 一定的连接，定时发送心跳包来判断对方是否在线，如果在一定时间内收 不到心跳包，则判断对方已经不在线，也就不再请求对方的服务了，如果 对方上线了，则心跳检测恢复，便可以继续向对方请求服务了。现在心跳 检测主要是服务端消费方发起的，服务提供方只是被动相应。这样做的弊 端是如果服务的消费方增多，那么服务的提供方在心跳检测上的开销是很 大的，严重的会影响系统的正常运行。

因此，需要一种新的服务状态检测技术，可以降低服务端在心跳检测 上的资源消耗，从根本上解决了服务增多给管理上带来的巨大开销。

发明内容

本发明正是基于上述问题，提出了一种新的服务状态检测技术，可以 降低服务端在心跳检测上的资源消耗，从根本上解决了服务增多给管理上 带来的巨大开销。

有鉴于此，本发明提出了一种分布式消息系统，包括：服务端、客户 端和Zookeeper集群，其中，所述服务端包括：服务器通讯单元，用于将 服务进程的启动信息发送至所述Zookeeper集群；所述Zookeeper集群包 括：节点管理单元，用于在已创建的根节点上，为启动的所述服务进程建 立相应的子节点，所述子节点为临时节点；所述客户端包括：客户端通讯 单元，用于从所述Zookeeper集群获取所述子节点的建立情况；判断单 元，用于根据所述子节点的建立情况，判断所述服务端当前可用的服务。

在该技术方案中，Zookeeper是指由Apache软件基金会（即Apache  Software Foundation，简称ASF）开发的一个分布式的服务框架。通过由 Zookeeper集群将服务端的服务状态告知客户端，无需在客户端与服务端 之间进行心跳检测，从而为服务端节省了相关资源消耗，尤其对于具有大 量客户端的情况下，显然极大地简化了服务端的构建和管理。需要说明的 是，这里的服务端和客户端并不特指服务器和终端，比如现有的运营商服 务器和用户使用的移动终端，当需要由运营商服务器提供服务时，运营商 服务器作为服务端，当需要由移动终端提供服务时（例如由运营商服务器 向移动终端推送消息），则移动终端作为服务端。

在上述技术方案中，优选地，所述Zookeeper集群还包括：进程状态 检测单元，用于检测所述服务进程是否发生中断；所述节点管理单元还用 于：当所述服务进程中断时，删除对应于所述服务进程的子节点；所述判 断单元还用于：根据所述子节点的建立情况和/或删除情况，判断所述服 务端当前可用的服务。

在该技术方案中，服务端的服务状态发生实时变化时，通过 Zookeeper集群的管理，使得客户端能够实时掌握该状态的实时变化。

在上述技术方案中，优选地，每个所述服务进程配置有服务端通讯组 件，则所述进程状态检测单元用于：通过与所述服务端通讯组件维持心跳 检测，以判断所述服务进程是否发生中断。

在该技术方案中，通过采用集中式的心跳管理，从而在根本上解决了 服务增多给管理上带来的巨大开销。

在上述技术方案中，优选地，所述服务器通讯单元发送至所述 Zookeeper集群的所述启动信息包括所述服务进程的IP地址和端口号，以 用于所述客户端与所述服务端建立连接。

在该技术方案中，通过将IP地址、端口号等信息告知客户端，便于 客户端在服务可用时进行连接。

在上述技术方案中，优选地，所述客户端还包括：列表建立单元，根 据所述判断单元判断得到的所述服务端当前可用的服务，建立相应的可服 务列表。

在该技术方案中，通过客户端将当前可用的服务记录在可服务列表 中，便于对可用服务进程查询以及建立相应的连接。

根据本发明的又一方面，还提出了一种分布式消息系统的服务状态检 测方法，包括：步骤202，服务端将服务进程的启动信息发送至 Zookeeper集群；步骤204，所述Zookeeper集群在已创建的根节点上，为 启动的所述服务进程建立相应的子节点，所述子节点为临时节点；步骤 206，客户端根据从所述Zookeeper集群获取的所述子节点的建立情况， 判断所述服务端当前可用的服务。

在该技术方案中，通过由Zookeeper集群将服务端的服务状态告知客 户端，无需在客户端与服务端之间进行心跳检测，从而为服务端节省了相 关资源消耗，尤其对于具有大量客户端的情况下，显然极大地简化了服务 端的构建和管理。需要说明的是，这里的服务端和客户端并不特指服务器 和终端，比如现有的运营商服务器和用户使用的移动终端，当需要由运营 商服务器提供服务时，运营商服务器作为服务端，当需要由移动终端提供 服务时（例如由运营商服务器向移动终端推送消息），则移动终端作为服 务端。

在上述技术方案中，优选地，所述步骤204还包括：当所述服务进程 中断时，所述Zookeeper集群删除对应于所述服务进程的子节点；以及所 述步骤206还包括：所述客户端根据所述子节点的建立情况和/或删除情 况，判断所述服务端当前可用的服务。

在该技术方案中，服务端的服务状态发生实时变化时，通过 Zookeeper集群的管理，使得客户端能够实时掌握该状态的实时变化。

在上述技术方案中，优选地，每个所述服务进程配置有服务端通讯组 件；所述Zookeeper集群与所述服务端通讯组件维持心跳检测，以判断所 述服务进程是否发生中断。

在该技术方案中，通过采用集中式的心跳管理，从而在根本上解决了 服务增多给管理上带来的巨大开销。

在上述技术方案中，优选地，所述启动信息包括所述服务进程的IP 地址和端口号，以用于所述客户端与所述服务端建立连接。

在该技术方案中，通过将IP地址、端口号等信息告知客户端，便于 客户端在服务可用时进行连接。

在上述技术方案中，优选地，所述步骤206还包括：所述客户端根据 判断得到的所述服务端当前可用的服务，建立相应的可服务列表。

在该技术方案中，通过客户端将当前可用的服务记录在可服务列表 中，便于对可用服务进程查询以及建立相应的连接。

通过以上技术方案，可以降低服务端在心跳检测上的资源消耗，从根 本上解决了服务增多给管理上带来的巨大开销。

附图说明

图1示出了根据本发明的实施例的分布式消息系统的框图；

图2示出了根据本发明的实施例的分布式消息系统的服务状态检测方 法的流程图；

图3示出了根据本发明的实施例的分布式消息系统的整体架构图；

图4A和图4B示出了根据本发明的实施例的服务端的通讯示意图；

图5A和图5B示出了根据本发明的实施例的客户端的通讯示意图。

具体实施方式

为了能够更清楚地理解本发明的上述目的、特征和优点，下面结合附 图和具体实施方式对本发明进行进一步的详细描述。需要说明的是，在不 冲突的情况下，本申请的实施例及实施例中的特征可以相互组合。

在下面的描述中阐述了很多具体细节以便于充分理解本发明，但是， 本发明还可以采用其他不同于在此描述的其他方式来实施，因此，本发明 的保护范围并不受下面公开的具体实施例的限制。

图1示出了根据本发明的实施例的分布式消息系统的框图。

如图1所示，根据本发明的实施例的分布式消息系统，包括：服务端 102、客户端106和Zookeeper集群104，其中，服务端102包括：服务器 通讯单元1020，用于将服务进程的启动信息发送至Zookeeper集群104； Zookeeper集群104包括：节点管理单元1040，用于在已创建的根节点 上，为启动的服务进程建立相应的子节点，该子节点为临时节点；客户端 106包括：客户端通讯单元1060，用于从Zookeeper集群104获取子节点 的建立情况；判断单元1062，用于根据子节点的建立情况，判断服务端 102当前可用的服务。

在该技术方案中，Zookeeper是指由Apache软件基金会（即Apache  Software Foundation，简称ASF）开发的一个分布式的服务框架。通过由 Zookeeper集群104将服务端102的服务状态告知客户端106，无需在客 户端106与服务端102之间进行心跳检测，从而为服务端102节省了相关 资源消耗，尤其对于具有大量客户端106的情况下，显然极大地简化了服 务端102的构建和管理。需要说明的是，这里的服务端102和客户端106 并不特指服务器和终端，比如现有的运营商服务器和用户使用的移动终 端，当需要由运营商服务器提供服务时，运营商服务器作为服务端102， 当需要由移动终端提供服务时（例如由运营商服务器向移动终端推送消 息），则移动终端作为服务端102。

在上述技术方案中，Zookeeper集群104还包括：进程状态检测单元 1042，用于检测服务进程是否发生中断；节点管理单元1040还用于：当 服务进程中断时，删除对应于服务进程的子节点；判断单元1062还用 于：根据子节点的建立情况和/或删除情况，判断服务端102当前可用的 服务。

在该技术方案中，服务端102的服务状态发生实时变化时，通过 Zookeeper集群104的管理，使得客户端106能够实时掌握该状态的实时 变化。

在上述技术方案中，每个服务进程配置有服务端通讯组件，则进程状 态检测单元1042用于：通过与服务端通讯组件维持心跳检测，以判断服 务进程是否发生中断。

在该技术方案中，通过采用集中式的心跳管理，从而在根本上解决了 服务增多给管理上带来的巨大开销。

在上述技术方案中，服务器通讯单元1020发送至Zookeeper集群104 的启动信息包括服务进程的IP地址和端口号，以用于客户端106与服务 端102建立连接。

在该技术方案中，通过将IP地址、端口号等信息告知客户端106，便 于客户端106在服务可用时进行连接。

在上述技术方案中，客户端106还包括：列表建立单元1064，根据 判断单元1062判断得到的服务端102当前可用的服务，建立相应的可服 务列表。

在该技术方案中，通过客户端106将当前可用的服务记录在可服务列 表中，便于对可用服务进程查询以及建立相应的连接。

图2示出了根据本发明的实施例的分布式消息系统的服务状态检测方 法的流程图。

如图2所示，根据本发明的实施例的分布式消息系统的服务状态检测 方法，包括：步骤202，服务端将服务进程的启动信息发送至Zookeeper 集群；步骤204，Zookeeper集群在已创建的根节点上，为启动的服务进 程建立相应的子节点，该子节点为临时节点；步骤206，客户端根据从 Zookeeper集群获取的子节点的建立情况，判断服务端当前可用的服务。

在该技术方案中，通过由Zookeeper集群将服务端的服务状态告知客 户端，无需在客户端与服务端之间进行心跳检测，从而为服务端节省了相 关资源消耗，尤其对于具有大量客户端的情况下，显然极大地简化了服务 端的构建和管理。需要说明的是，这里的服务端和客户端并不特指服务器 和终端，比如现有的运营商服务器和用户使用的移动终端，当需要由运营 商服务器提供服务时，运营商服务器作为服务端，当需要由移动终端提供 服务时（例如由运营商服务器向移动终端推送消息），则移动终端作为服 务端。

在上述技术方案中，步骤204还包括：当服务进程中断时， Zookeeper集群删除对应于服务进程的子节点；以及步骤206还包括：客 户端根据子节点的建立情况和/或删除情况，判断服务端当前可用的服 务。

在该技术方案中，服务端的服务状态发生实时变化时，通过 Zookeeper集群的管理，使得客户端能够实时掌握该状态的实时变化。

在上述技术方案中，每个服务进程配置有服务端通讯组件； Zookeeper集群与服务端通讯组件维持心跳检测，以判断服务进程是否发 生中断。

在该技术方案中，通过采用集中式的心跳管理，从而在根本上解决了 服务增多给管理上带来的巨大开销。

在上述技术方案中，启动信息包括服务进程的IP地址和端口号，以 用于客户端与服务端建立连接。

在该技术方案中，通过将IP地址、端口号等信息告知客户端，便于 客户端在服务可用时进行连接。

在上述技术方案中，步骤206还包括：客户端根据判断得到的服务端 当前可用的服务，建立相应的可服务列表。

在该技术方案中，通过客户端将当前可用的服务记录在可服务列表 中，便于对可用服务进程查询以及建立相应的连接。

图3示出了根据本发明的实施例的分布式消息系统的整体架构图。

Zookeeper对节点（即znode）进行维护，其中，节点分为临时节点和 持久节点，且节点的类型在创建时确定并且之后不能再修改。这两种节点 的区别在于：在创建临时znode的客户端会话结束时，zookeeper会将该 临时znode删除；相比之下，持久znode不依赖于客户端会话，只有当客 户端明确要删除该持久znode时，持久znode才会被删除；并且短暂 znode不可以有子节点。

如图3所示，可以在Zookeeper集群已创建的根节点上，为每个计算 节点创建对应的子节点，如子节点1、子节点2、子节点3……具体地， 这些子节点中的值（即value）可以为相应计算节点的IP地址。

同时，这些子节点都是临时节点(EPHEMERAL)，一旦连接断开，该 临时节点自动会被Zookeeper删除。由于所有的计算节点处于同一个计算 单元中，而每个处于该计算单元中的计算节点，若仍存在，则必然存在相 应的子节点，则关注这个根节点的机器都可以通过子节点的情况来判断现 在哪台机器离开计算单元了，并且获知现在有多少个计算节点在这个计算 单元中。

同时，如果有新的计算节点添加，在相应的服务进程启动后的第一步 将会到zookeeper集群上的根节点上创建一个子节点，则关注这个根节点 的机器都会知道现在多了一个计算节点。

另外，从图中可见，服务端（包括服务集群的形式）的每台服务进程 都嵌入了服务端通讯组件，应用端嵌入了客户端通讯组件，关于这两个组 件的组成和工作过程，下面结合图4A和图4B以及图5A和图5B进行详 细说明。

图4A和图4B示出了根据本发明的实施例的服务端的通讯示意图。

如图4A所示，该服务端通讯组件包括rpc skeleton模块、配置上报模 块和Zookeeper客户端，与zookeeper集群的配合过程如图4B所示：

1、服务端中的服务启动上线。

2、负责与客户端进行rpc通讯的rpc skeleton模块也同时启动。

3、将启动信息（包括服务端的IP地址和端口号）通过配置上报模块 上报给zookeeper集群。

4、Zookeeper客户端向Zookeeper集群上报启动信息。

5、Zookeeper集群为该启动的服务生成一个临时节点，同时更新存在 的节点信息。服务端通讯组件和zookeeper集群维持心跳检测，一旦服务 进程退出，这个临时节点就会被删除。

至此服务启动完毕，zookeeper集群维护了所有服务端的配置。

图5A和图5B示出了根据本发明的实施例的客户端的通讯示意图。

如图5A所示，该客户端通讯组件包括rpc stub模块、可用服务器列 表和Zookeeper客户端，与zookeeper集群的配合过程如图5B所示：

1、zookeeper集群获取服务端变更信息后上报给客户端通讯组件中的 Zookeeper客户端。

2、客户端根据该服务端变更信息，更新服务可用列表。

3、客户端从服务端变更信息中获取可用服务端的信息，包括上述启 动信息中的IP地址和端口号等，然后建立连接，准备跟服务端进行通 讯。

4、客户端通过rpc stub模块跟服务端（具体为如图4A所示的rpc  skeleton模块）进行通讯，完成rpc远程调用。

这里的rpc远程调用可以为任意形式，比如Google的 protocolbuffer，apache的Thrift或者hessian等比较流行的开源的rpc调用 框架都可以。

以上结合附图详细说明了本发明的技术方案，考虑到相关技术中，服 务的提供方在心跳检测上的开销是很大的，严重的会影响系统的正常运 行，本发明提供了一种分布式消息系统和一种分布式消息系统的服务状态 检测方法，可以降低服务端在心跳检测上的资源消耗，从根本上解决了服 务增多给管理上带来的巨大开销。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于 本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精 神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明 的保护范围之内。