发布模式
重建部署
版本A下线后版本B上线
重建策略是一个冗余的方式，它包含下线版本A，然后部署版本B; 服务的停机时间依赖于应用下线和启动耗时
优点：便于设置, 应用状态完整更新 缺点：对用户影响很大，预期的宕机时间取决于下线时间和应用启动耗时
滚动部署
又称 滚动更新或者增量发布
例如服务池有10个实例,
- 先增加2个新版本实例,
- 接收流量并且健康检查通过后；
- 下线旧版本 2 个实例；
- 循环上述过程直到全部更新。
相关参数
- 并行数，最大批量执行数：同时发布新实例的数目；
- 最大峰值：考虑到新增的实例数，即最大新旧副本数；
- 最大不可用数：在滚动更新过程中不可用的实例数；
- 最小可用数: 最少N个副本需要是正常的，才能进行下一轮次发布；
优点：
- 便于设置
- 版本在实例间缓慢发布
- 对于能够处理数据重平衡的有状态应用非常方便
缺点：
- 发布/回滚耗时
- 支持多个API很困难, 即 API 兼容性保障难
- 无法控制流量
蓝绿/部署
又名 红/黑
两种模式
- 日常情况下，环境由2个副本池运行，蓝绿各承担50%流量，蓝绿之间不存在互相调用；
- 日常只有1个区域, 旧区域下线时直接删除，新区域上线前创建。
发布过程
- 先将某一区的流量比例调整为0%
- 更新此区域的副本
- 调整新区的分流比例从 1%至5%进行验证，如果正常则提升至100% (旧区域减至0)；
- 验证完全正常后，升级旧区域的应用版本；
- 最后流量再调整回各50%
如果升级失败则切换回旧副本。
优点：
- 可以提前内部或小范围验证新环境, 实时发布、回滚,
- 避免版本冲突问题，整个应用状态统一一次切换
- 有一个单元总是可用的，回滚快速；
缺点：
- 资源翻倍
- 在发布版本到生产环境之前，整个平台的主流程测试必须执行
- 处理有状态的应用很棘手
金丝雀部署
新版本向一小部分用户发布，验证后再完全放开。
通常流量是按比例分配的; 例如90%的请求流向版本A，10%的流向版本B；
用于缺少足够测试，或者缺少可靠测试，或者对新版本的稳定性缺乏信心的情况下。
优点：
- 版本面向一部分用户发布
- 方便错误评估和性能监控
- 快速回滚
缺点：
- 发布缓慢
A/B部署
与 金丝雀部署 模式类型，差别是 只将 符合特定条件的流量给到新版本。
用于测试特定功能的切换，并发布使用占大部分的版本
例如
- 根据用户uid
- 地理位置
- 设备类型, 语言等
优点：
- 多个版本并行运行;
- 方便提前获得客户反馈，减少致命的影响和低级的错误;
- 完全控制流量分布;
缺点：
- 需要智能负载均衡网关和更高的自动化发布程度。
- 对于给定的会话，很难定位问题，分布式跟踪是必须的
影子部署
即流量镜像模式
新版本B接受真实的业务流量请求，但是不产生响应； 例如大部分的查询类业务操作, 如果有写操作需要mork；
配置非常复杂，而且需要特殊条件，尤其是分出请求
优点：
- 可以使用生产环境流量进行性能测试
- 对用户无影响
- 直到应用的稳定性和性能满足需求后才发布
缺点：
- 双倍资源，成本昂贵
- 配置复杂
- 对于需要变更数据的业务操作要么关闭，要么定制操作；
- 不是真实用户测试，可能出现误导
最后更新于