微服务治理滚动更新方法详解

滚动更新的基本原理

在微服务架构下，服务实例数量多、依赖关系复杂，直接停机发布新版本几乎不可行。滚动更新就是为了解决这个问题而生的——它通过逐步替换旧实例、上线新实例的方式，实现平滑发布。

想象一下高峰期的地铁换车：不可能把整条线路停了统一换新车，而是让新车一节节加入，旧车慢慢退出。滚动更新也是这个思路，系统始终在线，用户无感知。

核心流程拆解

典型的滚动更新流程包括以下几个步骤：

准备新版本镜像并推送到镜像仓库
从集群中挑选部分节点开始部署新版本
等待新实例健康检查通过
将流量逐步导入到新实例
确认运行稳定后，继续升级剩余节点
全部完成后清理旧实例资源

整个过程依赖于服务注册与发现机制。比如使用 Kubernetes 时，Deployment 控制器会自动管理 Pod 的替换节奏。

Kubernetes 中的配置示例

在 K8s 中，可以通过设置 strategy 字段来定义滚动更新行为：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: user-service
spec:
  replicas: 4
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  selector:
    matchLabels:
      app: user-service
  template:
    metadata:
      labels:
        app: user-service
    spec:
      containers:
      - name: app
        image: user-service:v2.1

这里 maxSurge: 1 表示最多允许比原定副本多启动一个 Pod，maxUnavailable: 0 意味着任何时候都不能有实例不可用，确保服务连续性。

配合健康检查更安全

光有滚动策略还不够，必须加上合理的健康检查。K8s 支持 livenessProbe 和 readinessProbe，前者判断容器是否存活，后者决定是否将流量分发给该实例。

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

这样即使新 Pod 启动了，也得等接口返回正常才纳入负载均衡池，避免把请求打到“半醒”状态的服务上。

灰度验证也很关键

虽然滚动更新本身是批量操作，但可以结合灰度发布进一步控制风险。比如先在一个可用区更新少量实例，接入内部测试流量观察日志和性能指标，没问题再全量推开。

有些团队还会在 CI/CD 流程中集成自动化回滚逻辑：一旦监控系统检测到错误率突增或延迟飙升，立即触发反向滚动，恢复至上一版本。

实际场景中的注意事项

数据库变更要特别小心。如果新版本代码依赖新的表结构，但旧实例还在运行，就可能出错。常见的做法是：先把数据库变更设计成向后兼容，等所有实例都升级后再清理废弃字段。

另一个容易忽略的是外部依赖版本对齐。比如订单服务调用库存服务，如果库存服务先升级并修改了接口格式，而订单服务还没跟上，就会导致调用失败。这时候建议采用版本共存或接口降级策略。