注册中心技术选型

本文主要是介绍注册中心技术选型，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

优质博文：IT-BLOG-CN

市面上流行的开源注册中心很多，耳熟能详的有Eureka、Zookeeper、Nacos、Consul。我们在选型的时候也主要从这四个组件中进行筛选。下面就对我们内部的讨论内容进行整理：

第一个维度：开源公司的实力

Eureka是Netflix公司出品的一款注册中心，Netflix是一家美国公司，主要做在线影片租赁提供商。嗯…，类似于爱奇艺吧。2012-2014开源，发布了一个release版本；Spring Cloud是基于Netflix Eureka做了二次封装。Eureka提供官方的控制台来查询服务注册情况。但是，Eureka 2.0在2018年宣布停止开发，但毕竟是开源的，所以有一群小伙伴还在维护着，但是不会有新功能的添加，它们主要是对目前版本的bug的修复。比较巧的是Nacos18年开源了。Eureka服务实例规模在5000左右的时候，就已经出现服务不可用的问题（我们不选择它的主要原因），甚至在压测的过程中，如果并发的线程数过高，就会造成Eureka crash。不过如果服务规模在1000上下，几乎目前所有的注册中心都可以满足。但是它也有优点就是稳定，稳定，像银行这种微服务还是比较适合的。不选它的原因是源码无更新，没有新功能。同时，当并发和注册用户达到一定量级的时候就会出现性能问题和不支持K8S。

Zookeeper是Google对Chubby一个开源的实现，后来托管到Apache，于2010年11月正式成为Apache的顶级项目。我们也习惯性的称它为动物园。在大数据领域极为广泛，是Hadoop和Hbase的重要组件。它是一个为分布式应用提供服务的软件，提供的功能包括：配置维护、域名服务、分布式同步等等。是一款经典的服务注册中心产品（虽然它最初的定位并不在于此）在很长一段时间里，它是国人在提起RPC服务注册中心时心里想到的唯一选择，这很大程度上与Dubbo在中国的普及程度有关。不选它的原因是不能与SpringCloud集成，同时ZooKeeper使用的ZAB协议，由于是单点写，在集群扩展性上不具备优势。

Nacos是国产的组件，由阿里巴巴在2018年开源，2019年1.0发布。此刻，应该有掌声，哈哈。Nacos是Dynamic Naming and Configuration Service的缩写，动态命名和配置服务。Nacos是阿里开源的注册中心+配置中心（配置中心我们使用的是携程的阿波罗，这个后面聊）服务。Nacos提供官方的控制台来查询服务注册情况，但如果在公司，一般只有运维大佬有这个权限访问控制台来对里面的服务删除等危险操作，像我们公司单独开发了一套Nacos控制台管理，权限对开发是比较小的，一些毁灭性的权限，是不会给它们分配的。后续还会继续增强控制台的能力，增加控制台登录和权限的管控，监控体系和 Metrics的暴露。Nacos 服务实例注册的支撑量约为100万，服务的数量可以达到10万以上。因为Nacos服务之间通过Raft算法保证一致性，所以建议Nacos部署的节点数为大于 3 的奇数。我们最终也是选择使用Nacos作为注册中心。

Consul是HashiCorp公司出品的开源工具，使用Go语言编写，也是一家美国公司，致力于为企业提供服务（它牛逼的功能没有对外开源，是对企业收费的）。Consul遵循CAP原理中的CP原则（跟ZK保持的一样），保证了强一致性和分区容错性。虽然保证了强一致性，但是可用性就相应下降了，例如服务注册的时间会稍长一些，因为Consul 的Raft协议要求必须过半数的节点都写入成功才认为注册成功；在Leader挂掉了之后，重新选举出 Leader之前会导致Consul服务不可用。不选择的原因，本身就是基于CP舍弃了A，而我们看中的就是A（有效性）。

声明：2020年5月29日禁止HashiCorp[Consul的公司]在中华人民共和国销售或以其他方式提供企业版本的产品，包括Consul企业版。目前不涉及到开源产品。

第二个维度：社区活跃度

Eureka核心代码停滞在2年前，源码地址【GitHub】根据下图我们得到的数据是：关注该项目的有 961次，点赞的9.4k，拉取项目次数 2.7k。我们看项目commit的时间都是比较旧的了，目前开源社区有人维护，所有偶尔也会有代码提交，基本都是bug的修复。

2.0放弃维护声明如下，1.x 相对稳定。如果你们还在使用，后续有必要迁移到其他开源微服务注册中心【链接】。

Zookeeper持续更新，源码地址【GitHub】根据下图我们得到的数据是：关注该项目的有 661次，点赞的8.2k，拉取项目次数 5.2k。拉取的比Eureka多，当时国内流行 RPC分布式调用的时候，还是很多的。项目在2小时前也有代码提交，还是很活跃的。只是不太适合作为我们目前说的微服务注册中心。

Nacos持续更新，源码地址【GitHub】根据下图我们得到的数据是：关注该项目的有 750次，点赞的12.6k，拉取项目次数 4k。18年开源的，但是目前从数据上看是未来微服务开发的趋势。据我了解目前很多公司，有能力迁移的都从Eureka迁移到了Nacos，因为它们遇见了性能问题。代码更新也是前一天就有更新，这里说下阿里的坏毛病，就是喜欢改项目名称或者就不维护了（借鉴Dubbo等）但是微服务这块大家就不用怕了，因为它托管给了SpringCloud了，也就是SpringCloudAlibaba。嗯…还是值得信赖的。其实，Nacos基本都是我们国内的公司再用，但我相信很快它还是能够在国外打下一片江山，毕竟是经过阿里双十一洗礼过的中间件。

