独立部署能力是关键目标,因此每个服务都需要自己的CI/CD pipeline加上低风险发布策略(通常是canary或blue-green),以便安全地每天发布多次。
按服务划分的pipeline
每个服务按照自己的节奏进行构建、测试和部署。对一个服务的更改永远不会触发完整系统发布。
text
commit ─▶ build ─▶ unit + contract tests ─▶ image ─▶ deploy (one service)
| 策略 | 方式 | 优点 | 缺点 |
|---|
| Rolling | 逐步替换实例 | 简单、默认 | 短时间内混合版本 |
| Blue-green | 两个环境,切换流量 | 即时回滚 | 2倍基础设施 |
| Canary | 将小比例发送到新版本 | 限制爆炸范围 | 需要良好的指标 |
v1 ████████████████ 95% ← watch error rate / latency
v2 █ 5% ← promote if healthy, roll back if not
└─ automated check on SLOs decides promote vs abort
[ Blue v1 ] ◀─ live ──┐
[ Green v2 ] ◀─ idle ├─ flip router ─▶ Green is live; Blue is instant rollback
没有向后兼容的schema,canary/blue-green会失败,因为两个版本同时运行。始终设计更改以在版本间兼容。
频繁、低风险的部署是使微服务值得其复杂性的原因——缓慢、高风险的发布会抹除自主性优势。
Canary和blue-green限制了坏部署的爆炸范围,并提供近乎即时的回滚,将部署从可怕的事件转变为常规、自动化的日常活动。