Frigate（高可靠的的分布式应用发布系统）

架构

1 稳定压倒一切

作为应用生命周期的最后一公里，发布系统的可靠性和健壮性直接影响着应用的服务质量。可靠性是指发布系统能否持续稳定的运行，不论上面同时运行着多少发布任务。而健壮性是指如果发布任务失败，应用的服务质量不受影响。

针对一个典型的分布式应用，Frigate总共支持三种发布模式，以满足不同场景下的发布需求：

• 分组发布模式(Group Mode)：适用于常规的兼容性版本（允许新老版本并存）发布
• 快速发布模式(Express Mode)：适用于Bug Fix发布
• 全量发布模式(Full Mode)：适用于非兼容性版本（不允许新老版本并存）发布

2 系统架构

2.1 系统组件

• CI: 负责应用打包上传，管理整个发布流程（包括出错回滚）。
• LB Plugin: 动态配置负载均衡。
• App Repository: 应用仓库，存储每次CI构建生成的程序包。
• App Agent: 负责下载，发布，启停，回滚应用。
• App Watcher: 实时检测应用运行状态。
• App Health Center: 维护应用运行状态数据。

2.2 系统拓扑（LB和应用层）

• Group-#: 根据特定策略（比如IP，用户ID等）将入口流量划分成若干流量组。
• Cluster-*: 将整个应用集群划分为若干应用组。每个流量组关联一个应用组，但一个应用组可以关联多个流量组。
• Standby-Cluster: 备用组，发布过程中始终运行在老版本，发布完成后再同步到新版本。

3 分组发布模式(Group Mode)

3.1 第一阶段：单应用组验证

发布流程（CI）

1. LB Plugin: 从LB摘下Cluster-A，挂上Standby-Cluster（原Cluster-A所关联的流量组改为关联Standby-Cluster）
2. App Agent: 从App Repository下载新版本的程序包，发布到Cluster-A并测活
3. LB Plugin: 从LB摘下Standby-Cluster，恢复Cluster-A

查看时序图

验证机制（App Watcher）

检测Cluster-A的应用运行状态，包括：

• 异常数
• WS连接数
• HTTP请求失败率
• 消息收发延迟

回滚流程（CI）

一旦App Watcher检测到任何异常，则触发版本回滚：

1. LB Plugin: 从LB摘下Cluster-A，挂上Standby-Cluster
2. 备份Cluster-A故障信息（日志，JVM dump），用于后续分析故障原因
3. App Agent: 从App Repository下载老版本的程序包，发布到Cluster-A并测活
4. LB Plugin: 从LB摘下Standby-Cluster，恢复Cluster-A

3.2 第二阶段：全量更新

类似第一阶段，依次更新除备份组之外的剩余应用组。

回滚流程（CI）

1. LB Plugin: 从LB摘下所有已更新至新版本的Cluster-X，挂上Standby-Cluster（原Cluster-X所关联的流量组改为关联Standby-Cluster）
2. 备份Cluster-A故障日志，用于后续分析故障原因
3. App Agent: 从App Repository下载老版本的程序包，发布到Cluster-X并测活
4. LB Plugin: 从LB摘下Standby-Cluster，恢复Cluster-X

3.3 第三阶段：更新备用组

全量更新后，App Watcher持续监测一段时间（不少于4小时），如果没有异常，再更新备用组，同时更新Git库打上发布标签。

回滚流程（CI）

由于已经没有运行在老版本的应用组或备用组，第三阶段的回滚策略是通过全量发布模式发布老版本来实现回滚。

4 快速发布模式(Express Mode)

与分组发布模式基本相同，除了第二阶段发布流程优化为：

1. LB Plugin: 从LB摘下除Cluster-A之外的所有应用组Cluster-Y，挂上Standby-Cluster（原Cluster-Y所关联的流量组改为关联Standby-Cluster）
2. App Agent: 从App Repository下载新版本的程序包，发布到Cluster-Y并测活
3. LB Plugin: 从LB摘下Standby-Cluster，恢复Cluster-Y

5 全量发布模式(Full Mode)

发布流程（CI）

1. LB Plugin: 重定向所有页面流量到维护页面，API流量到统一出错响应
2. App Agent: 停止所有应用组
3. App Agent: 从App Repository下载新版本的程序包，发布到所有应用组并测活
4. LB Plugin: 移除重定向配置
5. App Watcher: 检测新版本应用运行状态，一旦检测到任何异常，则触发版本回滚
   

   紧急情况下，此步骤可跳过

6. App Agent: 从App Repository下载新版本的程序包，发布到备用组并测活

全量发布一般涉及到非兼容性的数据迁移，通过人工方式回滚版本。

6 后续规划

• 通过独立应用管理发布流程