一、概述
在微服务时代，注册中心越来越被重视。服务治理逐渐跟业务服务并驾齐驱。所以本文想对注册中心进行体系化探索。注册中心，起源于分布式时代。不管是水平拆分架构 或者 ESB架构；对于多服务、多实例的支持，出现服务治理的需求，注册中心被用于服务治理中的服务发现、服务注册、服务探活三个功能与需求。
架构师需要追寻事物的本质，才能设计使用好技术。那么注册中心的本质是什么：
1、根据服务发现的需求反推出第一个本质是一个query函数
Si=F(serviceName)
serviceName查询服务参数
si为对应服务的可用列表(ip:port)
2、根据服务注册的需求反推出第二个本质是一个独立的、简单的第三方存储，用于服务基本信息的存储。高内聚、低耦合的思维要求了注册中心的存储极简化。业内比如dubbo 2.7对注册中心进行拆分、剥离出元数据中心，其实就是单一职责原则的体现，也侧边证明了注册中心的simple存储。
3、根据服务探活的需求反推出第三个本质是节点监控通知。节点的探活应该是多样化的，根据依赖倒置原则，节点既要提供默认探活-心跳，也应提供更多样化的服务探活。对于服务节点的存活，上游是最有发言权的。
二、服务代理
注册中心从需求上看是服务代理，常见服务代理有：
1、网络代理方式
如果是http方式通信的服务，可以增加一个nginx做反向代理，转发到两个服务A的实例上。
如果是RPC服务则可以增加一个LVS或HAProxy或者ESB之类的网络代理，客户端配置网络代理地址。
服务B我们再来一套一样的配置，这时候又来了服务C、服务D、服务E...，好吧我们好还要再多维护同样多的网络代理。此外，所有的服务调用服务调用都必须经过网络代理，我们还必须保证代理的高可用。最后，陷入运维灾难
2、DNS方式
给服务A配置一个域名,然后通过配置两个A记录分别指向两个服务A的实例，客户端只要配置服务A的域名即可。
这种方式也存在问题：DNS 只是到 IP 级别，无法处理端口等信息。DNS 携带的数据较少，例如节点权重、序列化方式等等，无法传递。另外 DNS 没有节点状态管理功能，如果由外部系统刷新，那么将无法剔除死的节点。
常见服务代理有很多问题，无法完全满足注册中心的三个需求，所以需要二次开发、引入新组件。
三、Zookeeper 注册中心的讨论
经常听见有的初级使用者就说 Zookeeper 这不好那不行有很多坑，那么架构师需要考虑是阶段试用性、场景适配性。那咱们系统性的讨论下zookeeper
首先了解一个产品，上官网，正常情况下，没有比owner更清楚自己。
从官网描述上，我们并未发现zookeeper提供注册中心的功能，所以注册中心是我们加上的一个属性。因此zookeeper做注册中心是不优雅的。从网上对Zookeeper做注册中心的局限分析，比较权威的文章有以下两篇：
第一篇文章，Eureka的文章：《Eureka! Why You Shouldn’t Use ZooKeeper for Service Discovery》
原文：https://medium.com/knerd/eureka-why-you-shouldnt-use-zookeeper-for-service-discovery-4932c5c7e764
第二篇文章，阿里文章:《阿里巴巴为什么不用 ZooKeeper 做服务发现？》
总结下zookeeper的局限性
1、网络划分后，强一致性引起的服务注册机制失效：
ZAB协议保证数据一致性，对于离线的少数节点进行保护，禁止读写引起。异地机房会有灾难性影响。
注册中心不能因为自身的任何原因破坏服务之间本身的可连通性。
注：对于zab协议，可看公众号<架构之美>的文章《分布式系统选主怎么玩》
2、持久化存储和事务日志
事务日志：CP模式，半数节点写入成功；采用事务日志，2PC提交。
定期dump内存数据到硬盘，保持数据一致性。
注册中心只关注实时的健康的服务列表，调用方不关心历史服务与状态
3、服务探活
Zk注册中心通常利用session 活性心跳和临时节点机制来进行服务探活
简单而言，就是将服务的健康监测绑定在了 ZooKeeper 对于 Session 的健康监测上，
或者说绑定在TCP长链接活性探测上了
4、服务容灾
服务调用链路弱依赖注册中心 , zk客户端并不提供缓存数据机制。
5、客户端不好用
原生客户端绝对称不上好用，Curator 会好一点，但其实也好的有限。
6、易用难精
ZooKeeper 看似很简单的一个产品，要完全理解 ZooKeeper 客户端与 Server 之间的交互协议也并不简单，完全理解并掌握 ZooKeeper Client/Session 的状态机并不简单。Zk集群常见坑：
https://yq.aliyun.com/articles/227260
zookeeper做注册中心是伴随着dubbo的流行而火热起来的，zk有那么多局限，又有那么多使用，这貌似是一个矛盾体，但存在即合理，所以需要分析dubbo使用zookeeper的合理场景：
- 局限一推导出zookeeper注册中心适用於单数据中心。但市面上大部分公司都用不到多数据中心，所以纠结的前提，多数据中心需求？过度设计并不是都是好的。
- 局限二需要去测试，得出一个精准上限值。但网易考拉、dubbo2.7都对此进行优化，如元数据中心。原始上限值是千位级服务，优化后上限值更高。微小企业貌似也用不到。
- 局限三、
- 局限四、局限五关注于zk客户端，很多框架，包含dubbo对这方面的client都已经原生带有，在绝大部分时候使用者是无感知的
- 局限六，zookeeper是大数据之王，理所当然的没有那么简单。在注册中心场景下，大部分情况是不需要那么深度的了解。
我们为啥做了那么分析呢。首先zookeeper注册中心源于dubbo的火热，dubbo的广泛使用，造成了大量存量的zookeeper注册中心，这些系统的注册中心是否需要升级，不能简单因为一句这不好那不行去否定。身为架构师，需要考虑全局性，比如小公司中间件部署维护通用就是一个选型指标：在引入一个中间件，增加系统的维护难度，是否可以接受；在比如注册中心足够稳定下，是否需要投入人力去做这注册中心的更换，是否将有限资源投入其他更紧急事项中……。架构是全局的，也是全栈的，需要取舍，只有阶段最合适。
四、服务规模
一说起微服务，我们习惯性说起规模，api有多少个、服务多少个、示例多少个。根据这些年看到听到的说法，个人总结了下有以下几个类型，这些类型是微服务时代组件选型的隐藏指标。
1、微型注册中心
该阶段注册中心，一般只关心服务本身，且是业务迭代比技术演进更被重视，需要的是一个无感知、部署简单的环境。指标如下：
api数量0-100，
部署服务个位数(注册中心客户端)
2、小型注册中心
该阶段注册中心，一般最关心服务发现特性，可能是一个很小的体量、很短的开发迭代周期、需要一个快速开发上手的环境。指标如下：
单数据中心
服务规模较小(接口数在 100-5K，注册中心客户端数量在 百位数 以下)
3、中型注册中心
该阶段注册中心，架构已经非常复杂，涉及到跨机房容灾等特性。一般会有专门的技术团队来做注册中心的日常运维。指标如下：
多数据中心
服务规模较大：接口数在 20K 以下，注册中心客户端数量在200K以下。
4、大型注册中心
该阶段注册中心，数据量已经非常大，可能一个注册中心已经无法满足需求，必须拆为多个注册中心，甚至需要容量的无限扩展。指标如下：
非常多的数据中心
服务规模十分大，单节点无法满足全量存储。
5、总结
架构是演进出来的，绝大部分使用者还属于微小型注册中心阶段；不需要一开始考虑机房容灾，不是一开始就上最终级的架构方案；每个阶段要挑最合适技术，而不是最好技术。如果目前就千来个接口百来个客户端的服务注册中心，随便哪个方案都能Hold住你的需求
五、选型
网上对consul有的说是ca模型，对于分布式时代，如果丢失了p-分区容错性，本质上回归成单机应用，完全可以ACID。所以作者上官网考究下：
第四节对zookeeper局限性做了大量分析，所以根据表格指标，在目前阶段和可预期的未来，推荐nacos。