20211224注册中心原理剖析思维导图模板_ProcessOn思维导图、流程图

注册中心的作用及设计分析

什么是注册中心： 用来实现微服务的自动注册与发现，是分布式系统中的核心基础服务

全局配置文件，多个业务系统更新不及时，不涉及自己时每个系统各自维护自己需要的配置， 一旦变化同步不及时，导致各个系统容易出现问题。 各个系统同步信息无法达到实时

注册中心主要功能：

服务注册

定义

服务提供方将自身路由信息发布到注册中心， 供消费方获取用于与提供方建立连接并发起调用

路由信息

注册服务节点 监听端口等路由信息

服务信息

序列化协议

路由规则

节点权重

服务发现

定义

服务消费方通过访问注册中心，获取服务提供方节点路由信息

数据同步方式

启动拉取

服务消费方启动后，从注册中心拉取提供方节点列表， 建立连接，进行rpc调用

通知回调

接收注册中心变更通知，重新获取数据，更新节点列表

轮询拉取

服务消费方运行过程中定时拉取服务提供方节点列表，用来更新本地数据

健康检查

定义

确保已经注册节点健康度，能够及时准确剔除失效节点， 保证服务发现正确性

失效原因

部署重启

服务假死

异常终止

解决方案

上报心跳

服务探测（ping、pong）

变更通知

定义

当服务提供方节点发生变更时， 注册中心能够第一时间把变更事件或变更后的数据推送到服务订阅方

订阅与通知

注册中心为每个服务提供方建立订阅列表， 当服务节点变更时通知所有订阅该服务的消费节点

注册中心设计

存储

数据组织

集群维度（订阅的一定是集群维度）

节点维度

订阅数据组织

双向存储，服务消费端存储对应的服务提供方， 服务提供方也存储服务都有哪写调用者列表

超时处理

遍历扫描

动态分组

超时数组，每秒钟超时的数据放在对应的数组下标， 循环使用数组，每秒钟有心跳过来就放入对应的数组下标中

注册中心实现思考

自带存储，保证数据一致性

逻辑+配套存储

节点便变更通知

如何发送到指定节点

gossip协议

六度分离理论

周期性散播消息

随机选N个节点散播

散播不重复不回传

注册中心的作用

注册中心除了实现服务注册和发现，还可以实现服务治理相关功能

服务扩容、缩容

机器迁移

权重

灰度流量

注册中心的本质与设计思考

注册中心是什么

抛开应用，只从实现角度看 注册中心就是订阅和存储

存储系统主要关注点

数据可靠性

数据冗余存储，确保不会因为但节点故障导致数据丢失

数据一致性

各个节点数据同步，保证数据一致

服务可用性

多节点对等的对外提供服务

cap定理

分布式系统中c（数据一致性） A（服务可用性） P（分区容错性） cp或者ap

cp---zookeeper（只有主节点可以写入）

ap----mysql主从读写

ap、cp选择

从业务场景出发

牺牲一致性继续提供服务

待恢复一致状态后提供服务

服务消费方：获取不同节点好过无法获取

服务提供方：部分节点提供服务好过全部不可用

ap提供服务

cp可以作为注册中心吗？可以的zookeeper

开源注册中心选型

数据模型

数据一致性

健康检查

性能和容量

稳定性

易用性

集群扩展性

成熟度

社区活跃度

对比

Nacos注册中心深入分析

支持cp（配置中心），ap（注册中心）

nacos功能分析

服务注册与健康检查

健康检查

临时节点

心跳注册

临时节点使用心跳上报方式维持活性，5秒上报，15秒标记不健康 30秒剔除

持久化节点

tcp/http探测

数据模型

数据存储

service

cluster

instances

instance

ip地址，端口，健康状态，ttl，权重

instance

cluster

数据隔离

四层数据隔离

User/namespace/group/service

账号

命名空间指定集群

分组及服务名标识服务

数据一致性保障

Raft-cp一致性

Distro AP一致性（nacos实现方式）

特性

客户端随机选择节点发送请求

服务端各个节点只负责部分数据

服务端处理数据写入，并异步广播通知

5秒一次心跳，同步数据

异常

服务端节点宕机

集群剔除故障节点，重新分配数据

集群网络分区

客户端随机心跳，两集群均为全量数据

Zookeeper实现深入分析

核心模块

选主逻辑

节点角色

sever节点组成的一个集群，在集群中存在一个唯一的leader节点负责相应写入请求，其他节点只负责接收转发client请求

leader相应请求，发起提案，超过半数follower同意写入，写入成功

fllower相应查询，将写入请求发给leader，参与选举和写入投票

observer相应查询，将写入请求发给leader，不参与投票，只接收写入结果

投票

获得法定数量票数（一半以上）

判断依据

epoch：leader任期

ZXID：zookeeper事务id，越大表示数据越新

SID;集群中每个节点的唯一编号

比较策略

任期大的胜出， 任期相同比较ZXID大的胜出， ZXID相同比较SID大的胜出

选举过程  https://www.processon.com/view/link/5f15009a07912906d9add32b

主节点宕机

节点进入looking状态

广播发起投票（一般投自己）

选出最大发起二次投票

多次投票多次对比，再发起投票

超过半数成为主节点

数据一致性保障

顺序一致

zab协议（zookeeper atomic broadcast）

leader负责写入请求

两阶段提交

zxid

32位任期+32位事务计数器

数据一致性过程

创建出一个提案

提案放入待提交map，key为zxid

向所有follower发出提案

收到ack

判断提案是否已经提交

从待提交map中取出提案

记录ack

确保当前zxid之前没有待提交提案

统计ack数量是否过半

提案顺序异常打印

提案可提交，从待提交map中删除

通知follower提交提案

将提案发送给observer

写入数据

数据模型

树状存储（临时节点，永久节点）

datanode

zk中存储的最小单元

结构： DataNode parent； byte【】data 该节点存储数据 Long acl 控制权限 StatPersisted stat 持久化节点状态 Set<String>children 子节点列表

datatree

以树形结构存储了zookeeper中给所有的数据信息

ConcurrentHashMap<String,DataNode> nodes WatchManager dataWatches 数据变更通知 WatchManager childWatches节点变更通知 String rootZookeeper 根节点 Map<Long,HashSet<String>>ephemerals 临时节点信息

注册中心时数据如何存储

nodes key：path，value DataNode ephemerals key：session value：path的集合（通过session找到路径） HashMap<String,HashSet<Watcher>>watchTable HashMap<Watcher,HashSet<String>>watch2Paths

zkdatabase

负责管理zookeeper的数据，会话信息和事务日志

DataTree datatree ConcurrentHashMap<Long,Integer>sessionWithTimeouts客户端会话连接管理 FileTxnSnapLog snapLog 事务日志

注册中心

服务注册：创建临时Node

顺序一致性，不保证读到最新数据

选举过程中不可用

服务发现：查询Node节点数据

顺序一致性，不保证读到最新数据

选举过程中不可用

健康检查：临时节点

信息订阅：Watch机制