关于后端:服务发现CP-or-AP

1 服务发现的意义

为高可用，生产环境中服务提供方都以集群对外提供服务，集群里这些 IP 随时可能变动，也须要用一本“通信录”及时获取对应服务节点，这获取过程即“服务发现”。

对服务调用方和服务提供方，其契约就是接口，相当于“通信录”中的姓名，服务节点就是提供该契约的一个具体实例。服务 IP 汇合作为“通信录”中的地址，从而可通过接口获取服务 IP 的汇合来实现服务的发现。即 PRC 框架的服务发现：RPC 服务发现原理图

1.1 服务注册

在服务提供方启动时，将对外裸露的接口注册到注册核心，注册核心将这个服务节点的 IP 和接口保留

1.2 服务订阅

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

2 为何不应用 DNS？

服务发现的实质，就是实现接口跟服务提供者 IP 的映射。是否把服务提供者 IP 对立换成一个域名，利用 DNS 实现？

2.1 DNS 流程

DNS 查问流程：

所有服务提供者节点都配置在同一域名下，调用方是可通过 DNS 拿到随机的一个服务提供者的 IP，并建设长连贯，但业界为何不必这计划？

异样思考

• 若该 IP 端口下线了，服务调用者是否及时摘除服务节点
• 若在之前已上线一部分服务节点，忽然对这服务扩容，新上线的服务节点是否及时接管到流量

都不能。为晋升性能和缩小 DNS 服务压力，DNS 采取多级缓存，缓存工夫较长，尤其 JVM 默认缓存是永恒无效，所以服务调用者不能及时感知服务节点变动。

是否能加个负载平衡设施？将域名绑定到这台负载平衡设施，通过 DNS 拿到负载平衡的 IP。服务调用时，服务调用方就能间接跟 VIP 建设连贯，而后由 VIP 机器实现 TCP 转发：

VIP 计划：

这是能解决 DNS 遇到的一些问题，但 RPC 里不是很适合：

• 搭建负载平衡设施或 TCP/IP 四层代理，需额定老本
• 申请流量都通过负载平衡设施，多通过一次网络传输，节约性能
• 负载平衡增加节点和摘除节点，个别要手动增加，当大批量扩容和下线时，会有大量人工操作和失效提早
• 服务治理时，需更灵便的负载平衡策略，目前负载平衡设施的算法不满足灵便需要

由此可见，DNS 或者 VIP 计划尽管能够充当服务发现的角色，但在 RPC 场景外面间接用还是很难的。

3 基于 zk 的服务发现 (CP)

服务发现的实质：实现接口跟服务提供者 IP 的映射。就是一种命名服务，还心愿注册核心实现实时变更推送，zk、etcd 都能实现。

搭建一个 zk 集群作为注册核心集群，服务注册时，只需服务节点向 zk 写入注册信息，利用 zk 的 Watcher 机制实现服务订阅与服务下发性能。

整体流程

基于 ZooKeeper 服务发现结构图：

1. 服务平台治理端先在 zk 创立一个服务根门路，可依据接口名命名（如：/service/com.javaedge.xxService），在这门路再创立服务提供方目录与服务调用方目录（如：provider、consumer），别离存储服务提供方、服务调用方的节点信息
2. 当服务提供方发动注册时，会在服务提供方目录中创立一个长期节点，节点中存储该服务提供方的注册信息
3. 当服务调用方发动订阅时，则在服务调用方目录中创立一个长期节点，节点中存储该服务调用方的信息，同时服务调用方 watch 该服务的服务提供方目录（/service/com.demo.xxService/provider）中所有的服务节点数据。
4. 当服务提供方目录下有节点数据产生变更时，zk 告诉给发动订阅的服务调用方

zk 缺点

晚期 RPC 框架服务发现就是基于 zk 实现，但后续团队微服务化水平越来越高，zk 集群整体压力越来越高，尤其在集中上线时越发显著。“集中暴发”是在一次大规模上线时，过后有超大批量服务节点在同时发动注册操作，ZooKeeper 集群的 CPU 飙升，导致集群不能工作，也无奈立马将 zk 集群重新启动，始终到 zk 集群复原后业务能力持续上线。

根本原因就是 zk 自身性能问题，当连贯到 zk 的节点数量特多，对 zk 读写特频繁，且 zk 存储目录达到肯定数量，zk 将不再稳固，CPU 继续升高，最终宕机。宕机后，因为各业务的节点还在继续发送读写申请，刚一启动，zk 就因无奈接受霎时的读写压力，马上宕机。

要重新考虑服务发现计划。

4 音讯总线 (AP)

zk 强一致性，集群的每个节点的数据每次产生更新操作，都告诉其它节点同时执行更新。它要求保障每个节点的数据实时完全一致，间接导致集群性能降落。

而 RPC 框架的服务发现，在服务节点刚上线时，服务调用方可容忍在一段时间后（如几 s 后）发现这个新上线的节点。毕竟服务节点刚上线后的几 s 内，甚至更长的一段时间内没有接管到申请流量，对整个服务集群没有什么影响，可就义掉 CP（强制一致性），抉择 AP（最终统一），换取整个注册核心集群的性能和稳定性。

是否有一种简略、高效，并且最终统一的更新机制，代替 zk 数据强统一的数据更新机制？最终一致性，可思考音讯总线机制。注册数据可全量缓存在每个注册核心的内存，通过音讯总线来同步数据。当有一个注册核心节点接管到服务节点注册时，会产生一个音讯推送给音讯总线，再通过音讯总线告诉给其它注册核心节点更新数据并进行服务下发，从而达到注册核心间数据最终一致性。

4.1 总体流程

