通过前面两章，一个点对点（Point to Point）版本的 RPC 框架就完成了。我一般称这种模式的 RPC 框架为单机版本，因为它没有集群能力。所谓集群能力，就是针对同一个接口有着多个服务提供者，但这多个服务提供者对于我们的调用方来说是透明的，所以在 RPC 里面我们还需要给调用方找到所有的服务提供方，并需要在 RPC 里面维护好接口跟服务提供者地址的关系，这样调用方在发起请求的时候才能快速地找到对应的接收地址，这就是我们常说的“服务发现”。
另外对于PRC，还需要服务治理的功能，比如服务提供方权重的设置、调用授权等一些常规治理手段。而服务调用方需要额外做哪些事情呢？每次调用前，我们都需要根据服务提供方设置的规则，从集群中选择可用的连接用于发送请求。
那到这儿，一个比较完善的 RPC 框架基本就完成了，功能也差不多就是这些了。按照分层设计的原则，我将这些功能模块分为了四层，具体内容见图示：
服务发现
在集群中，集群里面的这些节点随时可能变化，提供服务的节点增加或者减少，需要通知给调用方。这个过程叫做“服务发现”。
我们可以通过一个叫“注册中心”的模块，服务方注册到注册中心，调用方订阅服务接口，来实现监听服务的变更，并通知给客户端。这就是我要说的 PRC 框架的服务发现机制，如下图所示：
- 服务注册：在服务提供方启动的时候，将对外暴露的接口注册到注册中心之中，注册中心将这个服务节点的 IP 和接口保存下来。
- 服务订阅：在服务调用方启动的时候，去注册中心查找并订阅服务提供方的 IP，然后缓存到本地，并用于后续的远程调用。
基于 ZooKeeper 的服务发现
整体的思路很简单，就是搭建一个 ZooKeeper 集群作为注册中心集群，服务注册的时候只需要服务节点向 ZooKeeper 节点写入注册信息即可，利用 ZooKeeper 的 Watcher 机制完成服务订阅与服务下发功能，整体流程如下图：
- 服务平台管理端先在 ZooKeeper 中创建一个服务根路径，可以根据接口名命名（例如：/service/com.demo.xxService），在这个路径再创建服务提供方目录与服务调用方目录（例如：provider、consumer），分别用来存储服务提供方的节点信息和服务调用方的节点信息。
- 当服务提供方发起注册时，会在服务提供方目录中创建一个临时节点，节点中存储该服务提供方的注册信息。
- 当服务调用方发起订阅时，则在服务调用方目录中创建一个临时节点，节点中存储该服务调用方的信息，同时服务调用方 watch 该服务的服务提供方目录（/service/com.demo.xxService/provider）中所有的服务节点数据。
- 当服务提供方目录下有节点数据发生变更时，ZooKeeper 就会通知给发起订阅的服务调用方。
但随着微服务越来越多，当连接到 ZooKeeper 的节点数量特别多，对 ZooKeeper 读写特别频繁，且 ZooKeeper 存储的目录达到一定数量的时候，ZooKeeper 将不再稳定，CPU 持续升高，最终宕机。而宕机之后，由于各业务的节点还在持续发送读写请求，刚一启动，ZooKeeper 就因无法承受瞬间的读写压力，马上宕机。
基于消息队列的注册中心
Zookeeper保证了集群的强一致性，这也就直接导致了 ZooKeeper 集群性能上的下降。而RPC节点变更和通知并不需要那么强的一致性，所以可以基于最终一致性，来换取整个注册中心集群的性能和稳定性。
因为要求最终一致性，我们可以考虑采用消息总线机制。注册数据可以全量缓存在每个注册中心内存中，通过消息总线来同步数据。当有一个注册中心节点接收到服务节点注册时，会产生一个消息推送给消息总线，再通过消息总线通知给其它注册中心节点更新数据并进行服务下发，从而达到注册中心间数据最终一致性，具体流程如下图所示：
- 当有服务上线，注册中心节点收到注册请求，服务列表数据发生变化，会生成一个消息，推送给消息总线，每个消息都有整体递增的版本。
- 消息总线会主动推送消息到各个注册中心，同时注册中心也会定时拉取消息。对于获取到消息的在消息回放模块里面回放，只接受大于本地版本号的消息，小于本地版本号的消息直接丢弃，从而实现最终一致性。
- 消费者订阅可以从注册中心内存拿到指定接口的全部服务实例，并缓存到消费者的内存里面。
- 采用推拉模式，消费者可以及时地拿到服务实例增量变化情况，并和内存中的缓存数据进行合并。
为了性能，这里采用了两级缓存，注册中心和消费者的内存缓存，通过异步推拉模式来确保最终一致性。
健康检查
服务发现能够对机器的增加减少进行处理，但如果某个服务提供者突然发生了宕机，注册中心和调用方如何能够知道，从而不进行调用呢，这时候就需要进行健康检查。
通常方法是使用心跳机制，心跳机制说起来也不复杂，其实就是服务调用方每隔一段时间就问一下服务提供方目前的状态。
定义服务方三个状态就是：
- 健康状态：建立连接成功，并且心跳探活也一直成功；
- 亚健康状态：建立连接成功，但是心跳请求连续失败；
- 死亡状态：建立连接失败。
节点的状态并不是固定不变的，它会根据心跳或者重连的结果来动态变化，具体状态间转换图如下：
这里你可以关注下几个状态之间的转换剪头，我再给你解释下。首先，一开始初始化的时候，如果建立连接成功，那就是健康状态，否则就是死亡状态。这里没有亚健康这样的中间态。紧接着，如果健康状态的节点连续出现几次不能响应心跳请求的情况，那就会被标记为亚健康状态，也就是说，服务调用方会觉得它生病了。
负载均衡和路由策略
负载均衡
RPC 的负载均衡完全由 RPC 框架自身实现，RPC 的服务调用者会与“注册中心”下发的所有服务节点建立长连接，在每次发起 RPC 调用时，服务调用者都会通过配置的负载均衡插件，自主选择一个服务节点，发起 RPC 调用请求。
RPC 负载均衡策略一般包括随机权重、Hash、轮询。当然，这还是主要看 RPC 框架自身的实现。其中的随机权重策略应该是我们最常用的一种了，通过随机算法，我们基本可以保证每个节点接收到的请求流量是均匀的；同时我们还可以通过控制节点权重的方式，来进行流量控制。比如我们默认每个节点的权重都是 100，但当我们把其中的一个节点的权重设置成 50 时，它接收到的流量就是其他节点的 1/2。
路由策略
负载均衡是为了能够将流量比较均衡的打在各个服务节点上，起到多节点分担流量压力的作用。但有些场景，我们可能需要某些流量打到具体的节点上，这时候就需要使用路由策略。
其中比较场景的路由策略有IP路由和参数路由，前者根据IP对流量进行分流，后者根据调用中某个参数进行分流，例如按照城市id分流。
RPC框架往往也支持自定义路由策略，使用者通过实现抽象路由接口来自定义自己的路由策略。