注册中心选型篇-四款注册中心特色超全总结

在实际的项目选型中，该如何考虑选择合适的注册中心呢？

我在网上找了不少资料，但都基本不是最新的，好比说几乎全部的资料都还在说只有Eureka支持Spring Cloud的集成，其余注册中心均不支持Spring Cloud。所以，就想要本身写一篇 最新最全 的注册中心的特色比较的文章，来帮助本身以及亲爱的粉丝们从新梳理他们的特色，以保证以更全方位的考虑来进行项目选型

序号	比较项	Eureka	zookeeper	Nacos	Consul
1	集群结构	平级	主从	支持平级和主从	主从
2	集群角色	主人	Leader、follower observer	leader、follower、candidate	server-leader、server以及client
3	是否能够及时知道服务状态变化	不能及时知道	会及时知道	不能及时知道	不能及时知道
4	一致性协议（CAP）	注重可用性（AP）	注重一致性(CP)	支持CP和AP-如何实现	注重一致性(CP)
5	雪崩保护	有	没有	有	没有
6	社区是否活跃	Eureka2.0再也不维护了	持续维护	持续维护	持续维护
7	管理端	有现成的eureka管理端	没有现成的管理端	有现成的管理端	有现成的管理端
8	负载均衡策略	使用ribbon实现	通常能够直接采用RPC的负载均衡	权重/metadata/Selector	Fabio
9	权限控制	无	使用ACL实现节点权限控制	RBAC-用户、角色、权限	ACL
10	Spring Cloud集成	支持	支持	支持	支持
11	健康检查	Client Beat	Keep Alive	TCP/HTTP/MYSQL/Client Beat	TCP/HTTP/gRPC/Cmd
12	自动注销实例	支持	支持	支持	不支持
13	访问协议	HTTP	TCP	HTTP/DNS	HTTP/DNS
14	是否可用做配置中心	否	是	是	是
15	多数据中心	不支持	不支持	不支持	支持
16	跨注册中心同步	不支持	不支持	支持	支持
17	Dubbo集成	不支持	支持	支持	不支持
18	K8S集成	支持	支持	支持	支持

1 集群结构

Eureka的集群架构自己就是平级结构

zookeeper和consul则均为主从结构

Nacos则支持平级关系和主从这两种集群架构，经常使用的是后者

具体架构是怎样的，能够继续往下看~

2 集群角色

我发现，集群架构和角色每每是一个注册中心的核心功能，搞清楚这两点，基本上对于这个注册中心已经掌握了一半了。来分别看看四个注册中心的集群角色吧~

1） Eureka ：集群各节点都是分庭抗礼的关系，数据是相互复制的，所以各个节点都是主人角色

如图，服务端 Eureka-server 会存储服务实例信息，经过 复制 实现服务实例信息在各个节点同步，并按期去检查服务实例信息状态；

各个客户端也会经过健康检查等机制进行自我状态检查，要是信息有了变化，均会向服务Eureka-server发起请求

Eureka-server则会分别处理这些 状态变化 ，来保持实例信息的更新

2）zookeeper：集群角色包含leader、follower以及observer三类

具体来讲是一主多从结构，就是有一个leader，多个follower，以及只负责读操做、不参与选举的observer

下面是关于三个角色之间的关系图

a）首先图上是有client和server两大角色。client经过TCP与其中一个server创建链接。其中server分为leader、follower，以及observer三个角色

leader:负责投票的发起和决议

follower:同步leader的状态，参与leader选举。将写操做转发给leader,并参与“过半写成功”策略

observer:同步leader的状态，将写操做转发给Leader。不参加投票选举过程，也不参加写操做的“过半写成功”策略

b）当leader由于网络或者其余缘由挂掉以后，会从新在follower里面选择一个新的leader。

c）observer 机器能够在不影响写性能的状况下提高集群的读性能。

3）cosul：集群角色包含server-leader、server以及client

    

这三个角色实际上能够分别对应zookeeper中的 leader , follower 以及 observer 。对了，这块第三种角色- client ，千万要注意，它仍是属于consul的服务端的一个节点角色，而不是consul的客户端哦

来，看一下这张图，来梳理一下他们各自的功能

