7、Zookeeper场景案例分析

Zookeeper主要用于以下使用场景：

1. 实现配置管理（配置中心）
2. 服务注册中心
3. 集群通信与控制子系统

基本上每个使用Zookeeper的集群，都会同时采用Zookeeper存储集群的配置参数，可以说，实现配置管理是（配置中心）Zookeeper最广泛，最基础的使用场景。

服务注册中心是Zookeeper最“重量级”的需求场景，Zookeeper是这里的关键组件，同时最能体现其复杂能力，这个场景也是所有“以服务为中心”的分布式系统的核心设计之一。如下所示分别是来自WebService技术鼎盛时期由IBM等巨头主导的全球服务注册中心（UDDI）的原理架构图和某个互联网公司采用Zookeeper实现分布式服务注册与服务发现的原理架构图。

如上图所示，在此架构中有三类角色：服务提供者、服务注册中心和服务消费者。

首先，服务提供者作为服务的提供方，将自身的服务信息注册到服务注册中心，通常服务的注册信息包含如下内容。

1. 服务类型
2. 隶属于那个系统
3. 服务IP、端口
4. 服务请求的URL
5. 服务的权重

其次，服务注册中心主要提供所有服务注册信息的中心存储，同时负责将服务注册信息的更新通知实时的推送给服务消费者（主要通过Zookeeper的Wacth机制来实现）。

最后，服务消费者只在自己初始化及服务变更时会依赖服务注册中心，而在整个服务的调用过程中与服务的提供方直接通信，不依赖于任何第三方服务，包括注册中心。服务消费者的主要职责如下：

1. 服务消费者在启动时从服务注册中心获取需要的服务注册信息。
2. 将服务注册信息缓存在本地，作为服务路由的基础信息。
3. 监听服务注册信息的变更，例如接收到服务注册中心的服务变更通知时，则在本地缓存中更新服务的注册信息。
4. 根据本地缓存中的服务注册信息构建服务调用请求，并根据负载均衡策略（随机负载均衡，Round-Robin负载均衡）转发请求。
5. 对服务提供方的存活进行检测，如果发现服务不可用的服务提供方，则将其从本地缓存中删除。

比如TFS（天地方舟金融www.tfschange.com）E-Trade贸易平台的RPC原理架构，也采用了Zookeeper来实现服务的注册中心功能，其实现机制和主要逻辑基本上和上述案例大同小异。

Zookeeper的第3个重要业务场景是用来实现整个集群的通信与控制子系统，大多数系统都需要有命令行及web方式的管理命令，这些管理命令通常实现以下管理和控制功能。

1. 强制下线某个集群节点。
2. 修改配置参数并且生效。
3. 收集集群中各节点的状态数据并汇总展示。
4. 集群停止或暂停服务。

下面是用Zookeeper来设计实现的一个集群的控制子系统的原理架构图。

Zookeeper里规划了一个用于存放控制命令和应答的Znode路径（如上图的/Commands），集群中所有节点启动都监听（Watch）此路径，命令行程序（CLI）发给集群节点的命令及参数被包装成一个ZNode节点（ReloadConfig），写入Commands路径下，同时在ReloadConfig上Watch事件，紧接着集群中的所有节点都通过/Commands上的Watch事件收到此命令，然后开始执行ReloadConfig命令对应的逻辑，当某个节点执行完成后就在ReloadConfig路径下新建一个ZNode节点（如上图的node1result）作为应答。由于CLI之前在ReloadConfig上Watch，所以很快就会被通知此命令已经有节点执行完成，CLI就可以实时输出结果到屏幕上，当所有的节点应答都返回后（或者等待超时），命令行结束。

参考：架构揭秘从分布式到微服务