每次发布总有用户报错：连接排空和优雅停机的几秒差在哪

几乎每个做过滚动发布的团队都见过这个画面：发布窗口一开，错误率曲线上准时冒出一小撮尖刺，形态很固定——少量 502、少量连接被重置、少量请求超时，持续时间通常只有几秒到十几秒，窗口一过立刻回到基线。把版本回滚到上一个，用同样规模、同样时段的流量再走一遍，这批报错却一个都复现不出来。于是结论常常被写成"新版本有问题"，然后开始翻代码 diff，翻到最后发现改动只是一个日志字段。

这类报错的共同特征是它对代码不敏感、对时序极度敏感。它只在实例被替换的那几秒出现，只出现在正在下线的那批实例上，而且报错的请求往往不是"处理失败"，而是"根本没被完整处理"——连接被从中间掐断，或者请求刚被接受、进程就没了。换句话说，掉的不是逻辑，是时间。发布期的请求丢失，绝大多数是三层时序没对齐造成的：负载均衡侧什么时候把这台实例摘掉、进程什么时候开始拒收新连接、已经在处理的那批请求有多少时间跑完。这三层各有自己的默认值，而默认值几乎都不是为"无损"设计的。

发布窗口里那批 502 从哪来

先把现象的描述做细，因为"发布期有 502"这句话本身没有定位价值。真正有用的是四个维度的拆分：报错发生在发布窗口的第几秒、集中在哪几台实例、错误码是 502 还是连接重置、受影响请求的共同特征是什么。

如果报错集中在某几台正在下线的实例，而存活实例一切正常，那基本可以排除新版本逻辑问题——逻辑问题会均匀分布在所有已升级实例上。如果错误码是连接被对端重置，说明进程是在连接还开着的时候消失的；如果是网关返回的 502，说明上游在等待一个永远不会回来的响应；如果只有超时，说明请求可能还在队列里就被丢弃了。再往下一层看受影响请求的特征：是不是大 body 的上传、是不是耗时偏长的查询接口、是不是流式响应、是不是 WebSocket 上的长会话。这些请求有一个共同点——它们的结束时间不可控，而发布流程给的时间预算通常是固定的。

还有一个很关键的判断依据：报错会不会随发布批次的大小变化。如果一次只替换一台实例时几乎不掉，一批替换多台时明显变多，那问题大概率在共享层的时序上，比如注册中心的刷新周期被并发放大、或者网关侧的连接池在新旧实例切换时集中失效。这些信息不需要额外工具，网关访问日志里的上游地址、实例 ID、响应状态码和耗时就能拼出来。

把重启拆成四个时间点

一个实例被替换，表面上是一个动作，实际是四个时间点按先后顺序排成的链条。把它们拆开命名，后面所有讨论才有共同语言。

第一个时间点是摘除：负载均衡或者服务注册中心把这台实例从可用列表里拿掉，此后新建的请求不再被调度到它身上。第二个时间点是停止接收：进程自己关闭监听端口或者开始对健康检查返回失败，让"外部不再调度"和"自己不再接新"这两件事同时成立。第三个时间点是存量处理：已经在途的请求继续跑完，包括正在读 body 的、正在查数据库的、正在往客户端写流式数据的。第四个时间点是进程退出：进程真正结束，监听 socket、已建立连接、后台线程、连接池一起被回收。

无损发布要求这四个点严格按顺序发生，且相邻两点之间留有足够间隔。绝大多数事故出在两个地方：要么摘除晚于停止接收——进程已经不接新连接了，但上游还在往它身上调度，于是新建请求被直接拒绝；要么存量处理的时间预算短于实际需要——进程退出先发生，在途请求被连根拔起。前者产生 502，后者产生连接重置。两者都可能在同一批发布里同时出现，所以监控上看到的是"502 和 reset 混在一起"。

