微服务治理中的滚动更新实战技巧

在现代软件开发中，微服务架构已经成了主流。服务拆得越细，上线频率越高，怎么保证更新时不丢请求、不崩系统，就成了关键问题。滚动更新就是解决这事儿的常用办法，尤其适合那些不能停机的业务场景，比如电商大促、在线支付这些。

什么是滚动更新

滚动更新的核心思路是“边退边进”——逐步替换旧实例，同时上线新版本实例。不像一次性全量发布，它通过控制批次和节奏，把风险摊平。比如你有10个订单服务实例，先换2个新的，跑稳了再换下一批，直到全部更新完。

这种方式能最大限度减少对用户的影响。想象一下双十一大促，你正要付款，结果系统提示“服务升级中”，那体验得多差？滚动更新就是为了避免这种尴尬。

常见实现方式

在 Kubernetes 环境下，滚动更新几乎是标配。Deployment 资源本身就支持 strategy 字段来定义更新策略。下面是个典型的配置示例：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-service
spec:
  replicas: 10
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 2
      maxUnavailable: 1
  template:
    spec:
      containers:
      - name: app
        image: order-service:v2.1

这里 maxSurge 表示最多可以比原定副本多启动几个（这里是2个），maxUnavailable 是允许不可用的实例数上限（1个）。这样既能加快更新速度，又不会让用户请求大面积失败。

配合健康检查更安全

光有滚动策略还不够，得让系统知道“新实例到底行不行”。这就得靠就绪探针（readinessProbe）和存活探针（livenessProbe）。

比如某个新实例启动后依赖数据库连接，但网络抖动导致连不上。这时候即使进程起来了，也不能对外提供服务。readinessProbe 会检测接口是否可响应，只有通过才把它加入负载均衡池。

readinessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 10
  periodSeconds: 5

这个配置表示容器启动10秒后开始检查 /health 接口，每5秒一次。只有返回成功，才会被标记为“可服务”。

灰度与分批控制

对于特别敏感的服务，比如用户中心或计费模块，可以结合服务网格做更精细的流量控制。Istio 就能按百分比逐步导流，先放5%的请求到新版本，观察日志和指标没问题，再慢慢加到100%。

这种模式和滚动更新不冲突，反而互补。滚动更新管的是实例替换，而流量切分管的是请求走向，两者配合能让发布过程像“外科手术”一样精准。

实际项目中，不少团队会把 Jenkins 或 GitLab CI 和 K8s 更新流程打通。代码一合并，自动构建镜像，触发滚动更新，全程可视化进度。出了问题还能一键回滚，效率高也安心。