从一篇新案例看实时系统的恢复目标
AWS 于2026年10月14日发布 API Gateway WebSocket 多区域灾备设计案例，组合主备区域、Route 53、DynamoDB Global Tables、主动探测与客户端重连。它强调将业务状态从连接中分离，让客户端切换区域后恢复上下文。这是参考设计，不是平台新增了“连接无损迁移”能力。AWS 官方案例
先定义用户眼中的恢复
以下是本文的工程分析与实施建议，并非对案例代码的实测结果。对协作文档来说，恢复可能意味着能继续编辑且已确认修改仍存在；对行情看板来说，恢复可能意味着获得最新快照。两者都能重新打开连接，却需要不同的数据处理方式。
因此，评审灾备方案时应先写出三件事：允许中断多久、允许丢失哪些未确认操作，以及恢复后用户看到什么。没有这些条件，团队容易把“备用端点能够连接”当作全部验收标准。
DNS、连接与业务状态各自承担什么
域名切换处理下一次访问
Route 53 的健康检查与故障转移针对 DNS 查询，按资源健康状态返回目标。Route 53 官方说明
由此可以理解，DNS 更新不会把现有连接里的内存状态搬到另一处。本文建议把恢复过程拆成可观测的阶段：客户端发现异常、等待下一次尝试、解析域名、完成连接、校验身份、同步数据。分别计时，才能知道真正拖慢用户恢复的是哪一环。
区分连接标识和业务标识
连接标识适合定位一次通信通道，业务身份则需要跨越重连生命周期。建议在数据模型中明确用户、会话、订阅和连接之间的关系，而不是让一个临时连接编号承担所有职责。
例如，同一个用户可能同时打开多个标签页。若恢复逻辑只按用户覆盖所有订阅，就可能让一处页面的操作影响另一处。可为不同业务会话保留独立标识，再把当前连接绑定到对应会话；这种设计需要结合实际产品权限与并发规则决定。
重连逻辑也是容量设计的一部分
随机退避减少同时重试
AWS 关于退避与抖动的技术文章讨论了集中重试造成的竞争，以及随机化等待的作用。退避与抖动说明
在灾备场景中，本文建议将等待上限、最大连续尝试次数、后台页面行为与用户主动重试分开设计。所有终端使用完全一致的固定间隔，容易在同一时刻再次冲击服务。随机等待只能分散压力，不能替代容量评估，也不能保证服务一定恢复。
备用区域需要承受恢复流量
API Gateway 当前文档列出的 WebSocket 新连接默认配额是每账户、每区域每秒500个，可以申请提高；连接最长持续2小时，空闲超时10分钟。WebSocket 配额
这些约束说明，重连既是故障路径，也可能是正常生命周期的一部分。建议单独测量恢复高峰时的认证调用、状态读取与订阅重建成本。平时消息吞吐量足够，并不自动意味着短时间内大量新连接也能顺利建立。
状态恢复需要明确补偿边界
快照和增量不要混为一谈
本文建议先判断业务需要的是最新视图，还是完整历史。只关心当前温度的看板，可以重新获取快照；需要保留每次协作操作的系统，则应设计版本号、操作编号或可追溯日志，并说明增量保留时长。
如果客户端记录的版本太旧，服务端应明确要求全量同步，而不是返回一个看似成功却缺少中间变化的结果。同步期间也应定义新消息如何排队，避免快照覆盖刚收到的增量。
处理“提交过但没有收到确认”
这是值得专门演练的灰色状态：用户提交操作后，网络在确认消息返回前中断。客户端不知道服务端是否已完成处理，直接重发可能造成重复，不重发又可能让操作丢失。
建议为需要重试的业务操作设置稳定的操作编号，并在服务端定义去重范围、记录保存时间和重复请求响应。这里的关键是业务语义，不是简单给请求加一个字段。对于无法自动判断的状态，界面应显示待确认，并提供查询或人工核对入口。
健康检查与回切应分别设计
端口能连接，不代表业务能恢复
探测可以从连接握手逐步深入到认证、消息往返和关键数据读取。本文建议为探测建立专用、低权限身份，控制频率与数据规模，避免健康检查本身制造额外压力。
同时区分探测失败、指标未上报和监控链路异常。它们都值得关注，却未必具有相同含义。评审时应解释每类信号触发什么动作，以及如何避免一个局部依赖故障引起不必要的全局切换。
回切时继续维护业务一致性
主区域重新响应后，不宜仅凭一次成功探测就认为恢复完成。建议检查数据追平情况、身份服务状态、队列积压与客户端分布，再决定是否回切。对仍然活跃的备用区域会话，也应有清晰处理规则。
自动回切和人工确认各有代价。前者减少操作等待，后者让团队有机会确认系统稳定。选择取决于恢复目标、误切换成本与值班能力，不应照搬演示配置作为统一标准。
用演练证明整条链路可用
覆盖最容易漏掉的时间点
建议至少模拟三类情况：连接建立前失败、业务操作执行中失败，以及恢复过程中再次断开。演练应记录用户可见中断时间、最终状态差异、重复操作数量和失败原因分布，而非只截图展示连接到了备用区域。
还可以设置不同规模的客户端逐级加压，观察退避是否有效、认证是否先饱和、状态读取是否拖慢恢复。这些是待验证的测试项目，本文没有运行压测，也不提供未经测量的恢复时间。
把维护成本写进方案
双区域部署还意味着配置同步、证书管理、权限审查、数据复制费用和日常演练。建议为这些工作明确负责人，并保留可执行的降级与回滚步骤。
WebSocket 灾备真正的交付物，是一套从异常发现到业务恢复都能解释、测量和复盘的流程。连接再次变绿只是其中一个信号；用户能否安心继续之前的工作，才是架构验收的终点。
参与讨论
评论