共计 746 个字符，预计需要花费 2 分钟才能阅读完成。
注册核心实现
- 注册核心 api
- 服务注册接口: 实现服务的注册
- 服务登记接口: 实现服务的登记
- 心跳汇报: 服务端通过此接口汇报节点的存活状态
- 服务订阅: 消费者调用进行服务订阅, 获取可用的提供者节点列表
- 服务变更: 消费者调用此进行服务的变更, 获取新的节点
- 服务查问: 查问所有服务
- 服务批改: 批改服务中心的某些信息
- 集群部署 zookeeper 为例
- 每个 server 都存储全副数据, client 能够和任意一个 server 链接
- 启动时, 选举一个 leader(zookeeper 基于 paxox 算法, 大略就是所有节点向任意领队提交集体意见, 设置一个领队回复的准则, 例如最初一个提议的为准, n 个领队批准那个提议的多, 就把哪个提议作为决案)
- leader 负责数据更新等操作(通过 ZAB 协定保证数据的一致性)
- 目录存储 zookeeper 为例
- 每个目录在 zookeeper 中叫做 znode, 具备惟一的标识
- znode 能够蕴含 znode
- znode 下能够有多个版本, 查问时须要带上版本信息(有可能服务产生了变动, 新旧服务都在应用, 一种版本兼容的计划)
- 服务状态检测
注册核心要对服务的衰弱状态进行查看, 保障服务可用 \
以 zookeeper 为例, 其健康检查是通过长链接进行的, 在客户端和服务器建设连贯后, 建设会话, 生成 id, 而后在 timeout 周期内, 轮询, 重置 timeout, 如果产生了 timeout, 就阐明这个会话完结, 此节点不可用了, 就从注册核心删除 - 服务状态变更告诉
- 当新增或者删除一个服务的时候, 就立刻告诉订阅该服务的消费者, 刷新当地缓存的服务信息, 即为 zookeeper 的 watcher 机制, 消费者通过 getData 订阅服务, 通过 watcher 的 process 获取服务变更
- 白名单机制
- 用于避免上线时仍保留着开发的服务, 减少白名单, 只有白名单的服务能力调用
正文完