- 注册中心api
- 服务注册接口: 提供者调用此完成服务的注册
- 服务注销接口: 提供者调用此完成服务的注销
- 心跳汇报: 提供者通过此接口汇报节点的存活状态
- 服务订阅: 消费者调用进行服务订阅, 获取可用的提供者节点列表(如果为分布式的, 同一个服务存在多个节点中, 基于负载均衡的算法选择一个server发起调用)
- 服务变更: 消费者调用此进行服务的变更, 获取新的节点提供者
- 服务查询: 查询所有服务
- 服务修改: 修改服务中心的某些信息
- 集群部署 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获取服务变更
- 白名单机制
- 用于防止上线时仍保留着开发的服务, 增加白名单, 只有白名单的服务才能调用
网友评论