[JD] 三、注册中心原理分析

[JD] 三、注册中心原理分析

一、注册中心的作用与设计分析
二、开源注册中心选型
三、Nacos注册中心分析
四、ZK实现与ZK注册中心分析
五、注册中心与服务治理

一、注册中心的作用
1.注册中心是用来实现为服务实例的自动注册与发现，是分布式系统中的核心基础服务。
2.注册中心的主要功能：服务注册、服务发现、健康检查、变更通知。

· 服务注册：服务提供方将自身路由信息发布到注册中心，供消费方获取，用于与提供方建立连接并发起调用。
   路由信息包括注册服务节点ip、监听端口等
   服务信息包括：序列化协议、路由规则、节点权重
· 服务发现：服务消费方通过注册中心获取服务提供方节点路由信息。
   > 启动拉取：服务消费方启动后，从注册中心拉取提供方节点列表，建立连接，进行rpc调用
   > 通知回调：接受注册中心变更通知，重新获取数据，更新节点列表
   > 轮询拉取：服务消费方运行过程中，定时拉取服务提供方节点列表，用来更新本地数据
· 健康检查：确保已注册节点健康度，能够及时准确剔除失效节点，保证服务发现正确性。
   > 节点失效原因：部署重启、服务假死、异常终止
   > 健康检查解决方案：上报心跳、服务探测
· 变更通知：提供方节点发生变更时，注册中心应该能够第一时间把变更事件或变更后的数据推送到服务订阅方。
   > 注册中心内，为每个服务提供方建立订阅列表。当服务方节点变更时通知所有订阅该服务的消费方节点
3.注册中心设计分析
   注册中心设计主要考虑数据存储、超时处理、节点变更通知。
   > 数据存储：要保证数据可靠性，数据一致性，服务可用性。可靠性通过数据冗余存储，保证不会因单个节点故障导致数据丢失。各节点间数据同步共同保证数据一致。多节点对等的对外提供服务，保障服务可用。同CAP定理的角度出发，作为注册中心的使用场景AP模型更合适。
   > 节点变更通知：节点变更通知可以采用gossip协议。gossip协议特点：六度分离理论、周期性散播消息、随机选择n个节点散播、散播不重复不回传。
4.注册中心的作用除了实现服务注册与发现，还可以用来实现服务治理相关功能。比如，服务扩容缩容、机器迁移、权重、灰度流量

二、开源注册中心选型
1.注册中心选型维度：数据模型、数据一致性、健康检查、性能与容量、稳定性、易用性、集群扩展能力、成熟度、社区活跃程度。
2.注册中心选型对比

三、Nacos注册中心分析
   服务注册与健康检查：对于临时节点，心跳注册；持久化节点使用tcp或者http探测。5秒上报，15秒标记为不健康，30秒剔除。
   数据模型：主要包括数据存储和数据隔离。数据隔离做了四层数据隔离，分别是账号、命名空间、集群分组及服务名称标识。
   数据一致性：通过Raft CP一致性和Distro AP一致性保证。

四、ZK实现与ZK注册中心分析
1.Zookeeper的 Server节点组成一个集群，在集群中存在的唯一的leader节点负责响应写入请求，其他节点只负责接收，转发client请求。
   Leader：响应写入请求，发起提案，超过半数follower同意写入，写入成功。
   Follower：响应查询，将写入请求发给leader，参与选举和写入投票。
   Observer：响应查询，将写入请求发送给leader，不参与投票，直接接收写入结果。
2.选主逻辑
2.1 选择机制中的概念
   Serverid：服务器ID，比如有三台服务器，编号分别是1,2,3。编号越大在选择算法中的权重越大。
   Zxid：数据ID，服务器中存放的最大数据ID。值越大说明数据越新，在选举算法中数据越新权重越大。
   Epoch：逻辑时钟，或者叫投票的次数，同一轮投票过程中的逻辑时钟值是相同的。每投完一次票这个数据就会增加，然后与接收到的其它服务器返回的投票信息中的数值相比，根据不同的值做出不同的判断。
   Server状态：选举状态
       LOOKING，竞选状态。
       FOLLOWING，随从状态，同步leader状态，参与投票。
       OBSERVING，观察状态,同步leader状态，不参与投票。
       LEADING，领导者状态。
2.2 选举流程

