概述

在微服务时代，注册中心越来越被重视。服务治理逐渐跟业务服务并驾齐驱。所以本文想对注册中心进行体系化探索。注册中心，起源于分布式时代。不管是水平拆分架构，或者垂直拆分架构，对于多服务、多实例的支持，都需要对服务进行治理。注册中心被用于服务治理中的服务注册、服务发现、服务探活等场景。

架构师需要追寻事物的本质，并做好设计平衡，才能真正做到降本增效。那么注册中心的本质是什么：

1、根据服务发现的需求反推出第一个本质是一个Query函数
Si = F(serviceName)

• serviceName 查询服务参数

• Si 为对应服务的可用列表（IP：Port）

2、根据服务注册的需求反推出第二个本质是一个独立的、简单的第三方存储，用于服务元信息的存储。

• 高内聚、低耦合的设计思维要求注册中心存储的极简化。业内比如 dubbo 2.7 对注册中心进行拆分、剥离出元数据中心，其实就是单一职责原则的体现，也证明了注册中心的 simple 存储。

3、 根据服务探活的需求反推出第三个本质是节点监控通知。

• 节点的探活应该是多样化的，根据依赖倒置原则，节点既要提供默认探活：比如心跳机制，也应提供更多样化的服务探活。对于服务节点的存活，上游调用是最有发言权的。

服务代理

注册中心从需求上看是服务代理，常见服务代理有：

网路代理方式

对多实例服务的访问，可以通过增加反向代理，比如Nginx，上游调用方只需要访问Nginx，从而做到上游调用方对服务 A 多实例的透明。

如果公司有很多服务：服务 B、服务 C、服务 D、服务 E 等，遵循同样的基于反向代理的调用， 并必须保证代理的高可用，会陷入运维灾难。

DNS方式

给服务 A 配置一个域名，通过配置两个 A 记录分别指向服务 A 的两个实例，客户端只要配置服务 A 的域名。

这种方式存在问题：DNS 只是 IP 级别，无法处理端口等信息。DNS 携带的数据较少，例如节点权重、序列化方式等等，无法传递。另外 DNS 没有节点状态管理功能，无法及时剔除死掉的节点。

以上两者方式有很多问题，无法完全满足注册中心的三个需求，我们进一步探讨思考。

ZooKeeper 注册中心讨论

ZooKeeper用作注册中心是否适合？一切脱离场景谈架构都是耍流氓。NX架构师需要考虑针对场景进行探讨和分析。

官网对ZooKeeper的描述如下：

从官网描述上，我们并未发现 ZooKeeper 提供注册中心的功能，所以注册中心是我们加上的一个属性。从架构本质来分析，ZooKeeper 做注册中心是不优雅的。

之所以不优雅，总结了ZooKeeper 的局限性如下：

多机房网络划分后，强一致性引起的服务注册机制失效

ZAB 协议保证数据一致性，对于离线的少数节点进行保护，禁止读写引起。异地机房会有灾难性影响。
注册中心不能因为自身的任何原因破坏服务之间本身的可连通性。

持久化存储和事务日志

事务日志：CP 模式，半数节点写入成功；采用事务日志，2PC 提交。
定期 Dump 内存数据到硬盘，保持数据一致性。
注册中心只关注实时的健康的服务列表，调用方不关心历史服务与状态。

服务探活

ZooKeeper 注册中心通常利用 session 活性心跳和临时节点机制来进行服务探活。
简单而言，就是将服务的健康监测绑定在了 ZooKeeper 对于 Session 的健康监测上，或者说绑定在 TCP 长链接活性探测。

服务容灾

服务调用链路需要弱依赖注册中心，可是 ZooKeeper 原生客户端并不提供缓存服务节点机制。

客户端设计不优雅

原生客户端绝对称不上好用，Netflix Curator 会好一点，但其实也好的有限。

易用难精

ZooKeeper 看似很简单的一个产品，要完全理解 ZooKeeper 客户端与 Server 之间的交互协议也并不简单，完全理解并掌握 ZooKeeper Client/Session 的状态机并不简单。

ZooKeeper 做注册中心是伴随着 Dubbo 的流行而火热起来，他们之间相互成就，ZooKeeper 有局限，在业界也有众多的使用方，存在即合理，我们分析下 Dubbo 使用 ZooKeeper 的合理场景：

• 局限 1 推导出 ZooKeeper 注册中心适用于单数据中心。但市面上大部分公司都用不到多数据中心，所以不用纠结多数据中心。

• 局限 2 需要去测试，得出一个精准上限值。但网易考拉、Dubbo2.7 都对此进行优化，如元数据中心。原始上限值是千位级服务，优化和上限值更高。

• 局限 3、4、5 关注于 ZooKeeper 客户端，很多框架，包含 dubbo 对 Client 都已经原生支持，在绝大部分时候使用者是无感知的。

• 局限 6，ZooKeeper 是大数据之王，作为大数据协调器，在Hadoop生态中广泛使用。

ZooKeeper 作为注册中心源于 Dubbo 的火热，Dubbo 的广泛使用，造成了大量存量的 公司采用 ZooKeeper 作为注册中心，这些公司的注册中心是否需要升级，不能简单因为ZooKeeper本身存在的局限去否定。作为NX架构师，需要全局考虑，比如小公司中间件部署维护通常只有一个选型指标：引入一个中间件，增加系统的维护难度，是否可以接受；再比如注册中心足够稳定下，是否需要投入人力去做注册中心的更换，是否将有限资源投入其他更紧急业务项目中等。架构设计是全局的，需要取舍，做好折中，只有阶段最合适。

微服务规模

1、微型注册中心

该阶段注册中心，一般只关心服务本身，且是业务迭代比技术演进更被重视，需要的是一个无感知、部署简单的环境。指标如下：

API 数量 0-100
部署服务个位数

2、小型注册中心

该阶段注册中心，一般最关心服务发现特性，可能是一个很小的体量、很短的开发迭代周期、需要一个快速开发上手的环境。指标如下：

单数据中心，服务规模较小（API 数在 5K 以下，注册中心客户端数量在 50K 以下）

3、中型注册中心
该阶段注册中心，架构已经非常复杂，涉及到跨机房容灾等特性。一般会有专门的技术团队来做注册中心的日常运维。指标如下：

多数据中心
服务规模较大：API 数在 20K 以下，注册中心客户端数量在 200K 以下

4、大型注册中心

该阶段注册中心，服务量已经非常大，可能一个注册中心已经无法满足需求，必须拆为多个注册中心，甚至需要容量的无限扩展。指标如下：

非常多的数据中心
服务规模十分大，单注册集群无法满足全量存储

5、总结

架构是不断演进的，绝大部分使用者还属于微小型注册中心阶段；不需要一开始考虑机房容灾，不是一开始就使用最终级的架构方案；每个阶段要选型最合适技术，而不是最好技术。如果目前就千级别API接口、上百客户端调用的服务注册中心，ZooKeeper是能够很好满足需求的。

选型

从 CAP 模型来分析， 优雅的注册中心，需要AP模型，根据以上多维度对比，Eurake 和 Nacos 是 AP 模型，由于Netflix Eurake 2.0 已经停止更新，推荐阿里巴巴Nacos。

PS：对 Consul 的CAP模型，很多人认为是 CA 模型，对于分布式时代，如果丢失了 P 分区容错性，本质上回归成单机应用，意义不大。Consul官网对 Consul CAP 模型定义如下：