注册中心原理
RPC Server 提供服务，在启动时，根据服务发布文件 server.xml 中的配置的信息，向 Registry 注册自身服务，并向 Registry 定期发送心跳汇报存活状态。
RPC Client 调用服务，在启动时，根据服务引用文件 client.xml 中配置的信息，向 Registry 订阅服务，把 Registry 返回的服务节点列表缓存在本地内存中，并与 RPC Sever 建立连接。<br>
当 RPC Server 节点发生变更时，Registry 会同步变更，RPC Client 感知后会刷新本地内存中缓存的服务节点列表。
RPC Client 从本地缓存的服务节点列表中，基于负载均衡算法选择一台 RPC Sever 发起调用。
集群部署
以Zookeeper为例
工作原理<br>
每个 Server 在内存中存储了一份数据，Client 的读请求可以请求任意一个 Server。
ZooKeeper 启动时，将从实例中选举一个 leader（Paxos 协议）。<br>
Leader 负责处理数据更新等操作（ZAB 协议）。
一个更新操作成功，当且仅当大多数 Server 在内存中成功修改 。
高可用性-集群部署
为了实现异地多活，有的注册中心还采用多 IDC 部署<br>
高一致性-分布式一致性协议<br>
目录存储
以Zookeeper为例
每个目录在 ZooKeeper 中叫作 znode，并且其有一个唯一的路径标识。<br>
znode 可以包含数据和子 znode。<br>
znode 中的数据可以有多个版本，比如某一个 znode 下存有多个数据版本，那么查询这个路径下的数据需带上版本信息。<br>
服务健康状态检测
以Zookeeper为例
基于客户端和服务端的长连接和会话超时控制机制实现<br>
在 ZooKeeper 中，客户端和服务端建立连接后，会话也随之建立，并生成一个全局唯一的 Session ID。服务端和客户端维持的是一个长连接，在 SESSION_TIMEOUT 周期内，服务端会检测与客户端的链路是否正常，具体方式是通过客户端定时向服务端发送心跳消息（ping 消息），服务器重置下次 SESSION_TIMEOUT 时间。如果超过 SESSION_TIMEOUT 后服务端都没有收到客户端的心跳消息，则服务端认为这个 Session 就已经结束了，ZooKeeper 就会认为这个服务节点已经不可用，将会从注册中心中删除其信息。<br>
服务状态变更通知
以Zookeeper为例<br>
Watcher 机制<br>
服务消费者在调用 ZooKeeper 的 getData 方法订阅服务时，还可以通过监听器 Watcher 的 process 方法获取服务的变更，然后调用 getData 方法来获取变更后的数据，刷新本地缓存的服务节点信息。<br>
白名单机制
在实际应用中，注册中心可以提供一个白名单机制，只有添加到注册中心白名单内的 RPC Server，才能够调用注册中心的注册接口，这样的话可以避免测试环境中的节点意外跑到线上环境中去。
