sentinel dashboard分布式改造落地设计&实现解释(二)-分布式discovery组件

Python资料网推荐sentinel dashboard分布式改造落地设计&实现解释(二)-分布式discovery组件这篇文章给大家，欢迎收藏Python资料网享受知识的乐趣

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，选为主节点，写入自身的实例id到instance znode，即ip:port，选主服务凭此判断是否自身节点选上(实例Id相同)，选主是否已完成

Zookeeper重连

Zookeeper连接断开重连后，需要对app/机器资料库校对，实际调用refreshAppAndMachine

NEXT

弹性资源

目前版本分布式调度资源预先启动worker，需要对服务数量评估，启动相适应worker实例数，下一版本集成弹性资源组件，根据服务数(实际是transport数量)，动态申请资源

上图集成弹性资源的技术架构图

1. dashboard监控分片数量，也是transport登记数量，根据数量按一定策略申请/注销fetcher资源
2. fetcher主节点监控fetcher实例，每次调度根据当前的fetcher分配分片

 app/机器资料库

改造后每个dashboard的app/机器资料库是全量的，服务实例数多，性能和资源影响大，特别是dashboard上下线。

至此，sentinel dashboard分布式改造实现解释完成，后面继续sentinel原理源码分析

版权声明：本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若内容造成侵权/违法违规/事实不符，请联系邮箱：jacktools123@163.com进行投诉反馈，一经查实，立即删除！