基本原理

SOFARegistry 组成

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

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

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

• 数据服务器（DataServer）：负责存储客户端发布的数据。支持多副本存储，保证高可用，并支持海量客户端。

• 元数据服务器（MetaServer）：主要维护集群的一致列表，保证高可用和一致性。

  说明

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

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

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

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 订阅端。