不可变基础设施与部署：滚动更新与零停机部署

可视化演示

通过新旧实例平滑替换实现零停机，演示滚动循环、更新策略与就绪探针回滚机制。

滚动更新原理

想象一架航班正在一万两千米高空巡航，机长决定更换一台老化的引擎。他不能降落检修——几百名乘客正等着准点抵达。他的策略是在飞行中完成更换：机务先把新引擎挂到空余挂架上，启动并确认动力正常，再拆下旧引擎。四个引擎依次替换，飞机始终维持着足够的推力。乘客只是偶尔感到轻微颠簸，浑然不觉引擎已全部换新。

这套“边建边拆”的策略正是滚动更新的精髓。传统部署像“先降落后检修”：先把所有旧实例停掉，再拉起新版本，期间服务完全不可用。而滚动更新让新旧实例在短时间内共存——新实例就绪一个，旧实例才下线一个，服务如同飞机引擎一样始终“有动力”。

在 Kubernetes 中，滚动更新由 Deployment 控制器编排。Deployment 会创建一个新版本的 ReplicaSet（相当于新引擎的“编制名册”），然后逐步缩减旧 ReplicaSet 的副本数，同时扩大新 ReplicaSet。每次只替换一部分实例，直到所有 Pod 都换成新版本。这个过程让可用性公式中的“修复时间”大幅缩短，因为故障实例被自动替换，无需人工停机介入。

拆下的旧引擎先放进货仓而不是扔进海里——每个历史版本的镜像都保留着，随时可以装回去。这就是不可变基础设施配合滚动更新的意义：飞机在飞，服务在线，变化在无声中完成。

参数配置策略

机长换引擎前会明确两条硬性约束：任何时刻至少保留几台引擎运转？机舱最多能多放几台备用引擎？如果一次拆两台、偏偏另一台又罢工，飞机就失去足够动力；如果备用引擎堆满货仓，飞机超重根本飞不起来。这两条约束，就是滚动更新的节奏开关。

Kubernetes 滚动更新同样有两条关键参数：maxUnavailable（最大不可用数）和 maxSurge（最大额外实例数）。maxUnavailable 决定更新过程中最多允许几个旧实例同时离线，默认 25%；maxSurge 决定允许超出期望副本数的实例数量。它们共同刻画了“机舱的承重限额”。

生产环境为了保证零停机，通常把 maxUnavailable 设为 0，意思是：只有新实例就绪并接管流量后，才允许下线旧实例，任何时刻都不出现“空窗期”。maxSurge 设为 25%，表示可以多启动 25% 的新实例来加速替换。再加上 minReadySeconds——新实例稳定运行多少秒后才算数——三者共同控制着换引擎的节奏：既不让飞机失去动力，也不让货仓超载。

换引擎的节奏也是这样：先装一台新引擎确认稳定，再拆一台旧的。maxUnavailable=0 保证飞机永远有足够引擎，maxSurge 有上限保证不超重。滚动更新，就是在两条硬约束之间寻找最优的替换节奏。

就绪探针设计

新引擎挂上挂架，不代表可以立刻投入使用。机务人员必须盯着仪表盘：转速达到巡航值、油压稳定、温度正常，最后还要逐步加大推力做试车确认无异常——这一整套检查，就是飞机版的“就绪探针”。没有这套仪表，谁都不敢把新引擎接上动力系统。

在 Kubernetes 中，就绪探针（Readiness Probe）负责回答一个问题：“这个新实例能接流量了吗？”探针定期向容器发起检查，检查通过后负载均衡器才把流量转发给它；没通过就继续等，绝不提前放行。它和存活探针（Liveness Probe）不同——存活探针决定容器是否要重启，就绪探针只决定流量放不放行。

就绪探针有三种类型：HTTP GET（请求某个路径，看返回码是否为 200）、TCP Socket（检查端口能否建立连接）、Exec（在容器内执行命令看退出码）。关键参数有三个：initialDelaySeconds（容器启动后等多久才开始探测）、periodSeconds（每隔几秒探一次）、failureThreshold（连续失败几次判定未就绪）。对 AI 推理服务而言，探针不仅要确认端口可访问，还要确认模型权重已加载、推理引擎已预热，否则流量提前进来只会产生一串超时。

探针就是机长的仪表。没有仪表盲换引擎，新引擎是否可靠全靠运气；有了探针，每次替换都建立在“确认安全”之上。新实例真正 ready，旧实例才正式退役。

会话保持处理

乘客正在高空看电影、用机上 Wi-Fi 发消息。换引擎时，如果娱乐系统的供电闪断一下，乘客会立刻投诉。机务的解决办法是“无缝切换”：新引擎接入供电系统的瞬间，旧引擎继续维持片刻供电，娱乐画面全程不黑。这种切换的精细度，决定了乘客的体验。

Web 服务也有类似的“供电”——会话（Session）。用户在电商网站的登录状态、购物车信息，通常保存在会话中。当旧实例退出时，如果会话没有被妥善迁移，用户会被强制登出、购物车清空。这就是滚动更新中最容易“被投诉”的环节。

处理方案有三层。第一层：负载均衡器开启会话粘滞（Session Affinity），让同一用户的请求固定落到同一个后端实例，避免请求在不同实例间跳来跳去。第二层：旧实例收到关闭信号后先“排空”（drain），停止接收新请求，专注处理完正在进行的请求。第三层：Kubernetes 在停止容器时先发送 SIGTERM 信号，应用捕捉到信号后执行清理逻辑，等待 grace period 结束才被强制结束。如果排空处理得好，会话丢失率趋近于零。

乘客的娱乐系统全程没黑，是因为新旧引擎的“供电切换”设计得足够精细。服务升级时用户的会话不掉线，同样得益于粘滞、排空与优雅退出这三重保险。

