蓝绿色和金丝雀发行

（部分： 体系结构和协议）

1）为什么需要"安全推出"

在现代系统中，发布不仅是代码交付，而且是销售中的托管实验：我们同时将风险降至最低（不破坏用户），并缩短反馈时间（快速看到效果）。Blue-Green和Canary这两个经典策略以不同的方式解决了这个问题，但其共同目标是：零下移，快速回滚，SLO可观察性。

2）基本定义

Blue-Green

我们拥有两个完整的prod环境副本：主动（蓝色）服务于流量，被动（绿色）准备新版本。切换-平衡器/路由器级别的原子（switch/flip）。如果情况变得更糟-立即回到蓝色。

Canary

我们分批推出：首先，很小比例的流量（例如1-5％），观察指标/SLO，然后逐步增加份额（10％→ 25％→ 50％→ 100％）。退化-在上一个稳定步骤中回滚或停止。

3）哪种方法更好

• 我们需要一个没有复杂操作的即时回滚。
• 体系结构/预算允许双重基础架构重复。
• 我们希望孤立地进行大规模迁移或平台更新（OS/JDK/rantime）。
• 附录/连接池对渐进"混合"状态敏感。

• 您需要最小化blast radius并查看用户份额上的行为。
• 高发行频率，逐步交付为常态。
• 有成熟的可观察性和自动门（error budget，latency，conversion）。
• 产品团队希望验证假设：对转换，保留，LTV等的影响。

4）成功发布的一般原则

相同的广告牌文物：相同的影像/封装在所有阶段。
确定性配置：作为代码的config，环境的可比性。
设计可观察性：标志，度量，轨迹，变量；SLI/SLO提前。
快速、可自动回滚：按钮/回滚命令是管线的一部分,不是手动魔法。
可互操作的电路更改：expand-migrate-contract策略（参见第10节）。
L7级路由（最好）：在标题/cookie/路径/API版本上具有灵活性。

5） Blue-Green： 架构和流程

5.1个拓扑

两个程序堆栈：Blue（主动）和Green（候选人）。
常见的外部依赖关系：CDN，外部API，队列；DB是一种特殊情况（请参见第10条）。
切换点：平衡器/Ingress/Gateway。

5.2阶梯式洪水

1.在新的人工制品（vNext）下举起Green，进行工作服测试。
2.针对Green的自动测试运行（e2e，合同，回归）。
3.加热缓存/会话（如果适用）,同步背景乔巴/队列。
4.将流量切换到Green： atomic flip （DNS TTL低,Route/Listener交换,Ingress weight=100%）。
5.在第一分钟/小时观察SLO（金色信号：latency, errors, saturation+业务指标）。
6.有问题时-立即返回蓝色（翻转后）。

5.3个优点/缺点

优点：即时回滚，简单的心理模型，纯粹的隔离。
缺点：基础架构翻倍,复杂性与静态组件和数据迁移。

6）金丝雀： 架构和过程

6.1个拓扑

单个程序集群；单线后面的多个服务版本（稳定和金丝雀）。
流量按权重（1-5-10-25-50-100％）或目标（按标题/cookie/ID）分开。

6.2阶梯式洪水

1.将金丝雀版本丢入同一群集/ASG/NSG。
2.将部分流量（例如1-5%）路由到canary。
3.SLI/SLO自动检查和业务指标；CI/CD中的网关（error rate，p95 latency，CPU/RES，转换，故障/退款）。
4.通过门时的流量份额逐步增加。
5.完全滚动至100％，并停用旧版本；退化-自动回滚。

6.3个优点/缺点

优点：大多数用户风险最小,数据驱动解决方桉。
缺点：需要成熟的观察力，有能力的路由，实例之间"version skew"的风险。

7）流量路由

L4级别：IP/端口平衡；很简单，但几乎没有灵活性。
L7级别：HTTP/S规则-路径，主机，标头，cookie，用户代理，GeoIP，SNI。

• 重量路由（重量1-100％）。
• 基于头部/Cookie（将用户提交到组）。
• 会话保持稳定（对于静态/腰带脚本很重要）。
• 影子/交通镜头（将查询镜像到新版本的"静止"）。

8）工具和实现（示例）

Kubernetes: Ingress (NGINX, Contour), Service Mesh (Istio/Linkerd), Argo Rollouts, Flagger.

Облака: AWS ALB/ELB, Route 53 weighted records, ECS/EKS;GCP Load Balancing + NEG;Azure Front Door/App Gateway.

CD平台：Spinnaker，Argo CD，GitHub Actions+Progressive Delivery插件，GitLab/CD。

9）可观察性，SLI/SLO和门户

Golden signals: Latency (p95/p99), Error rate (5xx/4xx по типам), RPS, Saturation (CPU/Memory/GC), Queue lag.

业务指标：转换，授权，付款/成功，平均支票，漏斗步骤拒绝。

