Nacos系列【21】Nacos2.x服务发现模块之注册中心设计原理

服务发现是服务发现当应用程序开始脱离单机运行和访问时，服务发现就诞生了。目前的网络 架构是每个主机都有?个独立的 IP 所以服务发现基本上是通过某种方式获得的 署的 IP 地址。DNS 协议是最早的协议网络名称翻译为网络名称 IP 在最初的架构选择中， DNS LVS Nginx 基本可以满足所有的 RESTful 服务发现，此时服务 IP 列表通常配置在 nginx 或者 LVS。后来出现了 RPC 人们开始寻求服务，服务上下线更频繁。可支持动态上下 线并且推送 IP 注册中心产品列表变更。

开源产品在互联网软件行业广受欢迎，因为开源产品代码透明，可以参与共建，有社区交流学习 当然，更重要的是，它们是免费的。个人开发者或中小企业往往以开源产品为首选。 Zookeeper 是?经典的服务注册中心产品(虽然最初的定位不在这里)在很长一段时间内段时间里， 是中国人提到的 RPC 服务注册中心时心中唯一想到的在很大程度上，选择 Dubbo 在中国的普 与程度有关。Consul 和 Eureka 都出现于 2014 年，Consul 很多分布式服务在设计上都要治理 包括所有使用的功能，可支持服务注册、健康检查、配置管理Service Mesh 等。而 Eureka 微服务概念的流行与 SpringCloud 生态的深度结合也获得了大量用户。去年开源的 Nacos，凭借阿里巴巴的大规模服务生产经验，试图在服务注册和配置管理市场提供服务 用户?新的选择。

开源产品的优点之一是开发人员可以阅读源代码，了解产品的功能设计和架构设计，也可以 通过本地部署测试性能，随之而来的是各种产品的对比文章。然而，目前注册中心的对比往往是 通常停留在表面功能对比上，对架构或性能没有很深入的探讨。

另?服务注册中心作为默默支持的产品，往往隐藏在服务框架背后。优秀的服务框架往往 它将支持各种配置中心，但注册中心的选择仍然与服务框架密切相关，一般情况下，种类是常见的种服务框 架会带?默认服务注册中心。虽然消除了用户选择的麻烦，但单个注册中心的局限性 当用户使用多个服务框架时，必须部署多个完全不同的注册中心，这些注册中心之间的数据 协同也是?个问题。

本文从各个角度深度介绍 Nacos 注册中心的设计原则，试图从我们的经验和研究中总结和阐述 应遵循和考虑服务注册中心产品设计的要点。

负载均衡严格的来说，并不算是传统注册中心的功能。⼀般来说服务发现的完整流程应该是先从注 册中心获取到服务的实例列表，然后再根据自身的需求，来选择其中的部分实例或者按照⼀定的流 量分配机制来访问不同的服务提供者，因此注册中心本身⼀般不限定服务消费者的访问策略。 Eureka、Zookeeper 包括 Consul，本身都没有去实现可配置及可扩展的负载均衡机制，Eureka 的 负载均衡是由 ribbon 来完成的，而 Consul 则是由 Fabio 做负载均衡。

在阿里巴巴集团内部，却是使用的相反的思路。服务消费者往往并不关心所访问的服务提供者的负 载均衡，它们只关心以最高效和正确的访问服务提供者的服务。而服务提供者，则非常关注自身被 访问的流量的调配，这其中的第⼀个原因是，阿里巴巴集团内部服务访问流量巨大，稍有不慎就会 导致流量异常压垮服务提供者的服务。因此服务提供者需要能够完全掌控服务的流量调配，并可以 动态调整。

服务端的负载均衡，给服务提供者更强的流量控制权，但是无法满足不同的消费者希望使用不同负 载均衡策略的需求。而不同负载均衡策略的场景，确实是存在的。而客户端的负载均衡则提供了这 种灵活性，并对用户扩展提供更加友好的支持。但是客户端负载均衡策略如果配置不当，可能会导 致服务提供者出现热点，或者压根就拿不到任何服务提供者。

Zookeeper 和 Eureka 都实现了⼀种 TTL 的机制，就是如果客户端在⼀定时间内没有向注册中心发 送心跳，则会将这个客户端摘除。Eureka 做的更好的⼀点在于它允许在注册服务的时候，自定义检 查自身状态的健康检查方法。这在服务实例能够保持心跳上报的场景下，是⼀种比较好的体验，在 Dubbo 和 SpringCloud 这两大体系内，也被培养成用户心智上的默认行为。Nacos 也支持这种 TTL 机制，不过这与 ConfigServer 在阿里巴巴内部的机制又有⼀些区别。Nacos 目前支持临时实 例使用心跳上报方式维持活性，发送心跳的周期默认是 5 秒，Nacos 服务端会在 15 秒没收到心 跳后将实例设置为不健康，在30 秒没收到心跳时将这个临时实例摘除。

