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数量)，动态申请资源
上图集成弹性资源的技术架构图
- dashboard监控分片数量，也是transport登记数量，根据数量按一定策略申请/注销fetcher资源
- fetcher主节点监控fetcher实例，每次调度根据当前的fetcher分配分片
app/机器资料库
改造后每个dashboard的app/机器资料库是全量的，服务实例数多，性能和资源影响大，特别是dashboard上下线。
至此，sentinel dashboard分布式改造实现解释完成，后面继续sentinel原理源码分析
