迎关注我的头条号：Wooola，10 年 Java 软件开发及架构设计经验，专注于 Java、Go 语言、微服务架构，致力于每天分享原创文章、快乐编码和开源技术。

概述

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

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

1、根据服务发现的需求反推出第一个本质是一个Query函数

Si = F(serviceName)

serviceName 查询服务参数

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

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

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

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

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

服务代理

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

01 / 网路代理方式

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

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

02 / DNS方式

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

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

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

ZooKeeper 注册中心讨论

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

官网对ZooKeeper的描述如下：

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

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