一、零宕机升级概述

什么是零宕机升级

零宕机升级，说白了就是——系统在升级过程中，用户完全感觉不到服务中断。

我见过不少团队把「灰度发布」和「零宕机升级」混为一谈。其实不一样。灰度发布是流量控制策略，零宕机升级是可用性目标。你可以在灰度发布的基础上实现零宕机，也可以完全不灰度，直接全量升级但保证服务不中断。

零宕机升级的核心特征有三个：

• 用户无感知——交易请求不报错、不超时、不丢单
• 数据不丢失——在途订单、持仓状态、资金流水，一条都不能少
• 可回滚——出问题能秒级切回旧版本，而不是「先修半小时再说」

嗯，这里要注意：零宕机不等于零风险。它只是把风险窗口压缩到极致，而不是消灭风险。

为什么交易系统需要零宕机升级

你想想看，交易系统停一分钟意味着什么？

我亲身经历过一次。某券商核心交易系统升级，计划停机15分钟。结果数据库迁移出了点岔子，实际停了47分钟。那47分钟里，客户无法下单、无法撤单、无法查询持仓。客服电话被打爆，监管电话紧随其后。最后算下来，直接经济损失倒不大，但品牌信誉的损失——没法用钱衡量。

交易系统对零宕机的需求，来自几个硬约束：

约束维度	具体表现	我的经验
监管要求	交易时段必须连续服务	某地监管明确要求核心交易系统可用性≥99.995%
业务连续性	订单流不能断，风控不能停	我在期货公司见过，断一秒可能触发穿仓
资金安全	升级过程中资金状态必须一致	曾经因为升级导致对账不平，追了三天数据
市场声誉	一次重大故障可能流失大量客户	某互联网券商宕机后，客户量一个月跌了30%

说白了，交易系统不是电商网站。电商挂了你可以说「系统升级中，稍后再来」。交易系统挂了，客户可能正在平仓止损，每一秒都是真金白银。

零宕机升级的核心挑战

我做了十几年交易系统运维，踩过的坑能写一本书。零宕机升级最大的挑战，其实不是技术本身，而是「你以为没问题的地方，往往就是问题」。

具体来说，核心挑战有四个：

1. 状态一致性

交易系统是有状态的。用户的登录态、订单的撮合状态、资金的冻结状态……这些状态在升级过程中怎么保持？

我曾经遇到一个案例：升级了交易网关，结果老连接上的会话状态全部丢失，用户被迫重新登录。虽然只花了3秒，但高频交易客户那3秒里错过了行情，直接投诉到监管。

2. 流量平滑切换

从旧版本切到新版本，流量怎么导？一下子全切过去，新版本扛不住怎么办？

我建议的做法是：先切1%的流量，观察5分钟，没问题再逐步增加。但这里有个坑——有些业务场景不支持「部分流量」。比如撮合引擎，同一个订单簿的订单必须路由到同一个实例，否则会出现价格倒挂。

3. 数据兼容性

新旧版本同时运行，数据结构可能不一样。老版本写的数据，新版本能不能读？反过来呢？

我记得有一次，我们把订单状态字段从int改成varchar，结果老版本还在运行的定时任务写入了int值，新版本直接解析失败。嗯，从那以后我养成了一个习惯：任何数据结构的变更，必须做双向兼容测试。

4. 回滚能力

升级出问题了，能不能快速回滚？很多团队说「能」，但真到回滚的时候才发现——数据库表结构变了，回滚脚本没准备；或者新版本改了缓存key的格式，回滚后老版本读不到数据。

零宕机升级的目标

目标其实很简单，就三条：

1. 用户无感——升级期间，用户该下单下单，该撤单撤单，一切照常
2. 数据无损——升级前后，数据完全一致，对账能平
3. 快速回滚——出问题能在1分钟内切回旧版本

但说实话，这三个目标同时实现，难度不小。我见过很多团队，能做到「用户无感」但「数据有损」，或者「数据无损」但「回滚要半小时」。真正三个都做到的，凤毛麟角。

零宕机升级的知识体系

下面这张图，是我自己梳理的零宕机升级知识体系。你可以把它当成整个课程的地图：

这张图把零宕机升级拆成了三层：挑战层 → 目标层 → 策略层。后面的课程，我们会一层一层往下拆。每个挑战怎么应对，每个目标怎么达成，每种策略的优缺点和适用场景——我都会结合真实案例来讲。