微服务注册中心(2)

回顾

• 业务进行服务发现的真实业务场景是AP模型，因此注册中心本质上是AP模型

• 注册中心提供服务发现、服务注册、健康检查、服务元信息保存功能

主题

发现的服务一定健康吗？

• 异常场景分析

服务提供方 的心跳线程无法感知业务线程的健康状态，继续发送心跳保证自己在线

服务调用方 服务发现并watch，但是它得到了不健康的服务提供方 的信息

服务调用方 收到客户端 的请求一直向服务提供方 发送调用，但是一直失败或超时，导致服务调用方 不能正常给客户端正确响应

• 问题原因

单纯的靠zookeeper客户端的心跳无法保证服务的健康，选型或设计不是最完美

• 如何设计

• 如何选型

注册中心 本身具备主动服务健康检查能力，此时服务提供方 注册时提供健康检查地址(比如图中所示的Healthy)，注册中心 定期检查。zk本身不提供这种能力，此时应当选择其它具备这种能力的组件或是自研

注册中心故障了还能工作吗？

• 异常场景分析

机房3 的服务调用方 无法发现服务提供方，导致服务不可用

• 问题原因

注册中心本身的问题导致服务不可用，这是过度依赖注册中心所导致；

注册中心 单点写特性 导致服务不可注册

• 如何设计
  

改造注册中心 客户端，客户端增加缓存，服务发现和更新时缓存到本地，一旦注册中心 故障，直接从缓存读取服务列表。那么问题来了此时缓存的服务不健康怎么办，其实这超出了此时讨论范围，但是还有另外机制保证，比如断路器

• 如何选型

  技术选型上可以选择去中心化协议的组件作为注册中心，比如基于Gossip协议的组件
  

• 服务健康检查机制：确保服务真活，设计上客户端模拟调用方逻辑模拟检查；选型上选择提供主动健康检查功能的组件
• 弱依赖注册中心：注册中心本身的问题不能影响服务，设计上可以在注册中心客户端缓存服务列表，健康状况可由断路器等其它组件保证；技术选型上选择去中心化协议(比如Goosip协议)的组件
• 接入简单：提供http，rpc或多语言的客户端