software

# 零停机蓝绿部署规模化：我在迁移 500+ 微服务时的收获

发布: (2025年12月12日 GMT+8 04:45)
4 min read
原文: Dev.to

Source: Dev.to

生产环境 12 个月后的结果

指标之前之后改进幅度
部署失败率18 %0.7 %降低 96 %
平均部署时间42 分钟6 分钟加快 86 %
P99 延迟峰值+280 毫秒+11 毫秒—
年度事故成本£1.8 M£34 k节省 £1.766 M
年度节省（失败回滚 & 幽灵 pod）—~£340 k—

为什么滚动更新已经不够了

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxSurge: 25%
    maxUnavailable: 0

理论上看起来很安全，实际情况却是：

  • 健康检查延迟导致 3–7 秒的 5xx 错误。
  • 一个异常 pod 会阻塞整个 rollout。
  • Pod 中断预算（PDB）经常被忽视。
  • 回滚需要额外的 20–30 分钟，且常常失败。

我们需要一种即时、原子级的流量切换方式。

交付的 2025 架构

EKS 1.29 → Istio 1.20 → ArgoCD 2.11 → Helm 3.14 + Kustomize
│
└─ 同一集群中的两个完全相同的环境
     ├─ blue  ← 当前 LIVE（100 % 流量）
     └─ green ← 新版本先部署到这里

单个 Istio VirtualService 拥有公共主机名。

魔法：一行代码切换全局

# virtualservice-prod.yaml
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: payment-api
spec:
  hosts:
  - payment.api.company.com
  http:
  - route:
    - destination:
        host: payment-api
        subset: live       # ← 只改这里
      weight: 100

子集只需定义一次：

subsets:
- name: blue
  labels:
    env: blue
- name: green
  labels:
    env: green
- name: live
  labels:
    env: blue   # 最初指向 blue

流量切换 = 一个 JSON patch：

kubectl patch destinationrule payment-api --type=json \
  -p='[{"op":"replace","path":"/spec/subsets/2/labels/env","value":"green"}]'

完全自动化流水线（GitHub Actions）

- name: Deploy to green
  run: helm upgrade payment-api ./chart --set env=green --install

- name: Smoke tests on green
  run: ./smoke.sh https://payment-api-green.internal

- name: Instant traffic switch
  if: success()
  run: flipper switch payment-api green --instant

- name: Wait 5 min then terminate old blue pods
  run: |
    sleep 300
    kubectl delete pod -l app=payment-api,env=blue --grace-period=30

我们遇到的坑（以及解决办法）

  • 数据库迁移 – 先在 green 上执行 expand/contract + Liquibase runOnChange。
  • Istio mTLS “peer not authenticated” – 使用 init container 预热 SDS 证书。
  • Prometheus 抓取旧指标 – relabel_configs 丢弃 env != live。
  • 短暂的超时峰值 – 客户端重试 + 2 秒超时设置。

你的复制‑粘贴蓝图

  1. 安装 Istio + Argo CD。
  2. 为每个 Helm 发布复制一份，使用 --set env=green。
  3. 在 DestinationRule 中创建 blue / green / live 子集。
  4. 最初把 “live” 指向 blue。
  5. 编写一个小型 flipper 脚本（已开源 – 见下方 GitHub 链接）。

结束语

如果你在 2025 年仍在使用滚动更新，那你正为可靠性、成本和睡眠付出隐藏的代价。Blue‑green + Istio + Argo CD 已经成为任何严肃平台的基准。

祝部署顺利（且不再被呼叫器惊醒）！

参考资料

  • GitHub:
  • LinkedIn:
Back to Blog

相关文章

阅读更多 »