• 错误阈值（例如,错误率金丝雀≤基线+X%）。
• P95的潜伏期不超过Δ。
• 业务阈值（例如，转换下降
• SLO上的错误预算不应加速燃烧。

步骤持续时间：最低时间足以满足统计意义（取决于流量）。

10）DB迁移和电路兼容性

主要规则：如果版本前后兼容,则发布是安全的。

1.Expand：添加新的列/索引/表格,而不破坏旧版本。

2.Deploy app vNext（阅读/写入新方案，但知道如何与旧方案一起工作）。

3.Migrate数据（背景/batch，偶数，带有checkpoint）。

4.合同：稳定后删除旧字段/fichi。

反模式：在蓝绿色切换时需要独家锁定的迁移；该计划的失败是不可能的；没有重复数据消除的"双写"。

11）回滚（rollback）和事故计划

蓝绿色：蓝色上的即时翻转；监视绿色背景乔布斯的"尾巴"。
金丝雀：体重回调（例如，从25%回到5%或0%）；自动变速箱。
数据：经过深思熟虑的重复/补偿政策（idempotency keys, "inbox/outbox"模式,重复消息消除）。
Ficheflagi：快速杀手开关,关闭部分推出的功能。

12）与牛排和会议合作

加那利群岛的粘性会议，或外部存储会议（Redis/Memcached），以便版本可以互换。
预先预热缓存（绿色扭曲），并在翻转时考虑入侵。
背景操作员：不要允许版本之间的"比赛"-根据版本划分队列或"领先"。

13）安全性和合规性

Green/Canary访问-通过Zero Trust：服务帐户,最低要求角色。
秘密和钥匙-通过KMS/Secrets Manager；打开旋转。
流量仅为TLS；endpoint的版本已明确标记；审核路由和发布操作。

14）成本和性能

Blue-Green将基础架构加倍（在发布期间或永久）-提供预算。
金丝雀更经济，但需要观察工具和自动化工程时间。
优化：自动滑动,ephemeral环境,缩短版本并行存在的窗口。

15）支票单

发布之前

• 映像/票据是从单个来源启动的，签名已验证。
• 测试计划、Alerta和SLO门已配置。
• DB迁移-在expand模式下,可以使用downgrade计划。
• 回滚计划-已像插头/生产一样进行测试。

发布期间

• 度量指标和日志与基线进行了比较。
• 对于金丝雀-固定步骤和阈值；对于Blue-Green-防翻转。
• 呼叫团队知道,有反馈窗口。

发布后

SLO没有下降，错误预算正常。

• 发布后的迁移/清理已完成。
• 回顾和更新花花公子。

16）频繁的错误和反模式

在没有指标的情况下推出：没有数据-没有可管理的解决方桉。
混合不兼容的DB方案，缺乏下行策略。
随机溷合流量：没有粘性,用户在版本之间"跳跃"。
隐藏的状态依赖性（本地驱动器，内存缓存）。
长时间的DNS-TTL会干扰快速翻转（蓝绿色）。
缺乏自动登机：手动"眼对眼"的解决方案会减慢并增加风险。

17）组合方法

Blue-Green+Canary：首先推出Green，然后在Green内部推出Canary进行单独服务。
影子/迁移流量：在金丝雀之前,将镜像流量赶到新版本。
Feature flags（渐进式交付）：该功能在稳定版本的上方包含每个段的"深色"标志。

18）脚本示例（草图）

Blue-Green (web+api):

1.在新的Listener/Ingress后面部署绿色（v2）。
2.我们热缓存，我们执行readonly检查，烟雾。
3.将重量切换为Green=100％。
4.观看SLO 30-60分钟；如果所有-关闭Blue。

1.Deploy canary vNext （5%复制副本）。

2.包括内部帐户/测试段的5％流量。

3.自动门：error rate ≤ baseline+0。3%, p95 ≤ +20ms.

4.通过门时，我们将10％ → 25％ →每N分钟提高 50％。

5.100％跨所有细分市场翻译ficheflag；删除旧版本。

19）不同体系结构的变体

巨石：蓝绿色更简单，金丝雀更复杂，因为仙女不可分割。使用ficheflagi。
微服务：金丝雀是自然的；留意服务间合同（消费者驱动合同）。
Stateful服务：更喜欢Blue-Green和精心设计的迁移和稳定性。

20）简短比较（摘要）

回滚速度：Blue-Green=瞬间；金丝雀=速度快，但重量减轻。

基础设施成本： 蓝绿色↑；Canary ↔︎/↓.

用户风险：金丝雀较低（控制份额）。
实施难度：蓝绿色更容易启动；金丝雀需要强大的可观察性和自动化性。
数据/方案兼容性：两者都至关重要；计划expand-migrate-countract。

21）结果

蓝绿色和金丝雀不是相互排斥的策略，而是渐进式交付的元素。选择取决于成本限制，可观察性的成熟度以及变化的性质。无论采用哪种方法，可持续发布都取决于四个支柱：自动化，可观察性，向后兼容性和快速回滚。