服务注册eureka、zookeeper、nacos区别

服务注册表（Services Registry）

服务注册表是一个可用的服务实例的数据库。服务注册表提供了一个管理API和一个查询API。服务实例的注册和注销通过管理API实现，查询API用来寻找可用的服务实例。

服务注册表是一个分布式的kv数据库，因此存在CAP问题。根据CAP原则：分布式系统不能同时支持 C（一致性）、A（可用性）、P（分区容错性）需要根据自己的实际业务需求选择CAP的其中两个。

注册中心- Eureka

Eureka Server集群当中的每个节点都是通过Replicate(复制)来同步数据，没有主节点和从节点之分，所以节点都是平等且数据保持一致。节点之间通过一步方式进行同步数据，不保证强一致性，保证可用性所以是AP。

服务注册与发现的工作流程

1. 假设 Eureka Server 已经启动，Eureka Client（服务提供者）启动时把服务注册到 Eureka Server；
2. Eureka Client（服务提供者）每 30 秒（默认可配置）向 Eureka Sever 发 http 请求（即心跳），即服务续约；
3. Eureka Server90 秒没有收到向 Eureka Client（服务提供者）的心跳请求，则统计 15 分钟内是否存在 85% 的 Eureka Client（服务提供者）没有发心跳，如果是则进行自我保护状态（比如网络不稳定），如果不是则剔除该 Eureka Client（服务提供者）实例；
4. Eureka Client（服务消费者）定时调用 Eureka Server 接口获取服务列表更新本地缓存；
5. Eureka Client（服务消费者）远程调用服务时，先从本地缓存找，如果找到则直接发起服务调用，如果没有则到 Eureka Server 获取服务列表缓存到本地后再发起服务调用；
6. Eureka Client（服务提供者）应用关闭时会发 HTTP 请求到 Eureka Server，服务端接受请求后把该实例剔除。

流程图

 

 注册中心- Zookeeper

Zookeeper 支持 CP，当集群中如果有节点宕机则需要选举 leader(FastLeaderElection)，选举过程需要 30 至 120 秒，选举过程时集群不可用，牺牲时间来保证数据一致性。

注册与发现的工作流程

1. 假设 ZK 已经启动，服务提供者启动时把服务注册到 ZK 注册中心；
2. ZK 注册中心和服务提供者之间建立一个 Socket 长连接，ZK 注册中心定时向每个服务提供者发数据包，如果服务提供者没响应，则剔除该服务提供者实例，把更新后的服务列表发送给所有服务消费者（即通知）；
3. 服务消费者启动时到 ZK 注册中心获取一份服务列表缓存到本地供以后使用；
4. 服务消费者远程调用服务时，先从本地缓存找，如果找到则直接发起服务调用，如果没有则到 ZK 注册中心获取服务列表缓存到本地后再发起服务调用；
5. 当其中一个服务提供者宕机或正常关闭时，ZK 注册中心会把该节点剔除，并通知所有服务消费者更新本地缓存；
6. 当这个服务提供者正常启动后，ZK 注册中心也能感知到，并通知所有服务消费者更新本地缓存。

流程图

 

 

注册中心-nacos

Nacos从1.0版本选择Ap和CP混合形式实现注册中心，默认情况下采用Ap保证服务可用性，CP形式底层采用Raft协议保证数据的一致性问题。

注册与发现的工作流程

 

 

1. 假设 Nacos Server 已经启动，服务提供者启动时把服务注册到 Nacos 注册中心；
2. 服务提供者注册成功后，定时发 http 请求（即心跳）到注册中心，证明自身服务实例可用；
3. 如果注册中心长时间没有收到服务提供者的心跳请求，则剔除该实例；
4. 服务消费者发现服务支持两种方式，一种是主动请求注册中心获取服务列表（不推荐），一种是订阅注册中心的服务并提交一个 Listener，如果注册中心的服务有变更，由 Listener 来通知服务消费者更新本地服务列表；
5. 服务消费者获取服务相关信息进行远程调用。

流程图

 

 

总结：

Eureka 不能支撑大量服务实例，因为 Eureka 的每个节点数据都一致，会产生大量的心跳检查等等导致并发性能低下

ZooKeeper 的频繁上下线通知会导致性能下降

Nacos 可以支持大量服务实例又不丢性能，据说服务数量能达到 10 万以上。

 

 原文链接：https://zhuanlan.zhihu.com/p/367854163