2.3 选举流程详述
   > 首先开始选举阶段，每个Server读取自身的zxid。
   > 发送投票信息
   · 首先，每个Server第一轮都会投票给自己。
   · 投票信息包含：所选举leader的Serverid，Zxid，Epoch。Epoch会随着选举轮数的增加而递增。
   > 接收投票信息
   · 如果服务器B接收到服务器A的数据（服务器A处于选举状态(LOOKING 状态)
       1）首先，判断逻辑时钟值：
           a）如果发送过来的逻辑时钟Epoch大于目前的逻辑时钟，先更新本逻辑时钟Epoch，同时清空本轮逻辑时钟收集到的来自其他server的选举数据。再判断是否需要更新当前自己的选举leader Serverid，保存的zxid最大值和leader Serverid来进行判断的。先看数据zxid，数据zxid大者胜出；其次再判断leader Serverid，leader Serverid大者胜出；然后再将自身最新的选举结果(也就是上面提到的三种数据（leader Serverid，Zxid，Epoch）广播给其他server)
           b）如果发送过来的逻辑时钟Epoch小于目前的逻辑时钟，说明对方server在一个相对较早的Epoch中，这里只需要将本机的三种数据（leader Serverid，Zxid，Epoch）发送过去就行。
           c）如果发送过来的逻辑时钟Epoch等于目前的逻辑时钟。再根据上述判断规则来选举leader ，然后再将自身最新的选举结果(也就是上面提到的三种数据（leader Serverid，Zxid，Epoch）广播给其他server)。
       2）其次，判断服务器是不是已经收集到了所有服务器的选举状态：若是，根据选举结果设置自己的角色(FOLLOWER还是LEADER)，退出选举过程就是了。
       3）最后，若没有收到没有收集到所有服务器的选举状态：也可以判断一下根据以上过程之后最新的选举leader是不是得到了超过半数以上服务器的支持，如果是，那么尝试在200ms内接收一下数据，如果没有新的数据到来，说明大家都已经默认了这个结果，同样也设置角色退出选举过程。
   · 如果所接收服务器A处在其它状态（FOLLOWING或者LEADING）。
       1）逻辑时钟Epoch等于目前的逻辑时钟，将该数据保存到recvset。此时Server已经处于LEADING状态，说明此时这个server已经投票选出结果。若此时这个接收服务器宣称自己是leader，那么将判断是不是有半数以上的服务器选举它，如果是则设置选举状态退出选举过程。
       2）否则这是一条与当前逻辑时钟不符合的消息，那么说明在另一个选举过程中已经有了选举结果，于是将该选举结果加入到out of election集合中，再根据out of election来判断是否可以结束选举，如果可以也是保存逻辑时钟，设置选举状态，退出选举过程。
2.4 比较策略：任期大的胜出，任期相同比较zxid大的胜出，zxid相同比较server_id(SID)大的胜出
3.zookeeper数据一致性保障
   通过Zab协议保证数据一致性。Zab 协议包括两种基本的模式：崩溃恢复和消息广播
   协议过程：
       当整个集群启动过程中，或者当 Leader 服务器出现网络中弄断、崩溃退出或重启等异常时，Zab协议就会进入崩溃恢复模式，选举产生新的Leader。
       当选举产生了新的 Leader，同时集群中有过半的机器与该 Leader 服务器完成了状态同步（即数据同步）之后，Zab协议就会退出崩溃恢复模式，进入消息广播模式。
       这时，如果有一台遵守Zab协议的服务器加入集群，因为此时集群中已经存在一个Leader服务器在广播消息，那么该新加入的服务器自动进入恢复模式：找到Leader服务器，并且完成数据同步。同步完成后，作为新的Follower一起参与到消息广播流程中。
   协议状态切换：
       当Leader出现崩溃退出或者机器重启，亦或是集群中不存在超过半数的服务器与Leader保存正常通信，Zab就会再一次进入崩溃恢复，发起新一轮Leader选举并实现数据同步。同步完成后又会进入消息广播模式，接收事务请求。
   在整个消息广播中，Leader会将每一个事务请求转换成对应的 proposal 来进行广播，并且在广播事务Proposal 之前，Leader服务器会首先为这个事务Proposal分配一个全局单递增的唯一ID，称之为事务ID（即zxid），由于Zab协议需要保证每一个消息的严格的顺序关系，因此必须将每一个proposal按照其zxid的先后顺序进行排序和处理。
