产品架构

SOFARegistry

SOFARegistry 即服务注册中心。主要包含 4 个组件：

• 客户端（Client）

• 会话服务器（SessionServer）

• 数据服务器（DataServer）

• 元数据服务器（MetaServer）

每个组件司职不同能力，组合后共同对外提供服务能力。

SOFARegistry 架构图

对SOFARegistry 的主要组件，说明如下，：

• Client：提供应用接入服务注册中心的基本 API 能力，应用系统依赖客户端 JAR 包，通过编程方式调用服务注册中心的服务订阅和服务发布能力。

• SessionServer：会话服务器，提供客户端接入能力，接受客户端的服务发布及服务订阅请求，并作为一个中间层将发布数据转发至 DataServer 存储。SessionServer 可无限扩展以支持海量客户端连接。

• DataServer：数据服务器，负责存储客户端发布数据，数据存储按照数据 ID 进行一致性 hash 分片存储，支持多副本备份，保证数据高可用。DataServer 可无限扩展以支持海量数据。

• MetaServer：元数据服务器，负责维护集群 SessionServer 和 DataServer 的一致列表，在节点变更时及时通知集群内其他节点。MetaServer 通过 SOFAJRaft 保证高可用和一致性。

SOFARPC

SOFARPC 项目结构图

SOFARPC 主要分为以下两部分：

• 核心功能：包括 core 和 core-impl 两部分，主要内容为 API 和一些扩展机制。

• 扩展及实现：即 extension-impl 部分。主要包含了不同的实现和扩展，比如对 HTTP、REST、 metrics 以及其他注册中心的集成和扩展，例如 bootstrap 中对协议的支持，remoting 中对网络传输的支持，registry 中对注册中心的支持等。

DRM

DRM 的具体配置值并不通过服务注册中心推送，它由两个组件组成，一个是 dsrconsole，一个是 drmdata。dsrconsole 负责实时推送时配置的持久化化，并同步给 drmdata。drmdata 则维护着与各个应用之间的注册链接，并在收到 dsrconsole 的推送通知时缓存配置并通知各个订阅应用来拉取配置。应用接收到该指令后，知道配置项发生了变更，向 drmdata 发起 HTTP 请求，读取真正的配置值。过程如下图所示。

DRM 的整套模型中，配置项的变更推送仅起到通知作用，推送的是版本号，真实的配置值是依靠客户端接收到推送后主动发起的 HTTP 拉取，为了提高读取性能，drmdata 采用缓存提升读取效率，请求透传到 Java Server，经过 Java Server 的内存缓存过滤一次，未命中请求才可能请求到 DB。

推送流程

DRM 完整的推送流程是：

1. 页面上，单击 推送 按钮。

2. dsrconsole 写最新的推送数据到 DB，DB 返回此 key 的最新版本号。

3. dsrconsole 通知推送消息到同机房的一台 drmdata 机器，消息内容包括：key、value、version。

4. drmdata 收到推送消息后，广播通知消息到所有的机房的 drmdata 机器。

5. 每台 drmdata 收到推送消息后，根据 key 查询所有 Client 建立的长连接信息，通过长连接发送给客户端 key 最新的版本号。

6. Client 收到推送消息后，拿着 drmdata 告知的最新版本号，随机调用同机房 drmdata 提供拉取配置的 HTTP 接口，拉取最新的配置。

Guardian

Guardian 主要用于服务限流。

Guardian 架构图

Guardian 运行原理主要分成 4 部分：

• 组件集成：业务程序首先要集成 Guardian。

• 规则推送：用户在 Guardian Console（控制台） 上编辑限流规则，并且把编辑好的规则推送到客端户，限流规则才会生效。

• 流量匹配：当有流量进入到业务程序，首先会被 Guardian 组件拦截到，Guardian 会判断当前流量是否和限流规则匹配。

• 限流生效：如果流量和限流规则匹配上，并且达到了预设的限流值，则限流。

服务熔断

服务熔断主要目的是当某个服务故障或者异常时，如果该服务触发熔断，可以防止其他调用方一直等待所导致的超时或者故障，从而防止雪崩。

服务熔断的架构图

架构图说明如下：

• Provider APP：指服务提供端，发布服务，并向注册中心注册。

• Consumer APP：指服务使用端，通过从注册中心拉取信息，来使用服务。

• 注册中心：即 SOFARegistry，是 SOFA 中间件的底层组件，用于存储所有服务提供方的地址信息以及所有服务消费方的订阅信息；它和服务消费方、服务提供方都建立长连接，动态感知服务发布地址变更并通知消费方。

服务熔断的主要原理分为下述 4 部分：

• 订阅配置：Provider APP 首先要订阅熔断配置。

• 配置生效：用户在微服务控制台编辑、推送熔断配置值，并通过 动态配置（DRM） 进行动态调整。配置推送后，Provider APP 所订阅的配置即开始生效。

• 熔断触发：Consumer APP：通过 RPC 调用服务后，在规定时间内容，如果错误数大于阈值，会触发服务端熔断配置。

• 熔断自动恢复：当触发熔断后，RPC 会在一个时间窗口内快速失败，过了这个时间窗口后，系统会允许通过一个请求，去尝试探测服务是否恢复。如果恢复，则自动关闭熔断；如果没有恢复，则继续熔断，并等待下一个时间窗口。

服务降级

服务降级的主要目的是当服务器压力剧增的情况下，根据实际业务情况及流量，对某些不重要的服务，不处理或换种简单的方式处理，从而释放服务器资源以保证核心业务正常运作或高效运作。

服务降级的架构图

架构图说明如下：

• Consumer APP：指服务使用端，通过从注册中心拉取信息，来使用服务。

• 注册中心：即 SOFARegistry，是 SOFA 中间件的底层组件，用于存储所有服务提供方的地址信息以及所有服务消费方的订阅信息；它和服务消费方、服务提供方都建立长连接，动态感知服务发布地址变更并通知消费方。

服务降级的主要原理分为下述 3 部分：

• 订阅配置：Consumer APP 首先要订阅降级配置。

• 配置生效：用户在微服务控制台编辑、推送降级置值，并通过 动态配置（DRM） 进行动态调整。配置推送后，Consumer APP 所订阅的配置即开始生效。

• 降级触发：当 Consumer App 触发服务降级后，Consumer APP 将无法使用服务，而且表现为快速失败。此时，需要业务方主动处理降级所带来的影响。