注册中心分析

简述

之前面试问到了工作中用到的注册中心和市面上的有啥异同。

公司用的注册中心：Zookeeper

市面上除此之外还有其他注册中心：Eureka、Consul、Nacos

组件名称	所属公司	组件介绍
Zookeeper	Apache	Zookeeper是一个分布式协调工具，可以实现注册功能
Eureka	Netflix	Spring最早的注册中心，目前已经进入停更进维
Consul	Hashicorp	Consul简化了分布式环境中的服务的注册和发现流程，通过HTTP或者DNS接口发现，支持外部Saas提供者等
Nacos	Alibaba	Nacos致力于发现、配置和管理微服务。Nacos提供了一组简单易用的特性集，快速实现动态服务发现、服务配置、服务元数据以及流量管理

Zookeeper

遵循CP原则（一致性，分区容错性），牺牲了高可用。所以任何时候请求都能得到一致的数据结果，但是不能保证每次服务请求都是可达的。比如请求的时候leader节点宕机，或者集群中半数以上节点不可用，那么将无法处理请求。

Eureka

遵循AP原则（可用性，分区容错性），牺牲了数据一致性。也就是能保证每次服务请求都是可达的，但是不能保证每次的请求结果都是一致的。Eureka集群没有主从之分，采用的是Peer to Peer对等通信，这是一种去中心化的架构，每个节点都需要添加一个或多个有效的serviceUrl指向其他节点，每个节点都是其他节点的副本。集群中只要还有一个节点存活，那么服务就是可用的，但是不饿能保证查到的数据是最新的或者一致的。

除此之外还有一种保护机制，如果在15分钟内超过85%的节点都没有正常心跳，Eureka则认为客户端与注册中心之间出现了网络故障，此时会出现以下几种情况：

1、Eureka不再从注册表中移除因长时间没有收到心跳而过期的服务

2、Eureka仍然能够接受新服务注册和查询请求，但不会同步到其他节点上，只保证当前节点可用

3、当网络稳定时，当前实例新注册的信息会被同步到其他节点

Consul

遵循CP原则，Hashicorp公司开发，用于实现分布式系统的服务发现与配置。使用的时Raft算法，比zookeeper使用的Paxos算法更简单，虽然保证了强一致性，但是可用性方面性能有所下降，比如在服务注册方面，Raft协议要求半数以上的节点都写入才算注册成功，leader节点宕机之后，在重新选取出leader节点之前都会导致不可用。

Nacos

遵循AP原则，也可支持CP原则，阿里开源，nacos = 注册中心 + 配置中心，总之很强大，推荐。

总结

	Nacos	Eureka	Consul	Zookeeper
一致性协议	CP+AP	AP	AP	CP
健康检查	TCP/HTTP/MySQL/Client Beat	Client Beat	TCP/HTTP/gRPC/Cmd	keep alive
负载均衡	权重/metadata/Selector	Ribbon	Fabio	-
自动注销实例	支持	支持	不支持	支持
访问协议	HTTP/DNS	HTTP	HTTP/DNS	TCP
监听支持	支持	支持	支持	支持
多数据中心	支持	支持	支持	不支持
跨注册中心同步	支持	不支持	支持	不支持
SpringCloud集成	支持	支持	支持	不支持