client : consul的client模式的节点。接收到consul的客户端请求之后，不作处理，会转发到server-leader，也不会持久化信息

server: consul的server模式的节点，功能和client都同样。惟一不一样的是，它会把全部的信息持久化到本地，这样遇到故障，信息是能够被保留的

server-leader: 名字就已经说明，这个server是全部服务端接节点的老大了,那么它天然负责的工做就多啦~ 它除了和普通的server模式的节点同样，须要进行信息持久化之外，还额外须要负责同步注册的信息给其它的server，同时也要负责各个节点的健康监测

4）Nacos： 包含 leader 、follower、candidate三类

Leader：负责Client交互和log复制，同一时刻系统中最多存在1个

Follower：被动响应请求 RPC ，从不主动发起请求RPC。接收到请求，会 转发 给leader处理

Candidate：一种临时的角色，只存在于leader的选举阶段

某个节点想要变成leader，那么就发起投票请求，同时本身变成candidate，若是选举成功，则变为candidate，不然退回为follower

具体流程以下图所示：

a  集群启动后，初始节点状态都是  Follower  状态

b 某个follower想要被选举成为leader,因而变成 candidate (候选人)状态，向本身投票，并向其余follower发起投票请求

c 收到其余节点的投票响应之后，若 超过半数的follower 都投了本身，则投票成功，本身的状态变为 leader

d  若是并无收到大多数的选票，则进行新一轮的投票

3 是否能够及时知道服务状态变化

因为zooKeeper具备watcher机制，所以能够及时知道数据目录的状态变化，那么也就能够及时知道服务器节点以及所注册的实例的变化。咱们能够经过这种监听机制，可以实时获取到某个服务器的故障或者咱们比较关心的节点数据的更改（zookeeper的节点znode包含服务器节点和数据节点）

其余三个注册中心没有这样的机制，只是能够经过管理端进行主动查看服务状态，并不能实时感知服务状态的变化

4 一致性协议（CAP）

首先，咱们再复习一下CAP原理（参考维基百科）

在理论计算机科学中，CAP定理，又被称做布鲁尔定理，它指出对于一个分布式计算系统来讲，不可能同时知足如下三点：

1） 一致性 （Consistency）注册中心的集群各个节点的数据信息彻底一致

2） 可用性 （Availability）每次请求都能获取到 非错的响应 ——可是不保证获取的数据为最新数据

3） 分区容错性 （Partition tolerance）以实际效果而言，分区至关于对 通讯的时限 要求。系统若是不能在时限内达成数据一致性，就意味着发生了分区的状况，必须就当前操做在C和A之间作出选择

根据定理，分布式系统 只能知足三项中的两项， 而不可能知足所有三项

理解CAP理论的最简单方式是 想象两个节点分处分区两侧 。容许至少一个节点更新状态会致使数据不一致，即丧失了C性质。若是为了保证数据一致性，将分区一侧的节点设置为不可用，那么又丧失了A性质。除非两个节点能够互 相通讯，才能既保证C又保证A，这又会致使丧失P性质

而四个注册中心，对一致性协议的支持状况以下：

          

Eureka ：支持AP，即保障可用性和分区容错性

Zookeeper ：支持CP,即保障一致性和分区容错性

consul ：支持CP,即保障一致性和分区容错性
nacos ：支持AP和CP两种模式。能够分别支持AP和CP两种场景



　C是全部节点在同一时间看到的数据是一致的；A是全部的请求都会收到响应。一个保证一致性，一个保证可用性。那么， 对于Nacos,如何选择使用哪一种模式呢？　


　　1）通常来讲，若是 不须要存储 服务级别的信息，且服务实例是经过Nacos-client注册，并可以保持心跳上报，那么就能够选择AP模式。AP模式为了服务的可用性而减弱了一致性，所以AP模式下只能注册 临时实例


　　2）若是须要在服务级别 编辑或存储 配置信息，那么CP是必须，K8S服务和DNS服务则适用于CP服务，CP模式下则支持注册持久化实例，此时则是以Raft协议为集群运行模式，该模式下注册实例以前必须先注册服务，若是服务不存在，则会返回错误


