前言
在介绍四种开源项目之前，先简单认识一下注册中心。
我的简单理解：
注册中心提供服务注册和服务发现功能
注册中心解决单点故障问题
注册中心需要保存服务注册信息以及服务发现时的筛选和简单计算能力
那么我们应该从以下几点来“考量”一个注册中心：
如何解决单点故障问题以及如何保证信息不丢失，有何优缺点
如何存储服务注册信息，有何优缺点
如何通讯，通讯效率等
功能是否丰富，能否满足不同需求
简洁通俗的介绍它，注册中心就是一个高可用的分布式“字典”服务，各个服务之间通过这个“字典”服务找到对方。
下面就通过这些问题，针对不同的注册中心来深入和比较。
Eureka
请移步至【微服务系列（二）(1) Eureka源码分析】查看
ZooKeeper
ZooKeeper不仅作为注册中心而存在，其开发出来并被定义为分布式协调服务，还可以用作配置中心等其他功能，源码也比较复杂，这里分为三个部分来分析。
part-1【微服务系列（二）(2) ZooKeeper源码分析-part-1】：Zookeeper Server的初始化过程，通讯原理及选举机制
part-2【微服务系列（二）(3) ZooKeeper源码分析-part-2】：Zookeeper Server的数据存储机制
part-3【微服务系列（二）(4) ZooKeeper源码分析-part-3】：Zookeeper Client发送命令链路追踪，Zookeeper的事务请求原理，Watcher监听原理
Consul
由于consul是go语言开发，对go语言不熟悉，没办法深入源码进行分析，这里从官网列举一些consul的特性，以方便与其他注册中心进行对比。
我对consul的了解较少，仅仅尝试过搭建和使用consul的简单功能如服务发现、KV等。
文档上有以下描述：
The key features of Consul are:
Service Discovery: Clients of Consul can register a service, such as api or mysql, and other clients can use Consul to discover providers of a given service. Using either DNS or HTTP, applications can easily find the services they depend upon.
Health Checking: Consul clients can provide any number of health checks, either associated with a given service (“is the webserver returning 200 OK”), or with the local node (“is memory utilization below 90%”). This information can be used by an operator to monitor cluster health, and it is used by the service discovery components to route traffic away from unhealthy hosts.
KV Store: Applications can make use of Consul’s hierarchical key/value store for any number of purposes, including dynamic configuration, feature flagging, coordination, leader election, and more. The simple HTTP API makes it easy to use.
Secure Service Communication: Consul can generate and distribute TLS certificates for services to establish mutual TLS connections. Intentions can be used to define which services are allowed to communicate. Service segmentation can be easily managed with intentions that can be changed in real time instead of using complex network topologies and static firewall rules.
Multi Datacenter: Consul supports multiple datacenters out of the box. This means users of Consul do not have to worry about building additional layers of abstraction to grow to multiple regions.
consul的主要特点有：
服务发现：Consul的客户端可以注册服务，例如api或mysql，其他客户端可以使用Consul来发现给定服务的提供者。使用DNS或HTTP，应用程序可以轻松找到它们所依赖的服务。
运行状况检查：Consul客户端可以提供任意数量的运行状况检查，这些检查与给定服务（“是Web服务器返回200 OK”）或本地节点（“内存利用率低于90％”）相关联。运营商可以使用此信息来监控群集运行状况，服务发现组件使用此信息将流量路由远离不健康的主机。
KV存储：应用程序可以将Consul的分层键/值存储用于任何目的，包括动态配置，功能标记，协调，领导者选举等。简单的HTTP API使其易于使用。
安全服务通信：Consul可以为服务生成和分发TLS证书，以建立相互的TLS连接。意图可用于定义允许哪些服务进行通信。可以使用可以实时更改的意图轻松管理服务分段，而不是使用复杂的网络拓扑和静态防火墙规则。
多数据中心：Consul支持多个数据中心。这意味着Consul的用户不必担心构建额外的抽象层以扩展到多个区域。
可以知道：
consul的服务发现不仅支持HTTP，还可以支持DNS(基于DNS的服务发现)[https://yq.aliyun.com/articles/598792]。
consul能监控并实时的反馈服务的运行状况信息
consul提供KV存储，能支持动态配置、领导者选举等，且提供简单的HTTP API
consul提供TLS认证，对服务访问增加权限控制，管理方便
consul支持多数据中心，这里的多数据中心的概念是可以支持多个小集群，每个小集群作为一个数据中心，其内部的数据不会因其他集群的变化而受影响，且多数据中心直接支持跨数据中心请求，当服务器收到对不同数据中心的请求时，它会将其转发到正确数据中心中的随机服务器。那个服务器可能会转发给当地的领导。
最后总结一下，说一些个人对consul的看法，从官网的建设上看，不得不说consul的官方网站做的很漂亮，文档也非常齐全；从使用感受上看，consul的兼容性非常好，支持不同语言嵌入，支持DNS服务发现，如果仅针对个人使用体验而言，相对zk、eureka在部署和spring接入上看相对繁琐；从官方文档的了解上看，consul功能丰富、支持集群容错、提供TLS认证，不仅可用作注册中心，还可用于配置中心等其他场景。
Nacos
请移步至【微服务系列（二）(5) Nacos源码分析】查看
优缺点及适用场景分析
每篇源码分析中已经涵盖了一些简单的总结，这里用一个表格来展示这四者的异同点。
registry/feature Eureka ZooKeeper Consul Nacos
开发语言 Java（依赖Spring） Java（少量依赖） Go Java（依赖Spring）
重点特性 内存型，处理速度快 提供客户端监听机制，集群有崩溃恢复的特性 支持DNS的服务发现 支持DNS的服务发现，文件存储机制简单，处理速度较快，OpenAPI简单通用
client-server通讯方式 http tcp长连接 http http
peer节点间通讯方式 http tcp长连接 http http
server存储原理 JVM内存（有自我保护机制，防止大量服务失效） 同步写入JVM内存+同步写入文件+定期快照 未知 异步更新JVM内存+同步写入文件
client存储原理（保存服务列表信息） JVM内存 无（由用户自行处理） 未知 JVM内存+文件缓存
更新机制 轮询更新服务列表 Zk Watcher监听服务列表变化 Agent 监听 长轮询监听（由于使用http协议，定期发起一次http请求在服务端轮询较长时间，本质依然是轮询）
CAP AP CP AP AP/CP（Nacos1.0将支持两种模式）
一致性协议 无（单纯的进行节点间数据同步，互为备份节点） Zab协议 Raft协议 Raft协议
社区活跃度 中 高 低 低
生产环境适用规模（实际情况根据环境决定） 20 K ~ 30 K 实例（节点） 10K ~ 20K 实例（节点） < 3K 实例（节点） 未知
大规模实例环境下瓶颈分析 1. GC频繁 2. 扩展困难 1. GC较频繁 2. 扩展困难 3. 扩容困难 1. 更新列表速度慢 1. GC较频繁 2. 扩展较困难
适用场景分析 适合与Spring Cloud基础组件配合使用，在大规模实例的场景下需要进行相应的改造 适合规模中等且一致性较强的场景，如果无法忍受服务列表更新延迟，那么推荐使用ZooKeeper 适合跨语言移植项目 适合跨语言移植项目，Nacos配套提供了Nacos Sync同步组件，方便移植，支持较大规模实例的场景
小结
总的而言，如果项目架构选用Spring Cloud基础组件来支撑的话，注册中心最好还是使用eureka，适配度最高，如果有某些特殊需求也可以通过架构上的改造来完成效果；如果项目架构选用dubbo或是非Java项目，那么注册中心最好是选用ZooKeeper，一般而言如果不是因为性能瓶颈，一致性要求应该是比较高的，ZooKeeper就能实现一个很好的均衡，既能支撑较大的实例数又能保证一致性；如果项目架构是dubbo或者Spring Cloud原生组件遭遇无法改造的窘境，或是面临瓶颈又想避免增加系统复杂度的情况，那么就需要考虑项目架构的迁徙和改造了，这时consul和nacos将会是一个比较好的选择，当然，如果是纯Java项目，Nacos将会更加适合，前提是Nacos发布稳定可靠的版本。
如果简单看，这些注册中心都具备能支撑较大实例数的能力，项目规模不大的时候，我个人比较推荐Consul和ZooKeeper，因为Consul提供了较丰富的功能，控制台做的也很好，而ZooKeeper具备更好的集群系统，响应更快，也同样具备订阅功能，不足之处在于没有一个方便操作的控制台（毕竟ZooKeeper的定位本身就不单单只是为了作为注册中心），而Nacos从目前分析上看虽然具备了以上特性，控制台做的更加灵活，功能也更加强大，但还不够成熟，还是需要期待它的完善，期待虎牙生产环境的实践经验的分享。