• 服务上线，注册核心节点收到注册申请，服务列表数据变动，生成一个音讯，推送给音讯总线，每个音讯都有整体递增的版本
• 音讯总线被动推送音讯到各注册核心，同时注册核心定时拉取音讯。对获取到音讯的，在音讯回放模块外面回放，只承受大于本地版本号的音讯，小于本地版本号的音讯间接抛弃，实现最终一致性
• 消费者订阅可从注册核心内存拿到指定接口的全副服务实例，并缓存到消费者的内存
• 采纳推拉模式，消费者可及时拿到服务实例增量变动状况，并和内存中的缓存数据进行合并。

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

服务调用方拿到的服务节点不是最新的，所以指标节点存在已下线或不提供指定接口服务的状况，这时咋办？这问题放到 RPC 框架里解决，在服务调用方发送申请到指标节点后，指标节点会进行合法性验证，若指定接口服务不存在或正在下线，则回绝该申请。服务调用方收到回绝异样后，会平安重试到其它节点。

通过音讯总线，实现注册核心集群间数据变更的告诉，保证数据最终一致性，并能及时触发注册核心的服务下发。服务发现的个性是容许咱们在设计超大规模集群服务发现零碎的时候，舍弃强一致性，更多思考零碎健壮性。最终一致性才是分布式系统设计更罕用策略。

5 总结

通常可应用 zk、etcd 或分布式缓存（如 Hazelcast）解决事件告诉问题，但当集群达到肯定规模之后，依赖的 ZooKeeper 集群、etcd 集群可能就不稳固，无奈满足需要。

在超大规模的服务集群下，注册核心所面临的挑战就是超大批量服务节点同时高低线，注册核心集群承受到大量服务变更申请，集群间各节点间须要同步大量服务节点数据，导致：

• 注册核心负载过高
• 各节点数据不统一
• 服务下发不及时或下发谬误的服务节点列表

RPC 框架依赖的注册核心的服务数据的一致性其实并不需要满足 CP，只有满足 AP 即可。咱们就是采纳“音讯总线”的告诉机制，来保障注册核心数据的最终一致性，来解决这些问题的。

如服务节点数据的推送采纳增量更新的形式，这种形式进步了注册核心“服务下发”的效率，而这种形式，还可用于如对立配置核心，用此形式能够晋升对立配置核心下发配置的效率。

6 FAQ

某大厂中间件的用户平台，服务挂了，在注册核心上还得手动删除死亡的节点，若是 zk，服务没了，就代表会话也没了，长期节点应该会被告诉到把？为何还要手动删除？

长期节点是须要等到超时工夫之后才删除，不够实时。

如果要能切换流量，要服务端配置权重负载平衡策略，这样服务器端即可通过调整权重安顿流量。

服务消费者都是从注册核心拉取服务提供者的地址信息，所以要切走某些服务提供者数据，只须要将注册核心这些实例的地址信息删除（其实下线利用实例，理论也是去删除注册核心地址信息），而后注册核心反向告诉消费者，消费者受到拉取最新提供者地址信息就没有这些实例了。

通过服务发现来摘除流量是最常见的伎俩，还能够高低线状态、权重等形式。

现有开源注册核心是不是还没有音讯总线这种实现形式？音讯总线有没有开源实现？

现成 MQ 也可充当音讯总线。

音讯总栈相似一个队列，队列示意是递增的数字，注册核心集群的任何一个节点接管到注册申请，都会把服务提供者信息发给音讯总栈，音讯总栈会像队列以先进先出的准则推送音讯给所有注册核心集群节点，集群节点接管到音讯后会比拟本人内存中的以后版本，保留版本大的，这种形式有很强的实效性，注册核心集群也能够从音讯总栈拉取音讯，确保数据 AP，集体了解这是为了避免音讯未接管到导致个别节点数据不精确，因为服务提供者能够向任意一个节点发送注册申请，从而升高了单个注册核心的压力，而注册和注册核心同步是异步的，也解决了集中注册的压力，在 Zookeeper 中，因为 Zookeeper 注册集群的强一致性，导致必须所有节点执行完一次同步，能力执行新的同步，这样导致注册解决性能升高，从而高 I / O 操作宕机。

当集中注册时，音讯总栈下发告诉给注册核心集群节点，对于单个节点也会不停的收到更新告诉，这里也存在高 I / O 问题，会不会有宕机？event bus 能够革新成主从模式保障高可用。

AP 实现中“两级缓存，注册核心和消费者的内存缓存，通过异步推拉模式来确保最终一致性的具体实现？

推次要实现 callback，拉的动作在客户端。

音讯总线策略怎么保障音讯总线全局版本递增？最简略的用工夫戳。

音讯总线构建 ap 型注册核心，不是很了解。是多个注册核心独立提供读写，他们之间通过音讯队列做数据同步？那么一致性感觉不好保障，比方服务 a 先注册，再反注册，然而别离发到两个注册核心节点，最终同步可能是乱序的哇？个别不会呈现这种状况，只有连贯断开后，那须要从新注册。

音讯总线的另一个利用 case：配置核心。

关注我，紧跟本系列专栏文章，咱们下篇再续！

作者简介：魔都技术专家兼架构，多家大厂后端一线研发教训，各大技术社区头部专家博主，编程严选网创始人。具备丰盛的引领团队教训，深厚业务架构和解决方案的积攒。

负责：

• 地方 / 分销预订零碎性能优化
• 流动 & 优惠券等营销中台建设

• 交易平台及数据中台等架构和开发设计

  目前主攻升高软件复杂性设计、构建高可用零碎方向。

参考：

• 编程严选网

  本文由博客一文多发平台 OpenWrite 公布！