Day 22 Medium Deployment Canary Feature Flags DB Migration

上线与发布 — 每天部署上百次、坏版本 5 分钟自动滚回Deployment & Release: Blue-Green, Canary, Feature Flags & Schema Migration

问题场景 + 需求约束

设计一个支撑 500+ 微服务、日均数千次部署 的发布平台。目标不是「能上线」，而是 在高频部署下把坏版本的爆炸半径压到最小：一个有 bug 的版本进了生产，要在 用户感知前自动检测并回滚，而不是等告警、等 on-call 起床。

这件事的反面教材是 Knight Capital 2012：一次部署把新代码推到 8 台服务器中的 7 台，第 8 台还跑着旧代码，复用了一个废弃的 feature flag，45 分钟内亏掉约 4.4 亿美元，公司就此终结（SEC 8-K）。发布系统不是 CI 的尾巴，它是可靠性工程的核心。

部署频率：日均数千次（Amazon 量级是每秒级），人工评审每个版本不现实 → 自动化卡口是前提。
零停机：滚动期间新旧版本并存，要求请求无感、连接不断。
回滚 SLO：从「检测到异常」到「流量切回旧版本」< 5 分钟（MTTR 的主要构成）。
状态约束：无状态服务好办；带 schema 变更的有状态服务才是难点 —— 数据库回不了滚。
解耦：部署（把代码放上去）必须和发布（让用户看到功能）解耦，否则没法灰度。

高层架构

核心是一条带自动金丝雀分析（ACA）的流水线：新版本先只接一小撮流量，把它的黄金指标（错误率、延迟、饱和度）与基线版本做统计对比，显著劣化就自动回滚，达标才逐步放量。Feature flag 平台横切在外，让「发布」可以在不重新部署的前提下用配置开关控制。