把时间点画成一条时间轴还有一个好处：它能让你直接看出哪一项是瓶颈。如果摘除到停止接收之间的间隔是几秒量级，而存量处理只给了很短的预算，那么优化顺序应该是先压缩摘除延迟，再谈排空预算；否则你给排空多加十秒，也只是让进程在没人访问的情况下空等。

摘除到真正生效之间隔了多久

很多人以为"调用摘除接口"是一个瞬时动作，实际上从你发出摘除指令，到上游真的不再把新请求打过来，中间隔着好几段被动等待。

第一段是健康探测的周期。负载均衡判断一个实例是否可用，靠的是周期性探测，而且通常要连续失败若干次才判定为不健康，避免单次网络抖动导致误摘。这意味着摘除生效的延迟大致等于"探测间隔乘以失败阈值"，再加上判定生效后配置下发或客户端拉取的刷新周期。不少组件的常见默认值大约在这个量级：探测间隔在数秒、失败阈值在两到三次，再叠加注册中心推拉模型的刷新周期，整体落到十秒上下并不罕见，具体以你使用的组件配置为准。第二段是注册中心的传播方式，如果是客户端定时拉取服务列表，那么每台调用方本地还有一份缓存，缓存过期前它依然会往旧实例打。第三段是上游网关自身的连接池，长连接的复用让"摘除列表"对已建连接不起作用。

正确的做法是不要等被动探测，而是主动注销：进程在收到停止指令后，第一步就向注册中心发起注销或者把自己标记为不健康，然后主动等待一个完整的探测周期加刷新周期，确认新建流量已经归零，再进入下一步。这个等待不是浪费，它是整条链里唯一不可压缩的常量，必须被显式写进发布脚本，而不是靠 sleep 猜一个数字。

验证这一层是否真的生效，看的是该实例的新建连接数曲线。摘除生效后，新建连接应该在数秒内趋近于零；如果摘除动作发出后仍然有稳定速率的新连接进来，说明探测周期、失败阈值或客户端缓存里至少有一项比你预估的更长。

长连接在什么时候会被硬切断

摘除只影响"新建连接"，这是最容易被忽略的一点。现代网关和客户端普遍使用连接复用，一条建立好的连接上会连续跑几十上百个请求。当实例从列表里被摘掉时，已经建立的连接不会自动断开，连接上的后续请求依然会打到这台即将下线的实例上。如果你的发布流程是"摘除 → 立刻杀进程"，那么这批复用连接上的请求就是最直接的受害者。

连接什么时候会被硬切断，取决于进程退出时 socket 的关闭方式。优雅关闭会先发结束标记、把发送缓冲区里的数据发完；而进程被强制终止时，内核直接回收 socket，对端收到的就是连接重置。更麻烦的是，很多框架在收到终止信号后的默认行为是立刻退出，连正在写的大响应体都会被截断——客户端看到的是一个状态码正常、body 不完整的响应，这类问题在日志里极难发现。

处理办法有两个方向。一个方向是让进程主动结束复用连接：在停止接收阶段就对健康检查返回失败，同时在响应里带上关闭标记的头部，或者对 HTTP/2 连接发送结束帧，让客户端在下一个请求时主动新建连接到健康实例。另一个方向是给复用连接设置上限，比如单条连接最多处理多少个请求、空闲多久就回收，这样即使不做特殊处理，连接也会在一个可控的时间窗口内自然轮换完。这两个方向的取舍在于：前者收敛快但依赖客户端配合，后者不依赖客户端但收敛慢，需要的时间预算更长。

客户端那头还在往旧实例上打

服务端把顺序排得再整齐，客户端那边也可能有自己的一份"旧视图"。最常见的三处是：域名解析结果的本地缓存、客户端连接池里已经建好的长连接、以及从服务端下发或配置中心拉取的地址列表。

