写点什么

注册中心如何选型?Eureka、Zookeeper、Nacos 怎么选

作者:EquatorCoco
  • 2025-01-08
    福建
  • 本文字数:2287 字

    阅读完需:约 8 分钟

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 的实例注册表中删除。下线请求不会自动完成,需手动调用:

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.注册中心比较



3.1 选型场景


Nacos


适用场景包括:


  • 微服务架构:微服务架构,尤其是需要动态服务发现和配置管理时,Nacos 是一个不错的选择。

  • 云原生应用:Nacos 提供了良好的 Kubernetes 支持,适合运行在云环境中的应用。

  • 弹性功能:如果系统需要负载均衡和服务治理功能,Nacos 提供强大的支持。


Eureka


  • Spring Cloud 生态系统:如果您的项目是基于 Spring Cloud 的,Eureka 是最常用的注册中心,集成非常简单。

  • AP 模式需要:适合对一致性要求不高的场景,可以承担部分服务不可用的风险。


Consul


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

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


Zookeeper


  • 适合对一致性要求非常高的场景,例如分布式协调、分布式锁等。

  • 复杂的分布式应用:在需要严格一致性系统中,如 Hadoop 和 Kafka,Zookeeper 是常见的选择。


文章转载自:卷福同学

原文链接:https://www.cnblogs.com/dnboy/p/18658749

体验地址:http://www.jnpfsoft.com/?from=001YH

用户头像

EquatorCoco

关注

还未添加个人签名 2023-06-19 加入

还未添加个人简介

评论

发布
暂无评论
注册中心如何选型?Eureka、Zookeeper、Nacos怎么选_云原生_EquatorCoco_InfoQ写作社区