微服务的注册中心

原理

• 在微服务架构下，主要有三种角色：服务提供者（RPC Server）、服务消费者（RPC Client）和服务注册中心（Registry）

  • RPC Server 提供服务，在启动时，根据服务发布文件 server.xml 中的配置的信息，向 Registry 注册自身服务，并向 Registry 定期发送心跳汇报存活状态。

  • RPC Client 调用服务，在启动时，根据服务引用文件 client.xml 中配置的信息，向 Registry 订阅服务，把 Registry 返回的服务节点列表缓存在本地内存中，并与 RPC Sever 建立连接。

  • 当 RPC Server 节点发生变更时，Registry 会同步变更，RPC Client 感知后会刷新本地内存中缓存的服务节点列表。

  • RPC Client 从本地缓存的服务节点列表中，基于负载均衡算法选择一台 RPC Sever 发起调用。

注册中心需要提供的接口

• 服务注册接口：服务提供者通过调用服务注册接口来完成服务注册。

• 服务反注册接口：服务提供者通过调用服务反注册接口来完成服务注销。

• 心跳汇报接口：服务提供者通过调用心跳汇报接口完成节点存活状态上报。

• 服务订阅接口：服务消费者通过调用服务订阅接口完成服务订阅，获取可用的服务提供者节点列表。

• 服务变更查询接口：服务消费者通过调用服务变更查询接口，获取最新的可用服务节点列表。

• 服务查询接口：查询注册中心当前注册了哪些服务信息。

• 服务修改接口：修改注册中心中某一服务的信息。

集群部署

• 一般都是采用集群部署来保证高可用性，并通过分布式一致性协议来确保集群中不同节点之间的数据保持一致。

• 以开源注册中心 ZooKeeper 为例，ZooKeeper 集群中包含多个节点，服务提供者和服务消费者可以同任意一个节点通信，因为它们的数据一定是相同的，这是为什么呢？这就要从 ZooKeeper 的工作原理说起：

  • 每个 Server 在内存中存储了一份数据，Client 的读请求可以请求任意一个 Server。

  • ZooKeeper 启动时，将从实例中选举一个 leader（Paxos 协议）。

  • Leader 负责处理数据更新等操作（ZAB 协议）。

  • 一个更新操作成功，当且仅当大多数 Server 在内存中成功修改 。