域名解析的缓存受记录生存时间影响，但这个时间只是建议值，操作系统、运行时、应用自己都可能各缓存一份，实际生效时间常常长于记录上写的值。客户端连接池则更直接：池子里躺着的连接指向的就是旧实例的地址，只要连接还活着，请求就会继续走老路。这也是为什么"摘除已经生效"和"客户端还在报错"可以同时成立。

于是很自然的一个想法是让客户端重试。重试确实能把大部分掉掉的请求救回来，但它有两个前提必须确认。第一，被重试的请求必须是幂等的，否则一次发布可能带来重复下单、重复扣款这类比 502 严重得多的问题；对非幂等接口，正确做法是让它失败得干净、让用户重新发起，而不是在客户端悄悄重试。第二，重试必须是收敛的——如果大量客户端在同一瞬间发现连接断开，然后同时重连、同时重试，就会形成一次重试风暴，把流量整体放大数倍，反而把还活着的实例压垮。给重连加上随机抖动、限制重试次数与重试预算，是这一层必须写进设计的内容。

还有一个常被忽略的顺序问题：客户端的超时时间如果短于服务端的排空预算，那么服务端还在认真处理存量请求，客户端已经放弃了。这种情况下请求其实处理完了，但用户看到的是失败。排空预算要和客户端超时一起做对齐，而不是各定各的。

预算按最长请求乘以 safety 系数来定

排空预算不是一个拍脑袋的数字，它有一个明确的计算起点：你的接口在途耗时分布的上界。

具体做法是取近一段时间内所有接口耗时的高分位值，找出其中最慢的那几个接口——通常是大文件上传、复杂报表查询、批量导出、调用链较长的聚合接口，然后以它们的最大或高分位耗时作为基数。在这个基数上乘一个安全系数，用来覆盖发布时刻的额外开销：此时实例可能正在做优雅关闭、线程池正在收缩、缓存可能还没热、数据库那边可能还有同批次其他实例同时在发布。安全系数取多少没有标准答案，取决于你的耗时分布有多长的尾巴；如果高分位和最大值之间差距很大，说明长尾很重，系数就要给得更大。

算出来的数字还要再加上前面那一段不可压缩的摘除延迟。也就是说，从发出停止指令到进程被强制终止的总时长，至少应该覆盖"摘除生效时间 + 最长请求耗时 × 安全系数"。这个总时长需要同时写进两个地方：应用自己的优雅停机超时，以及平台或进程管理器强制终止的超时。两者必须一致且前者略小于后者，否则会出现应用还在认真排空、外面已经把它强杀的情况。

预算不够时怎么办，也要提前定好。合理的兜底不是硬切断，而是让进程在预算耗尽前主动结束那些明显跑不完的请求：返回一个明确的错误码，让客户端知道这次调用失败了、可以安全重试。这比让连接静默断开要好得多——前者是可观测、可重试的失败，后者在客户端看来是网络故障，很难判断请求到底有没有被处理。

把长连接和 WebSocket 单独拎出来

普通请求有明确的开始和结束，长连接类流量没有。WebSocket 连接一旦建立，可能几十分钟甚至几小时都不结束；服务端推送、流式响应、长轮询也是同理。对这类流量，"等存量请求处理完"这句话根本没有定义——它永远不会自己处理完。

处理方式必须变成协商式的。服务端在准备下线前，先向连接上的对端发送一个应用层的关闭预告或者结束帧，明确告诉客户端"这台实例要退了，请在某个时间窗口内重新连接"；客户端收到后主动断开并重连到健康实例。这里的重点是重连窗口必须错开：如果所有客户端同时收到预告、同时重连，结果就是一次规模不小的瞬时洪峰。给客户端的重连时刻加上基于连接标识的随机抖动，让重连在时间轴上摊开，是这一层最有效也最容易被漏掉的措施。

网关侧的超时配置同样要对齐。长连接类流量通常受网关的空闲超时和读写超时约束，如果这些超时短于你的排空预算，那么连接会在排空完成前被网关单方面切断，服务端做再多的优雅处理都没有意义。反过来，如果网关超时设得过长，故障实例上的连接会长时间占着资源不释放。合理的做法是给长连接类路径单独配置超时，让它明显大于普通接口的排空预算，同时用应用层的预告机制来主动收敛，而不是靠超时被动兜底。

