哪些部署策略（CI/CD、canary、blue-green）适合微服务？

Question

Accepted Answer

独立部署能力是关键目标，因此每个服务都需要**自己的CI/CD pipeline**加上**低风险发布策略**（通常是canary或blue-green），以便安全地每天发布多次。

## 按服务划分的pipeline

每个服务按照自己的节奏进行构建、测试和部署。对一个服务的更改永远不会触发完整系统发布。

```text
commit ─▶ build ─▶ unit + contract tests ─▶ image ─▶ deploy (one service)
```

## 发布策略

| 策略 | 方式 | 优点 | 缺点 |
|---|---|---|---|
| Rolling | 逐步替换实例 | 简单、默认 | 短时间内混合版本 |
| Blue-green | 两个环境，切换流量 | 即时回滚 | 2倍基础设施 |
| Canary | 将小比例发送到新版本 | 限制爆炸范围 | 需要良好的指标 |

## Canary实践

```text
v1 ████████████████ 95%   ← watch error rate / latency
v2 █                 5%   ← promote if healthy, roll back if not
  └─ automated check on SLOs decides promote vs abort
```

## Blue-green

```text
[ Blue v1 ] ◀─ live ──┐
[ Green v2 ] ◀─ idle  ├─ flip router ─▶ Green is live; Blue is instant rollback
```

## 陷阱

没有向后兼容的schema，canary/blue-green会失败，因为两个版本同时运行。始终设计更改以在版本间兼容。

## 为什么这很重要

频繁、低风险的部署是使微服务值得其复杂性的原因——缓慢、高风险的发布会抹除自主性优势。

Canary和blue-green限制了坏部署的爆炸范围，并提供近乎即时的回滚，将部署从可怕的事件转变为常规、自动化的日常活动。

Rolling	逐步替换实例	简单、默认	短时间内混合版本
Blue-green	两个环境，切换流量	即时回滚	2倍基础设施
Canary	将小比例发送到新版本	限制爆炸范围	需要良好的指标