[关闭]
@emac 2016-05-11T06:13:55.000000Z 字数 1991 阅读 3306

Frigate(高可靠的的分布式应用发布系统)

架构


1 稳定压倒一切

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

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

2 系统架构

2.1 系统组件

arch.png-28kB

2.2 系统拓扑(LB和应用层)

QQ20160405-2.png-10.8kB

3 分组发布模式(Group Mode)

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

QQ20160405-3.png-44.3kB

发布流程(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的应用运行状态,包括:

回滚流程(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 第二阶段:全量更新

QQ20160405-4.png-16.2kB

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

回滚流程(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 第三阶段:更新备用组

QQ20160405-5.png-14.8kB

全量更新后,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)

QQ20160405-6.png-38.5kB

发布流程(CI)


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

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

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

回滚流程(CI)

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

6 后续规划

添加新批注
在作者公开此批注前,只有你和作者可见。
回复批注