还有一类容易被误伤的是流式响应。服务端已经写出了一部分响应头和数据，进程却在中间退出，客户端可能只收到半截数据。这类接口在排空阶段应当被特殊标记：要么拒绝在排空期间新建，要么在关闭前显式写入结束标记，让客户端能区分"正常结束"和"被截断"。

数据库事务与后台任务会不会被连根拔起

HTTP 层排空只是可见的那一部分，进程退出时一起被回收的还有数据库连接池、消息队列消费者、定时任务线程和本地缓存的刷盘逻辑。这些组件的收尾顺序如果没设计，同样会造成数据层面的问题。

数据库连接这块最常见的错误是关闭顺序反了：进程先关掉连接池，此时还有在途请求正持有连接执行事务，于是事务被中断、连接被强制回收。正确的顺序是先停入口，再等排空，最后关依赖——先停止接收新请求，等所有在途请求跑完、连接归还到池中，再关闭连接池。事务本身是否会被切断，取决于进程退出时事务处于哪个阶段：已提交的没有风险，正在执行的会被数据库侧回滚，这通常是安全的；真正危险的是"应用认为成功了、数据库其实没提交"这类跨阶段的中间态，因此事务边界必须清晰，且关键写入要可重放或可核对。

消息队列消费者要处理的是位点与再均衡。进程准备退出时，应当先停止拉取新消息、把已拉取但未处理完的消息处理完并提交位点，然后主动退出消费组，触发一次干净的再均衡，而不是让协调者通过心跳超时才发现它离开。后者会带来一段消息无人消费的空窗，前者能把空窗压到最小。

定时任务与后台线程则要在退出流程里被显式 join。很多应用在收到终止信号后只处理了主线程，后台还在跑的补偿任务、日志刷盘、缓存回写直接被中断，这类问题往往不会立刻暴露，而是在数据一致性核对时才被发现。发布脚本里应该包含一次"退出前的收尾清单"检查，把这几类组件的关闭顺序固定下来。

让灰度与回滚共用同一条时间线

灰度和回滚经常被当成两件独立的事，实际上从时序角度看，它们是同一件事的两次执行：都要把一批实例从流量里摘掉、排空、替换、再放回。如果发布流程里的排空逻辑是对的，那么回滚时它也应该是对的；如果回滚时出现了发布时没有的报错，通常说明回滚走的是另一条更快的路径，把排空跳过了。

批次大小是这一层最值得调的参数。一批替换的实例越多，同时在排空的连接就越多，网关侧需要重建的连接也越多，重连风暴的风险随之上升；批次太小，发布总时长又会被拉长。合理的做法是按"同时处于排空状态的实例数"来定批次，而不是按百分比——因为决定压力的是绝对数量。同时必须保证任何时刻的可用实例数不低于承载当前峰值流量所需的下限，这个下限要在发布前算清楚，而不是发布时凭感觉。

观测指标也要提前定好。发布窗口里至少要看四个数：错误率与错误码分布、正在排空的实例上的在途请求数、新建连接数的下降曲线、以及进程的退出原因。第四个最容易被忽略——如果进程是被强制终止而不是正常退出，说明排空预算不够或者优雅停机逻辑没生效，这类信息在退出码和进程管理器的日志里都能拿到。把这些指标和发布批次打上同一个标签，事后才可能把某一次尖刺精确对应到某一批实例。

收到终止信号就立刻退出，掉的到底是哪一段