graph LR
    DEV["commit / CI
build + 单测"]
    ART["镜像仓库
immutable artifact"]
    CD["发布编排
Spinnaker / Argo"]
    LB["流量路由
service mesh / LB"]
    BASE["Baseline v1
旧版本"]
    CAN["Canary v2
新版本 · 5%"]
    ACA{"金丝雀分析
指标统计对比"}
    OBS[("Metrics / Traces")]

    DEV --> ART --> CD --> LB
    LB -->|95%| BASE
    LB -->|5%| CAN
    BASE --> OBS
    CAN --> OBS
    OBS --> ACA
    ACA -->|达标| CD
    ACA -.->|劣化→回滚| LB

    classDef ci fill:#1a2530,stroke:#64c8ff,color:#e8eef5
    classDef route fill:#0e2030,stroke:#5eead4,color:#e8eef5
    classDef ver fill:#1a1a30,stroke:#ffb450,color:#e8eef5
    classDef judge fill:#2a1530,stroke:#ff7ab6,color:#e8eef5
    class DEV,ART,CD ci
    class LB,OBS route
    class BASE,CAN ver
    class ACA judge

金丝雀只接小流量；分析模块自动判优劣，达标放量、劣化回滚 —— 人不在回路里

关键技术点

1. 部署策略：Rolling vs Blue-Green vs Canary

一句话 trade-off：用「多花的资源 + 慢」换「更小的爆炸半径 + 更快回滚」。

原理：三者本质都是「新旧版本如何共存与切换」。Rolling（滚动）逐批替换实例，每批下线旧的、起新的，全程只需 1 份资源，但回滚要再滚一遍、慢。Blue-Green（蓝绿）开两套完整环境，绿色就绪后流量一次性切过去，回滚就是把路由切回蓝色 —— 秒级回滚，代价是双倍资源。Canary（金丝雀）只把 1%~5% 流量导给新版本，观察指标再决定放量还是回滚，爆炸半径最小，但流程最复杂、放量最慢。

	Rolling	Blue-Green	Canary
资源开销	1×（+1 批）	2×	1× + 少量
回滚速度	慢（再滚一轮）	秒级（切路由）	快（撤金丝雀）
爆炸半径	中（逐批扩大）	大（一次全切）	极小（1~5%）
新旧共存	是（需兼容）	短暂	是（需兼容）
适用	默认、无状态	要秒级回滚、能承担双倍成本	高风险变更、有完善可观测性

关键陷阱：Rolling 和 Canary 都让新旧版本同时在线，所以两个版本必须互相兼容（前后向）—— 这把难度从「部署」转移到了「兼容性设计」（见技术点 3、4）。Blue-Green 看似规避了共存，但共享同一个数据库时，schema 仍要对蓝绿两版都兼容。

现实案例：

Netflix：用 Spinnaker 编排，红黑部署（蓝绿变体）+ 金丝雀，跨 AWS 多区域。
Kubernetes：原生 Deployment 即 rolling update（maxSurge/maxUnavailable 控制批次）；蓝绿/金丝雀靠 Argo Rollouts、Flagger 实现。
Google：金丝雀 + 渐进放量是 SRE 标准实践，《Site Reliability Engineering》专门讲发布工程。

2. 自动金丝雀分析：让统计学替你做发布决策

一句话 trade-off：用「统计严谨性 + 工程复杂度」换「人不再肉眼盯 dashboard」。

原理：金丝雀的价值在于对比，而不是孤立地看新版本指标。正确做法是同时跑一个基线（baseline）—— 用和金丝雀相同版本的旧代码、接相同小流量，排除「正好赶上流量高峰」之类的环境噪声。然后对两组的错误率、延迟分位、CPU 等指标做统计假设检验，判断差异是否显著。Netflix Kayenta 用 Mann-Whitney U 检验（非参数，不假设正态分布）给每个指标打分，再汇总成一个「通过 / 边缘 / 失败」判定。

# 金丝雀判定核心逻辑 (pseudo-code)
def judge_canary(canary, baseline, metrics):
    scores = []
    for m in metrics:                       # 错误率、p99、CPU...
        # 非参数检验：金丝雀样本是否显著差于基线
        p = mann_whitney_u(canary[m], baseline[m])
        if significant(p) and worse(canary[m], baseline[m]):
            scores.append(FAIL)
        else:
            scores.append(PASS)
    fail_ratio = scores.count(FAIL) / len(scores)
    if fail_ratio > 0.5:  return "ROLLBACK"   # 自动回滚
    if fail_ratio > 0:    return "MANUAL"      # 人工介入
    return "PROMOTE"                           # 自动放量

Trade-off：

不设基线、只看绝对阈值：✅ 简单；❌ 阈值要手调、易误报（流量高峰把延迟顶上去也触发回滚）。
金丝雀 vs 基线对比：✅ 抵消环境噪声、阈值自适应；❌ 多一份基线资源、需要足够样本量（低流量服务统计不显著）。
金丝雀只接 5% 流量：观测窗口要够长才能积累样本，与「快速放量」存在张力。

现实案例：

Netflix + Google：开源 Kayenta，用 Mann-Whitney U 检验；上线时已承担 Netflix 约 30% 的金丝雀判定、日均约 200 次。
Argo Rollouts / Flagger：在 K8s 上对接 Prometheus 做 metric analysis，按阈值/对比自动推进或回滚。

3. 部署 ≠ 发布：用 Feature Flag 解耦

一句话 trade-off：用「flag 的配置债 + 代码分支复杂度」换「随时灰度、随时关停、上线无需重新部署」。

原理：把代码部署到生产，不等于把功能暴露给用户。新功能包在一个 feature flag 里，部署时默认关闭（dark launch），之后通过配置中心按用户/比例/地区动态开启。这带来三个能力：① 渐进放量（1% → 50% → 100%，出问题秒关，无需回滚部署）；② 解耦发布与部署时间（代码合主干即可，营销定时再开）；③ A/B 实验。Knight Capital 的惨剧正源于 flag 治理失败 —— 复用了一个早该删除的旧 flag。

# Feature flag 调用 (pseudo-code)
if flags.enabled("new_checkout_v2", user=ctx.user,
                 rollout_pct=5, allow=["beta_team"]):
    return checkout_v2(ctx)     # 新路径：仅 5% + 内测组
else:
    return checkout_v1(ctx)     # 旧路径：兜底
# kill switch：把 rollout_pct 设 0，无需部署即可全量关停

Trade-off：

不用 flag（靠部署/回滚控制）：✅ 代码干净；❌ 每次灰度都要重新部署，关停慢、无法精细分人群。
用 flag：✅ 秒级 kill switch、精细灰度、实验；❌ flag 债 —— 旧 flag 不清理就是定时炸弹，代码里 if/else 分支组合爆炸、测试覆盖困难。
纪律：临时 flag 必须有「下线日期」，放量到 100% 后回头删代码（很多团队栽在这一步）。

现实案例：

Flickr：2009 年的经典博文「Flipping Out」奠定了 feature flag + dark launch 的工程范式。
Facebook：Gatekeeper 系统按地区/用户群精细控制功能曝光，部署与发布彻底解耦。
LaunchDarkly：把 feature flag 做成独立 SaaS 品类，progressive delivery 的代表。

4. 向后兼容与数据库迁移：唯一不能回滚的东西

一句话 trade-off：用「多步骤 + 临时双写的工程量」换「schema 变更全程零停机、任意时刻可回滚」。

原理：代码能回滚，数据回不了滚。一旦删了列、改了类型，旧版本代码读到就崩。新旧版本共存期间，schema 必须同时让两版都能跑。解法是 Expand-Contract（扩张-收缩，又名 Parallel Change）：把破坏性变更拆成三段 —— Expand 只加不减（加新列/新表，不动旧的）；Migrate 双写 + 回填历史数据，读切到新结构；Contract 等所有旧版本下线后，才删旧列。每一步都向后兼容，回滚只是停在当前步。API 层同理：Stripe 的日期版本把账号「钉」在首次调用的版本，内部只写最新逻辑，再由响应兼容层把结果转换回旧格式 —— 自 2011 年起从未真正破坏过 API。

graph LR
    E["① Expand
加 new_col
不删旧的"]
    M["② Migrate
双写 old+new
回填 + 读切新"]
    C["③ Contract
删 old_col
旧版本已下线"]
    E --> M --> C
    E -.可回滚.-> X1["旧代码仍工作"]
    M -.可回滚.-> X2["旧列仍在"]
    classDef step fill:#1a2530,stroke:#5eead4,color:#e8eef5
    classDef safe fill:#0e2030,stroke:#64c8ff,color:#7a8590
    class E,M,C step
    class X1,X2 safe

Trade-off：

直接 ALTER（一步到位）：✅ 简单；❌ 共存期旧代码崩、大表 ALTER 可能锁表、无法回滚。
Expand-Contract 三段式：✅ 全程兼容、可随时停；❌ 步骤多、Migrate 期要维护双写、忘了做 Contract 会留技术债。
纪律：Expand 和 Contract 必须是独立的两次发布，中间确认所有旧实例已退场，否则就是 Knight Capital 式的版本错配。

现实案例：

Stripe：日期滚动版本 + 响应兼容层，13 年零破坏性变更，被业界奉为 API 版本管理标杆。
Martin Fowler：把该模式正式命名为 Parallel Change（expand / migrate / contract 三段）。
GitHub / Shopify：大表迁移用「在线 schema change」工具（gh-ost / lhm）配合 expand-contract，避免锁表停机。

扩展与优化

渐进放量自动化：金丝雀达标后按 5%→25%→50%→100% 阶梯放量，每档都跑一轮分析，全自动推进（Argo Rollouts 的 step）。
多区域错峰：先发一个小区域，烤 24 小时（catch 只有特定时区/流量模式才暴露的 bug），再全球铺开。
回滚 vs 前滚：带 schema 变更时往往「前滚修复（roll forward）」比回滚更安全 —— 因为数据已经按新结构写了。这要求 hotfix 流水线本身极快。
flag 治理：建 flag 生命周期看板，自动提醒清理过期 flag，把「flag 债」纳入技术债管理。
部署即代码：发布流程版本化（pipeline as code），审计每次变更，可重放。

常见陷阱 + 面试追问

1. 「能部署」当成「能发布」：没把部署和发布解耦，灰度只能靠反复部署。面试期望你主动提 feature flag。

2. 忘了新旧版本要双向兼容：rolling/canary 期间新旧共存，新版本写的数据旧版本要能读，反之亦然。最容易翻车的是「先删 API 字段再发客户端」的顺序错配。

3. 把数据库迁移当代码部署：以为回滚部署就万事大吉，结果 schema 已改、旧代码读崩。务必 expand-contract，且 Expand/Contract 分两次发。

4. 金丝雀不设基线：只看新版本绝对指标，被流量波动误导。正确做法是金丝雀 vs 同流量基线做统计对比。

5. flag 不清理：Knight Capital 复用废弃 flag 触发死代码，45 分钟亏 4.4 亿。临时 flag 必须有过期与清理机制。

深入资源

《Designing Data-Intensive Applications》Ch 4（Kleppmann）：演进式 schema、向前/向后兼容的本质讨论。
Netflix TechBlog：Automated Canary Analysis with Kayenta —— ACA 的统计方法与工程实现。
Stripe Blog：APIs as infrastructure: future-proofing Stripe with versioning。
Martin Fowler bliki：ParallelChange、BlueGreenDeployment、CanaryRelease、FeatureToggle。
Flickr code blog：Flipping Out —— feature flag + dark launch 范式起点。

深入思考（点击展开答案）

1. 蓝绿部署号称「秒级回滚」，但如果两套环境共享同一个数据库，这个承诺会在什么情况下失效？

蓝绿的秒级回滚只对无状态、无 schema 变更的版本成立。一旦绿色版本上线时执行了破坏性 schema 变更（删列、改类型），切回蓝色时蓝色代码读到的还是已经变了的库，照样崩 —— 数据库是蓝绿共享的，它没跟着回滚。

更隐蔽的是数据污染：绿色运行的几分钟里写入了只有新格式才合法的数据（比如新枚举值、新 JSON 结构），回到蓝色后，蓝色读到这些「未来数据」反序列化失败。

正确姿势：schema 必须先用 expand-contract 走到「对蓝绿两版都兼容」的中间态，再做蓝绿切换。也就是说，数据迁移的节奏必须领先于代码发布，蓝绿只解决无状态部分的回滚。这也是为什么「带 schema 变更时前滚常比回滚安全」。

2. 一个 QPS 很低的内部服务（每分钟几十次请求）想做自动金丝雀分析，会遇到什么根本性障碍？怎么办？

障碍：样本量不足，统计检验失去意义。金丝雀只接 5% 流量，本来 QPS 就低，5% 后每分钟可能只有几个请求。Mann-Whitney U 这类检验在小样本下要么 p 值永远不显著（放过真 bug），要么单个异常点就左右结论（误报）。统计需要足够的 n。

办法：① 提高金丝雀流量比例（低流量服务直接给 50%，反正绝对量小，爆炸半径仍可控）；② 拉长观测窗口（不看每分钟，看几小时累积）；③ 降级为蓝绿 + 阈值告警，放弃统计对比，靠简单错误率阈值 + 人工确认；④ 合成流量，用回放/压测给金丝雀灌可控负载凑样本。本质是：ACA 是为高流量设计的，低流量服务该换更朴素的策略，别为统计而统计。

3. Expand-Contract 要求「Expand 和 Contract 分两次发布」。如果团队图省事合成一次发，最坏会发生什么？

合成一次发，意味着「加新列 + 双写 + 删旧列」在同一个版本里完成。问题出在滚动部署的共存窗口：当新版本正在逐批替换旧版本时，集群里同时有「已删旧列认知」的新实例和「还在读写旧列」的旧实例。

新实例已经把旧列 DROP 了 → 旧实例的查询立刻 column not found 报错。这就是 Knight Capital 的结构性病因：同一时刻不同实例对数据契约的认知不一致。

即使不滚动、用蓝绿一次切，回滚时也回不去 —— 旧列已被物理删除。分两次发的本质，是在两次发布之间插入一个「确认所有旧实例已退场」的同步点，把「版本共存」这个分布式难题，降维成两个各自兼容的串行步骤。省这一步省掉的正是安全性本身。

4. Feature flag 给了「秒级 kill switch」，那它能不能替代金丝雀和回滚？三者是什么关系？

不能替代，三者作用在不同层次，是组合关系：

金丝雀解决「要不要让这个二进制进生产」—— 针对整个部署单元的风险评估，颗粒度是「版本」。
Feature flag解决「已经在生产的代码，要不要让用户看到这个功能」—— 颗粒度是「功能 / 人群」，且无需重新部署即可开关。
回滚是兜底 —— 当前两者都没拦住、坏版本已造成影响时，把二进制换回旧的。

典型流水线是三者叠加：新功能藏在 flag 后（关闭）随版本部署 → 金丝雀分析确认这个版本本身健康 → 全量部署 → 再单独用 flag 渐进打开功能、出问题秒关。flag 关不掉的问题（如框架升级、依赖变更、内存泄漏）才需要金丝雀拦截和回滚。把 flag 当万能开关、不做金丝雀，等于放弃了对「版本级劣化」的防护。

5. 估算：一个版本有 0.1% 概率引入会致瘫的 bug。若每天部署 1000 次、每次直接全量，与改用「金丝雀拦截掉 95%」相比，年度生产事故次数差多少？

全量直发：每次部署致瘫概率 0.1%，每天 1000 次 → 期望 1000 × 0.001 = 1 次/天致瘫事故 → 一年约 365 次。系统基本没法用了。

金丝雀拦截 95%：金丝雀只接小流量，坏版本即便漏过也只影响 5% 用户那一小段时间，且 95% 的坏版本在放量前被自动回滚挡下 → 真正全量爆发的事故降到 365 × 5% ≈ 18 次/年，且每次的用户影响面还被金丝雀流量比例进一步缩小（影响 = 概率 × 爆炸半径，两个因子都被压低）。

二阶洞察：可靠性不是靠「让 bug 不发生」（0.1% 这个基础率很难再降），而是靠把每次失败的代价压低。高频部署反而更安全 —— 部署越频繁，每次变更越小，金丝雀越容易从指标里识别出「是哪次变更搞坏的」。这就是「deploy more often to be safer」这个反直觉结论的数学来源：频率高 + 批量小 + 自动拦截，整体风险远低于「攒一大波、谨慎地全量发一次」。

← 回到 index