在微服务架构下，主要有三种角色：
- 服务提供者(RPC Server)
- 服务消费者(RPC Client)
- 服务注册中心(Registry)
RPC Server：服务提供者，启动时根据服务发布文件server.xml中的配置信息向Registry注册自身服务，并定期向Registry发送心跳汇报存活状态。
RPC Client：服务消费者，启动时根据服务引用文件client.xml中的配置信息向Registry订阅服务，并缓存Registry返回的服务节点列表到本地内存中。
RPC Server节点变更：Registry会同步变更，RPC Client感知到服务节点变更后会更新本地内存中缓存的服务节点列表。
RPC Client调用：RPC Client根据本地缓存的服务节点列表，基于负载均衡算法选择一台RPC Server发起调用。
注册中心实现思路：
- 注册中心需要提供哪些接口？
- 注册中心如何部署？
- 如何存储服务信息
- 如何监控服务节点的存活状态？
- 服务节点变更如何通知到消费者？
- 注册中心的访问权限控制？
1.注册中心API
基本API:
- 服务注册接口：服务提供者通过调用服务注册接口完成服务注册
- 服务反注册接口：服务提供者通过调用服务反注册接口完成服务注销
- 心跳汇报接口：服务提供者通过心跳汇报接口上报节点存活状态
- 服务订阅接口：服务消费者通过调用服务订阅接口完成服务订阅，获取到可用的服务提供者节点列表
- 服务变更查询接口：服务消费者通过调用服务变更查询接口，获取最新的服务节点列表
后台管理API:
- 服务查询接口：查询注册中心当前注册了哪些接口
- 服务修改接口：修改注册中心的某一服务的信息
2.集群部署
注册中心都是需要采用集群部署来保证注册中心的高可用性，并通过分布式一致性协议确保集群中节点之前的数据一致性。
以开源注册中心Zookeeper工作原理解释：
- 每个server内存中存储了一份数据，client可以请求任意server
- Zookeeper启动时将从实例中选取一个leader(Paxos协议)
- leader负责处理数据更新等操作(ZAB协议)
- 一个更新操作成功，当且仅当大多数server在内存中更新成功
3.目录存储
开源注册中心Zookeeper存储服务信息采用的是层次化的目录结构：
- 每个目录在Zookeeper中叫作znode，并且具有一个唯一的路径标识
- znode可以包含数据和子znode
- znode中的数据可以有多个版本，那么查询这个路径下的数据就需要带入版本信息
4.服务健康状态检测
开源注册中心Zookeeper的服务健康状态检测机制实现原理：通过客户端和服务端建立长链接以及会话的超时机制来实现服务健康状态检测。
主要步骤如下：
- 客户端与服务端建立长链接后，同时生成会话，并生成一个全局的唯一Session ID。
- 在客户端和服务端的长链接的SESSION_TIMEOUT周期内，客户端会定时向服务端发送心跳消息(ping消息)。
- 如果服务器接收到客户端心跳消息，会后重置下次SESSION_TIMEOUT时间。
- 如果服务器在这个SESSION_TIMEOUT时间内没有接收到客户端心跳消息，则服务端会认为这个session就已经结束，zookeeper就会认为这个服务节点不可用，将会从注册中心中删除该节点信息。
5.服务状态变更通知
一旦注册中心检测到有服务提供者节点新加入或者被剔除，就必须立刻通知所有订阅该服务的消费者，刷新本地缓存的服务节点信息，确保服务调用不会请求到不可用的节点。
开源注册中心Zookeeper的服务变更通知实现原理：是基于监听器Watcher机制，来实现服务状态变更通知给服务消费者。
主要步骤如下：
服务消费者在调用Zookeeper的getData方法订阅服务时，还可以通过监听器Watcher的process方法感知到服务的变更，再通过调用getData方法获取变更后的数据，重新刷新本地缓存的节点信息。
6.白名单机制
注册中心可以提供一个白名单机制，只有添加到注册中心白名单内的RPC Server，才能调用注册中心的注册接口，避免测试环境的节点注册到线上引起服务不可用。
这篇就总结到这里，如果喜欢我的文章，欢迎关注我的头条号，后续会有新的文章更新。
