蓝绿部署 vs 金丝雀部署：更安全的 API 与数据库变更

为什么在模式变更和缓慢的移动更新下部署会变得危险

一次部署在测试中看起来完美，但一旦遇到真实流量就可能失败。常见原因是你不仅仅在变更代码：API 合约和数据库模式也在改变，而且它们很少以相同节奏前进。

当系统的不同部分对“正确”的定义不一致时就会出问题。新版后端期望一个还不存在的列；旧版后端以新版不再理解的格式写入数据。即便是微小改动，比如字段重命名、校验收紧或枚举值变化，也会引发生产错误。

移动应用把风险放大，因为老版本会一直存在。有的用户几分钟内更新，有的用户几周甚至更久才更新。这意味着后端必须同时为多代客户端提供服务。如果你发布了只适配最新版客户端的 API，可能会打断一部分用户的结账、注册或后台同步，而你不会立即注意到。

“停机风险”并不等同于网站完全无法访问。在真实系统中，它经常表现为部分失败：

• 某些端点的 4xx/5xx 错误激增，而其它看起来正常
• 登录失败，因为令牌、角色或用户记录不再匹配预期
• 隐性数据问题（错误的默认值、被截断的文本、缺失的关联）在数天后才显现
• 后台作业卡住并生成一个需要数小时才能清空的队列

这也是团队比较蓝绿部署 vs 金丝雀发布的原因之一：你在尝试减少兼容性不完美时的冲击面。

蓝绿与金丝雀的通俗解释

当人们比较蓝绿和金丝雀时，通常是在回答一个问题：你想要一次大的、可控的切换，还是想先做一个小范围的谨慎试验？

蓝绿：两个完整版本和一次流量切换

蓝绿意味着你同时运行两个完整环境。“蓝”是当前对外提供服务的版本。“绿”是并行部署并测试的新版本。准备就绪后，你把流量从蓝切到绿。

这种方法在可预测性上有优势。你可以在接触真实用户前，用类生产环境的设置验证新版本，然后做一次干净的切换。

回滚也很直接：切换回蓝即可。切换几乎可以瞬间回退，但缓存、后台任务和数据变更仍可能让恢复复杂化。

金丝雀：先给一小部分流量

金丝雀是先把新版本暴露给少量用户或请求。如果表现良好，再逐步提高比例，直到对所有人可用。

当你担心未知行为在真实流量下的表现时，金丝雀最有价值。它能在大部分用户受影响前发现问题。

回滚通过把金丝雀流量降到零（或停止把流量路由到新版本）来实现，通常速度快，但并不总是干净回退，因为部分用户可能已经生成了需要两个版本同时处理的数据或状态。

一个简单的记忆法：

• 蓝绿偏向干净的切换与快速回退。
• 金丝雀偏向从真实流量中学习并限制影响范围。
• 任何一种方法都不会自动解决数据库兼容性风险。如果模式变更不兼容，两者都可能失败。
• 金丝雀依赖于监控，因为决策基于实时信号。
• 蓝绿通常需要额外容量，因为你要运行两个完整栈。

举例：如果你发布的 API 有时会返回一个新字段，金丝雀能帮你观察旧客户端在接收到意外字段时是否崩溃。如果变更需要重命名一个列，而旧代码无法处理，除非在模式设计上支持两种版本，否则蓝绿也救不了你。

为什么数据库迁移不同于代码部署

代码部署通常可以较为轻松地回滚。如果新版本表现异常，你重新部署旧构建，大体上就能回到之前的状态。

数据库变更不同，因为它改变了数据的形状。一旦行被重写、列被删除或约束被收紧，回退很少能瞬间完成。即便你回滚了应用代码，旧代码也可能无法理解新的模式。

这就是为什么模式迁移的停机风险往往与迁移设计关系更大，而不仅仅取决于部署方式。

在线迁移基础

最安全的迁移是在旧版和新版应用能够同时运行时完成的。模式很简单：先做可被忽略的改动，更新代码以使用新改动，随后清理。

一个常见的“先扩展再收缩”序列如下：

• 先做添加性改动：新增可为空的列、新表、以不阻塞写入的方式添加索引。
• 双重行为：同时写老位置和新位置，或优先读新字段但回退到旧字段。
• 单独回填：以小批量迁移已有数据。
• 切换：把大部分流量移到新行为。
• 最后做破坏性改动：删除旧列、移除旧代码路径、收紧约束。

“重打包”迁移会把最危险的步骤合并到一次发布中：长时间锁表、庞大的回填、以及假定新模式在任何地方都已存在的代码。

为什么缓慢的移动更新提高了要求

移动客户端可能在旧版本停留数周。你的后端必须在数据库演进期间继续接受旧请求并返回旧响应。

如果旧客户端发送的请求缺少某个字段，你的服务器就不能突然把该字段在数据库中设为必填。你需要一段时间让两种行为并存。

哪种策略能降低模式迁移的停机风险

最安全的选择更多取决于一个问题：旧版和新版应用能否在同一数据库模式下共存一段时间？

