1 容灾架构要回答什么
零售订单 API 在促销期间遇到机房故障，用户点击“提交订单”后只看到超时。此时，架构师面对的并非单纯的服务器修复题：已经确认的订单是否还在，支付回调是否继续到达，备用站点能否承接请求，以及恢复后会不会出现重复订单，都需要有人回答。容灾架构的任务，是在故障超出日常高可用边界时，让业务按照事先约定的损失范围和恢复顺序继续运行。
本课沿用零售订单 API：客户端提交订单，订单服务写入订单库，通过消息通知库存与履约，支付结果由回调更新。订单号与提交请求的幂等键用于识别重复操作。正常情况下，同城的多个可用区承担日常高可用；另有异地备用站点承接重大故障后的恢复。这里的“备用”包含应用、数据、配置和依赖的准备状态，不能只理解成提前放好的服务器。
先把需求说成业务语言。示例约定：下单能力在灾难声明后 15 分钟内恢复；订单数据的恢复点目标为 60 秒；恢复初期至少承接正常峰值的 50%，暂时关闭推荐等非关键功能。支付确认的订单不得静默消失，发现状态缺口必须进入对账和人工处理流程。这些数字是本课的方案输入，并非通用标准；团队需要让业务负责人确认它们的适用时段与例外。
恢复时间目标 RTO 表示可接受的恢复耗时，恢复点目标 RPO 表示可接受的数据回退范围。RPO 为 60 秒，并不表示每次必然丢失 60 秒的数据，也不等于可以不查证地删除最近 60 秒订单。它要求设计有能力控制恢复点，并在事故中报告真实缺口。支付、订单和库存可能具有不同要求，整体业务承诺必须说明这些差异如何处理。
还要区分目标与测量口径。本课把灾难声明作为 RTO 起点，把目标容量下关键下单链路通过验收作为终点；故障发生到声明之间的检测与决策耗时另行记录，同时报告从故障发生到恢复的总中断时长。若业务合同从故障发生计时，就必须按合同重算预算。不能靠推迟宣布灾难，让恢复报表看起来更好。
需求最终应形成可追踪关系：业务要求决定恢复目标，恢复目标筛选架构选项，选项进入架构决策记录 ADR，决策再落实为成本预算、风险清单和演练证据。高可用 HA 处理常见的局部故障，容灾处理更大范围的失效；两者需要共同定义边界，避免局部故障也触发异地切换，反而扩大影响。同城高可用的基础模式与云上可用区接管分别见 P11 与 C43；备份、快照与受限恢复验收见 C44——本课在这些已验证材料之上做拓扑选择与切换决策，而不是重讲如何做一次恢复演练。
2 同城、异地与故障切换边界
同城部署常用于降低单个机房或可用区失效的影响。它通常有较低的通信时延，应用与数据可以采用更紧密的协作方式，但同城站点也可能受到共同的供电、骨干网络或灾害影响。异地部署扩大了故障隔离范围，同时引入更长的通信路径、更多复制延迟和额外运维工作。距离只提供隔离的可能性，真正的隔离还要检查共享依赖。
在订单 API 的拓扑上，先标出“会一起坏”的组件。例如多个入口虽然部署在不同站点，却依赖同套证书分发、同个身份服务或同处配置中心；站点看似分散，恢复时仍可能同时失效。备用站点还可能从主站点拉取镜像、获取密钥或读取静态配置。若主站点不可用时这些动作无法完成，备用环境便不能独立启动。
入门阶段可比较 3 个选项。备份恢复是在事故后从备份重建，日常成本较低，但恢复时间受数据规模、恢复速度和环境准备影响——其机械路径、密钥依赖与受限验收已在 C44 验证，本课只把它当作架构选项之一来比较成本与 RTO。温备让备用应用与数据持续准备，平时容量较小，事故时扩容接管。热备预留较完整的应用与容量，能减少准备时间，但持续成本更高。每种选项都需要贴近生产拓扑的演练证明，名称本身不能保证恢复速度。
本例暂选同城多可用区高可用加异地温备，理由是业务给出 15 分钟恢复目标，也接受恢复初期按 50% 峰值运行。选择成立的前提是：备用扩容、数据追赶、依赖检查与验收能进入时间预算。如果扩容测得需要 20 分钟，就必须增加预留容量、改变方案或重新协商目标。不能在 ADR 中只写“成本适中”，却不写可验证的前提。
切换边界应按业务故障定义。单个应用实例退出，由本地调度恢复；单个可用区失效，优先由同城高可用承接；主站点持续不可用且本地恢复预计超出预算，才进入异地切换评估。入口访问失败也可能只是客户端网络问题，只有业务探针、内部服务和数据状态相互印证，才能判断是否真的需要迁移写入位置。
谁有权决定切换也属于架构的一部分。值班人员收集证据，事故负责人作出声明，数据负责人确认恢复点，业务负责人接受明确的数据缺口或降级范围。允许自动处理的局部故障可以自动化；跨站点写入权变更若缺少可靠判据，应保留明确审批节点。职责需要在事故前确定，避免故障时临时寻找能够承担决定的人。
3 数据复制与会话迁移
数据复制解决的是备用站点能看到什么状态。同步复制通常要求远端确认进入写入成功条件，因此会增加提交等待，并使业务可用性受到远端链路影响；异步复制让主站点先完成写入，再把变化传送到远端，正常请求等待较少，但故障时可能留下尚未复制的数据。这里先关注业务取舍，具体复制协议与一致性算法留给后续课程。
复制链路应拆成接收与应用两个阶段。备用站点收到日志，不代表订单查询已经能读到对应结果；日志可能仍在等待重放。判断接管条件时，要检查可用于恢复的持久化位置、已经应用的位置，以及主站点最后可确认的成功写入位置。只看“网络连接正常”或“复制进程运行中”，无法证明数据已经满足恢复点要求。
复制延迟还要结合业务水位理解。订单服务可以保存可核对的订单序号、提交时间和提交结果，用这些证据界定缺口；不同分区或不同库的序号不能简单合成全局顺序。仅比较服务器时钟可能被时钟偏差误导，繁忙时段的 60 秒也可能包含大量订单。因此恢复报告既要说明时间范围，也要尽量说明受影响的订单集合与数量。
订单业务的状态分散在数据库、库存服务、消息队列和支付系统。订单记录追平，并不代表库存扣减消息和支付回调也已处理完。备用站点需要明确积压消息从哪里继续消费，重复消息如何识别，以及外部回调如何转发或重试。本例用订单号与事件标识去重，通过对账补齐不确定状态；去重记录本身也必须进入恢复范围。
会话迁移则关注用户请求如何继续。将关键购物与订单状态保存在可恢复的数据存储中，能降低对单台应用内存的依赖；登录令牌也需要备用站点能够验证。若签名密钥、权限配置或会话存储只存在于主站点，应用即使启动也无法服务原有用户。可以允许用户重新登录，但必须将这个体验写进降级约定，不能把它当作未记录的例外。
请求超时后的重试尤其危险。用户可能已经创建订单，只是没有收到响应；切换后再次提交，备用站点若缺少原幂等记录，就可能创建重复订单。本例要求幂等键与订单结果一起进入数据恢复设计；遇到无法确认的键，先返回明确的处理中状态并查询或对账，避免自动把“不知道是否成功”解释为“从未成功”。
业务切换的顺序因此应为：确认故障、阻止旧写入、核对数据恢复点、授予备用写入权、验证依赖、开放流量。旧站点隔离需要可靠的写入围栏，例如撤销写权限或使用能够阻止过期写入者的授权机制。仅关闭入口不足以阻止后台任务写库；网络失联也不能证明旧站点已经停止写入。
4 动手：画一条业务切换的决策树
准备纸笔或绘图工具，把入口异常作为起点，终点限定为“继续本地恢复”“进入异地准备”“开放降级服务”与“保持写入关闭并升级处理”。决策树每个分支都写可观测条件、责任人和最长等待时间。不要把“情况严重”放进判断框，因为不同值班人员对严重程度的理解可能完全不同。
先判断订单关键路径是否真的不可用。组合查看来自不同网络的业务探针、提交成功率和订单落库证据，排除监控自身失效。健康检查应使用受控的测试订单或不产生真实交易的专用流程，并覆盖必要依赖。只有进程存活、首页可打开或接口返回 200，都不能证明用户能成功下单。
接着判断故障是否在本地高可用边界内。如果只是单个可用区失效，且同城剩余容量足够，就执行既定本地恢复流程。如果主站点受影响范围较大，本地预计恢复时间超过可用预算，则由事故负责人声明灾难，启动异地准备。预计恢复时间不是拍脑袋的乐观值，应引用相似故障或当前修复进度，并持续更新。
进入异地准备后，画出“旧站点写入是否已被可靠阻止”的判断。答案为否时，目标站点不得直接开放订单写入，可以展示只读信息、接受非交易查询或告知稍后重试。隔离手段必须覆盖 API、后台任务和运维入口。若无法获得可信的隔离结果，应进入升级处理分支，而不是把等待超时当作隔离成功。
再判断恢复点与依赖是否满足接管要求。数据负责人报告最后可确认写入位置、备用已应用位置、缺口范围和证据可信度；支付与库存负责人报告回调、消息和对账准备情况。若缺口不明，节点应明确指向继续核查。若已知超出承诺，则由预先规定的业务例外流程处理，不能让技术人员默默放宽 RPO。
最后设置容量与业务验收节点。备用站点至少满足约定的 50% 峰值能力，关键配置和密钥就绪，受控订单完成提交、查询和状态更新后，才逐步开放流量。开放后继续观察错误率、延迟、重复订单和数据积压；指标越界时优先停止放量或关闭写入。回退到旧站点仍是新的写入权迁移，不能画成没有条件的返回箭头。
完成图后，用 3 张事故卡片走读：主站点机房失联、入口故障但数据库健康、备用数据追赶过慢。每张卡片都记录走过的节点、需要的证据和可能停住的位置。只要出现“这个指标暂时拿不到”或“这步没有负责人”，就把它作为方案缺口；决策树的价值在于提前暴露这些缺口。
5 切换时间与数据损失取舍
恢复时间来自多个阶段：发现与声明、隔离旧写入、数据准备、应用与依赖准备、业务验收、流量收敛。本课 RTO 从声明计时，因此将声明后的环节纳入 15 分钟预算，并单列声明前的检测耗时。有些准备能够并行，但数据接管和业务放量之间存在先后关系。把所有阶段时间简单相加可能过于保守，只取最短阶段又会低估恢复时间。
可以先编制示例预算：隔离旧写入 2 分钟，数据准备最多 6 分钟，应用与依赖准备 5 分钟，后两项在确认隔离后并行；业务验收 3 分钟，流量收敛预留 4 分钟。关键路径为 2 加 6 加 3 加 4，共 15 分钟。这个预算只是待验证假设，实际重试、排队和扩容失败都可能消耗余量，应通过演练修正。
流量收敛不能只看 DNS 配置中的 TTL。递归解析缓存、客户端缓存、连接复用与移动端重试都影响用户何时到达新站点。降低 TTL 可能缩短部分解析缓存时间，却不能保证所有连接立即迁移。旧地址在迁移期间应按设计拒绝写入或返回可识别的维护响应，避免残留请求继续修改旧数据。
数据损失取舍要区分“多等待能追上的数据”和“已经无法取得的数据”。如果日志已在备用站点持久保存，只是应用速度落后，等待可以改善恢复点；如果日志从未离开已经损坏的主站点，继续等待不会自动缩小缺口。需要先确认数据在哪里、能否读取，再讨论等待多久，不能把所有复制延迟都解释为可恢复的积压。
更小的 RPO 往往需要更及时的复制、更强的故障隔离或更多对账能力；更小的 RTO 往往需要更多预留容量和自动化。这些投入还包括日志保留、跨地域传输、演练、值班与备用依赖的成本。本例应同时估算平时月度成本和切换期间的额外支出，并检查促销峰值下的配额与资源可用性。
下面的滑块使用教学模型，让备用站点从落后 120 秒开始追赶：每等待 1 秒处理 2 秒历史变化，主站点仍每秒产生 1 秒新变化，因而净追赶速度为每秒 1 秒。若主站点已停止写入，其他条件不变，追赶会更快。模型只帮助理解等待与恢复点的关系，不能代表真实数据库的吞吐承诺。
在 ADR 中记录选择：采用异地温备，接受恢复初期的受控降级，以持续复制、写入隔离和对账控制风险；同时记录被放弃选项、选择依据与重新评审条件。例如连续演练超出 15 分钟，或促销峰值使净追赶速度降到接近 0，都应触发容量与方案复审。这样，成本变化才会与业务目标直接关联。
6 常见坑：演练脚本与生产拓扑脱节
演练脚本成功，不等于生产切换可行。脚本可能直接访问备用站点的内部地址，绕过真实 DNS、证书、入口策略和客户端缓存；也可能只验证数据库连通，没有执行支付回调和库存消息。这样的演练能够证明局部组件可运行，却无法证明用户能够在约定时间内重新完成下单。
另种偏差是演练使用了过于理想的数据和容量。测试库很小、日志积压很少，备用实例提前全部启动，于是切换只用 3 分钟；生产却需要处理峰值订单、扩容失败和历史消息。演练报告应明确数据规模、请求负载、预热状态、故障注入范围和未覆盖依赖，避免把有限条件下的成功写成无条件保证。
配置漂移也会让备用站点逐渐失真。主站点新增了订单字段、调整权限或更新证书，备用应用与迁移脚本却没有同步；事故时才发现新版本无法读取旧数据，或者回调地址仍指向原站点。把生产拓扑、配置清单和部署流程作为共同来源，并定期比较实际状态，能让脚本随着系统变化，而不是依赖记忆更新。
凭据与操作权限常被遗漏。平时能打开控制台，不代表事故中能够取得紧急凭据；负责批准的人可能不在场，身份服务本身也可能受灾。方案应提前定义授权范围、替代负责人、凭据取得方式和操作留痕，同时验证备用站点能访问必要的密钥。紧急流程仍要能够审计，不能把共享的永久高权限口令当作容灾能力。
改进演练时，可采用逐步增加真实性的方式：先做桌面走读，再在隔离环境验证组件，然后在审批范围内验证真实入口和受控流量。每次只声明实际验证过的能力。生产演练需要明确影响范围、停止条件和恢复责任；本课不要求立即制造真实故障，而是要求将这些条件写进计划，并由合适负责人组织执行。
演练结果至少包含阶段时间、数据缺口、容量表现、用户路径和人工等待。若某步失败，就记录证据、修复负责人和复验条件，不能只截取最终成功画面。平时监控也应观察备用站点：复制积压是否持续增加、恢复所需日志是否即将过期、关键证书是否临近失效。备用能力需要持续维护，临近事故时无法突然补齐。
7 案例：DNS 切换快于数据追上
促销日 10:00，主站点失联。事故记录显示，主站点最后可确认的成功写入时间为 09:59:50；备用站点的已应用水位仍停在 09:53:00。值班人员认为备用应用健康，于 10:01 修改 DNS。到 10:02，部分客户端已经访问备用站点，但备用数据库只应用到 09:55:00。入口迁移完成得比数据准备更快。
用户开始查询不到刚刚提交的订单，于是再次下单。某些幂等记录也尚未应用，备用应用把请求当作首次提交，生成新的订单。与此同时，支付平台重试先前的成功回调，备用服务却找不到对应订单，只能不断重试。CPU 使用率和 HTTP 成功率看上去正常，业务状态已经出现缺口。问题发生在入口、数据与业务验收的顺序上。
时间线需要把事实与推测分开。09:55:00 是备用已应用的水位；截至 09:59:50 的日志其实已经在备用持久保存，只是尚未完成重放。最后 10 秒内是否存在未确认写入，还需要进一步核查。不能将应用落后直接等同于永久丢失，也不能看到日志已到达就立即宣称没有损失。事故报告应明确每种判断的证据来源。
正确流程应先验证旧站点写入围栏，保持备用订单写入关闭，并让客户端收到一致的维护状态。然后继续应用已有日志，检查订单、幂等记录与事件进度。示例中 10:07 应用追至 09:59:50，10:09 完成受控业务验收，10:10 开始分批开放流量。若 10:00 已声明灾难，则声明至开始开放耗时 10 分钟；最终达标时间仍须等待流量和容量验收。
最后 10 秒的不确定范围也不能忽略。数据负责人需要结合提交日志、客户端结果和外部支付记录核查，确认是否满足 60 秒目标，并为无法确认的订单建立对账清单。支付成功却缺少订单的情况进入显式补偿流程，不能由用户反复提交来修复。若证据不足，就报告未知并延长写入关闭或执行已批准的业务降级。
已经出现的重复订单需要按订单号、幂等键与支付交易号建立关联，由业务规则决定保留、取消或退款，并留存处理记录。恢复动作不应直接删除看似重复的记录，因为它们可能已经影响库存、支付和履约。这个案例说明，基础设施恢复时间只是部分结果，订单状态可解释、用户重试可控，才是业务恢复的证据。
8 把切换判据写进容灾方案
把“可以切换”拆成可核查的判据，方案才具有执行价值。触发判据应说明故障范围、观察窗口、本地恢复预计耗时和声明人；例如连续多个观测周期确认关键链路不可用，且本地修复预计超出剩余预算。观察窗口的长度需要通过误报率与中断容忍度确定，不能为了流程整齐随意固定。
数据判据应写明水位来源、测量时间、可接受缺口和未知状态的处理方式。记录可以采用这样的句式：“数据负责人确认备用已应用至位置 X，主站点最后可确认写入为位置 Y，缺口集合已核对，结果满足目标。”位置 X 与 Y 应使用系统能解释的标识；跨库恢复还要说明关联业务如何验收，避免拿无法比较的序号计算差值。
安全接管判据包括旧写入围栏生效、新写入权授予完成以及权限证据可追溯。业务就绪判据包括幂等记录可用、支付回调能够落地、库存事件有明确消费进度、受控订单全链路成功。容量判据则说明目标吞吐、错误率、延迟和观察窗口，不能用“机器已经扩出来”替代“已具备业务承载能力”。
放量步骤要写出节奏和停止条件。可以先开放受控流量，再增加到小比例业务流量，随后逐步达到约定的 50% 峰值能力；每步均检查关键指标与积压趋势。具体比例和观察时长由演练决定。若出现订单重复、状态缺失或持续积压，应停止放量并关闭有风险的写入路径，而不是仅增加实例数量。
回切也需要独立方案。原站点修复后，其数据可能落后于当前主站点，不能因为设备恢复就立即重新接收写入。先保持隔离，再从当前权威数据源同步与核对，选定维护窗口，重新执行写入权迁移和业务验收。容灾期间的新订单、补偿动作和消息消费进度，都必须进入回切检查范围。
最后把 ADR、成本表与风险登记关联起来。ADR 记录为什么选温备、哪些目标仍依赖假设；成本表说明备用容量、传输、日志存储和演练投入；风险表记录供应能力不足、共享依赖失效和未知数据缺口等风险的负责人。每个未消除风险都应有缓解方式与复审日期，业务接受风险也需要明确范围和有效期限。
方案验收应要求可重复的证据：拓扑版本、演练版本、时间线、恢复点、业务样本和遗留问题。这样评审者能看出哪些承诺已经验证，哪些仍待验证。若业务目标、订单链路或生产拓扑发生变化，就重新评估判据；容灾文档不能在首次签字后停止更新。
9 从容灾架构走向多区域架构（P14）
本课的异地温备方案通常只有 1 个站点承担订单写入，备用站点以恢复准备为主要职责。它有助于集中理解恢复点、接管顺序和写入权。进入多区域架构后，业务可能希望多个区域平时就服务用户，以改善访问时延或提高资源利用率。此时，区域之间的关系从“故障后接管”扩展为“日常共同运行”。
容灾方案不会因此失去作用。即使多个区域都在线，仍需要定义区域失联时谁继续接收订单、怎样保护已确认结果、如何迁移请求以及恢复后如何核对状态。日常多区域服务与灾难恢复具有不同验收场景，不能因为存在多个在线入口，就省略写入隔离、数据恢复与演练。
对订单 API，可以先提出较温和的演进问题：是否由多个区域提供商品查询，订单写入仍归属确定区域；用户进入其他区域时，是转发订单写入，还是执行明确的归属迁移。这些问题要求识别哪些操作只是读取，哪些会改变库存、支付或履约责任。将整套 API 无差别复制到多个区域，会隐藏业务状态的不同约束。
评估下一阶段时，继续沿用需求到 ADR 的路径。若目标只是重大故障后在 15 分钟内恢复，当前温备经验证后可能已经足够；若目标变成跨区域用户的日常低时延访问，就需要新增路由、状态归属与容量需求。架构复杂度应由新增需求解释，而不是将“区域越多”当作自然的成熟度指标。
成本也需要重新描述。备用站点平时容量较小，多区域在线则可能让更多资源持续运行，并增加跨区域通信、监控、发布和排错成本。在线区域承担真实流量，能持续暴露部分问题，但不能自动证明有能力在失去某个区域后承接额外负载。剩余容量与故障后的流量分配仍需专门验证。
带到 P14 的输入应包括：本课确认的业务目标、订单状态与幂等记录的存放位置、依赖图、现有写入权边界、演练时间线和未解决风险。下一课再讨论区域职责、请求路由与日常运行方式。本课先守住基本原则：入口可达、数据可用、写入安全和业务可验收，需要分别取得证据，再共同构成恢复结论。
放进方案里
在零售订单 API 的方案中，将容灾目标写为：灾难声明后 15 分钟内恢复关键下单链路，达到正常峰值的 50%；订单恢复点目标为 60 秒，支付确认订单的缺口必须显式对账和处理。同时记录故障发生到声明的时间，按业务合同报告总中断时长。目标由业务负责人确认，技术团队提供容量与恢复证据。
部署选择采用同城多可用区高可用加异地温备。ADR 说明选择原因、备份恢复与热备的比较，以及温备成立的前提。数据持续复制到备用站点，订单结果、幂等记录与消息进度纳入恢复范围；复制监控分别展示日志接收与应用水位。备用应用、证书、密钥和必要外部依赖应能独立就绪。
切换流程依次要求故障确认、灾难声明、旧写入围栏验证、恢复点核对、备用写入权授予、业务验收与分批放量。任何阶段出现未知数据缺口、隔离失败或关键依赖不可用，都进入明确的暂停与升级分支。DNS 调整只能作为流量迁移动作，不能作为数据就绪或恢复完成的证明。
成本预算包含备用计算与存储、复制传输、日志保留、演练和值班投入，并评估切换期间的额外资源需求。风险登记列出共享依赖、容量不足、日志不可恢复和客户端缓存等风险，逐项指定负责人、缓解措施与复审条件。未验证假设需标注，不能写成已具备能力。
验收交付包含生产拓扑版本、决策树、操作流程、演练时间线、恢复点报告及受控订单证据。演练覆盖支付回调、库存消息、用户重试和恢复后的回切准备；拓扑或业务目标变化后重新评审。业务恢复以目标负载下关键链路通过验收为准，遗留订单进入可追踪的对账队列。
10 小结：下一步多区域架构（P14）
容灾架构把业务承诺变成恢复顺序与验收证据。先定义故障边界和 RTO、RPO，再比较选项、记录 ADR、核算成本与风险，最后通过贴近生产的演练检验。对订单 API，旧写入可靠隔离、恢复点明确、幂等与支付状态可解释，是开放流量的必要条件。
自测时尝试回答：DNS 已切换而数据仍落后，为什么不能直接开放下单？日志已经到达而尚未应用，应记录什么证据？旧站点恢复后，为什么还需要重新核对写入权？能把答案放回决策树，就已具备继续学习 P14 多区域架构的基础。