不过正如前文所说，有⼀些服务无法上报心跳，但是可以提供⼀个检测接口，由外部去探测。这样 的服务也是广泛存在的，而且以我们的经验，这些服务对服务发现和负载均衡的需求同样强烈。服 务端健康检查最常见的方式是 TCP 端口探测和 HTTP 接口返回码探测，这两种探测方式因为其协 议的通用性可以支持绝大多数的健康检查场景。在其他⼀些特殊的场景中，可能还需要执行特殊的 接口才能判断服务是否可用。例如部署了数据库的主备，数据库的主备可能会在某些情况下切换，需要通过服务名对外提供访问，保证当前访问的库是主库。此时的健康检查接口，可能就是⼀个检 查数据库是否是主库的 MYSQL 命令了。

客户端健康检查和服务端健康检查有⼀些不同的关注点。客户端健康检查主要关注客户端上报心跳 的方式、服务端摘除不健康客户端的机制。而服务端健康检查，则关注探测客户端的方式、灵敏度 及设置客户端健康状态的机制。从实现复杂性来说，服务端探测肯定是要更加复杂的，因为需要服 务端根据注册服务配置的健康检查方式，去执行相应的接口，判断相应的返回结果，并做好重试机 制和线程池的管理。这与客户端探测，只需要等待心跳，然后刷新 TTL 是不⼀样的。同时服务端健 康检查无法摘除不健康实例，这意味着只要注册过的服务实例，如果不调用接口主动注销，这些服 务实例都需要去维持健康检查的探测任务，而客户端则可以随时摘除不健康实例，减轻服务端的压 力。

Nacos 既支持客户端的健康检查，也支持服务端的健康检查，同⼀个服务可以切换健康检查模式。 我们认为这种健康检查方式的多样性非常重要，这样可以支持各种类型的服务，让这些服务都可以 使用到 Nacos 的负载均衡能力。Nacos 下⼀步要做的是实现健康检查方式的用户扩展机制，不管是服务端探测还是客户端探测。这样可以支持用户传入⼀条业务语义的请求，然后由 Nacos 去执 行，做到健康检查的定制。

虽然大部分用户用到的性能不高，但是他们仍然希望选用的产品的性能越高越好。影响读写性能的 因素很多：⼀致性协议、机器的配置、集群的规模、存量数据的规模、数据结构及读写逻辑的设计 等等。在服务发现的场景中，我们认为读写性能都是非常关键的，但是并非性能越高就越好，因为 追求性能往往需要其他方面做出牺牲。Zookeeper 在写性能上似乎能达到上万的 TPS，这得益于 Zookeeper 精巧的设计，不过这显然是因为有⼀系列的前提存在。首先 Zookeeper 的写逻辑就是 进行 K-V 的写入，内部没有聚合；其次 Zookeeper 舍弃了服务发现的基本功能如健康检查、友好 的查询接口，它在支持这些功能的时候，显然需要增加⼀些逻辑，甚至弃用现有的数据结构；最后， Paxos 协议本身就限制了 Zookeeper 集群的规模，3、5 个节点是不能应对大规模的服务订阅和查 询的。

在对容量的评估时，不仅要针对企业现有的服务规模进行评估，也要对未来 3 到 5 年的扩展规模 进行预测。阿里巴巴的中间件在内部支撑着集团百万级别服务实例，在容量上遇到的挑战可以说不 会小于任何互联网公司。这个容量不仅仅意味着整体注册的实例数，也同时包含单个服务的实例数、 整体的订阅者的数目以及查询的 QPS 等。Nacos 在内部淘汰 Zookeeper 和 Eureka 的过程中， 容量是⼀个非常重要的因素。

Zookeeper 的容量，从存储节点数来说，可以达到百万级别。不过如上面所说，这并不代表容量的 全部，当大量的实例上下线时，Zookeeper 的表现并不稳定，同时在推送机制上的缺陷，会引起客 户端的资源占用上升，从而性能急剧下降。

Eureka 在服务实例规模在 5000 左右的时候，就已经出现服务不可用的问题，甚至在压测的过程中， 如果并发的线程数过高，就会造成 Eureka crash。不过如果服务规模在 1000 上下，几乎目前所有 的注册中心都可以满足。毕竟我们看到 Eureka 作为 SpringCloud 的注册中心，在国内也没有看到 很广泛的对于容量或者性能的问题报告。

