目录

注册中心是什么

注册中心有哪些？又改如何选用

CAP 原理

Nacos（CP+AP）

Zookeeper(CP)

Eureka（AP）

Consul(CP)

总结

在微服务环境中，往往存在着多个服务提供者或者服务调用者，服务提供者和调用者需要具备弹性收缩扩容的能力，所以原始的LB(LoadBalance)负载均衡机制不能够在满足，由此引入了服务注册中心，来管理服务提供者和服务消费者；服务注册中心的核心就是为了解耦服务提供者和服务消费者；

当前市场上存在了很多注册中心，从最开始的Zookeeper,到Netfix 的Eureka,再到Alibaba 的Nacos 等。服务注册中心变得越来越多样化，我们需要了解不同服务注册中心的特性、不同注册中心之间的对比，从而可以帮助我们在业务架构中进行对服务注册中心进行选型；下面是不同服务注册中心的对比：

在梳理不同服务注册中心的特性之前，前戏先了解下CAP 定理，CAP 定理是服务设计过程中，需要遵循的；

C: Consistency  表示一致性，及同一时间，所有节点的数据一致

A: Availability    表示可用性，一个请求，不管成功或者失败，都要收到服务端的响应

P: Partition tolerance  表示分区容错性， 系统中，任意节点数据的丢失不会影响系统整体的稳定性

Nacos 被分为两块功能，服务注册发现 和配置中心。我们主要关注Nacos 服务注册中心，从表格中可以看出，Nacos 一致性协议支持CP 或者AP两种协议 。Nacos支持两种协议的本身是因为Nacos支持临时实例和持久实例的切换，二者的区别是，心跳检测失败一段时间后，实例是自动下线还是标志不健康状态。CP 对应的是 永久实例，AP 对应的是临时实例，Nacos 默认是临时实例，及一致性协议是AP;

AP切换为CP 可以通过配置  spring.cloud.nacos.discovery.ephemeral=false ；

zookeeper 设计遵循了CP原则，及访问任意节点的数据始终保持数据一致性，同时，每个节点的数据具有分区容错性。但是zookeeper 不能保证每次请求都会得到服务端的响应

zookeeper 在使用过程中，如果集群中zk 的Leader宕机，那么需要从新选举或者集群中过半节点不可用时，此时是无法处理请求的。所以说zookeeper 不能保证服务的可用性；

对于服务来说，服务设计是优先遵循的是AP 原则，及保证服务可用性（双11 和618 设计都遵循了AP原则），所以说，对于服务调用方来说，服务提供者能够响应服务调用方的调用更为重要；

对于涉及数据处理相关，数据一致性是要优先被保证的

Eureka 设置遵循了AP 原则，Eureka  不同于Zookeeper Leader选举过程，Eureka Server采用的是Peer To Peer 对等通信，是一种去中心话的思想，没有master/slave 之分，从而每个节点都是平等的。

通过这种架构方式，每个节点都是其他节点的副本，当一个节点宕机时，Eureka 客户端的请求会自动被分配到新的存活的Eureka server 上，保证了服务的可用性；

当一个新的 Eureka Server 节点启动后，会首先尝试从邻近节点获取所有注册列表信息，并完成初始化。Eureka Server 通过 getEurekaServiceUrls() 方法获取所有的节点，并且会通过心跳契约的方式定期更新。

默认情况下，如果 Eureka Server 在一定时间内没有接收到某个服务实例的心跳（默认周期为30秒），Eureka Server 将会注销该实例（默认为90秒， eureka.instance.lease-expiration-duration-in-seconds 进行自定义配置）。

当 Eureka Server 节点在短时间内丢失过多的心跳时，那么这个节点就会进入自我保护模式。

Eureka的集群中，只要有一台Eureka还在，就能保证注册服务可用（保证可用性），只不过查到的信息可能不是最新的（不保证强一致性）。除此之外，Eureka还有一种自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况：

Eureka不再从注册表中移除因为长时间没有收到心跳而过期的服务； Eureka仍然能够接受新服务注册和查询请求，但是不会被同步到其它节点上（即保证当前节点依然可用）； 当网络稳定时，当前实例新注册的信息会被同步到其它节点中； 因此，Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像zookeeper那样使得整个注册服务瘫痪

在产线使用时，建议是关闭掉自我保护模式（eureka.server.enable-self-preservation: false），及如果存在节点心跳异常，剔除异常服务

Consul 遵循CAP原理中的CP原则，保证了强一致性和分区容错性，且使用的是Raft算法，比zookeeper使用的Paxos算法更加简单。虽然保证了强一致性，但是可用性就相应下降了，例如服务注册的时间会稍长一些，因为 Consul 的 raft 协议要求必须过半数的节点都写入成功才认为注册成功 ；在leader挂掉了之后，重新选举出leader之前会导致Consul 服务不可用

 Consul本质上属于应用外的注册方式，但可以通过SDK简化注册流程（流程如下图）。而服务发现恰好相反，默认依赖于SDK，但可以通过Consul Template（下文会提到）去除SDK依赖。

所幸通过Consul Template（集成流程如下图），可以定时从Consul集群获取最新的服务提供者列表并刷新LB配置（比如nginx的upstream），这样对于服务调用者而言，只需要配置一个统一的服务调用地址即可。

通过上述列举不同的服务注册中心的特点，在使用过程中，结合具体的业务场景设计，是要满足AP 还是CP 原则，然后选择对应的服务发现中心。

在实际使用过程中，由于Alibaba Spring Cloud 的越来越普及话，Nacos使用的更多，Nacos 支持了两种一致性协议，可以根据业务设计对一致性协议的设定；

参考链接：

https://nacos.io

https://mp.weixin.qq.com/s/66Q_jYBjWa1AVwbLwVzrfw