AI推理实践

这架飞机换的不只是普通引擎，还是一台“智慧引擎”——它内置了全球航线数据库和自动驾驶算法。新引擎装好后，必须先加载航线数据、跑一遍完整的自检程序，才能接入自动驾驶系统。如果没等数据加载完就切换，飞机连基本的航线都认不出来，更别提自动巡航了。

AI 推理服务正是这样一台“智慧引擎”。一个 GPU 实例上运行着大模型，模型权重从磁盘加载到显存往往需要数十秒甚至数分钟。滚动更新时，如果新实例还没加载完模型就被并入流量池，用户的推理请求会全部超时或返回垃圾结果。这也是 AI 服务滚动更新与普通 Web 服务的最大分水岭。

AI 推理服务的滚动更新方案需要“四件套”：就绪探针内检查模型加载完成的标志位；新实例就绪后主动发送 warmup 请求预热推理引擎（如 TensorRT、ONNX Runtime 的 CUDA 上下文）；持续监控 GPU 利用率和 P99 延迟，发现性能劣化立即暂停更新；用实例饱和度公式评估当前实例数能否扛住流量，避免盲目滚动导致过载。

给智慧引擎换新，核心不是换硬件那一刻，而是让新引擎“带着完整的记忆和手感”上岗。AI 服务的滚动更新，本质上就是让新模型在不中断服务的前提下，无缝接替旧模型的推理职责。

回滚与评估

新引擎在空中试车时，仪表显示振动频率异常。机长没有慌，因为旧引擎并没有扔进海里——它好端端地放在货仓里，随时可以重新挂上。机组决定：停止更换计划，把已装上的新引擎拆下，换回旧引擎。飞机继续平稳飞行，仿佛什么都没有发生过。

在不可变基础设施中，回滚同样不是“撤销一个操作”，而是“反向发布”。每个版本镜像都是不可变的——构建完成后永远不会被修改。旧版本镜像依然存在于镜像仓库中，滚动更新的回滚，就是让部署目标重新指向旧版本镜像，让实例重新从旧镜像重建。

自动回滚由健康信号驱动：当新版本实例的就绪探针持续失败、错误率超过设定阈值、或 P99 延迟明显劣化于基线时，控制系统自动触发回滚。回滚的耗时取决于三个变量：流量切换时间、单个实例重建时间、回滚批次数量。性能评估也是一项必修课——更新前要记录基线指标（GPU 利用率、错误率、吞吐量、P99），更新中持续对比，回滚后重新评估，才能量化这次变更对服务的影响。

旧引擎放货仓不是因为恋旧，而是因为备用方案永远是最可靠的保险。不可变基础设施的魅力就在于此：版本不可变，回滚变得异常简单，飞机永远有退路。

AI 应用场景

Python 演示

import randomimport time  class Instance:    """模拟一个应用实例 (Pod)"""     def __init__(self, version, name):        self.version = version        self.name = name        self.ready = True        self.connections = random.randint(5, 20)        self.health = 100     def drain(self):        """优雅排空: 停止接新请求, 等存量请求处理完"""        self.ready = False        time.sleep(0.1 * self.connections / 5)        self.connections = 0     def check_ready(self):        """模拟就绪探针"""        return self.ready and self.health >= 80  class Deployment:    """模拟一个 Deployment 控制器"""     def __init__(self, instances):        self.instances = instances     def add(self, instance):        self.instances.append(instance)     def remove(self, name):        self.instances = [i for i in self.instances if i.name != name]     def total_ready(self):        return sum(1 for i in self.instances if i.check_ready())     def rolling_update(self, new_version, batch_size=1):        print("=== 开始滚动更新到 {} ===".format(new_version))        old_list = [i for i in self.instances if i.version != new_version]        for idx, old in enumerate(old_list):            old.drain()            self.remove(old.name)            print("  移除 {}, 当前 {} 个实例".format(old.name, len(self.instances)))            time.sleep(0.05)            new_name = "pod-{}-{}".format(idx + 1, new_version)            new_inst = Instance(new_version, new_name)            self.add(new_inst)            print("  新增 {}, 就绪探针通过, 当前 {} 个实例就绪".format(                new_name, self.total_ready()))            if (idx + 1) % batch_size == 0:                print("  -- 完成一批 ({} 个), 等待确认...".format(batch_size))        print("=== 更新完成, 全部实例版本: {} ===".format(new_version))  def main():    deploy = Deployment([        Instance("v1", "pod-1-v1"),        Instance("v1", "pod-2-v1"),        Instance("v1", "pod-3-v1"),    ])    print("更新前: {} 个实例在线".format(deploy.total_ready()))    deploy.rolling_update("v2", batch_size=1)    print("更新后: {} 个实例在线".format(deploy.total_ready()))  if __name__ == "__main__":    main()

1. self.connections = random.randint(5, 20)模拟每个实例当前正在处理的请求连接数，随机性贴近真实负载。
2. def drain(self)优雅排空的核心：先标记不可用，再等存量请求处理完，最后才真正“关闭”。
3. old.drain(); self.remove(old.name)先排空再移除，保证没有请求被强行掐断，这是零停机的关键动作。
4. new_inst = Instance(new_version, new_name)创建新版本实例，模拟新 Pod 被 Deployment 拉起。
5. self.add(new_inst)新实例加入负载池，对应“接管流量”。
6. self.total_ready()模拟就绪探针统计，只有健康分达标且 ready 标记为真的实例才被计数。
7. if (idx + 1) % batch_size == 0批次节奏控制，每替换完一批就“暂停确认”，对应部署策略中的批次大小参数。

常见误区

面试题