怎么提高网站收录,WordPress用户聊天功能,网站内链接怎么做,唐山房产网站建设这是小卷对分布式系统架构学习的第9篇文章#xff0c;第8篇时只回答了注册中心的工作原理的内容#xff0c;面试官的第二个问题还没回答#xff0c;今天再来讲讲各个注册中心的原理#xff0c;以及区别#xff0c;最后如何进行选型 上一篇文章#xff1a;如何设计一个注册… 这是小卷对分布式系统架构学习的第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 的实例注册表中删除。下线请求不会自动完成需手动调用
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节点注册时ephemeraltrue那么Nacos集群对这个client节点的效果就是AP采用distro协议实现而注册Nacos的client节点注册时ephemeralfalse那么Nacos集群对这个节点的效果就是CP的采用raft协议实现。
根据client注册时的属性APCP同时混合存在只是对不同的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 和 KafkaZookeeper 是常见的选择。
