RPC 开发系列三：服务发现

最新推荐文章于 2024-07-14 17:32:11 发布

octopusHu

最新推荐文章于 2024-07-14 17:32:11 发布

阅读量1k

点赞数

分类专栏： RPC 原理文章标签： rpc 微服务

本文链接：https://blog.csdn.net/hfut_zhanghu/article/details/118683250

版权

RPC 原理专栏收录该内容

11 篇文章 21 订阅

订阅专栏

一、PRC 框架的服务发现机制。

1.1 服务注册

在服务提供方启动的时候，将对外暴露的接口注册到注册中心之中，注册中心将这个服务节点的 IP 和接口保存下来。

1.2 服务订阅

在服务调用方启动的时候，去注册中心查找并订阅服务提供方的 IP，然后缓存到本地，并用于后续的远程调用。

二、为什么不使用 DNS？

既然服务发现这么“厉害”，那是不是很难实现啊？其实类似机制一直在我们身边，我们回想下服务发现的本质，就是完成了接口跟服务提供者 IP 的映射。那我们能不能把服务提供者 IP 统一换成一个域名啊，利用已经成熟的 DNS 机制来实现？

简单地看下 DNS 的流程：

如果我们用 DNS 来实现服务发现，所有的服务提供者节点都配置在了同一个域名下，调用方的确可以通过 DNS 拿到随机的一个服务提供者的 IP，并与之建立长连接，这看上去并没有太大问题，但在我们业界为什么很少用到这种方案呢？不知道你想过这个问题没有，如果没有，现在可以停下来想想这样两个问题：

如果这个 IP 端口下线了，服务调用者能否及时摘除服务节点呢？
如果在之前已经上线了一部分服务节点，这时我突然对这个服务进行扩容，那么新上线的服务节点能否及时接收到流量呢？

这两个问题的答案都是：“不能”。这是因为为了提升性能和减少 DNS 服务的压力，DNS 采取了多级缓存机制，一般配置的缓存时间较长，特别是 JVM 的默认缓存是永久有效的，所以说服务调用者不能及时感知到服务节点的变化。

是不是可以加一个负载均衡设备呢？将域名绑定到这台负载均衡设备上，通过 DNS 拿到负载均衡的 IP。这样服务调用的时候，服务调用方就可以直接跟 VIP 建立连接，然后由 VIP 机器完成 TCP 转发，如下图所示：

这个方案确实能解决 DNS 遇到的一些问题，但在 RPC 场景里面也并不是很合适，原因有以下几点：

搭建负载均衡设备或 TCP/IP 四层代理，需求额外成本；
请求流量都经过负载均衡设备，多经过一次网络传输，会额外浪费些性能；
负载均衡添加节点和摘除节点，一般都要手动添加，当大批量扩容和下线时，会有大量的人工操作和生效延迟；
我们在服务治理的时候，需要更灵活的负载均衡策略，目前的负载均衡设备的算法还满足不了灵活的需求。

由此可见，DNS 方案虽然可以充当服务发现的角色，但在 RPC 场景里面直接用还是很难的。

三、基于 ZooKeeper 的服务发现

3.1 整体的思路

搭建一个 ZooKeeper 集群作为注册中心集群，服务注册的时候只需要服务节点向 ZooKeeper 节点写入注册信息即可，利用 ZooKeeper 的 Watcher 机制完成服务订阅与服务下发功能，整体流程如下图：

3.2 过程

服务平台管理端先在 ZooKeeper 中创建一个服务根路径，可以根据接口名命名（例如：/service/com.demo.xxService），在这个路径再创建服务提供方目录与服务调用方目录（例如：provider、consumer），分别用来存储服务提供方的节点信息和服务调用方的节点信息。

当服务提供方发起注册时，会在服务提供方目录中创建一个临时节点，节点中存储该服务提供方的注册信息。
当服务调用方发起订阅时，则在服务调用方目录中创建一个临时节点，节点中存储该服务调用方的信息，同时服务调用方 watch 该服务的服务提供方目录（/service/com.demo.xxService/provider）中所有的服务节点数据。
当服务提供方目录下有节点数据发生变更时，ZooKeeper 就会通知给发起订阅的服务调用方。

当连接到 ZooKeeper 的节点数量特别多，对 ZooKeeper 读写特别频繁，且 ZooKeeper 存储的目录达到一定数量的时候，ZooKeeper 将不再稳定，CPU 持续升高，最终宕机。而宕机之后，由于各业务的节点还在持续发送读写请求，刚一启动，ZooKeeper 就因无法承受瞬间的读写压力，马上宕机。

因此，ZooKeeper 集群性能显然已经无法支撑我们现有规模的服务集群。

四、基于消息总线的最终一致（AP）性的注册中心

