做为架构师的我，微服务注册中心该如何选型

我只总结干货，不喜欢扯炉子。确定还有不少方面没有涉及到，但愿各位指出。ths~

市面上流行的开源注册中心不少，耳熟能详的有 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（鼓掌）：https://spring.io/projects/spring-cloud-alibaba
【2】Spring Cloud Netflix：https://spring.io/projects/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		F五、Ribbon
分布式事务	-	-	Seata	最终事务一致性

Nacos相关资料，关注后回复 "nacos"