如果答案是肯定的，蓝绿通常在停机时间上更有优势。你可以先准备数据库变更，保持流量在旧栈上，然后一次切换到新栈。如果出现问题，可以快速切回。

当新应用立即依赖新模式时，蓝绿也会失败。常见情况包括删除或重命名旧版仍在读取的列，或在应用开始写入前就加入 NOT NULL 约束。在这些情况下，回滚可能不安全，因为数据库已经不兼容。

当你需要在真实流量中受控学习时，金丝雀会更合适。把少量真实流量打到新版本，有助于发现缺失索引、意外查询模式或后台作业在生产负载下的不同行为。代价是你必须让两个版本同时工作，这通常要求数据库变更具备向后兼容性。

一个实用的决策规则

在为模式迁移的停机风险权衡蓝绿 vs 金丝雀时：

• 如果你能保持模式变更为添加性且兼容，并且你主要想要快速、干净的切换，就选蓝绿。
• 当你不确定改动在生产中的表现，或者预计稀有数据形态会影响结果时，选金丝雀。
• 如果迁移会强制立即破坏兼容性，不要在蓝绿和金丝雀之间选择，改为采用先扩展后收缩的计划。

“兼容”在实际中的样子

比如你要在 orders 表添加新字段。安全路径是：先把列加为可空，部署会写该字段的应用，回填旧行，然后再强制约束。在这种安排下，蓝绿能给你一次干净切换，而金丝雀能在某些代码路径仍假定旧形态时给出提前警告。

缓慢的移动更新如何影响部署选择

网页用户会刷新页面，移动用户则不会。

在 iOS 和 Android 上，人们会在旧版本停留数周或数月。有些人直到应用强制更新才升级，有些设备长期离线。这意味着“旧”客户端在你发布新后端很久之后仍会调用你的 API。旧移动客户端事实上成了向后兼容性的长期测试。

这把目标从“零停机部署”转变为“同时支持多代客户端”。在实践中，即便基础设施使用蓝绿，移动场景也常把你推向类似金丝雀的思路来处理 API。

向后兼容变更 vs API 版本化

大多数情况下，你希望做向后兼容的变更，因为它们允许旧版和新版应用共用同一端点。

向后兼容的例子包括新增字段、接受旧/新载荷格式、保留现有响应字段并避免含义改变。只有在行为必须改变（而非仅仅新增数据）或必须移除/重命名字段时，才需要为移动应用做 API 版本化。

例如：新增可选字段 marketing_opt_in 通常安全；改变 price 的计算方式通常不安全。

规划弃用窗口

如果确实需要破坏性变更，把停止支持当作产品决策。一个有用的弃用窗口应由“仍在使用旧版本的活跃用户”来衡量，而不是按日历天数。

一个实用序列：

• 发布同时支持旧版与新版客户端的后端。
• 发布新版移动应用并追踪按版本的采纳率。
• 仅当旧版占比降到安全阈值后才警告或限制。
• 在移除旧行为前保留回滚计划。

步骤详解：API + 数据库变更的安全发布模式

当你同时改动 API 与数据库时，最安全的方案通常是两步或三步发布。每一步都应能单独安全部署，即便用户在数周内仍使用旧移动应用。

避免打断旧客户端的发布模式

先做添加性数据库变更。新增列或表、避免重命名或删除、必要时允许空值并使用默认值，这样旧代码不会突然遇到约束错误。

然后发布能兼容两种数据形态的应用代码。读取应接受“旧字段缺失”或“新字段存在”，写入应继续写旧字段，或同时写新字段与旧字段。

典型序列：

• 添加新模式（列、表、索引），保留旧项。
• 部署能读旧或新字段且不会因 null 崩溃的代码。
• 以小批量回填旧行，验证计数、空值率和查询性能。
• 切换写入到新字段，同时保留回退读取。
• 在旧移动版本逐渐消失后，移除旧字段与清理代码。

回填和验证：故障往往藏在这里

回填常失败的原因是被当作一个快速脚本处理。把它们分批运行，关注负载并验证结果。如果新行为需要索引，应在切换读写前先添加索引，而不是之后。

举例：你新增 phone_country_code 来改进格式化。先把列加入（可空），更新 API 以接受它但在缺失时仍能工作，回填已有号码，然后对新注册开始写入。若干周后旧版客户端几乎消失时再移除遗留解析路径。

不需要复杂工具也能让两种策略更安全的做法

你不需要复杂的基础设施来让蓝绿或金丝雀更安全。几个良好习惯能在 API 与数据库模式步调不一致时降低意外发生：

双读双写（仅做短期过渡）

Dual-write 表示在过渡期同时把数据写到旧位置和新位置（例如同时写 users.full_name 和新加的 users.display_name）。Dual-read 表示优先读新字段但回退到旧字段。

这为缓慢的客户端升级争取时间，但应是短期桥接。要决定何时清理、记录新旧路径的使用情况，并做基本校验确保两者写入一致。

用特性开关管理行为变化

