discovery
discovery负责维护app/机器资料库,transport健康检测, transport上下线处理。discovery关键是分布式存储,后续研究一下raft,其复制,状态机,快照技术,但个人觉得,discovery功能只是作为目录,提供app/resource,支持搜索和规则更改,不需要太严谨和高效的技术保障。
上图discovery涉及的znode,discovery监听transport的实例(item)的上下线,维护app/机器,删除对应分片。
app/机器资料库
discovery负责构建app/机器资料库和健康检查,用于查询metrics,规则发布,原discovery组件通过心跳登记app/机器实例,更新lastHeartbeatTime, 检查lastHeartbeatTime判断机器是否监控。改造后,心跳实现基于zookeeper的watcher方式,通过监控znode获得上下线通知, 增加或移除machine。
上图基于zookeeper的discovery实现
上图zookeeper discovery初始化
- refreshAppAndMachine
刷新app/ 机器资料,读取/transport/instances 的子节点,获取node data ,data 是MachineInfo序列号,反序列化获得MachineInfo对象,更新AppManagement
- UpAndDownTransportListenerManager
监听管理器负责设置和启动监听器,包括zookeeper连接状态监听,tranport上线和下线3个监听器
transport上线下线
transport实例下线或撤下,相应的机器和分片需要增加或删除
transport上线
transport上线,增加机器对象
transport下线
transport下线,做两件事,移除机器对象,删除对应的分片
删除对应分片,首先成为主节点,主节点负责删除
选主涉及到上图两个节点
|----------------------------------------------------------------------------|----------------------------------------------------------------------------|
| | |
选主使用latch znode,选为主节点,写入自身的实例id到instance znode,即ip:port,选主服务凭此判断是否自身节点选上(实例Id相同),选主是否已完成
Zookeeper重连
Zookeeper连接断开重连后,需要对app/机器资料库校对,实际调用refreshAppAndMachine
NEXT
弹性资源
目前版本分布式调度资源预先启动worker,需要对服务数量评估,启动相适应worker实例数,下一版本集成弹性资源组件,根据服务数(实际是transport数量),动态申请资源
上图集成弹性资源的技术架构图
- dashboard监控分片数量,也是transport登记数量,根据数量按一定策略申请/注销fetcher资源
- fetcher主节点监控fetcher实例,每次调度根据当前的fetcher分配分片
app/机器资料库
改造后每个dashboard的app/机器资料库是全量的,服务实例数多,性能和资源影响大,特别是dashboard上下线。
至此,sentinel dashboard分布式改造实现解释完成,后面继续sentinel原理源码分析