Nacos 在开源版本中，服务实例注册的支撑量约为 100 万，服务的数量可以达到 10 万以上。在 实际的部署环境中，这个数字还会因为机器、网络的配置与 JVM 参数的不同，可能会有所差别。 图 9 展示了 Nacos 在使用 1.0.0 版本进行压力测试后的结果总结，针对容量、并发、扩展性和延时 等进行了测试和统计。

完整的测试报告可以参考 Nacos 官网:

• https://nacos.io/en-us/docs/nacos-naming-benchmark.html
• https://nacos.io/en-us/docs/nacos-config-benchmark.html

易用性也是用户比较关注的⼀块内容。产品虽然可以在功能特性或者性能上做到非常先进，但是如 果用户的使用成本极高，也会让用户望而却步。易用性包括多方面的工作，例如 API 和客户端的接 入是否简单，文档是否齐全易懂，控制台界面是否完善等。对于开源产品来说，还有⼀块是社区是 否活跃。在比较 Nacos、Eureka 和 Zookeeper 在易用性上的表现时，我们诚邀社区的用户进行全 方位的反馈，因为毕竟在阿里巴巴集团内部，我们对 Eureka、Zookeeper 的使用场景是有限的。从 我们使用的经验和调研来看，Zookeeper 的易用性是比较差的，Zookeeper 的客户端使用比较复杂， 没有针对服务发现的模型设计以及相应的 API 封装，需要依赖方自己处理。对多语言的支持也不太 好，同时没有比较好用的控制台进行运维管理。

Eureka 和 Nacos 相比较 Zookeeper 而言，已经改善很多，这两个产品有针对服务注册与发现的 客户端，也有基于 SpringCloud 体系的 starter，帮助用户以非常低的成本无感知的做到服务注册 与发现。同时还暴露标准的 HTTP 接口，支持多语言和跨平台访问。Eureka 和 Nacos 都提供官方 的控制台来查询服务注册情况。不过随着 Eureka 2.0 宣布停止开发，Eureka 在针对用户使用上的 优化后续应该不会再有比较大的投入，而 Nacos 目前依然在建设中，除了目前支持的易用性特性 以外，后续还会继续增强控制台的能力，增加控制台登录和权限的管控，监控体系和 Metrics 的暴 露，持续通过官网等渠道完善使用文档，多语言 SDK 的开发等。

从社区活跃度的角度来看，目前由于 Zookeeper 和 Eureka 的存量用户较多，很多教程以及问题 排查都可以在社区搜索到，这方面新开源的 Nacos 还需要随着时间继续沉淀。

集群扩展性和集群容量以及读写性能关系紧密。当使用⼀个比较小的集群规模就可以支撑远高于现 有数量的服务注册及访问时，集群的扩展能力暂时就不会那么重要。从协议的层面上来说，Zookee per 使用的 ZAB 协议，由于是单点写，在集群扩展性上不具备优势。Eureka 在协议上来说理论上 可以扩展到很大规模，因为都是点对点的数据同步，但是从我们对 Eureka 的运维经验来看， Eureka 集群在扩容之后，性能上有很大问题。

集群扩展性的另⼀个方面是多地域部署和容灾的支持。当讲究集群的高可用和稳定性以及网络上的 跨地域延迟要求能够在每个地域都部署集群的时候，我们现有的方案有多机房容灾、异地多活、多 数据中心等。

首先是双机房容灾，基于 Leader 写的协议不做改造是无法支持的，这意味着 Zookeeper 不能在 没有人工干预的情况下做到双机房容灾。在单机房断网情况下，使机房内服务可用并不难，难的是 如何在断网恢复后做数据聚合，Zookeeper 的单点写模式就会有断网恢复后的数据对账问题。Eure ka 的部署模式天然支持多机房容灾，因为 Eureka 采用的是纯临时实例的注册模式：不持久化、所 有数据都可以通过客户端心跳上报进行补偿。上面说到，临时实例和持久化实例都有它的应用场景， 为了能够兼容这两种场景，Nacos 支持两种模式的部署，⼀种是和 Eureka ⼀样的 AP 协议的部署， 这种模式只支持临时实例，可以完美替代当前的 Zookeeper、Eureka，并支持机房容灾。另⼀种是 支持持久化实例的 CP 模式，这种情况下不支持双机房容灾。

