“ 任何技术和理念都将不能成为解决一切问题的银弹，有的只是权衡和选择”
点击上方蓝色字体，关注我
ZooKeeper、Eureka、Consul、Nacos：
最近微服务框架流行的几年，公司一共用过3个服务注册中心，分别是Eureka、Consul和Nacos(正在用?)，下面对这三个注册中心，进行简单的比较和分析。
记得之前最早的就是用Nginx，就可以满足基本的RESTful服务的发现，服务的IP列表配置在Nginx上即可，后来出现了RPC服务，然后就学习了Zookeeper。
说起Zookeeper，肯定要说到Dubbo，Java开发的程序猿或多或少肯定有了解或者采用过，它是阿里巴巴公司开源的一个高性能优秀的服务框架，使得应用可通过高性能的 RPC 实现服务的输出和输入功能，而且又可以和Spring框架无缝集成。主要Dubbo在国内很火，所以Zookeeper就顺理成章的作为Dubbo服务的注册中心，工业强度较高，可用于生产环境，并推荐使用。
Consul和Eureka都出现于2014年，Eureka则借着微服务概念的流行，与SpringCloud生态的深度结合，公司第一个微服务项目就使用Eureka来作为服务注册中心。而Consul在设计上把很多分布式服务治理上要用到的功能都包含在内，可以支持服务注册、健康检查、配置管理、Service Mesh等，17年-18年的项目公司都采用Consul来作为服务注册中心。2018年发布并开源的Nacos，则携带着阿里巴巴大规模服务生产经验，试图在服务注册和配置管理这个市场上，提供给用户一个新的选择，今年开始我们就选择Nacos来提供服务注册和配置中心了。
1)CAP定理，指的是在一个分布式系统中， Consistency(一致性)、 Availability(可用性)、Partition tolerance(分区容错性)，三者不可得兼。
一致性(C)：在分布式系统中的所有数据备份，在同一时刻是否同样的值。(等同于所有节点访问同一份最新的数据副本)
可用性(A)：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。(对数据更新具备高可用性)
分区容忍性(P)：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。
CAP原则的精髓就是要么AP，要么CP，要么AC，但是不存在CAP。如果在某个分布式系统中数据无副本， 那么系统必然满足强一致性条件， 因为只有独一数据，不会出现数据不一致的情况，此时C和P两要素具备，但是如果系统发生了网络分区状况或者宕机，必然导致某些数据不可以访问，此时可用性条件就不能被满足，即在此情况下获得了CP系统，但是CAP不可同时满足。因此在进行分布式架构设计时，必须做出取舍。
CAP原理
Zookeeper和Consul保证的是CP，而Eureka则是AP，Nacos不仅支持CP也支持AP。
当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的注册信息，但不能接受服务直接down掉不可用。也就是说，服务注册功能对可用性的要求要高于一致性。但是Zookeeper会出现这样一种情况，当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于，选举leader的时间太长，30 ~ 120s， 且选举期间整个Zookeeper集群都是不可用的，这就导致在选举期间注册服务瘫痪。在云部署的环境下，因网络问题使得Zookeeper集群失去master节点是较大概率会发生的事，虽然服务能够最终恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。
所以Eureka看明白了这一点，因此在设计时就优先保证可用性。Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或时如果发现连接失败，则会自动切换至其它节点，只要有一台Eureka还在，就能保证注册服务可用(保证可用性)，只不过查到的信息可能不是最新的(不保证强一致性)。除此之外，Eureka还有一种自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况：
Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务
Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上(即保证当前节点依然可用)
当网络稳定时，当前实例新的注册信息会被同步到其它节点中
因此， Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像zookeeper那样使整个注册服务瘫痪。
2)Eureka是一个服务发现工具。该体系结构主要是客户机/服务器，每个数据中心有一组Eureka服务器，通常每个可用区域一个。Eureka的客户端使用嵌入式SDK来注册和发现服务。对于不是本机集成的客户机，使用一个sidecar(如Ribbon)通过Eureka透明地发现服务。
Consul提供了一组超级功能，包括更丰富的健康检查、密钥/值存储和多数据中心感知。Consul在每个数据中心需要一组服务器，在每个客户机上需要一个代理，类似于使用类似sidecar的功能区。consul允许通过配置文件执行服务注册，并通过DNS或负载平衡器sidecars进行发现。
Consul提供了强大的一致性保证，因为服务器使用Raft协议复制状态。Consul支持一组丰富的健康检查，包括TCP、HTTP、Nagios/Sensu兼容脚本或基于TTL的Eureka。同时Consul提供了支持面向服务体系结构所需的功能工具包。这包括服务发现，但也包括丰富的运行状况检查、锁定、密钥/值、多数据中心联合、事件系统和acl。
Eureka1.X版本的实现是基于servlet的Java Web应用，它的极限性能肯定会受到影响。2.X的版本也不开源，停止更新了，所以当时17-18年之间考虑公司新项目选用Consul的原因，公司新项目app可以点击下载。
3)Consul实际上是和Nacos比较相似的产品，虽然Consul目前的主要发展方向放在了Service Mesh，但是Consul最初支持的服务发现和配置管理，也是Nacos的两大功能。虽然Nacos在Consul之后以与之相似的部署架构开源，但这并不意味着Nacos在功能和架构上也模仿Consul，Nacos的架构和功能是由阿里巴巴内部十年的运行演进经验得来，所以二者的比较也一定会让大家更加了解他们的定位和演进方向是完全不一样的。
19年底阿里云要全面停止对docker swarm的支持，大力推广支持k8s了，同时nacos也发布一年多了，并且有了GA的版本，nacos对k8s支持也很好，所以公司新项目也打算上nacos了紧随阿里云的步伐?，这段时间也要把之前老项目从swarm迁移到k8s上。
下面是网上找的几个主流产品的对比图，希望能帮到大家更好的理解和选择产品。
主流微服务产品对比图
配置中心
eureka 不支持
consul 支持 但用起来偏麻烦，不太符合springBoot框架的命名风格，支持动态刷新
nacos 支持 用起来简单，符合springBoot的命名风格，支持动态刷新
注册中心
eureka
应用内/外：直接集成到应用中，依赖于应用自身完成服务的注册与发现，
ACP原则：遵循AP(可用性+分离容忍)原则，有较强的可用性，服务注册快，但牺牲了一定的一致性。
版本迭代：目前已经不进行升级
集成支持：只支持SpringCloud集成
访问协议：HTTP
雪崩保护：支持雪崩保护
界面：英文界面，不符合国人习惯
上手：容易
consul
应用内/外：属于外部应用，侵入性小
ACP原则：遵循CP原则(一致性+分离容忍) 服务注册稍慢，由于其一致性导致了在Leader挂掉时重新选举期间真个consul不可用。
版本迭代：目前仍然进行版本迭代
集成支持：支持SpringCloud K8S集成
访问协议：HTTP/DNS
雪崩保护：不支持雪崩保护
界面：英文界面，不符合国人习惯
上手：复杂一点
nacos
应用内/外：属于外部应用，侵入性小
ACP原则：通知遵循CP原则(一致性+分离容忍) 和AP原则(可用性+分离容忍)
版本迭代：目前仍然进行版本迭代
集成支持：支持Dubbo 、SpringCloud、K8S集成
访问协议：HTTP/动态DNS/UDP
雪崩保护：支持雪崩保护
界面：中文界面，符合国人习惯
上手：极易，中文文档，案例，社区活跃
2、总结：
本文简单介绍了几块微服务框架注册中心的优势和劣势，更多的内容请参考下面的两个本文参考链接，上面有更详细的介绍。
本文参考链接：
https://yq.aliyun.com/articles/698930
https://www.consul.io/intro/vs/index.html
喜欢本文，点个“在看”
扫一扫
2586
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
