滚动更新的基础原理与流量控制
滚动更新的核心思想是永不将所有实例同时置于不可用状态。它维护一个可配置的“最大不可用”或“最大超出”窗口，每次只升级一小批实例。旧实例在停止接收流量后优雅退出，新实例通过健康检查后才接替工作。整个过程对调用方透明，因为负载均衡器始终能把请求转发到健康的端点。
以反向代理（如Nginx）为例，我们可以通过upstream模块配合max_fails和fail_timeout实现简单的滚动摘除。但更通用的方式是在编排系统（如Kubernetes）中利用Deployment的rollingUpdate策略。该策略允许我们指定maxSurge和maxUnavailable，决定新实例的创建速率和旧实例的删除速率。例如，将maxSurge设为1、maxUnavailable设为0，就能确保在升级过程中永远不会出现可用实例数低于期望值的情况。
流量控制的另一关键点是健康检查的真实性。如果应用只是进程存活但无法正确处理请求（例如数据库连接池耗尽、缓存尚未预热），那么健康检查不应返回成功。Kubernetes提供了readinessProbe和livenessProbe：前者决定是否将Pod加入到Service的端点列表，后者用于决定是否重启容器。实现零停机，必须让readinessProbe在应用真正准备好对外服务时再返回成功，而在收到终止信号（SIGTERM）后立即返回失败。这通常需要在应用内部提供/healthz或/ready接口，并配合preStop钩子执行几秒的sleep，确保负载均衡器有足够时间完成端点摘除。
安全补丁场景下的滚动策略设计与实例
安全更新往往比普通功能更新更紧急，且补丁本身可能只是替换文件（如libc库、Java安全包）或修改容器镜像层。此时，滚动更新的触发要足够快，但又不能跳过任何验证步骤。一个稳妥的实施流程是：先在预发环境验证镜像，确认补丁不会破坏兼容性；接着通过修改Deployment的image字段或新增ConfigMap触发滚动升级。在滚动过程中，必须实时监控错误率、响应时间以及操作系统级别的安全告警。
以下是一个Kubernetes Deployment的YAML片段，它定义了一个强制零停机滚动更新的策略，并配置了就绪探针以模拟真实的就绪条件。
apiVersion: apps/v1
kind: Deployment
metadata:
name: secure-app
spec:
replicas: 3
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 0
selector:
matchLabels:
app: secure-app
template:
metadata:
labels:
app: secure-app
spec:
terminationGracePeriodSeconds: 30
containers:
- name: app
image: registry.internal.com/secure-app:v1.2.3-patch
ports:
- containerPort: 8080
readinessProbe:
httpGet:
path: /ready
port: 8080
initialDelaySeconds: 5
periodSeconds: 5
successThreshold: 1
lifecycle:
preStop:
exec:
command: ["/bin/sh", "-c", "sleep 10"]
affinity:
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 100
podAffinityTerm:
labelSelector:
matchExpressions:
- key: app
operator: In
values:
- secure-app
topologyKey: kubernetes.io/hostname
该配置强制maxUnavailable=0，意味着在任何时刻至少保持3个Pod就绪。Pod反亲和性（软策略）尽量将Pod分散到不同节点，避免单节点故障导致多个副本同时不可用。preStop钩子给予10秒宽限期，使得在Pod收到终止信号后，应用仍能维持运行但标记就绪探测为失败，从而让Service在Pod真正退出前完成端点剔除。探针每隔5秒检测一次，满足实时性要求。
对于非容器化环境或传统虚拟机组，滚动更新可以通过Ansible等自动化工具串行执行。在每个节点上执行补丁安装并重启服务，同时利用前端Nginx的health_check模块或HAProxy的httpchk指令主动探测。以Nginx Plus为例，可以为上游组配置主动健康检查：
upstream backend {
zone backend 64k;
server 192.168.1.10:8080;
server 192.168.1.11:8080;
server 192.168.1.12:8080;
}
server {
listen 80;
location / {
proxy_pass http://backend;
health_check interval=3 fails=2 passes=2 uri=/health;
}
}
此时，当某台后端被Ansible打补丁重启时，Nginx快速检测到检查失败（fails=2），立即暂时将该server标记为不可用，并在其后两次连续成功（passes=2）后才重新加入池中。整个过程完全自动化，无需人工摘流量。
零停机打补丁的常见陷阱与验证方法
即使滚动策略配置得当，仍有一些隐性因素可能打破零停机的承诺。首先是会话粘滞（session affinity）问题。如果应用依赖内存会话且未实现外部共享存储，那么当请求被负载均衡器分配到新的Pod时，会话会丢失。此时需要启用基于Cookie的会话保持，让同一用户在滚动期间始终路由到同一节点，但这样做可能使该节点关闭时用户感知到中断。更彻底的方案是将会话状态外置到Redis等共享存储，实现无状态化，这样任何实例被替换都不会影响用户体验。
数据库连接与连接池也是高风险区。滚动更新时，旧实例关闭会导致其持有的数据库连接被强制断开，如果连接池没有做好关闭前的等待和清理，可能导致短暂的事务失败。应用应该在收到SIGTERM后停止接受新请求，并等待现有请求处理完毕（优雅关闭）。例如在Java应用中配置server.shutdown=graceful和合理超时时间。同时，数据库端应配置自动重连和连接验证，确保新实例启动后能立即建立新连接。
另一个需要注意的点是补丁本身的兼容性。安全补丁有时会修改安全协议的最低版本或禁用不安全的加密套件，如果部分旧实例尚未更新，新实例与旧实例间的网络通信可能出现协议协商失败。因此，在滚动更新前必须确认该补丁可以兼容前一版本，否则需要采用蓝绿部署或金丝雀发布来隔离新旧流量，待全部升级完毕后再切换。此外，验证零停机的效果不能仅靠肉眼观察，需要构建量化的压测方案。可以借助工具如wrk2或locust持续施压，同时执行滚动更新，观察延迟分位数和错误率。一个验证脚本示例：
#!/bin/bash
# 持续发送请求并记录状态码
while true; do
curl -s -o /dev/null -w "%{http_code}n" http://service-endpoint/api
sleep 0.1
done | tee status.log
在滚动更新过程中，如果status.log中只出现200状态码，则基本可以认为零停机目标达成。同时，监控系统的告警规则也应该覆盖更新窗口，一旦出现5xx错误或响应时间抖动，立即中止滚动并回滚。最后，不要忽略基础设施层面：节点内核或容器运行时补丁也可能引发滚动重启，此时应当利用节点池（Node Pool）逐组排水、升级、重新加入集群，将应用Pod漂移到健康节点上，实现平台层的零停机安全更新。