Zero-Downtime部署

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

1）什么是Zero-Downtime，为什么需要

• 零方便客户和集成。
• 可预测的发布、快速回滚和可管理的风险。
• 将SLO/SLI（潜在性，错误，可访问性）保留在安排范围内。

ZDT的关键不是单一"魔术"技术，而是交付模式，数据兼容性和可胜任的流量路由的组合。

2） Zero-Downtime基本原则

1.版本兼容性：新版本和旧版本必须同时正确处理流量和数据。
2.操作的相等性：重复处理不应破坏状态。
3.优美的完成（graceful shutdown）和连接排水。
4.循序渐进的健康检查：准备/生活样本，健康结束。
5.作为头等舱公民回滚：回滚比hotfix更简单、更快。
6.通过设计可观察性：发布标签，单个dashbords，SLO上的差分。
7.自动化：发布和回滚脚本-代码而不是手动说明。

3）没有市中心的交付模式

3.1 Rolling Update

渐渐地，我们将旧版本的一些实例从流量中删除，将它们更新到新版本，然后返回池。

优点： 经济的基础架构,只是k8s/ASG.

缺点：有一段时间群集同时运行两个版本（version skew）。

3.2 Blue-Green

两个完整的程序堆栈：主动（蓝色）和候选人（绿色）。切换流量-原子翻转。

优点：瞬间回滚，清洁隔离。
缺点：基础架构的↑成本，与静态更难。

3.3金丝雀/渐进式滚动

我们给出新版本的流量的一小部分（1-5-10-25-50-100％），并按指标给出门。

优点：最小爆炸射线,数据驱动解决方桉。
缺点：需要成熟的可观察性和智能路由。

3.4 Shadow traffic / Dark launch

我们将真实查询镜像到新版本（未回复用户）或隐藏运行以收集指标。

优点：及早发现问题。
缺点：成瘾的双重负担，需要控制副作用。

4）交通和连接管理

4.1 Readiness/Liveness

Liveness告诉管弦乐队"重新启动我"。

准备就绪-"不引导流量，我还没有准备好。"

没有正确的准备逻辑和时间限制，就无法发布。

4.2连接排水（连接排水）

• 停止接受新的连接，
• 等待活动结束，
• 打断"盘旋"的时间。

4.3 Sticky会话和L7路由

Sticky在静态场景中很有用，但是使负载平衡复杂化。
L7规则（路径，标题，cookie，API版本）适用于金丝雀/环。

4.4长寿化合物

WebSocket/gRPC流式传输：在升级之前,启用drain mode+信号"GOAWAY"。
规划Windows以胜过客户的Stream和Backof Retrai。

5）数据互操作性和数据库迁移

5.1 Expand-Migrate-Contract

1.Expand：添加新的列/索引/表格,而不破坏旧版本。
2.Migrate：以背景和偶数方式传输数据（batchi，chekpoints）。
3.合同：我们只有在稳定后才能删除旧的合同。

5.2个实践

在发布窗口中避免独家DDL锁定。
验证API/事件合同 （schema registry, CDC）。
对于大量迁移-在线工具、副本、分阶段切换。
双环记录（双写）,只有重复数据消除和偶数用户。
Outbox/Inbox可通过队列进行可靠的集成。

6）缓存，会话和背景任务

会话和缓存是外部（Redis/Memcached），因此版本可以互换。
在打开池之前加热缓存/jit/速度索引。
按版本划分背景队列,或使用领先优势避免比赛。

7）SLO的可观察性和门户

Golden signals： p95/p99潜伏期,error rate, RPS, saturation,排队。
业务SLA：授权，转换，成功付款，漏斗步骤故障。
大门：只有当金丝雀≤基线+降解阈值并且错误预算不燃烧时，滚动才能推进。

8）安全完成和回滚

回滚是相同的管道，只是相反的：固定的命令，不是"手工艺品"。
对于蓝绿色-翻转；金丝雀-重量减至0%或前一个稳定步骤。
数据：补偿事务、重复处理、事件重复数据消除。

9）零下时间支票清单

发布之前

• 收集了一个签名的工件（immutable），SBOM和依赖性检查。
• Readiness/Liveness已实施和测试。
• 外包模式下的迁移计划，可逆性得到确认。
• 新版本的Dashbords和Alertes已准备就绪，发布标签已滚动。
• 回滚已在staging/pre-prod上验证。

发布期间

• 连接排水包括在内，taymouth是足够的。
• 流量将逐步转移（金丝雀/环）或翻转（蓝绿色）。
• 将度量标准与基线进行比较，并遵循门槛。

发布后

• N小时后监测，没有事件。
• 合同迁移已完成,临时标志/路线已删除。
• 回顾,更新花花公子。

10）反模式

无排水的Recreate Deploy和Readiness ⇒请求的悬崖。
未经准备的DDL在黄金时段⇒锁定和定时。
在服务版本之间混合不兼容的方案。
处理者和锻炼者缺乏同位素。
"感觉不好"，没有门和基线比较。
蓝绿色时长DNS-TTL，导致翻转持续数小时。
滚动/金丝雀时实例内存中的本地会话/缓存。

11）实施方桉

11.1 Kubernetes (rolling + canary)

Deployment с `maxUnavailable=0`, `maxSurge=25%`.

准备等待预热（缓存初始化、次要迁移）。
服务-mesh/Ingress带有重量路由功能（1-5-10-25-50-100％）。
Alerts： p95, 5xx, lag队列,业务漏斗。

11.2蓝绿色在云中

平衡器后面的两个堆栈是'蓝色。example.com` и `green.example.com`.

预热绿色，烟雾/倒退，然后是听者/路线交换（或低TTL DNS切换）。
有问题时-即时翻转。

11.3 Stateful服务

数据副本+在线迁移；双读与验证。
背景乔巴通过"领导"版本或分队进行传输。
实例外的会议/缓存；sticky只是暂时打开。

12） Ficheflagi和客户端应用程序

新的fici被旗帜激活（细分：员工→ beta →所有）。
对于移动/台式机客户端,请考虑协议兼容性边界和旧版本的生存能力（deprecation policy, server side fallback）。

13）生产力和成本

滚动更便宜，但需要谨慎的兼容性。
Blue-Green在发布时更昂贵，但会立即回滚。
金丝雀平衡风险和成本，但需要强大的可观察性。
通过ephemeral预览和自动清洁看台节省费用。

14） ZDT最低参考线

1.Build：单个工件，签名，SBOM。

2.Test: unit/integration/contract + security.

3.Staging： smoke,负载,expand模式迁移,回滚检查。
4.Prod：阴影→金丝雀（网关）或蓝绿色翻转。
5.后处理：监视，合同清洁，复古。

15）简短摘要

Zero-Downtime是一门学科：兼容版本+正确路由+受控迁移+可观察性和快速回滚。选择上下文（滚动、蓝绿色、金丝雀）下的模式,自动化SLO网关,保持数据等效性-发布将不再是事件,成为可靠的例行过程。