20211224注册中心原理剖析
2022-01-12 11:07:45 0 举报AI智能生成
20211224注册中心原理剖析
作者其他创作
大纲/内容
什么是注册中心：用来实现微服务的自动注册与发现，是分布式系统中的核心基础服务
全局配置文件，多个业务系统更新不及时，不涉及自己时每个系统各自维护自己需要的配置，一旦变化同步不及时，导致各个系统容易出现问题。各个系统同步信息无法达到实时
服务提供方将自身路由信息发布到注册中心，供消费方获取用于与提供方建立连接并发起调用
定义
注册服务节点监听端口等路由信息
路由信息
序列化协议
路由规则
节点权重
服务信息
服务注册
服务消费方通过访问注册中心，获取服务提供方节点路由信息
服务消费方启动后，从注册中心拉取提供方节点列表，建立连接，进行rpc调用
启动拉取
接收注册中心变更通知，重新获取数据，更新节点列表
通知回调
服务消费方运行过程中定时拉取服务提供方节点列表，用来更新本地数据
轮询拉取
数据同步方式
服务发现
确保已经注册节点健康度，能够及时准确剔除失效节点，保证服务发现正确性
部署重启
服务假死
异常终止
失效原因
上报心跳
服务探测（ping、pong）
解决方案
健康检查
当服务提供方节点发生变更时，注册中心能够第一时间把变更事件或变更后的数据推送到服务订阅方
注册中心为每个服务提供方建立订阅列表，当服务节点变更时通知所有订阅该服务的消费节点
订阅与通知
变更通知
注册中心主要功能：
集群维度（订阅的一定是集群维度）
节点维度
数据组织
双向存储，服务消费端存储对应的服务提供方，服务提供方也存储服务都有哪写调用者列表
订阅数据组织
存储
遍历扫描
超时数组，每秒钟超时的数据放在对应的数组下标，循环使用数组，每秒钟有心跳过来就放入对应的数组下标中
动态分组
超时处理
注册中心设计
自带存储，保证数据一致性
逻辑+配套存储
注册中心实现思考
如何发送到指定节点
六度分离理论
周期性散播消息
随机选N个节点散播
散播不重复不回传
gossip协议
节点便变更通知
注册中心除了实现服务注册和发现，还可以实现服务治理相关功能
服务扩容、缩容
机器迁移
权重
灰度流量
注册中心的作用
注册中心的作用及设计分析
抛开应用，只从实现角度看注册中心就是订阅和存储
注册中心是什么
数据冗余存储，确保不会因为但节点故障导致数据丢失
数据可靠性
各个节点数据同步，保证数据一致
数据一致性
多节点对等的对外提供服务
服务可用性
存储系统主要关注点
cp---zookeeper（只有主节点可以写入）
ap----mysql主从读写
分布式系统中c（数据一致性）A（服务可用性）P（分区容错性）cp或者ap
cap定理
牺牲一致性继续提供服务
待恢复一致状态后提供服务
从业务场景出发
服务消费方：获取不同节点好过无法获取
服务提供方：部分节点提供服务好过全部不可用
ap提供服务
cp可以作为注册中心吗？可以的zookeeper
ap、cp选择
注册中心的本质与设计思考
数据模型
性能和容量
稳定性
易用性
集群扩展性
成熟度
社区活跃度
对比
开源注册中心选型
支持cp（配置中心），ap（注册中心）
临时节点使用心跳上报方式维持活性，5秒上报，15秒标记不健康30秒剔除
心跳注册
临时节点
tcp/http探测
持久化节点
服务注册与健康检查
instances
ip地址，端口，健康状态，ttl，权重
instance
cluster
service
数据存储
User/namespace/group/service
四层数据隔离
账号
命名空间指定集群
分组及服务名标识服务
数据隔离
Raft-cp一致性
客户端随机选择节点发送请求
服务端各个节点只负责部分数据
服务端处理数据写入，并异步广播通知
5秒一次心跳，同步数据
特性
集群剔除故障节点，重新分配数据
服务端节点宕机
客户端随机心跳，两集群均为全量数据
集群网络分区
异常
Distro AP一致性（nacos实现方式）
数据一致性保障
nacos功能分析
Nacos注册中心深入分析
sever节点组成的一个集群，在集群中存在一个唯一的leader节点负责相应写入请求，其他节点只负责接收转发client请求
leader相应请求，发起提案，超过半数follower同意写入，写入成功
fllower相应查询，将写入请求发给leader，参与选举和写入投票
observer相应查询，将写入请求发给leader，不参与投票，只接收写入结果
节点角色
获得法定数量票数（一半以上）
投票
epoch：leader任期
ZXID：zookeeper事务id，越大表示数据越新
SID;集群中每个节点的唯一编号
判断依据
任期大的胜出，任期相同比较ZXID大的胜出，ZXID相同比较SID大的胜出
比较策略
主节点宕机
节点进入looking状态
广播发起投票（一般投自己）
选出最大发起二次投票
多次投票多次对比，再发起投票
超过半数成为主节点
选举过程 https://www.processon.com/view/link/5f15009a07912906d9add32b
选主逻辑
顺序一致
leader负责写入请求
两阶段提交
zab协议（zookeeper atomic broadcast）
32位任期+32位事务计数器
zxid
创建出一个提案
提案放入待提交map，key为zxid
向所有follower发出提案
收到ack
判断提案是否已经提交
从待提交map中取出提案
记录ack
确保当前zxid之前没有待提交提案
统计ack数量是否过半
提案顺序异常打印
提案可提交，从待提交map中删除
通知follower提交提案
将提案发送给observer
写入数据
数据一致性过程
结构：DataNode parent；byte【】data 该节点存储数据Long acl 控制权限StatPersisted stat 持久化节点状态Set<String>children 子节点列表
zk中存储的最小单元
datanode
注册中心时数据如何存储
以树形结构存储了zookeeper中给所有的数据信息
datatree
负责管理zookeeper的数据，会话信息和事务日志
zkdatabase
树状存储（临时节点，永久节点）
顺序一致性，不保证读到最新数据
选举过程中不可用
服务注册：创建临时Node
服务发现：查询Node节点数据
健康检查：临时节点
信息订阅：Watch机制
注册中心
核心模块
Zookeeper实现深入分析
zookeeper是基于树形目录结构，节点分为四种类型，支持 变更推送，可以作为注册中心使用dubbo推荐使用
持久化顺序节点
临时顺序节点
节点类型
数据改变
被删除
子目录节点增加删除
通知机制
服务提供者在对应的的providers下写下自身的元数据信息（url）
注册
服务消费者订阅providers节点的变更事件
订阅
使用方式
/(root)dubbo/(service)com.***.**/(type)provider或者consumers/(url)ip:port
dubbo使用zookeeper时的数据结构
zookeeper基本功能
registry接口，abstractRegistry实现registry接口，failbackregistry类继承abstractregistry类，最终实现类有etcdregistry，redisregistry，zookeeper继承failbackregistry类
类之间的实现关系
获取注册中心实例
组装注册url
删除重试的注册任务
删除注销的任务
创建临时节点
递归创建节点，先创建永久节点，在逐层返回创建节点最终完成节点创建
有重试任务直接返回
添加failregistrytask任务
没有超过重试次数时进行继续重试，超过重试次数或返回
重试方法调用registry方法，移除任务
调用重试方法异常时，重新添加failregistrytask任务
失败时添加失败重试任务
调用failbackregistry的注册
向注册中心发起注册
注册过程
deletepath
取消注册
异常时继续添加取消注册任务
dubbo取消注册
notify-》refreshoverride（覆盖，刷新url对应关系）
先删除订阅
根据传入的url判断是否有关联订阅
没有关联订阅则创建关联订阅，并把订阅和指定的方法进行关联起来
添加监听
dosubscribe
添加订阅
添加失败则addfailedsubscribed
dorefer（订阅）还是操作failbackregistry
dubbo服务订阅
服务注册的应用
zookeeper注册中心
zookeeper注册中心应用
功能角度是微服务架构中核心服务
架构角度可以触达所有服务是一个核心枢纽
发布少量节点验证，降低对线上业务影响
降低权重
发布服务
观察业务
全量发布
步骤：
问题：节点很少如何处理？
灰度发布
动态权重
流量路由
当服务提供方异常不可用，或实际情况需要暂停掉某些业务，有损提供服务，可以通过注册中心下发熔断指令
熔断
列表页熔断用户中心调用
双十一大促是熔断退款，历史订单查询功能
场景
服务熔断降级
权重管理
动态权重过载保护
ab测试
服务治理
注册中心与服务治理
0 条评论
回复 删除
下一页
