【Soul网关探秘】配置同步原理

引言

网关是流量请求的入口，在微服务架构中承担了非常重要的角色。在使用网关的过程中，为了满足业务诉求，经常需要变更配置，比如流控规则、路由规则等等。因此，网关动态配置是保障网关高可用的重要因素。

探究动态配置实现之前，我们需要先了解Soul的配置同步原理。
本篇内容整理自官方文档。

配置同步流程

翻阅官方文档，我们找到了如下所示数据同步流程图：

Soul网关在启动时，会从配置服务同步配置数据，并且支持 pull 和 push 两种模式获取配置变更信息，并且更新本地缓存。
网关持续运行期间，管理员在管理后台进行的用户、插件、规则、流量等配置变更信息，将通过 pull/push 模式同步到网关。

具体同步时，由配置决定采用 pull 模式 还是 push 模式。需要注意的是，网关和管理后台配置的同步模式应该约定一致。
这里的配置同步模块，可以看做一个简版的配置中心。

配置同步策略

在 1.x 版本中，配置服务强依赖 Zookeeper 实现，将变更信息 push 到网关。
而 2.x 版本开始，soul 开始支持 websocket、http 长轮询、zookeeper、nacos 四种配置同步策略。
这里，我们仅对 2.x 版本进行讨论。

我们可以通过配置 soul.sync.strategy 指定使用的同步策略，默认情况下将使用 http 长轮询同步策略，可以做到秒级数据同步。
需要注意：soul-admin 和 soul-web 必须使用相同的同步机制。

同样翻阅官方文档，我们找到了如下所示数据同步策略图：

注：nacos 是最新支持功能，官方文档暂未列入，但实际已经开始支持。关于 soul 的 nacos 同步策略，网上暂无相关资料说明，我将在后续篇幅里进行介绍。

处理流程说明：

• 用户进行配置变更后，soul-admin 通过 EventPublisher 发出配置变更通知
• 由 EventDispatcher 处理该变更通知，根据配置的同步策略(http、weboscket、zookeeper、nacos)，将配置发送给对应的事件处理器
• 再由对应的事件处理器负责将配置同步到 soul-web

同步策略说明：

• http 同步策略
  • soul-web 主动发起长轮询请求，默认 90s 超时时间
    • 若 soul-admin 没有数据发生变更，则阻塞 http 请求。超过 60s 仍无数据变更，则响应空数据
    • 若 soul-admin 有数据发生变更，则相应变更的数据信息
  • 网关层接到响应后，重新发起 http 请求，如此往复。
• websocket 同步策略
  • soul-admin 将变更后的数据主动推送给 soul-web，在网关层由对应的 WebSocketCacheHandler 处理器来处理。
• zookeeper 同步策略
  • soul-admin 将变更数据更新到 zookeeper，由网关层的 ZookeeperSyncCache 监听 zookeeper 的数据变更，并予以处理。
• nacos 同步策略
  • 暂无相关资料

配置同步原理

1、基于 zookeeper 的同步原理

基于 zookeeper 的同步依赖于 zookeeper 的 watch 机制。

• soul-admin 在启动时，将全量数据写入 zookeeper，后续数据发生变更时，会增量更新 zookeeper 节点。
• soul-web 监听配置的节点，一旦有配置节点发生变更，会更新本地缓存

2、基于 websocket 的同步原理

与 zookeeper 同步机制类似

• soul-web 与 soul-admin 建立好 websocket 连接时，soul-admin 将会推送一次全量数据
• 若后续配置数据发生变更，则 soul-admin将再次推送增量数据给 soul-web

注意：
使用 websocket 进行同步时，特别要注意断线重连，即保持心跳。

soul 使用 java-websocket 来进行 websocket 连接。

3、基于 http 长轮询的同步原理

soul 的 http 长轮询机制如下图所示：

• soul-web 发起长轮询请求，默认超时时间为 90s。

  意味着 soul-web 请求配置服务最多会等待 90s，以便与 soul-admin 配置服务及时响应变更数据，实现准实时同步。

• http 请求到达 soul-admin 之后，利用 Servlet3.0 的异步机制，异步响应数据。

  • 将长轮询请求任务 LongPollingClient 加入到 BlockingQueue 中，并且开启调度任务 60s 后执行。

    此番做法目的是 60s 后将该长轮询请求移除队列并响应，以通知 soul-web 此期间内无数据变更。

  • 若期间管理员变更了配置数据，此时逐个移除队列中的长轮询请求并响应数据，告知 soul-web 数据发生变更的 Group

• soul-web 收到 http 响应信息后

  • 若发现存在 Group 变更，则再次向 soul-admin 请求该 Group 的配置数据。

    由于 http 长轮询机制只能保证准实时，如果网关处理不及时或管理员频繁更新配置，可能导致 soul-web 错过某个配置变更的推送，安全起见，soul-admin 只告知 soul-web 哪个 Group 的信息发生变更。

  • 若未发现 Group 变更，则重新发起长轮询请求

总结

通过梳理官方文档，对 Soul 的配置同步流程、同步策略及同步原理有了基本的了解，后续将从源码中分析具体的同步实现。

个人知识库

高性能微服务API网关-Soul