4.zookeeper数据存储
   zookeeper数据存储为树状结构传输数据，分为永久节点和临时节点
   DataNode：zookeeper数据存储最小单元，是持久化数据节点描述的最小单位。包括的属性有：父节点的引用、该节点存储的数据、acl控制权限、持久化节点状态、子节点列表。
   DataTree：以树形结构存储了所有的数据信息。包括的属性：节点信息、节点路径信息、节点变更通知、数据变更通知。
   ZKDataBase：负责管理Zookeeper的数据、会话信息和事务日志。
5.zookeeper注册中心分析
   · zookeeper节点类型有：持久化节点、持久化顺序节点、临时节点，临时顺序节点。
   · 通知机制有：数据改变、被删除、子目录增加或者删除节点

五、注册中心与服务治理
1.注册中心除了实现服务注册与发现，从系统架构角度，基于注册中心在微服务架构中所处的位置，还可以有的扩展功能：动态权重、流量路由、服务熔断降级、权限管理、动态过载保护、Ab测试
2.注册中心扩展之灰度上线功能
灰度上线步骤：降低权重、发布服务、观察业务，最后全量发布。
3.注册中心扩展之服务熔断
当服务提供方异常不可用，或者实际情况需要暂停掉某些业务，有损提供服务，可以通过注册中心下发熔断指令。

[JD] 三、注册中心原理分析相关推荐

注册中心—注册中心原理
在微服务架构中,注册中心是最核心的基础服务之一,本文将详细介绍下注册中心的组成部分和它们之前的关系. 目录一.注册中心原理二.注册中心功能三.常见的注册中心一.注册中心原理注册中心主要涉及到 ...
【计算机视觉】数字图像处理（三）—— 图像变换原理分析
数字图像处理(三)-- 图像变换原理分析一.图像变换的目的与用途 1. 图像变换的目的 2. 图像正交变换的要求正交变换的应用 (一).傅里叶变换 1.傅里叶变换的理论基础与基本定义 2.连续函数 ...
SpringCloud--Eureka 注册中心原理及其搭建
一. Eureka简介 Eureka是Netflix开发的服务发现框架,本身是一个基于REST的服务,主要用于定位运行在AWS域中的中间层服务,以达到负载均衡和中间层服务故障转移的目的.SpringC ...
zookeeper使用及模拟注册中心原理
什么是Zookeeper Zookeeper是一个分布式开源框架,提供了协调分布式应用的基本服务,它向外部应用暴露一组通用服务--分布式同步(Distributed Synchronization). ...
2021SC@SDUSC-PALISADE（三）BGV原理分析与python实现
2021SC@SDUSC 目录 BGV原理分析 1 符号说明 2 多项式运算 3 Learning With Error 与 Ring Learning With Error 4 构建一个全同态体系 ...
c++界面开发_QT开发（三）——GUI原理分析
一.命令行程序命令行程序是面向过程的程序设计. 命令行程序的特点: A.基于顺序结构执行 B.程序执行过程中不需与用户交互 C.程序执行结束给出最终运行结果命令行程序适用场合: A.单任务场合 B ...
注册中心—常见注册中心组件对比分析
原文作者:知了V笑原文地址:微服务技术栈:常见注册中心组件,对比分析关于注册中心原理,请先阅读微服务注册中心原理目录一.Zookeeper组件二.Eureka组件三.Consul组件四. ...
eureka 之前的服务如何关闭_干货分享 | 服务注册中心Spring Cloud Eureka部分源码分析...
友情提示:全文13000多文字,预计阅读时间10-15分钟 Spring Cloud Eureka作为常用的服务注册中心,我们有必要去了解其内在实现机制,这样出现问题的时候我们可以快速去定位问题.当我 ...
java基础巩固-宇宙第一AiYWM：为了维持生计，架构知识+分布式微服务+高并发高可用高性能知识序幕就此拉开（三：注册中心、补充CAP定理、BASE 理论）~整起
架构知识+分布式微服务+高并发高可用高性能知识序幕就此拉开(一:总览篇) 网关开了个头你请求来了,我网关把你拦截住,验明正身,加以控制,协助你调用服务,完成请求的调用.但是这个过程中,为了解耦和或者 ...

[JD] 三、注册中心原理分析

[JD] 三、注册中心原理分析相关推荐

最新文章

热门文章