分布式注册中心ZooKeeper、Eureka、 Nacos

分布式注册中心

一、分布式注册中心的概念

​ 注册中心是只有在分布式架构中才有的概念，注册中心是分布式架构中所有服务器注册信息等相关功能的专用服务器，注册的地址是服务器的名称与对应IP地址。分布式环境下的应用在启动时候都会向这个地方来注册自己的网络地址和名称。用一句话来概括，注册中心的作用就是存放和调度服务，实现服务和注册中心，服务与服务之间的通信。

注册中心的功能不仅包括注册服务，还包括服务下线管理、服务状态监测、向服务推送配置，如下图所示：

二、常用注册中心举例

2.1 CAP理论

​ 在分布式系统中，有一个理论，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。

• 一致性( C-数据同步耗时 )：所有节点在同一时间具有相同的数据，节点越多，数据同步越耗时。
• 可用性( A-保证正常响应时间 )：服务一直可用，保证每个请求不管成功或者失败都有响应，而且是正常响应时间。
• 分区容错性( P-节点数量多 )：分区容忍性，就是高可用性，一个节点宕机了，并不影响其它的节点，服务仍然能提供。

​ CAP原理指的是在分区容错发生时，只能在保证一致性或可用性中二选其一。因为分区容错不可避免，在系统设计时必须放弃一致性或可用性，没有分区发生时可以同时保证一致性和可用性。只有在CP和AP选择一个平衡点。

CAP不能同时满足的原因：

1. CA满足时，P不能满足：数据同步©需要耗费时间，如果要正常的时间内响应(A)，那么节点数量就要少，所以P就不满足，这也就是单点问题。
2. CP满足时，A不能满足：数据同步©需要时间, 节点数量越多§，同步的时间也就越长，正常响应时间内不能返回，所以A就不满足。
3. AP满足时，C不能满足：节点数量越多§，正常的时间内响应(A)，那么数据就不能及时同步到其他节点，所以C不满足。

2.2 三大常用注册中心比较

​ ZooKeeper、Eureka和Nacos是三大常用的注册中心。

2.2.1 ZooKeeper

​ ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是大数据处理框架Hadoop和Hbase的重要组件。ZooKeeper是非常经典的服务注册中心中间件，在国内环境下，由于受到Dubbo框架的影响，大部分情况下认为Zookeeper是RPC服务框架下注册中心最好选择，随着Dubbo框架的不断开发优化，和各种注册中心组件的诞生，即使是RPC框架，现在的注册中心也逐步放弃了ZooKeeper，ZooKeeper保证CP，它的架构如下图所示：

优点：保持数据的一致性，在设计时就紧遵CP原则，即任何时候对 ZooKeeper 的访问请求能得到一致的数据结果。

缺点：不适合服务，针对同一个服务，即使注册中心的不同节点保存的服务提供者信息不尽相同，也并不会造成灾难性的后果。当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。选举leader的时间太长，可达30~120s，选举期间整个ZooKeeper集群都是不可用的，这就导致在选举期间注册服务瘫痪。

2.2.2 Eureka

​ Eureka是Netflix开发的服务发现框架，本身是一个基于REST的服务，主要用于定位运行在AWS域中的中间层服务，以达到负载均衡和中间层服务故障转移的目的。SpringCloud将它集成在其子项目spring-cloud-netflix中，以实现SpringCloud的服务发现功能。Eureka包含两个组件：Eureka Server和Eureka Client。服务启动后向Eureka注册，Eureka Server会将注册信息向其他Eureka Server进行同步，当服务消费者要调用服务提供者，则向服务注册中心获取服务提供者地址，然后会将服务提供者地址缓存在本地，下次再调用时，则直接从本地缓存中取，完成一次调用。Eureka保证AP，它的架构如下图所示：

优点：

• 高可用性。在设计时就紧遵 AP 原则，Eureka 的集群中，它是去中心化结构，只要有一台 Eureka 还在，就能保证注册服务可用，只不过查到的信息可能不是最新的（不保证强一致性）。
• 自我保护机制。Eureka有一种自我保护机制，如果在15mins内超过85%的节点都没有正常的ping心跳，那么Eureka就认定客户端和注册中心出现了网络故障。

缺点：只有一个服务注册中心，显然这不符合高可用的原则，高可用就得增加Eureka server 的数量，维护成本太高了。

2.3 Nacos

​ 阿里的一个开源产品，是针对微服务架构中的服务发现、配置管理、服务治理的综合型解决方案。用于实现配置中心和服务注册中心。Nacos支持基于DNS和基于RPC的服务发现,动态配置服务(配置中心),动态DNS服务。Nacos支持CP和AP两种机制，Nacos是根据配置识别CP或AP模式。它的架构如下图所示：

优点：

• Nacos支持目前几乎所有主流的微服务生态体系
• nacos在自动或手动下线服务，使用消息机制通知客户端，服务实例的修改很快响应。
• nacos可以根据namespace命名空间，DataId,Group分组，来区分不同环境（dev，test，prod），不同项目的配置。
  三大注册中心对比如下表所示：

对比内容	Nacos	Eureka	ZooKeeper
一致性协议	CP+AP	AP	CP
健康检查	TCP/HTTP/MYSQL/Client Beat	Client Beat	Keep Alive
负载均衡策略	权重/metadata/Selector	Ribbon	-
雪崩保护	有	有	无
自动注销实例	支持	支持	支持
访问协议	HTTP/DNS	HTTP	TCP
监听支持	支持	支持	支持
多数据中心	支持	支持	不支持
跨注册中心同步	支持	不支持	不支持
Spring Cloud集成	支持	支持	支持
Dubbo集成	支持	不支持	支持
Kubernetes集成	支持	不支持	不支持