注册核心实现
- 注册核心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获取服务变更
- 白名单机制
- 用于避免上线时仍保留着开发的服务, 减少白名单, 只有白名单的服务能力调用