在谈到异地多活时，很巧的是，很多业务组件的异地多活正是依靠服务注册中心和配置中心来实现 的，这其中包含流量的调度和集群的访问规则的修改等。机房容灾是异地多活的⼀部分，但是要让 业务能够在访问服务注册中心时，动态调整访问的集群节点，这需要第三方的组件来做路由。异地 多活往往是⼀个包含所有产品线的总体方案，很难说单个产品是否支持异地多活。

多数据中心其实也算是异地多活的⼀部分。从单个产品的维度上，Zookeeper 和 Eureka 没有给出 官方的多数据中心方案。Nacos 基于阿里巴巴内部的使用经验，提供的解决方案是采用 Nacos-Sy nc 组件来做数据中心之间的数据同步，这意味着每个数据中心的 Nacos 集群都会有多个数据中心 的全量数据。Nacos-Sync 是 Nacos 生态组件里的重要⼀环，不仅会承担 Nacos 集群与 Nacos 集群之间的数据同步，也会承担 Nacos 集群与 Eureka、Zookeeper、Kubernetes 及 Consul 之 间的数据同步。

在框架的设计中，扩展性是⼀个重要的设计原则。Spring、Dubbo、Ribbon 等框架都在用户扩展性 上做了比较好的设计。这些框架的扩展性往往由面向接口及动态类加载等技术，来运行用户扩展约 定的接口，实现用户自定义的逻辑。在 Server 的设计中，用户扩展是比较审慎的。因为用户扩展 代码的引入，可能会影响原有 Server 服务的可用性，同时如果出问题，排查的难度也是比较大的。 设计良好的 SPI 是可能的，但是由此带来的稳定性和运维的风险是需要仔细考虑的。在开源软件中， 往往通过直接贡献代码的方式来实现用户扩展，好的扩展会被很多人不停的更新和维护，这也是⼀ 种比较好的开发模式。Zookeeper 和 Eureka 目前 Server 端都不支持用户扩展，⼀个支持用户扩 展的服务发现产品是 CoreDNS。CoreDNS 整体架构就是通过插件来串联起来的，通过将插件代码 以约定的方式放到 CoreDNS 工程下，重新构建就可以将插件添加到 CoreDNS 整体功能链路的⼀ 环中。

那么这样的扩展性是否是有必要的呢？举⼀个上文提到过的例子，假如要添加⼀种新的健康检查方 式，连接数据库执行⼀条 MySQL 命令，通常的方式是在代码里增加 MySQL 类型的健康检查方法、 构建、测试然后最终发布。但是如果允许用户上传⼀个 jar 包放到 Server 部署目录下的某个位置， Server 就会自动扫描并识别到这张新的健康检查方式呢？这样不仅更酷，也让整个扩展的流程与 Server 的代码解耦，变得非常简单。所以对于系统的⼀些功能，如果能够通过精心的设计开放给用 户在运行时去扩展，那么为什么不做呢？毕竟增加扩展的支持并不会让原有的功能有任何损失。

所有产品都应该尽量支持用户运行时扩展，这需要 Server 端 SPI 机制设计的足够健壮和容错。 Nacos 在这方面已经开放了对第三方 CMDB 的扩展支持，后续很快会开放健康检查及负载均衡等 核心功能的用户扩展。目的就是为了能够以⼀种解耦的方式支持用户各种各样的需求。

本文并不是⼀篇介绍 Nacos 功能的文章，因此 Nacos 的⼀些特色功能并没有在文中涉及，这些特 色功能其实也是 Nacos 区别与其他注册中心的重要方面，包括 Nacos 支持的 DNS 协议，打自定 义标等能力。稍微熟悉 Nacos 的读者可能会注意到，Nacos 的整体架构和 Consul 有⼀些类似， 但是事实上 Nacos 和 Consul 除了都是把配置管理和服务发现部署在⼀起，其他地方基本上没有 相似的地方，我们将会在另外⼀篇文章中专门介绍与 Consul 的差异。Nacos 的架构和功能是由阿 里巴巴内部十年的运行演进经验得来，所以二者的比较也⼀定会让大家更加了解他们的定位和演进 方向是完全不⼀样的。当然在国内社区来说，目前主流的注册中心还是 Zookeeper 和 Eureka，后 续作者也会对这两个注册中心与 Nacos 的异同点进行详细介绍，同时会介绍如何从 Zookeeper 和 Eureka 平滑无痛的迁移到 Nacos，敬请期待。

Nacos 2.0 发布了 GA 版本，后续将会以和社区共建的方式，持续输出新的功能，在服务发现和配 置管理这两大领域继续深耕，期待与大家⼀起建设出最好用的服务发现和配置管理平台。