1 多区域容灾要回答什么
手机上的订单页面显示“提交成功”，背后通常经过入口、应用、身份验证、数据库和消息处理。假如这些组件都在区域 A，区域 A 长时间无法服务时，在区域 B 启动相同程序是否就能接住订单？答案取决于程序之外的条件：B 有没有可用数据，用户还能不能登录，应用能否读取密钥，支付回调能否进入，值班人员能否操作入口。多区域容灾要回答的，是主要区域失去服务能力之后，怎样在约定时间内恢复约定业务，以及能够接受多少数据缺口。
区域是云资源部署的地理与管理边界，可用区通常是区域内进一步隔离的故障域。跨可用区部署可以应对部分机房或设施故障，却不能直接证明区域级依赖中断时仍能服务。跨区域也不是绝对独立：相同身份服务、错误配置、软件缺陷或误操作仍可能同时影响多个区域。设计时应写明保护的故障范围，例如“区域 A 的业务网络与数据服务不可用”，再检查备用路径是否仍依赖 A。
本课采用容易观察的订单 API：用户登录后提交订单，再查询订单状态。A 正常接收写入，B 保留应用环境和数据副本，必要时接管。这里的“接管”包含网络入口、计算容量、身份权限和业务依赖，不只是数据库角色变化。库存扣减、支付确认等外部结果需要核对，不能因为备用库出现订单，就推断整笔交易已经完成。先围绕这条有限业务路径学习，比直接讨论复杂的全球同时写入更容易明确边界。
备份和容灾也有不同用途。备份保留可恢复的数据版本，帮助应对误删、损坏或勒索；备用区域提供恢复业务的落点。持续复制可能把误删迅速复制过去，因此跨区域副本不能替代历史备份。反过来，有备份但没有恢复环境、权限和操作步骤，也无法知道恢复需要多久。完整方案应同时考虑故障时继续服务与事后找回正确数据。
先为业务划定最低可用范围。例如故障期间允许查询旧订单，允许接收新订单，但暂缓生成报表；也可能只保留查询，明确暂停下单。不同范围对应不同依赖和验收方法。“服务已恢复”必须能翻译成用户完成了哪些操作，而不是“机器都启动了”。范围越清楚，后续的时间目标、数据目标和演练结果才越容易比较。
2 RPO、RTO 与流量切换
恢复点目标 RPO 描述可以接受的数据恢复点与故障之间的时间差，回答“最多容忍多旧的数据”。假设故障发生在 10:00:30，备用能够恢复到 10:00:15 的提交状态，时间差是 15 秒。这是理解数据窗口的方法，不代表必然丢失 15 秒内的全部订单，也不代表能直接按平均吞吐量计算实际丢单数。主区域可能还能找回部分记录，窗口内各类数据的复制情况也可能不同，需要事后核对。
恢复时间目标 RTO 描述允许业务中断多久。应在方案中约定计时起点和终点，例如从故障导致约定业务不可用开始，到区域外业务探针连续 2 分钟满足成功率与延迟要求结束。发现故障、判断影响、联系负责人、隔离写入、准备容量、调整入口和验收都可能计入其中。若从操作人员点击切换才开始计时，就会漏掉用户已经等待的时间。
目标与测量结果要分开。方案可以要求 RPO 不超过 30 秒、RTO 不超过 10 分钟，演练却可能测出 45 秒的数据窗口和 14 分钟的恢复时间。这说明当前准备没有达到目标，应修复或重新约定业务承受能力。不能把目标数字直接写成系统保证，也不能拿某次最快演练代表所有故障。故障范围、当时负载和依赖状态都会改变结果。
流量切换可以通过全局入口调整、DNS 解析变化或客户端备用地址实现。DNS 把域名解析为地址，记录有缓存有效期，但改变记录不会强制所有客户端立即丢弃缓存，也不会自动断开旧连接。已经建立的连接、客户端连接池和中间代理可能继续访问 A。因此“权威解析已返回 B”只能证明入口配置的一部分变化，不能证明所有请求已经迁移。
正确观察应结合解析结果、区域入口请求量、应用响应和用户操作。切换初期可以先给 B 少量流量，检查身份验证、下单、查询和错误率，再逐步增加。若业务已经完全中断，也仍需保留最低验收，避免把请求快速送进同样不可用的环境。旧区域可能突然恢复，故而入口切换不能替代写入隔离；后者必须保证旧路径即使收到请求也不能继续产生冲突写入。
3 数据复制与冲突边界
异步复制常见的顺序是：A 提交数据，向客户端返回成功，再由复制链路把记录送到 B。实际传输可与响应交叠，但成功响应通常不等于 B 已经持久保存并应用记录。网络变慢、备用处理能力不足或复制暂停时，落后窗口会扩大。若 A 此时不可恢复，B 可能缺少客户端已经收到成功响应的订单。理解这个窗口，是讨论 RPO 的基础。
监控中的“复制正常”需要拆成可以解释的状态：记录是否发出、备用是否接收、是否持久保存、是否应用到可查询状态。不同系统的延迟指标含义不完全相同，不能看到 0 就宣布不会丢数据。对入门实践而言，至少记录最后可恢复或已应用的位置，并用已知业务记录验证。没有新写入时，某些时间型指标还可能容易误读，需要结合位置和探针判断。
同步复制可以要求远端达到某个确认条件后才向用户报告成功，缩小相应的数据风险，但跨区域往返会增加等待，链路异常也可能影响写入可用性。确认究竟代表接收、落盘还是其他状态，仍要看具体系统约定。本课不展开复制协议内部算法，只保留重要取舍：更严格的远端确认需要付出延迟或可用性成本，不能同时假定远端不可达、写入照常成功且绝无数据风险。
接管前还要明确谁能写。如果 A 只是与操作人员失联，却仍能接收部分用户请求，此时直接让 B 写入，可能形成 2 个相互独立的写入者。入口改到 B 不能封住 A 的旧连接、后台任务和内部调用。隔离应使用预先验证、在故障情况下仍可执行的机制，例如撤销旧写入资格或由受控仲裁确认唯一写入者。无法确认隔离时，应停止开放新的写入，按既定策略提供查询或等待人工处置。
订单的唯一标识和请求幂等键可以帮助识别重试：同一次业务意图重发时，服务尽量返回已有结果，而不是再次创建订单。但如果幂等记录也没复制到 B，单靠这个键不能凭空找回 A 的执行结果。支付等外部动作应保留可查询的业务流水，供恢复后核对。冲突处理必须按业务规则判断，不能简单认为最后时间戳最大的记录就是正确结果。
回切同样是数据迁移。A 恢复后可能保留 B 缺失的旧记录，而 B 已经产生新订单。应先确定当前权威写入端，核对缺口，重建复制，等待追平，再按受控步骤迁回。不能把 A 启动成功当作回切条件。多区域同时写入需要更细的归属和冲突规则，本课先采用单区域写入，让恢复路径保持可以解释和演练。
4 动手：演练一次区域切换
在隔离的测试环境准备区域 A 与 B，使用测试域名、测试身份和模拟支付服务。让 A 接收写入，B 接收复制并具备接管权限。准备 20 个带唯一业务标识的测试订单，记录提交时间、响应结果和查询结果；探针从区域外运行。演练前确认 B 的配额、网络出口、证书、密钥访问、应用版本与数据结构兼容，尤其不要让 B 读取只能从 A 获取的配置。
先写出停止条件与恢复路径：出现写入归属不清、备用持续报错或数据位置无法确认时停止放量，保留记录，由负责人决定保持查询还是暂停业务。把暂停业务和回退入口区分开：当 B 已接收新写入后，直接把入口退回旧 A 可能制造数据分叉。演练中的恢复路径必须依据当前权威数据位置决定，而不是机械地把每个配置改回原值。
在正常状态执行登录、下单、查询，保存基线。随后暂停测试环境中 A 的业务入口，制造“主要区域无法提供服务”的现象，并记录时间。这个注入只模拟入口故障，不能声称覆盖真实区域断电或全部控制服务不可用。检查告警能否从区域外到达，操作人员是否能不依赖 A 登录运行平台；这些都是演练范围内可以直接观察的事实。
按顺序停止并确认 A 的写入资格，核对 B 最后应用位置，记录尚未确认的订单范围，再提升 B 的写入角色。只有隔离证据和数据状态都满足预定条件，才开放 B 写入。然后调整测试入口，用不同客户端观察解析、连接与请求落点。不要通过同时打开两边的写入来追求表面上没有中断，这会改变练习的故障模型。
在 B 执行新登录、旧会话请求、订单重试、订单查询和新订单提交。记录每次响应是否符合预定策略，并观察队列消费者、后台任务和模拟支付回调。保持业务探针运行到验收窗口结束，记录恢复时间；同时对比那 20 个订单在 B 的状态，列出确认存在、确认缺失和仍待调查的集合。客户端超时的订单尤其需要查询，因为超时不代表服务端没有提交。
最后恢复 A 的测试环境，但先让 B 保持权威写入端。核对差异，重建 A 作为备用的复制关系；如果还要回切，再安排受控切换。保存事件时间线、操作记录、订单核对结果和未覆盖的故障条件。完成这次实验的标志，是能够用证据解释业务何时恢复、哪些数据仍不确定，以及下次需要补测什么。
5 恢复速度与数据损失取舍
从备份恢复适合能够接受较长中断的业务：故障后准备资源，取回备份，恢复数据，再启动应用。持续资源成本相对较低，但恢复时间包含数据传输、恢复和验证，数据量变大时不能假定速度不变。若支持连续日志恢复，恢复点可能比最近的完整备份更新；能否使用这些日志必须经过恢复验证，不能仅检查备份任务显示成功。
温备用保留必要环境与较小规模的服务，接管时扩容；热备用提前准备更接近生产的容量，通常能够减少资源准备等待。它们没有跨所有系统统一的严格定义，所以方案应写具体状态：B 当前有多少实例、能承受多少请求、数据多旧、还需执行哪些动作。仅写“已建热备”无法说明在高峰时段是否接得住流量。
容量要考虑故障时的实际流量，而不是平时平均值。B 可能同时接收用户重试、后台积压和监控请求，短时压力高于正常情况。如果自动扩容依赖临时申请配额，区域容量紧张时可能失败。可提前保留关键容量，限制非核心任务，逐步恢复后台处理，并对超过承受能力的请求提供明确结果。容灾期间的限流策略应保护已承诺的核心业务路径。
恢复速度和数据损失是相关但不同的维度。提前运行更多应用实例可以缩短启动时间，却不能自动缩小数据库的复制落后；加强复制可以改善恢复点，也不能保证证书、网络或值班决策立即就绪。评估方案时分别列出时间瓶颈和数据风险，再为最重要的业务选择投入。否则容易买了更多备用机器，却仍卡在身份服务不可用或人工审批等待。
交互中的加总是教学估算，真实恢复过程有可并行步骤，也有无法预知的长尾。入口缓存、数据恢复速度和外部依赖可能让同一方案出现不同结果。可以通过多次有明确范围的演练积累结果，识别最慢步骤，并保留容量余量。不要把相对成本档位当成价格报价，也不要把某次演练的最佳结果当作对业务的承诺。
对订单 API，可以先把查询恢复目标与下单恢复目标分开。查询可接受稍旧数据时可能先恢复，但界面应说明状态更新时间；下单涉及库存和支付，需要等待写入隔离与相关依赖就绪。恢复顺序应由业务容忍度决定，并让调用方知道重试条件。这样既能更早提供有用服务，也不会把不满足数据条件的操作提前开放。
6 常见坑：只同步库不同步依赖
最常见的误判，是把“数据库副本可用”当成“业务已经具备备用”。应用还需要镜像、启动配置、密钥、证书和访问身份。如果部署文件只引用 A 的私有镜像仓库，B 的现有实例可能正常，新扩容实例却无法拉取镜像。应验证从空实例启动的完整路径，并确保必要制品和配置在接管时可获得，而不是只看已经运行的进程。
身份依赖也可能跨回 A。B 的应用角色可能没有读取密钥的权限，身份提供方的回调地址可能只允许 A，密钥解密服务可能只在 A 配置。处理方法不是简单复制所有凭据，而是为 B 准备必要且受控的权限、密钥使用路径和轮换流程。演练时实际执行鉴权与解密操作，并记录成功与否，避免在日志里暴露敏感材料。
网络层面，B 的子网、路由和安全规则存在，不代表应用能访问外部服务。支付模拟端可能只允许 A 的出口地址，内部服务名可能仍解析到 A，回调入口可能没有 B 的证书。应从 B 的应用环境验证出站请求和入站回调，检查目标地址与身份。只从值班人员电脑连通某个地址，无法证明应用所在网络也有同样路径。
数据依赖不只关系数据库。订单附件可能在对象存储，会话在缓存，待处理事件在队列，搜索结果来自索引。每类依赖都要说明权威来源、能否重建、容许多旧以及切换动作。搜索索引可以重建时，不必与核心订单表采用完全相同的保护方式；但队列丢失可能让已创建订单永远没有后续处理，需要保留可重放的业务依据。
定时任务和消费者需要特别检查。若 B 启动后自动执行结算任务，而 A 的任务仍在运行，可能重复扣减或发送通知。应把后台执行资格纳入写入归属管理，在恢复初期按优先级逐步开放。监控与操作入口也要避免全部放在 A，否则故障时既看不到 B，也不能执行恢复。观测系统本身的故障不能被误认为业务没有请求。
最后，备用环境会随时间偏离生产：权限更新没同步、证书到期、数据库结构升级不兼容，都会在故障时暴露。应让日常发布覆盖备用部署检查，并周期性执行真实业务探针。检查清单的价值在于持续产生可用证据；如果上次成功已经是很久以前，就不能据此推断今天仍然能接管。
7 案例：DNS 切换成功但会话全丢
某订单服务把会话标识放在浏览器 cookie 中，把对应登录状态保存在 A 的缓存。B 已部署相同 API，也有订单数据库副本。区域 A 故障后，值班人员修改 DNS，看到新解析地址和 B 的健康检查都正常，便宣布恢复。用户刷新页面却被要求重新登录，进行中的下单操作失败，客服收到“切换后账户状态消失”的反馈。
问题不在 DNS 是否生效，而在健康检查没有覆盖用户身份路径。匿名健康接口只证明 B 的进程能响应；用户带来的会话标识必须在相应存储中找到有效状态。B 的缓存没有这些会话，因此数据库即使完整，应用也不知道请求属于哪个用户。部分用户仍走旧连接，还会出现有时连接失败、有时返回未登录的混合现象。
排查时先用入口日志确认请求确实落到 B，再比较匿名探针、旧会话探针和新登录探针。若匿名请求成功、旧会话失败而新登录成功，就应重点检查会话存储与验证路径。若新登录也失败，则继续检查身份提供方、回调地址、签名密钥与时钟。这样的分层证据能减少盲目修改 DNS 的次数，并避免把身份问题误判成订单数据丢失。
修复可以选择使会话状态具备跨区域恢复能力，也可以采用可在 B 验证的令牌方案，但后者仍需处理验证密钥、过期和撤销等依赖，不是改成令牌就没有状态问题。另一个可接受策略，是在故障时要求用户重新登录；前提是业务目标明确允许，登录路径可用，页面能够提示并恢复未提交的操作。不能在演练失败后才临时把所有用户退出解释成预期行为。
这个案例还暴露出重试边界。用户没有看到订单结果时，重新登录后可能再次点击提交。服务应使用稳定的业务标识核对已有订单，并对复制缺口中的请求保留待确认状态。不能为了页面立即变绿就重复调用外部支付。会话恢复、订单恢复和外部交易核对是相互关联的检查项，但必须分别给出证据。
8 把容灾演练写进运行方案
运行方案要让没有参与设计的值班人员也能执行。开头写清业务范围、故障假设、RPO 与 RTO 目标、计时方式和降级行为，随后列出判断条件与具体动作。把“确认复制正常”改成“记录备用最后应用位置，查询指定探针订单，并确认没有持续增长的落后”，就能让不同人员得到可以比较的证据。
角色应有明确责任：谁确认业务影响，谁执行写入隔离，谁调整入口，谁核对订单，谁批准停止或扩大恢复范围。小团队可以由同一人员承担多个角色，但不能省略责任。操作通道和必要权限应事先验证，并保证不依赖受影响区域。紧急权限的使用也应留下记录，演练后按流程收回临时授权。
每个关键动作写出前置条件、预期结果和失败分支。提升备用前必须满足写入隔离与数据位置确认；入口放量前必须通过核心业务探针；扩容失败时按限流或降级策略处理。如果前置条件无法成立，应停在明确边界，由负责人评估继续中断与数据风险，不能让执行人员靠猜测推进。自动化可以减少重复操作，但仍需要同样的边界和证据。
演练应逐步增加覆盖范围。先验证备用环境能够独立启动，再测试受控切换，之后覆盖旧区域不可操作、复制落后、部分客户端保留旧地址等情形。每次只改变清楚定义的条件，才能解释失败原因。测试入口中断成功不等于已经验证区域整体失联，报告必须标明注入方式、未覆盖依赖与负载条件。
验收记录至少包含业务不可用起点、告警到达、隔离确认、数据点确认、开放备用写入、入口调整和业务达标时间。订单核对表应区分成功响应、客户端超时、备用可查和外部交易结果。复盘把问题转成有负责人、完成条件和复测日期的改进项。修复后重测相应路径，才能把“发现风险”变成“降低风险”。
9 从多区域容灾走向大规模 Kubernetes（C48）
本课始终围绕完整业务路径，而非某种部署工具。接下来即使把订单 API 放进 Kubernetes，也仍需解决区域故障、写入归属、数据恢复与入口收敛。集群内自动重启可以恢复部分进程故障，却不能替备用区域补出缺失订单，也不能自动获得外部身份或支付服务的权限。应先识别工具能够覆盖的故障层级，再讨论自动化收益。
进入大规模环境后，部署数量增多，配置差异和依赖遗漏更难靠人工发现。可以把本课的备用启动检查转成发布流程中的条件，把业务探针转成持续验证，把资源配额与恢复容量纳入日常管理。自动化的目标是让相同条件产生可重复动作，同时让失败停在能够解释的位置；不能只把手工步骤复制成脚本，就认为可靠性自然提高。
区域与集群也不是同一个概念。可以在不同区域建立独立集群，但集群外的数据、身份、镜像和入口仍需单独设计。若多个区域都依赖同一个不可达的管理入口，表面上的多集群仍可能一起失去操作能力。C48 将继续讨论大规模 Kubernetes 的部署与管理问题，本课先保留这个判断习惯：每增加一种平台能力，都要追问它保护了哪段路径，又依赖哪些外部条件。
读到这里，应能给订单 API 画出接管依赖，指出故障后最晚可恢复的数据点，并说明业务恢复以什么证据为准。如果只能回答“有备用区域”和“DNS 可以改”，方案还缺少操作边界。下一步不是立即追求更多区域，而是把现有恢复路径演练清楚，再用平台能力降低重复劳动与环境偏差。
放进方案里
为订单 API 写下明确承诺：区域 A 无法服务时，先恢复登录、订单查询和下单，报表暂缓；目标 RTO 为 10 分钟，目标 RPO 为 30 秒。计时从约定业务不可用开始，到区域外探针连续 2 分钟满足成功率与延迟要求结束。数值先作为待演练验证的目标，若结果超出范围，必须调整准备程度或与业务重新约定，不能直接宣称达标。
采用 A 写入、B 备用的部署，列明 B 的应用容量、扩容配额、数据复制方式与最后应用点的读取方法。把身份服务、会话、密钥、镜像、对象、队列、网络出口和支付回调逐项纳入依赖表，注明故障时的访问路径及验证证据。对能够重建的索引与必须保留的订单记录采用不同恢复要求，保留独立历史备份。
切换步骤写成有条件的动作：确认故障影响，可靠隔离 A 的写入，核对 B 的数据位置，提升 B，验证核心业务，再调整入口并放量。无法确认旧写入者已隔离时，不开放 B 写入。入口修改后继续检查缓存与旧连接，使用旧会话、新登录、订单重试和回调探针验收，不以 DNS 返回地址作为恢复终点。
指定执行与决策负责人，准备区域外的操作和观测通道，记录每个关键时间点。每次演练列出实际恢复时间、待核对订单、失败依赖和未覆盖条件，并安排修复与复测。A 恢复后先核对差异、重建复制，再决定回切；B 已有新写入时禁止直接退回旧 A。将这份方案随发布、权限变更和依赖调整持续更新，使下一次接管依据当前环境执行。
验收时保存旧写入资格失效的证据，并从保留旧连接的客户端尝试写入，确认请求被拒绝。将故障前已返回成功的订单与 B 的记录逐项对账，单列超时请求和支付已确认但订单缺失的情况；未完成核对的交易不得自动重复扣款。报告同时注明演练是否覆盖跨区域链路中断与高峰重试负载，未覆盖项不能计入已验证能力。
10 小结：下一步大规模 Kubernetes（C48）
多区域容灾把业务目标、数据保护和运行操作连接起来。RPO 约束可接受的数据恢复点，RTO 约束业务中断时间；复制状态、写入隔离与完整业务探针提供判断证据。备用区域只有在身份、网络、容量及外部依赖都能工作时，才具备接管能力。
用 3 个问题自测：DNS 已返回 B，为什么还不能宣布恢复？备用报告复制延迟为 0，为什么仍要核对提交点？B 已接收新订单后，为什么不能直接把入口改回旧 A？能够分别说明连接与业务依赖、指标语义与数据证据、权威写入端与回切核对，就掌握了本课的基础判断。
下一课进入大规模 Kubernetes，关注平台如何组织部署与运行。带上本课的依赖图和验收标准，才能判断自动化究竟缩短了哪个恢复步骤，以及哪些业务责任仍需由方案明确承担。