注册中央如何选型？Eureka、Zookeeper、Nacos怎么选

这是小卷对分布式系统架构学习的第9篇文章，第8篇时只回答了注册中央的工作原理的内容，面试官的第二个问题还没回答，今天再来讲讲各个注册中央的原理，以及区别，最后如何进行选型
  上一篇文章：如何计划一个注册中央？以Zookeeper为例
还是先讲讲各个中间件的区别，zookeeper已经讲过了，这里开始讲其他中间件的工作原理
1. Eureka工作原理

Eureka的官方文档：Netflix Eureka
不外只有对1.0版本的文档，2.0之后的没有了。
官方对Eureka的解释：一种基于 REST（表述性状态转移）的服务，重要用于 AWS 云中定位服务，以实现中间层服务器的负载均衡和故障转移。称为 Eureka 服务器。
Eureka解决的需求是：在AWS中，服务器常常上线/下线，因此AWS需要动态地注册/注销负载均衡器上的服务器，而Eureka就是如许作为中间层负载均衡器出现的。
1.1高可用架构

Eureka在多个机房部署的架构图如下，这也是它高可用的上风

解释阐明：

• 每个区域都部署一个 Eureka 集群，且该集群仅知道其区域内的实例，每个区域内至少有一个 Eureka 服务器，以处理区域故障；
  
• 服务向 Eureka 注册，然后每 30 秒发送一次心跳，以续租；假如客户端没有续租，90s后就会从注册中央剔除；
  
• 注册信息和续租信息会复制到集群中的所有Eureka节点；
  
• 恣意客户端可以每隔30s哀求一次获取注册信息，用于定位服务提供者，并发起长途调用
  

1.2 客户端-服务端间的通信

（1）注册Register
Eureka 客户端将运行实例的信息注册到 Eureka 服务器，注册在第一次心跳时发生（30 秒后）
（2）续约机制Renew
客户端每隔30 秒发送一次心跳来续租，关照 Eureka 服务器实例，当前客户端仍然处于存活状态。假如服务器在 90 秒内没有收到续租，它将把实例移出注册表；

• 续租方式是更新服务对象的最近续约时间，即lastUpdateTimestamp;
  

（3）获取注册表 Fetch Registry

• 客户端从服务器获取注册表信息并将其缓存到当地，之后客户端使用该信息表查找其他服务；
  
• 此信息会定期（每 30 秒）更新，通过获取上一个提取周期和当前周期之间的增量更新；
  
• 增量更新时，假如客户端通过比较注册表信息不匹配，则会哀求整个注册表信息全量更新
  

（4）下线Cancel
Eureka Client 在程序关闭时向 Eureka Server 发送取消哀求。 发送哀求后，该客户端实例信息将从 Eureka Server 的实例注册表中删除。下线哀求不会自动完成，需手动调用：

1. DiscoveryManager.getInstance().shutdownComponent()

复制代码

1.3自我保护机制

默认环境下，Eureka服务端在90s没有收到某个服务实例的心跳，就会注销该实例，将实例下线。假如出现大量实例心跳检测失败，Eureka就会以为是注册中央出现问题了，启动自我保护机制，不再剔除这些失败实例。触发条件阈值为：

• 注册表中高出15%的实例心跳检测失败
  

1.4 小结

• Eureka属于AP模型，即牺牲同等性，来换取高可用。在部门阶段失效时，系统仍然能正常运作。但是服务节点间的数据大概不同等
  
• Eureka 客户端具备良好的弹性本领，即使与所有 Eureka 服务端的毗连断开，它们依然能通过当地缓存机制正常工作
  
• 适合跨多机房，对注册中央可用性要求高的场景
  

2. Nacos工作原理

Nacos官方文档所在：Nacos架构 2.3版本，注册中央计划原理文档：Nacos注册中央

上面的图比较复杂，这里贴下其他人的关于注册中央这部门的架构图

整体流程也就是服务发现那套流程：

• 服务提供者轮询注册中央集群节点所在，把自己的协议所在注册到Nacos server
  
• 服务消费者需要从Nacos Server上去查询服务提供者的所在（根据服务名称）
  
• Nacos Server需要感知到服务提供者的上下线的变化
  
• 服务消费者需要动态感知到Nacos Server端服务所在的变化
  

Nacos采用了Pull和Push同时运作的方式来保证当地服务实例列表的动态感知。服务消费者通过定时任务的方式每10s Pull一次数据，Nacos Server在服务提供者出现变化时，基于UDP协议PUSH更新
2.1 数据模型

Zookeeper使用的是抽象的树形K-V组织结构，没有专门的数据模型。 Eureka 或者 Consul 都是做到了实例级别的数据扩展。Nacos使用的是服务-集群-实例的三层数据模型。

从上图的分级数据模型可以看到：

• 服务级别：保存了康健检查开关、元数据、路由机制、保护阈值等设置
  
• 集群保存了康健检查模式、元数据、同步机制等数据
  
• 实例保存了该实例的ip、端口、权重、康健检查状态、下线状态、元数据、响应时间。
  

2.2 数据同等性协议选择（CP or AP）

Nacos 由于要支持多种服务类型的注册，并能够具有机房容灾、集群扩展等必不可少的本领，是支持AP 和 CP 两种同等性协议的，默认是AP模式

• 假如注册Nacos的client节点注册时ephemeral=true，那么Nacos集群对这个client节点的效果就是AP，采用distro协议实现；
  
• 而注册Nacos的client节点注册时ephemeral=false，那么Nacos集群对这个节点的效果就是CP的，采用raft协议实现。
  

根据client注册时的属性，AP，CP同时混淆存在，只是对不同的client节点效果不同。

Distro 协议则是参考了内部 ConfigServer 和开源 Eureka ，在不借助第三方存储的环境下，实现基本大同小异。Distro 重点是做了一些逻辑的优化和性能的调优。
3.注册中央比较

对比项目NacosEurekaConsulZookeeper同等性协议支持AP和CP模式AP模式CP模式CP模式康健检查TCP/HTTP/MYSQL/Client BeatClient BeatTCP/HTTP/gRPC/CmdKeep Alive负载均衡策略权重/metadata/SelectorRibbonFabio-幂等保护有有无无自动注入实例支持支持不支持支持访问协议HTTP/DNSHTTPHTTP/DNSTCP监督支持支持支持支持支持多数据中央支持支持支持不支持跨注册中央同步支持支持不支持不支持SpringCloud集成支持不支持支持不支持Dubbo集成支持不支持不支持不支持k8s集成支持不支持不支持不支持 3.1选型场景

Nacos

适用场景包括：

• 微服务架构：微服务架构，尤其是需要动态服务发现和设置管理时，Nacos 是一个不错的选择。
  
• 云原生应用：Nacos 提供了良好的 Kubernetes 支持，适合运行在云环境中的应用。
  
• 弹性功能：假如系统需要负载均衡和服务管理功能，Nacos 提供强盛的支持。
  

Eureka

• Spring Cloud 生态系统：假如您的项目是基于 Spring Cloud 的，Eureka 是最常用的注册中央，集成非常简单。
  
• AP 模式需要：适合对同等性要求不高的场景，可以负担部门服务不可用的风险。
  

Consul

没写关于consul的工作原理，简单列下适用场景：

• 多数据中央：适合大型分布式系统，尤其是需要在多个数据中央之间提供服务发现和注册的场景。
  

Zookeeper

• 适合对同等性要求非常高的场景，例如分布式协调、分布式锁等。
  
• 复杂的分布式应用：在需要严酷同等性系统中，如 Hadoop 和 Kafka，Zookeeper 是常见的选择。
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。