核心功能

• 提供服务注册功能
  • 服务提供者在注册中心注册服务
    • 提供服务的地址、端口等信息
• 提供服务查询功能
  • 服务引用者可以在注册中心查询注册的服务
    • 获得服务的地址、端口等信息

注册中心

工作流程

1. 启动注册中心（Registry）
2. 服务提供者启动服务（RPC Server）并向注册中心发送注册信息以及定期的心跳（存活报告）等
3. 服务引用者（RPC Client）启动服务并向注册中心查询要引用的服务
4. 注册中心根据查询返回结果
5. 服务引用者缓存引用服务信息，并与该服务建立连接
6. 当服务提供者的服务发生变化时，注册中心会将变更信息同步到引用者，引用者处理变更

实现

注册中心 API

• 基本 API
  • 服务注册接口
    • 提供者：注册服务
  • 服务注销接口
    • 提供者：注销服务
  • 心跳汇报接口
    • 提供者：汇报存活状态
  • 服务订阅接口
    • 引用者：订阅服务，获得服务节点列表等
  • 服务变更查询接口
    • 引用者：查询服务最新状态
  • 服务查询接口
    • 管理者：查询注册中心提供的服务
  • 服务修改接口
    • 管理者：修改注册中心某些服务

集群部署

• 要求
  • 保证高可用（可采用分布式）
  • 保证各节点间的数据一致（分布式一致性协议）

目录存储

• 实现思想
  • 一般采用层次化目录结构
    • 有唯一路径标识
    • 支持多个版本

健康检查

• 作用
  • 对服务提供者的服务进行健康状态检查
  • 保证注册中心中的服务可用
• 实现思想
  • 长连接、会话超时控制机制
    • 服务端设置会话 ID、超时时间
    • 客户端向服务端发送 ping 消息，服务端刷新下次超时时间
    • 服务端在超时时间内没收到新 ping 则表示服务不健康，随机剔除该服务

状态变更通知

• 作用
  • 注册中心探测到服务提供者的服务有新加入或者被剔除，通知相关服务引用者
  • 避免引用者调用无效服务或者服务负载不均衡

白名单

• 作用
  • 提供注册中心权限控制，只有在注册中心白名单内的对象（IP、ID 等信息）才能访问注册中心的接口
  • 避免人工操作失误，在不允许的环境下（开发环境等）访问注册中心

落地

存储服务信息

• 分组
  • 核心与非核心
  • 机房
  • 环境（测试、正式）
• 服务名
• 节点信息
  • 节点地址及其它信息

Example：

节点注册

1. 查看注册节点是否在白名单内？不存在 -> 抛出异常；存在 -> 继续执行
2. 查看注册的服务接口名是否存在？不存在 -> 抛出异常；存在 -> 继续执行
3. 查看分组是否存在？不存在 -> 抛出异常；存在 -> 继续执行
4. 将节点信息添加到对应的分组、服务接口名下进行存储

节点反注册

1. 查看分组是否存在？不存在 -> 抛出异常；存在 -> 继续执行
2. 查看服务接口名是否存在？不存在 -> 抛出异常；存在 -> 继续执行
3. 删除分组和服务接口名下对应的存储信息
4. 更新节点信息（服务接口名的 sign 值）

订阅服务变更

1. 消费者获取服务信息时，即订阅了服务变化，并在本地保留服务接口名的 sign 值
2. 消费者每隔一段时间从注册中心获取最新 sign 值，如果不一致就从注册中心拉取最新信息，并更新到本地内存和本地快照中

查询节点信息（消费者）

1. 从本机内存中查找？不存在 -> 继续查询；存在 -> 返回结果
2. 从本机快照（为了防止消费者与注册中心网络异常，无法查找，所以需要快照）中查找？不存在 -> 抛出异常？继续查询？；存在 -> 返回结果

避坑指南

1. 多注册中心
   • 服务可能在不同的多个注册中心
2. 并行订阅服务
   • 串行订阅可能导致启动时间超长，且受异常服务的影响大
   • 并行订阅有效降低订阅消耗时长
3. 批量反注册服务
   • 注意“僵尸节点”问题
4. 服务变更信息增量更新
   • 有效减少在网络抖动频繁的场景下的带宽消耗

选型

实现类型

应用内注册与发现

• 原理
  • 注册中心提供服务端和客户端 SDK
  • 业务应用通过引用注册中心提供的 SDK，通过 SDK 实现服务的注册和发现
• 知名产品
  • Netflix、Eureka
• 使用场景
  • 同一技术体系内的服务

应用外注册与发现

• 原理
  • 不通过 SDK 与注册中心交互
  • 通过其它方式（Nginx 等）间接完成注册与发现
• 知名产品
  • Consul
• 使用场景
  • 不同技术体系的服务
  • 容器化的云应用

考虑因素

1. 高可用
   • 集群部署
   • 多 IDC 部署
2. 数据一致性
   • CP 型注册中心
     • Consul 等
   • AP 型注册中心
     • Eureka

选型分析

• 基于注册中心的主要功能是注册与发现的事实，一般更推荐 AP 型（并不一定就是 Eureka）
• 如果业务技术体系较复杂（多语言混合等）或者在云原生业务场景下，使用 Consul 可能是更好的选择