那么该如何 切换 这两种模式呢？



1）执行以下命令：


curl -X PUT `$NACOS_SERVER:8848/nacos/v1/ns/operator/switches?entry=serverMode&value=CP'



2）同时微服务的bootstrap.properties 需配置以下选项指明注册为临时/永久实例


#false-注册永久实例，true-注册为临时实例
spring.cloud.nacos.discovery.ephemeral=false






5 自动注销实例


除了 consul不支持自动注销 实例之外，其余三个注册中心均支持 自动注销 实例


1）Eureka ：默认状况下，若是Eureka Server在90秒内没有接收到某个微服务实例的心跳，Eureka Server将会注销该实例（时间间隔能够配置）


2）zookeeper :使用临时节点，依托于Session超时时间来实现 TTL 功能来实现自动注销。能够给每个键或目录指定一个存活时限TTL，当指定的秒数过去之后，若是相应的键或目录没有获得更新，就会被自动从Etcd记录中移除


3）Nacos ：从 0.5.0 版本开始，用户经过客户端SDK注册的实例，将默认开启TTL功能，实例会默认每5秒向服务端发送一次心跳，若是Nacos服务端15秒内没有收到实例的心跳，则会将实例置为不健康，若是30秒没有收到心跳，则会将直接将实例删除


Tips：
TTL, 是 Time To Live的简称，意思为一条域名解析记录在DNS服务器中的存留时间


6 雪崩保护


1）Eureka :有雪崩保护。咱们知道，当网络分区故障发生时，微服务与Eureka Server之间忽然没法正常通讯了，根据心跳机制，微服务将会被注销。那么这种心跳机制是否是就变得不太友好了？由于这种状况下微服务自己实际上是健康的，本不该该注销这个微服务，所以Eureka就提供了一个自我保护机制，也就是雪崩保护机制；



a）条件：



当Eureka Server节点在短期内丢失过多客户端（可能发生了网络分区故障），默认是15分钟内收到的续约低于原来的85%时，这个节点就会进入自我保护模式


b）动做：


一旦进入该模式，Eureka Server仍能接收新服务的注册和查询请求，可是不会同步到其余节点上；同时也会保护服务注册表中的信息，再也不移除注册列表中由于长时间没收到心跳而应该过时的服务。当网络故障恢复后，该Eureka Server节点会自动退出自我保护模式


这样获取的数据的确有可能不是最新的，但Eureka的这种自我保护机制，极大地保证了Eureka的高可用特性


2）Zookeeper： 没有雪崩保护



3）consul： 没有雪崩保护


4）nacos： 有雪崩保护。为了防止因过多实例 (Instance) 不健康致使流量所有流向健康实例 (Instance) ，继而形成流量压力把健康实例 (Instance) 压垮并造成雪崩效应，应将健康保护阈值定义为一个 0 到 1 之间的浮点数


当域名 健康实例 占 总服务实例 的比例小于该值时，不管实例是否健康，都会将这个实例返回给客户端。这样作虽然损失了一部分流量，可是保证了集群的剩余健康实例 (Instance) 能正常工做


7 社区是否活跃


Eureka2.0再也不维护了，而其余三个注册中心依旧在持续维护中，其中 Nacos 和 Consul 的社区应该说活跃度是最高的。从代码更新速度来说，也是如此。分别看了一下eureka、zookeeper、nacos以及consul的代码更新记录


1）eureka





2）zookeeper









3）nacos 





4）consul




会发现， Eureka 的更新频率相对来讲，明显比较低， Zookeeper 逐渐趋于成熟化，所以代码更新频率也很低，只是稍好于 Eureka 。而 Nacos 和 Consul 的更新频率明显很高，所以社区活跃度来讲， Nacos 和 Consul 仍是颇有优点的，所以对于将来的微服务项目的注册中心选型，更建议考虑这两种，更有保障一些



8 是否有管理端


Eureka 、 Consul 和 Nacos 都有现成的管理端


zookeeper没有现成的管理端，但客户端也能够根据提供的API，很容易本身实现一个也控制台，好比zkui就是其中一个比较好用的zookeeper管理端


9 负载均衡策略


Eureka :使用ribbon实现


Zookeeper :通常能够直接采用RPC的负载均衡


Nacos :采用权重/metadata/Selector


Consul :使用Fabio


关于负载均衡策略，这块就不作过多介绍了，感兴趣的能够在网上找找~


10 权限控制


Eureka 自己没有权限控制的机制，所以它须要与Spring Cloud Security来实现它的权限控制；


zookeeper :使用ACL实现节点权限控制
nacos ：使用RBAC实现节点权限控制-用户、角色、权限


consul ：使用ACL实现节点权限控制


11 Spring Cloud集成


四个注册中心，现 均已支持Spring Cloud的集成


12 健康检查


Eureka ： Eureka Server 与 Eureka Client 之间使用 心 跳机制 来肯定Eureka Client 的状态，默认状况下，服务器端与客户端的心跳保持正常，应用程序就会始终保持 UP 状态




Zookeeper： 自己没有健康检查机制，须要消费者本身实现服务提供者的健康检查动做
Nacos ： Nacos 支持传输层（PIND 或 TCP）和应用层（如 HTTP、MySQL 以及用户自定义）的监控检查，同时还支持相似于Eureka的心跳机制的健康检查
Consul：TCP/HTTP/gRPC/Cmd
健康检查，不得不说，是Consul的一个亮点特性了！Consul支持如下几种类型的健康检查：


1）脚本检查机制：经过执行程序外的脚本
2）HTTP检查机制：经过向指定的URL发起GET请求，服务的状态依赖HTTP请求的状态码：


2xx - passing
429 - Too ManyRequests is a warning
other - failure


与使用Curl或是外部进程检查的健康检查机制相比，HTTP检查机制应该是首选的


3）TCP检查机制
经过与指定的IP/hostname + 端口监理TCP链接


4）TTL检查机制


保留了给定的TTL（生命周期）的最新的状态，这些状态必须经过HTTP接口定时进行更新，须要服务周期性汇报健康状态


5）Docker检查机制


依赖触发一同被打包进容器的外部应用程序


13 访问协议


Eureka采用HTTP协议进行访问


Zookeeper采用TCP进行访问


而Nacos和Consul除了支持HTTP协议访问之外，还支持DNS协议


14 是否可用做配置中心


除了eureka不能够做为配置中心之外，其余三个注册中心都可以做为配置中心


15 多数据中心


只有consul支持多数据中心，但其余注册中心都有方案部署为多数据中心


16 跨注册中心同步


nacos 和 consul 支持跨注册中心同步


17 Dubbo集成


zookeeper 和 Nacos 支持Dubbo集成，Eureka和consul则暂不支持



18 K8S集成


四个注册中心 均支持k8s集成



三 总结

好了，今天呢，咱们主要经过18个方面，对四个注册中心作了分析比较，从新梳理比较了4个注册中心的核心特色。总得来讲， 四个注册中心各有优点
consul 和新晋的 nacos 的社区活跃度比较高， nacos 能够同时支持 AP 和 CP ； consul 则结合了 zookeeper 和 nacos 的诸多优势，还自然支持 多数据中心 ；而 zookeeper 则又能够惟一感知到服务状态的实时变化； Eureka 的自我保护机制使得它即便只剩下一台服务，也不影响正常运行，具备高可用性

那么选择的时候，究竟应该如何选择呢？
须要结合业务场景来进行选择。好比说，对于金融类的业务场景，对于 一致性 要求更高，那么就会排除掉 Eureka ,而后根据易用性、性价比等其余方面再进行后续的选择；对于 高可用 比较注重的项目，如电商类项目，则能够选择 Eurek 或者 Nacos ，但再比较其余方面，Nacos不只能够作注册中心，还能够做为架构中的配置中心，而且社区活跃度比较高，功能也日渐在完善，使用的人愈来愈多，所以综合来说，就选择了 Nacos
具体选择的过程当中，固然也会考虑这些因素以外的一些特色，包括人员的熟悉度等等，但确定也是先考虑主要的特色，再去考虑这些不是那么重要的特色的
点个 在看,赞👍支持我吧
   

本文分享自微信公众号 - 码农沉思录（code-thinker）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。