因为多数运行时对终止信号的默认处理就是立即结束进程。 terminating 信号本身只是一个通知，是否捕获、捕获后做什么，完全由应用决定；框架层面只有部分脚手架会提供一个默认的优雅停机钩子，而且这个钩子默认等待的时间往往很短，甚至为零。所以"收到信号就立刻退出"不是故障，而是你从未显式定义过退出流程。要做的事情很直接：在应用里注册信号处理逻辑，收到信号后按顺序执行标记不健康、停止接收新连接、等待在途请求完成、关闭依赖连接、最后退出；同时把平台的强制终止超时调到大于这个流程所需的时间。需要注意的是，信号只会被发给进程树的特定进程，容器或进程管理器里如果主进程不是应用本身，信号可能压根没传到应用那里。

探测间隔调快，是不是就等于摘除更快

这个参数没有普适答案，因为它同时决定两件事：故障实例被摘除的速度，以及误摘的概率。间隔越短、失败阈值越低，摘除越快，但一次网络抖动就可能把健康实例摘掉，反而造成容量不足；间隔越长越稳，故障实例却在列表里多待一段时间。一般的思路是让"探测间隔乘以失败阈值"落在你能接受的故障发现时间内，同时保证阈值不小于两次，避免单次抖动触发。更重要的做法是加一个就绪探针与存活探针的区分：就绪探针失败只摘流量、不重启进程，存活探针失败才触发重启，这样排空阶段用就绪探针就足够，不会引发进程被反复拉起。具体数值请以你使用的组件文档为准，并在变更前后对比摘除耗时。

复用连接上的请求为什么没被摘除救下来

核心矛盾在于摘除只作用于新建连接，已建立的连接不受影响。处理思路有三层。第一层是服务端主动宣告：在停止接收阶段就让健康检查失败，同时对新建响应带上关闭标记，HTTP/2 场景下发送结束帧，让客户端在下一个请求时主动换连接。第二层是给复用设上限：限制单条连接最多处理多少个请求、空闲多久回收，让连接在一个可预期的窗口内自然轮换，这样即使客户端不配合也有兜底。第三层是排空预算要按"最长连接可能存活多久"来校核，而不是只按请求耗时算。三层里最容易被漏掉的是第二层，因为它平时看不出作用，只有在发布时才会显出价值。

排空预算给到多少才算既不浪费也不掉请求

按前面说的公式来推，而不是照抄别人的数字。总预算至少等于"摘除生效时间"加上"最长在途请求耗时乘以安全系数"，如果业务里有 WebSocket 或流式响应，还要加上应用层预告与重连窗口的时间。这个数字必须同时配置在两处并且保持一致：应用内部的优雅停机超时，以及平台或进程管理器强制终止的超时，后者要略大于前者，给应用留出写最后几行日志的余量。设完之后要做一次反向验证——故意把一个耗时超过预算的请求挂在实例上再发布，看它是被优雅结束还是被强杀，这个测试结果比配置数字本身更有说服力。

进程退出那一刻，事务停在哪一步

取决于关闭顺序。如果进程先关连接池再等在途请求，那么正在执行的事务就会被中断，数据库侧会把它回滚，通常不会留下脏数据，但业务上表现为一次失败；真正麻烦的是应用已经返回成功、事务尚未提交的中间态。正确顺序是先停止接收新请求、等在途请求跑完并归还连接、最后关闭连接池，这样事务就有机会正常提交或正常回滚。此外要确认连接归还的超时设置：如果池子等待归还的时间短于事务耗时，同样会被强制关闭。对关键的资金与库存类写入，建议额外准备可重放或对账机制，把"进程退出"这一事件纳入一致性核对的范围，而不是只依赖事务本身。

把这条时间线搬到自管机器上会变什么

时序逻辑完全一样，差别在谁来控制这些时间点。容器编排环境下，摘除、停止、排空、强杀这几个动作通常由平台串联，你只需要正确响应信号和配置探针；但默认配置往往偏向快速收敛而不是无损，需要显式调大终止宽限期。自管物理机则相反，没有平台替你编排，摘除要靠自己调负载均衡接口或改注册中心状态，强杀由进程管理器或运维脚本的超时控制，任何一个环节漏掉都不会有人兜底。物理机上还要额外注意发布窗口内可用容量是固定的，替换一台就少一台，无法临时补充，因此批次大小和排空顺序更需要提前算清。