Nacos 开发团队：阿里巴巴、虎牙直播，都是中国人就贴出来。详细信息自己可以上官网看看【链接】

Nacos 1.0发布时间点，2019.4.10 正式发布1.0 版本。

Consul持续更新，源码地址【GitHub】根据下图我们得到的数据是：关注该项目的有 985次，点赞的19.4k，拉取项目次数 3.3k。其实很多人没怎么听过，但是使用的也不少，因为使用它的基本都是国外的公司，Consul和Nacos其实很像，我们在后面有一张对比图大家也能看到两者差别不大，但Nacos还是比Consul牛逼。嗯…打压下大家的心情，其实，Consul牛逼的功能没有开源，哈哈。是付了钱才能用的。。

第三个维度：社区用户群

Eureka、Consul在2014开源，时间早，存在大量用户，中文文档资料也比较丰富。
Nacos在2018开源，2019发布1.0版本，比较年轻，社区用户以国内为主，中文文档资料也比较丰富。目前市面上用户群：阿里巴巴、虎牙直播、中国工商银行、爱奇艺、中国平安、平安科技、浙江农信、贝壳、丰巢、百世快递、汽车之家等。平安科技根据需求将Eureka和Nacos都进行了使用。是不是你们的公司也在里面，骄傲一波。。如果没有，点这个链接Who is Using

Zookeeper开源的比较早 2010年就开源，目前用户量都来自大数据那边，中文文档也比较丰富。这个就留给大数据大小伙伴，这里就不好好介绍了。

Spring Cloud 生态整合： 得到Spring Cloud开源组织的认可的有两个：
【1】Spring Cloud Alibaba（鼓掌）：链接
【2】Spring Cloud Netflix：链接

第四个维度：成熟稳定性

RESTful API支持：Eureka&Nacos
■ 都有RESTful API支持，可以通过定制化开发，巡检注册中心的稳定性；
■ Nacos Open API的更丰富一些；
■ Eureka Restful 参考地址
■ Nacos Restful 参考地址

Nacos兜底策略：选Nacos就对了
■ 人员招聘：跟进开源社区，技术交流；
■ Nacos注册中心，健康检查：
– 服务实例的健康状态；
– 服务实例的数量（包括健康、不健康）；
– 服务节点的健康状态；

其实选择用哪个注册中心的时候，都是从业务的角度考虑的，所以以后选型的时候，带着这张表就解决一大半问题：

功能	Nacos	Eureka	Consul	Zookeeper
协议	CP+AP	AP	CP	CP
负载均衡	weight/metadata/Selector	Rabbon	Fabio	-
监听机制	支持	支持	支持	不支持
自动注销实例	支持	支持	不支持	支持
雪崩保护	有	有	无	无
心跳检测	TCP/HTTP/MYSQL/Client Beat	Client Beat	TCP/HTTP/gRPC/Cmd	Keep Alive
访问协议	HTTP/DNS	HTTP	HTTP/DNS	TCP
多数据中心	支持	支持	支持	不支持
SpringCloud集成	支持	支持	支持	不支持
跨注册中心同步	支持	不支持	支持	不支持
K8S集成	支持	不支持	支持	不支持
Dubbo集成	支持	不支持	不支持	支持

第五个维度：负载均衡的策略

其实，负载均衡并不算是传统注册中心的功能。我们都知道服务发现的流程是先从注册中心获取到服务的实例列表，然后再根据自身的需求，来选择其中的部分实例或者按照一定的流量分配机制来访问不同的服务提供者，所以注册中心本身一般不参与服务消费者的访问策略。Eureka、ZooKeeper包括Consul，本身都没有去实现可配置及可扩展的负载均衡机制，Eureka的负载均衡是由Ribbon来完成的，而Consul则是由Fabio做负载均衡。

重点来了，阿里巴巴根据自己的业务场景，必须使用的相反的思路。服务消费者并不关心所访问的服务提供者的负载均衡策略，消息者要的是以最高效的方式访问提供者的服务。服务提供者则需要非常关注自身被访问的流量的调配，原因就是阿里巴巴内部服务访问流量巨大，稍有不慎就会导致流量异常压垮服务提供者的服务。因此服务提供者需要能够完全掌控服务的流量调配，并可以动态调整。服务端的负载均衡，给服务提供者更强的流量控制权，但是无法满足不同的消费者希望使用不同负载均衡策略的需求。而不同负载均衡策略的场景也确实存在。客户端的负载均衡则提供了这种灵活性，并对用户扩展提供更好的支持。但是客户端负载均衡存在的问题就是可能会导致服务提供者出现热点，或者压根就拿不到任何服务提供者。所以根据我们的场景只能选基于流量限制的 Sentinel，后面再好好唠这个。

生态中大礼包组件： Spring Cloud Alibaba和Netflix生态大礼包对比

组件	SpringCloud 官方	SpringCloud Netflix	SpringCloud Alibaba	我们的选择
分布式配置	SpringCloud Config	Archaius	Nacos	Ctrip Apollo（携程）
服务注册和发现	-	Eureka(停止更新）	Nacos	Eureka/Nacos?
服务熔断	-	Hystrix(维护状态)	Sentinel	Sentinel
服务路由	Gateway	Zuul(维护状态）	-	Gateway/Zuul
分布式消息	RabbitMQ	-	RocketMQ
负载均衡	LoadBalancer	Ribbon		F5、Ribbon
分布式事务	-	-	Seata	最终事务一致性