这是我参与8月更文挑战的第16天，活动详情查看：8月更文挑战
RPC的目的，是将远程调用变得像本地调用一样简单方便，主要由客户端、服务端、注册中心三部分组成。
那么，服务端发布的接口怎么向客户端暴露？客户端怎么获取到服务端的地址并创建连接执行调用逻辑呢？
本篇将带大家 通过分析一个由Zookeeper引发的全链路服务雪崩的真实案例，来说明注册中心的生产场景诉求和选型原则。
0.1 注册中心
如图所示
Provider 主要向注册中心进行服务注册，以及上报服务节点心跳。
Consumer 需要向注册中心订阅感兴趣的服务，将对应服务的节点信息缓存到本地，同时接受注册中心下发的服务变动通知。
注册中心 的职权也很明确了，就是维护服务信息以及服务实例节点信息，同时监测服务节点心跳，确认节点状态，在节点状态不健康时，从实例列表中剔除；同时在节点列表变动时，负责通知订阅者，以实现服务的及时更新和数据一致性
0.2 Zookeeper 注册中心实现方案
ZK曾经真的非常火，当然现在也不差。很多年之前，同事曾经笑称，只要架构里用上ZK，就可以叫分布式。
ZK是经常被提及的注册中心选型。那么ZK怎么实现注册中心呢？
节点创建的能力
持久化节点。在节点创建后，就一直存在，直到有删除操作来主动清除这个节点。
临时节点。将自身的生命周期和客户端状态绑定。如果客户端会话失效，那么这个节点就会自动被清除掉。注意，这里提到的是会话失效，而非连接断开。
监听通知的能力
也就是Watch机制。一个zk的节点可以被监控，包括这个目录中存储的数据的修改，子节点目录的变化，一旦变化可以通知设置监控的客户端。
这个功能是zookeeper对于应用最重要的特性，通过这个特性可以实现的功能包括配置的集中管理，集群管理，分布式锁等等。
ZK的上述两个关键能力，让其成为注册中心成为可能。
Zookeeper注册中心
如上图所示，ZK创建了Service的持久化节点，在Service下创建了Provider和Consumer两个子节点，也是持久化的；在Provider和Consumer下挂着很多临时节点，每一个临时节点，代表一个应用实例。这样方便根据实例状态进行动态增减。然后用wtach机制来监听服务端心跳，通知客户端服务节点的变动，从而实现注册中心的整个能力。
