文档

基本原理

更新时间:

SOFARegistry 即服务注册中心。下面详细介绍 SOFARegistry 的原理。

SOFARegistry 组成

SOFARegistry 即服务注册中心。其包含的 4 个组件及其职责为:

  • 客户端(Client):提供应用接入服务注册中心的基本 API 能力,可以是订阅方,也可以是发布方。

  • 会话服务器(SessionServer):主要是跟客户端建立连接,并作为一个中间层将发布数据转发至 DataServer 存储。

  • 数据服务器(DataServer):负责存储客户端发布的数据。支持多副本存储,保证高可用,并支持海量客户端。

  • 元数据服务器(MetaServer):主要维护集群的一致列表,保证高可用和一致性。

    说明

    引入这三个角色的目的为:

    • SessionServer 与 DataServer 的分离是为了同时突破连接数和存储的瓶颈。

    • 引入 MetaServer 是为了运维简单化。因为角色的多样化让服务注册中心有状态,使用 MetaServer 管理这些元数据,就无需引入第三方组件管理这些元数据,MetaServer 能够感知到 session 和 data 的状态,而无需 session 内部或者 data 内部自感知,让架构更加清晰。

SOFARegistry 架构图

SOFARegistry 架构图

SOFARegistry 交互图

交互图

单次服务注册过程

单次服务注册

单次服务注册的主要步骤为:

  1. Client 发布端向 SessionServer 发送待发布数据 dataPub。

  2. SessionServer 接收到 dataPub 数据后,进行下述操作:

    1. 首先写入内存:用于后续可以跟 DataServer 做定期检查。

    2. 然后将数据 dataPub 发送给 DataServer。

  3. DataServer 接收到 dataPub 数据后,进行下述操作:

    1. 将数据写入内存:DataServer 将从 SessionServer 收到的所有待发布数据汇总为 dataInfoId。

    2. 将数据同步给副本:DataServer 在一致性 hash 分片的基础上,对每个分片保存了多个副本(默认是 3 个副本)。

    3. 将数据变更事件通知给所有 SessionServer,事件内容是:

      • id:<dataInfoId>

      • 版本号信息:<version>

  4. SessionServer 接收到变更事件通知后,对比 SessionServer 内存中存储的 dataInfoId 的 version,发现比 DataServer 发过来的小,所以主动向 DataServer 获取 dataInfoId 中待发布的数据,即获取具体的 dataPub 列表。

  5. SessionServer 获取到 dataInfoId 中待发布的数据后,将数据推送给相应的 Client 订阅端,Client 订阅端就接收到这一次服务注册之后的最新待发布的 dataPub 列表数据。

单次服务订阅过程

单次服务订阅

单次服务订阅的主要步骤为:

  1. Client 订阅端向 SessionServer 发起订阅请求 subReq。subReq 主要包含 dataInfoId,表示需要订阅哪个 dataInfoId 的数据。

  2. SessionServer 接收到订阅请求 subReq 后,进行下述操作:

    1. 首先将订阅请求 subReq 写入内存:发送过来的 subReq 数据,SessionServer 都会存储到内存,用于实现数据变更推送的功能。

    2. 然后尝试从缓存里获取相应 dataInfoId 中的待发布数据。根据缓存中是否有此数据,做出下一步行动:

      • 若无,则向 DataServer 发起请求,获取相应数据。

      • 若有,则直接返回相应数据。

  3. SessionServer 从 DataServer 中获取到 dataInfoId 中的待发布数据。

  4. SessionServer 将获取到的数据发送给 Client 订阅端。