特性开关让你可以先部署代码但不开启有风险的行为，把“部署”和“开启”分离。

例如：部署对新响应字段的支持，但保持服务器返回旧格式直到准备好为止。然后对一小部分用户打开新行为，观察错误并逐步放量。如果出现问题，关闭开关而无需完整回滚。

契约测试思维（把 API 当作承诺）

许多迁移事故本质上不是“数据库问题”，而是客户端期望问题。

把 API 当作一项承诺。避免移除字段或改变含义。让未知字段可选。新增字段或端点通常安全；破坏性变更应等到新 API 版本。

可信赖的数据迁移作业

模式迁移往往需要回填任务来复制数据、计算值或清理。这些作业应可重复、安全可重试、可限速以免冲击负载，并且易于追踪。

导致迁移故障的常见错误

大多数迁移故障发生在发布假定所有东西会同时改变的情况下：所有服务同时部署、所有数据都干净、所有客户端都即时更新。真实系统不是这样，尤其是移动端。

常见失败模式：

• 过早删除或重命名列。旧的 API、后台作业或旧移动应用可能仍在使用它。
• 假定客户端会很快更新。移动发布需要时间，很多人并不会马上升级。
• 在高峰时段运行会锁表的迁移。一个“简单”的索引或列变更也可能阻塞写入。
• 只测试干净的示例数据。生产数据包含 null、奇怪格式、重复和遗留值。
• 没有针对代码和数据的真实回滚计划。“我们可以重新部署以前的版本”不够，如果模式已经改变回滚就不是简单的事。

举例：你把 status 重命名为 order_status 并部署新 API。网页应用工作正常，但旧移动客户端仍发送 status，API 现在拒绝这些请求导致结账失败。如果你已删除该列，恢复行为不是迅速的切换。

更好的默认策略是：把变更拆成小、可逆的步骤，让旧路径和新路径并存，并写清当指标飙升时的应对步骤（如何路由回流量、哪个特性开关关掉新行为，以及回填出问题时如何验证和修复数据）。

发布前的快速检查清单

在发布前，一个简短的检查清单能捕捉导致深夜回滚的问题。当你同时变更 API 与数据库，尤其是在缓慢移动更新的场景下，这点尤为重要。

防止大多数故障的五项检查

• 兼容性： 确认旧版与新版应用都能在同一数据库模式下工作。一个实用测试是把当前生产构建对接应用了新迁移的预演数据库运行一遍。
• 迁移顺序： 确保首个迁移是添加性的，把破坏性改动（删除列、收紧约束）安排在后期。
• 回滚： 定义最快的撤销方法。对于蓝绿，是切回流量；对于金丝雀，是把 100% 流量回退到稳定版本。如果回滚需要另一次迁移，那就不简单。
• 性能： 在模式变更后测量查询延迟，而不仅仅验证正确性。缺失索引会让某个端点看起来像是在发生故障。
• 客户端现实： 识别仍在调用 API 的最旧移动应用版本。如果有显著比例仍在使用，计划更长的兼容窗口。

一种快速的合理情形

如果你要添加 preferred_language 之类的新字段，先把数据库改为可空。然后发布服务器端代码：当字段存在时读取它，但不强制要求。只有在大部分流量来自已升级的客户端后，再把它设为必填或移除旧行为。

示例：在不打断旧移动应用的情况下添加新字段

假设你要新增用户档案字段 country，且业务要求变为必填。两处都会出问题：旧客户端可能不发送该字段，数据库若过早拒绝写入会导致失败。

更安全的做法是分两次变更：先以向后兼容方式新增字段，然后在客户端普遍升级后再强制“必填”。

蓝绿下的流程

在蓝绿情况下，你会并行部署新版本但仍需保证数据库变更兼容两者。

安全流程示例：

• 部署迁移（把 country 加为可空）
• 部署 green 版本，能接受缺失 country 并使用回退值
• 在 green 上测试关键流程（注册、编辑资料、结账）
• 切换流量

若出现问题就切回。关键在于切回只在模式仍支持旧版本时有效。

金丝雀下的流程

金丝雀会把新 API 行为先暴露给小部分请求（通常 1% 至 5%），观察缺失字段的校验错误、延迟变化和意外的数据库失败。

常见惊喜是旧移动客户端提交不含 country 的资料更新。如果 API 立即把它视为必填，你会看到 400 错；若数据库在写入时强制 NOT NULL，可能出现 500 错。

更安全的序列：

• 把 country 加为可空（可选地用安全默认值如 “unknown”）
• 接受旧客户端缺失 country 的请求
• 通过后台任务逐步回填现有用户的 country
• 在稍后先在 API 层再在数据库层强制“必填”

发布后记录旧客户端可以发送的内容和服务器保证的行为。把约定写下来能防止下一次迁移重复犯同样的错误。

如果你使用 AppMaster (appmaster.io) 构建，尽管你可以从一个模型生成后端、Web 和原生移动应用，相同的放量纪律仍然适用：先发布添加性模式变更和容错的 API 逻辑，待采纳率足够高后再收紧约束。