ZooKeeper 的一大特点就是强一致性，ZooKeeper 集群的每个节点的数据每次发生更新操作，都会通知其它 ZooKeeper 节点同时执行更新。它要求保证每个节点的数据能够实时的完全一致，这也就直接导致了 ZooKeeper 集群性能上的下降。这就好比几个人在玩传递东西的游戏，必须这一轮每个人都拿到东西之后，所有的人才能开始下一轮，而不是说我只要获得到东西之后，就可以直接进行下一轮了。

而 RPC 框架的服务发现，在服务节点刚上线时，服务调用方是可以容忍在一段时间之后（比如几秒钟之后）发现这个新上线的节点的。毕竟服务节点刚上线之后的几秒内，甚至更长的一段时间内没有接收到请求流量，对整个服务集群是没有什么影响的，所以我们可以牺牲掉 CP（强制一致性），而选择 AP（最终一致），来换取整个注册中心集群的性能和稳定性。

因为要求最终一致性，我们可以考虑采用消息总线机制。注册数据可以全量缓存在每个注册中心内存中，通过消息总线来同步数据。当有一个注册中心节点接收到服务节点注册时，会产生一个消息推送给消息总线，再通过消息总线通知给其它注册中心节点更新数据并进行服务下发，从而达到注册中心间数据最终一致性，具体流程如下图所示：

当有服务上线，注册中心节点收到注册请求，服务列表数据发生变化，会生成一个消息，推送给消息总线，每个消息都有整体递增的版本。

消息总线会主动推送消息到各个注册中心，同时注册中心也会定时拉取消息。对于获取到消息的在消息回放模块里面回放，只接受大于本地版本号的消息，小于本地版本号的消息直接丢弃，从而实现最终一致性。

消费者订阅可以从注册中心内存拿到指定接口的全部服务实例，并缓存到消费者的内存里面。

采用推拉模式，消费者可以及时地拿到服务实例增量变化情况，并和内存中的缓存数据进行合并。

为了性能，这里采用了两级缓存，注册中心和消费者的内存缓存，通过异步推拉模式来确保最终一致性。

另外，服务调用方拿到的服务节点不是最新的，所以目标节点存在已经下线或不提供指定接口服务的情况，这个时候有没有问题？这个问题我们放到了 RPC 框架里面去处理，在服务调用方发送请求到目标节点后，目标节点会进行合法性验证，如果指定接口服务不存在或正在下线，则会拒绝该请求。服务调用方收到拒绝异常后，会安全重试到其它节点。

通过消息总线的方式，我们就可以完成注册中心集群间数据变更的通知，保证数据的最终一致性，并能及时地触发注册中心的服务下发操作。在 RPC 领域精耕细作后，你会发现，服务发现的特性是允许我们在设计超大规模集群服务发现系统的时候，舍弃强一致性，更多地考虑系统的健壮性。最终一致性才是分布式系统设计中更为常用的策略。

五、CAP

计算机机专家Eric Brewer于2000年在ACM分布式计算原理专题讨论会（PODC）中提出的分布式系统设计要考虑三个核心要素：一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance），而这三个特性不可能同时满足。三个特性的说明如下：

一致性（Consistency） 同一时刻同一请求的不同实例返回的结果相同，这要求数据具有强一致性(Strong Consistency)，需要特别说明的这里的一致性与ACID（见上文）的一致性不是同一个概念，不要混淆
可用性（Availability） 所有读写请求在一定时间内得到正确的响应
分区容错性（Partition tolerance） 在网络异常情况下，系统仍能正常运作

如果要保证一致性（C），即所有节点可查询到的数据随时随刻都是一致的（同步中的数据不可查询），就要求一个节点写入数据后必须再将数据写入到另一个节点后才能返回成功，这样当我们读取之前写入的数据时才能确保一致，但上文说明过网络异常在所难免，如果两个服务节点无法相互通讯时为保证一致性在数据写入发现无法同步到另一节点时就会返回错误进而牺牲了可用性（A）。

如果要保证可用性（A），即只要不是服务宕机所有请求都可得到正确的响应，那么在网络异常节点不能通讯的情况下要让数据没有同步到另一节点的请求也返回成功，这就必须牺牲一致性（C）导致在一段时间内（网络异常期间）两个服务节点所查询到的数据可能不同。

所以从中可以简单地发现一致性（C）与可用性（A）是不可能同时满足的。同FLP Impossibility 一样CAP理论也为我们做分布式服务架构指明了方向：分布式系统中我们只能选择CP（满足一致性牺牲可用性）或AP（满足可用性牺牲一致性）。

当我们选择CP，即满足一致性而牺牲可用性时意味着在网络异常出现多个节点孤岛时为了保证各个节点的数据一致系统会停止服务，反之选择AP，即满足可用性牺牲一致性时网络异常时系统仍可工作，但会出现各节点数据不致的情况。