什么才算真正跑通了一次无损发布

验证要放在发布流程里而不是事后。做法是准备一个稳定的背景流量，持续以固定速率打核心接口，覆盖普通请求、大 body 上传和长耗时查询三类，然后在流量运行期间执行一次完整发布，统计窗口内的错误码分布与在途请求曲线。判定标准应该是"零连接重置、零非幂等请求丢失"，而不是"错误率低于某个百分比"——因为少量丢失恰恰就是时序没对齐的证据。同时要检查进程的退出原因是否都是正常退出，有没有出现强制终止。这个验证不需要额外工具，网关日志、应用退出日志和连接数监控就能覆盖，关键是把它做成每次发布的固定步骤，而不是只在出问题时才做一次。

五、扩容之外的另一条路：发布顺序本身可以重排

遇到发布期掉请求，第一反应往往是"容量不够，扩容一批实例再发布"。这个思路在弹性环境里成立，在固定资源的环境里却不总是可行——你手上的机器数量是定死的，发布窗口内替换一台就少一台，没有临时补充的余地。这时候更有效的办法不是加机器，而是把发布顺序本身重排一遍。

重排的核心是把"先起新的还是先停旧的"这件事显式决策。默认流程通常是滚动替换：停一台、起一台，中间有一段单实例承担双份压力的窗口。改成先摘除、再排空、再退出、最后启动新实例的顺序，虽然总时长变长，但任意时刻的流量都只落在完全健康的实例上。另一种重排是把耗时最长的接口在发布前临时切换到单独的一批实例上，让主实例池里只剩短耗时请求，这样排空预算可以大幅缩短。还有一种是把发布安排在流量低谷并把批次缩小到单台，用时长换稳定。

自管物理机的场景里，这个顺序还要多考虑两件事：一是带外管理通道是否可用，如果发布脚本把网络或进程搞到无法自愈，你仍然需要一条独立于业务网络的路径进去处理；二是回滚路径要提前定好，回滚本质上也是一次带排空的替换，不能因为它"紧急"就跳过排空直接重启。一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。自管物理机的发布节奏和云上不太一样，窗口、带外与回滚路径要提前定好。

六、上线前逐项过一遍的检查表

第一项，应用是否显式捕获了终止信号，并且退出流程里包含"标记不健康、停止接收、等待在途、关闭依赖、退出"这五个步骤。可以用一次手动发信号的办法直接验证：给进程发信号，看它是立刻消失还是按预期等待。

第二项，摘除生效时间是否被测量过。记录从发出注销到该实例新建连接数归零的实际耗时，而不是依赖配置的推测值。这个数字是所有时间预算的地基。

第三项，排空预算是否按接口耗时分布算出来，并且应用内的优雅停机超时、平台强制终止超时、客户端超时三者做了对齐，后者不小于前者。

第四项，长连接类流量是否有独立方案：是否有应用层的结束预告、客户端重连是否带随机抖动、网关侧的空闲与读写超时是否大于排空预算。用一次发布观察重连是否集中在同一瞬间。

第五项，依赖组件的关闭顺序是否固定：连接池在在途请求之后关闭，消费者先停拉取再提交位点再退出消费组，后台线程被显式等待。

第六项，批次大小是否按"同时排空的实例数"而不是百分比来定，并且任何时刻的可用实例数不低于承载峰值流量的下限。

第七项，观测是否到位：错误码分布、在途请求数、新建连接曲线、进程退出原因，四项都能按批次标签查到。

第八项，回滚是否走同一条时间线。演练一次回滚，确认它没有跳过排空直接重启。把这张表在每次大版本发布前过一遍，比在故障复盘时逐条补要省事得多。