微服务中 Zookeeper 的应用及原理
- 一、背景
- 二、Zookeeper 的特性
- 1. 树状目录结构
- 2. 持久节点 (Persistent)
- 3. 持久有序节点 (Persistent_sequential)
- 4. 临时节点 (Ephemeral)
- 5. 临时有序节点 (Ephemeral_sequential)
- 6. 节点监听 (Wacher)
- 三、微服务中应用场景
- 1. 分布式锁
- 2. 服务注册与发现
- 2.1 背景
- 2.2 服务注册原理
- 2.3 服务动态发现原理
一、背景
了解微服务的小伙伴都应该知道 Zookeeper，ZooKeeper 是一个分布式的, 开源的分布式应用程序协调服务。现在比较流行的微服务框架 Dubbo、Spring Cloud 都可以使用 Zookeeper 作为服务发现与组册中心。但是，为什么 Zookeeper 就能实现服务发现与组册呢？
二、Zookeeper 的特性
我们先来了解一下 Zookeeper 的特性吧，因为它的特性决定了它的使用场景。
1. 树状目录结构
如上图，Zookeeper 是一个树状的文件目录结构，有点想应用系统中的文件系统的概念。每个子目录（如 App）被称为 znode，我们可以对每个 znode 进行增删改查。
2. 持久节点 (Persistent)
客户端与 zookeeper 服务端断开连接后，该节点仍然存在。
3. 持久有序节点 (Persistent_sequential)
在持久节点基础上，由 zookeeper 给该节点名称进行有序编号，如 0000001，0000002。
4. 临时节点 (Ephemeral)
客户端与 zookeeper 服务端断开连接后，该节点被删除。临时节点下，不存在子节点。
5. 临时有序节点 (Ephemeral_sequential)
在临时节点基础上，由 zookeeper 给该节点名称进行有序编号，如 0000001，0000002。
6. 节点监听 (Wacher)
客户端 2 注册监听它关心的临时节点 SubApp1 的变化，当临时节点 SubApp1 发生变化时（如图中被删除的时候），zookeeper 会通知客户端 2。
该机制是 zookeeper 实现分布式协调的重要特性。我们可以通过 get，exists，getchildren 三种方式对某个节点进行监听。但是该事件只会通知一次。
三、微服务中应用场景
1. 分布式锁
分布式锁主要解决不同进程中的资源同步问题。大家可以联想一下单进程中的多线程共享资源的情况，线程需要访问共享资源，首先要获得锁，操作完共享资源后便释放锁。分布式中，上述的锁就变成了分布式锁了。那这个分布式锁又是如何实现呢？
步骤 1: 如图，根据 zookeeper 有序临时节点的特性，每个进程对应连接一个有序临时节点（进程 1 对应节点 / znode/00000001，进程 2 对应节点 / znode/00000002… 如此类推）。每个进程监听对应的上一个节点的变化。编号最小的节点对应的进程获得锁，可以操作资源。
步骤 2: 当进程 1 完成业务后，删除对应的子节点 / znode/00000001，释放锁。此时，编号最小的锁便获得锁（即 / znode/00000002 对应进程）。
重复以上步骤，保证了多个进程获取的是同一个锁，且只有一个进程能获得锁，就是 zookeeper 分布式锁的实现原理。
2. 服务注册与发现
2.1 背景
在微服务中，服务提供方把服务注册到 zookeeper 中心去如图中的 Member 服务，但是每个应用可能拆分成多个服务对应不同的 Ip 地址，zookeeper 注册中心可以动态感知到服务节点的变化。
服务消费方（Order 服务）需要调用提供方（Member 服务）提供的服务时，从 zookeeper 中获取提供方的调用地址列表，然后进行调用。这个过程称为服务的订阅。
2.2 服务注册原理
rpc 框架会在 zookeeper 的注册目录下，为每个应用创建一个持久节点，如 order 应用创建 order 持久节点，member 应用创建 member 持久节点。
然后在对应的持久节点下，为每个微服务创建一个临时节点，记录每个服务的 URL 等信息。
2.3 服务动态发现原理
由于服务消费方向 zookeeper 订阅了（监听）服务提供方，一旦服务提供方有变动的时候（增加服务或者减少服务），zookeeper 就会把最新的服务提供方列表（member list）推送给服务消费方，这就是服务动态发现的原理。
（完）
