一度成立的假设，终被打破
云架构师们所采用的故障模型广为人知且经过了实战检验：通过自动扩缩容来处理实例故障，以多可用区部署抵御数据中心级别的故障，而区域则处于架构顶层，作为故障爆炸半径的最终边界。这一模型诞生于以硬件故障、自然灾害和软件缺陷为主要威胁的时代，对这类威胁模型而言是合理的。区域在设计上相互独立，具有独立的供电、网络及物理基础设施。
这一假设建立在一个前提之上，即云区域只会因技术原因发生故障，且故障模式均在云服务商的可恢复范围内。但这个前提正悄然崩塌，地缘政治事件并不遵循这一规律。当一国政府切断边境网络连接时，云区域不会以“优雅降级”的方式失效；当制裁迫使云服务商暂停对整个国家的服务时，服务也无法按可预期的时间线恢复。此外，当冲突危及物理基础设施或数据驻留法规突然导致跨境数据复制不再合规时，表现也与常规硬件故障截然不同。
区域并非主权孤岛。地缘政治冲击可以将整个区域作为整体目标予以攻陷，而且速度更快、影响程度更彻底、恢复难度也更高，远超架构师们规划的任何技术故障场景。
本文将探讨地缘政治冲击对分布式系统设计带来的影响。我们的目标是拓展云架构师对故障模型的思考维度，在“区域”之上新增一层架构，让从业者能够以与设计可用区冗余同等的严谨程度来应对这类风险。
图 1：扩展了主权故障域后的云故障层级——边界由管辖权与地缘政治环境而非工程设计来定义。
当区域假设在经受考验时
以下案例不以政治评论为目的。它们作为一系列压力测试，每个案例都打破了传统故障模型中的特定假设，揭示出架构师们往往后知后觉才会发现的真相。
云提供商退出：俄罗斯，2022 年
2022 年，随着制裁措施落地，主流云服务商（亚马逊云科技、微软、GCP 和 IBM）相继限制或终止在俄服务。这一事件对架构造成的影响并非渐进式降级，而是跨越地理边界、近乎同步的强制性基础设施依赖剥离。技术团队这才意识到他们的系统设计仅支持主动迁移，并未考虑被动撤离的极端场景。
这里被打破的假设是：跨区域复制链路具备可恢复性与可控性。这些链路在技术层面中断之前就已演变为法律问题，迫使团队在数据完整性与合规要求之间做出抉择。从中得到的架构教训是：系统并非缺少冗余，而是冗余设计并未考虑主权边界限制。
冲突活跃地区的物理基础设施风险
云区域并不是抽象的概念，它们是实体数据中心，依靠物理光纤线路互联，并接入实体电网获得电力。当某一区域的基础设施地处或邻近冲突活跃地带，电网波动、光纤中断以及设施访问受限等问题可能会同时影响该区域内的多个可用区——而这正是多可用区架构原本想要避免的关联性故障场景。
这里被打破的假设是：同一区域内的可用区是独立发生故障的。在物理冲突场景下，多个可用区同时出现关联故障已成为现实的运维风险，而非理论可能性。
数据本地化要求
欧盟的数据治理框架、印度的数据本地化要求以及中国的跨境数据传输限制迫使许多全球 SaaS 平台进行原始设计中未曾预料到的架构改造。那些依赖全球分布式复制来实现弹性的系统——使用跨区域异步写入来降低 RPO——在更为严格的监管执行要求下，原有的复制拓扑已不再合规。
这里被打破的假设是：复制拓扑是纯技术决策。在注重管辖权限的环境中，数据的存储位置与流转方式受法律约束，而非仅受工程技术限制。那些未在数据层中纳入主权边界、仅将复制当作可靠性保障机制的系统，恰恰因为它们在可用性方面设计精良，反而变成了合规风险。
海底光缆中断
海底光缆被切断会引发区域性的关联网络中断事件，这类情况在很大程度上超出了云服务商的控制范围。红海、太平洋及关键互联节点周边所发生的光缆故障事件表明，看似相互独立的网络链路，若共用物理基础设施，可能会同时出现服务降级。
这一案例将地缘政治因素与架构因素区分开来：即便不涉及政治因素，区域级的关联故障本身就是一类真实存在、却在设计中考虑不足的故障场景。仅物理地理条件本身就足以引发这类问题。
图 2：能够以关联单元攻陷整个区域、完全绕过多可用区弹性的地缘政治与法律力量。
引入主权故障域
为了清晰地分析区域级别的主权性中断，我们需要借助一个概念：主权故障域（Sovereign Fault Domain，SFD）。它是由法律、政治或物理管辖范围定义的故障边界，而非由硬件拓扑结构决定。
可用区是由云服务商设计、运营并负责恢复的、可控的故障影响边界，而主权故障域是自然形成的边界，由云区域所处物理位置及运营所属的主权环境共同决定。服务商无法通过工程手段消除主权故障域，无论架构师是否为其做了规划，它都客观存在。
SFD 概念的实用价值在于它能促使架构师在设计阶段思考一个全新的问题。传统架构设计只会考虑单个可用区故障的应对方案，而 SFD 则聚焦于某一区域因法规限制或物理因素导致无法访问的极端场景，同时还会审视这类情况相较于普通技术故障的发生概率。绝大多数架构师在思考后都会意识到自己从未真正应对过该类风险，因为现有沿用的工具、运维手册与威胁模型从一开始就不是围绕这类极端场景而设计。
下表将常见的地缘政治事件类型映射到分布式系统中的同类问题。这种映射并非单纯的隐喻，每种地缘事件都会在系统中都会有明确的故障表现，与已知的分布式系统故障类型一一对应，因此也能对应到已知的风险缓解方案。
将这类事件视作一等故障模式加以考量能够让架构师把分布式系统领域的成熟设计思路，例如分区容忍、一致性取舍、依赖隔离等，运用到这类目前大多仅靠非正式方式应对（甚至完全未被重视）的风险场景中。
架构影响：从多可用区到多区域
SFD 模型对架构设计的核心影响在于高可用性默认边界的重新定义：
旧标准通过多可用区部署来实现高可用性，而新标准则明确了：对于无法承受主权层级破坏的系统，多区域部署属于必备要求。
这并非要求所有系统都必须采用多区域架构，而是主张：对于跨主权边界运营、或是存在区域性依赖的系统，仅依靠多可用区部署已不足以充分保障高可用性。后续小节将具体阐述这一理念转变在实际落地中需要落实哪些要求。
多主与主备多区域
多区域架构有多种形态。主备架构会在备用区域部署热备实例，可在故障切换时承接流量，但在日常运行中，写入流量仅定向至主区域。多主架构则在多个区域同时分发读写流量，不存在唯一的核心主区域。
就主权弹性而言，架构模型的选择取决于可接受的区域级故障恢复时长。支持自动故障转移的主备架构受 DNS 传播与数据库切换延迟影响，RTO 通常在数分钟至数十分钟。多主架构通过地理分布式写入与最终一致性能力可实现近乎零停机的 RTO，但代价是运维复杂度更高，且数据一致性保障更弱。
在发生故障转移前，有必要理清楚决定实际切换耗时的机制。健康检查延迟是第一道门槛。Amazon Route 53、Azure Traffic Manager 等服务需要判定区域端点状态异常，通常要连续两至三次探测失败才会触发，仅这一检测环节耗时就可达 30 至 90 秒，具体取决于配置策略。DNS 传播延迟则是第二道门槛。
通过中间解析器解析的客户端会受历史域名解析记录的 TTL 过期限制。值得注意的是，AWS Global Accelerator 与 Azure Front Door 可借助任播技术在网络层完成流量路由，从而规避 DNS 传播带来的延迟问题。只要流量管理控制平面不部署在故障区域内便能将实际故障切换时长压缩至一分钟以内。数据库切换延迟是第三道门槛，往往也是最不可控的一环。将只读副本提升为主节点的耗时从数秒至数分钟不等，具体取决于故障发生瞬间的复制延迟。不少团队只在复制延迟为零的理想环境中测试过恢复时效，一旦遭遇真实的区域性故障，实际表现往往会令人感到惊讶。
关键设计决策在于：结合系统的一致性要求和主权中断事件的概率与综合成本来选择合适的多区域部署模型。对于面向跨境支付的金融科技平台，承担多主架构的额外成本是合理的，而仅服务单一市场的内部分析平台则完全没有必要采用这种方案。
图 3：主权中断场景下的主备与多主架构：分钟级恢复与零 RTO，在一致性和成本之间做出权衡。
CAP 定理在主权边界场景下的影响
地理分布式数据库让 CAP 理论的取舍在区域维度上变得清晰明确。跨区域强一致性依赖同步复制，这会导致与区域间网络往返距离正相关的写入延迟。对于要求写入延迟控制在个位数毫秒级的系统而言，跨区域同步复制方案并不适用。
大多数系统的实际解决方案是：跨主权边界采用最终一致性，而在边界内部保持强一致性。数据层对主权边界的识别并非概念层面的设计，它需要通过代码来实现。CockroachDB 具备本地化副本部署能力，运维人员可以借助局部性约束将租约持有者固定部署在指定区域，确保同一管辖范围内的写入操作必须由该辖区内的租约持有者完成确认后才判定为数据持久化完成。Google Spanner 的多区域配置通过命名部署策略实现类似的效果，精准管控数据库主副本的部署位置。未采用全球分布式数据库的开发团队可在应用层落地等效方案：每一条写入请求都会附带管辖范围标签，存储路由层会强制校验标签与服务端点的匹配关系，校验通过后才会完成写入确认：
write_request = { "payload": "user_data", "jurisdiction": "EU", "classification": "personal_data"}if storage_router.compliant_endpoint(write_request.jurisdiction) != current_region: raise SovereigntyViolationError("write would cross sovereign boundary")storage.write(compliant_endpoint, write_request)
那些混淆区域内与跨区域一致性模型、把数据复制当作全局操作且未对管辖权限定做编码约束的系统往往会在极端场景下暴露出这两种架构的本质差异。
控制平面分离
多区域架构设计中一个常被忽视的短板是控制平面的主权隔离。一个系统即便在多个区域完成了数据平面部署，但若负责配置管理、任务编排与运维管控的控制平面仅部署在单一区域，一旦该区域发生故障导致无法访问，整个系统在实际运行层面就等同于单区域架构。
主权弹性要求控制平面能够在各个主权边界内独立运行。也就是说，必须摒弃集中式配置存储、单区域密钥管理服务和不具备区域故障转移能力的编排系统。倘若一个系统必须依赖特定区域才能完成部署或配置变更，那么从主权弹性的角度来看，它算不上真正的多区域架构。这一问题十分普遍，很多系统虽已投入大量成本实现数据平面的多区域冗余，却忽略了控制平面。控制平面往往是遗留的最后一处单点故障隐患，这类风险通常只有经过故障演练才会彻底暴露。
依赖图审计
在上述架构方案落地之前，必须梳理并审计系统依赖关系，排查所有缺少主权容灾兜底的区域性依赖。主权边界故障场景中最常见的问题是：原本默认可全局访问的依赖组件实际上只做了区域性部署。
典型示例包括：未做多区域部署的认证服务、数据仅限单区域存储的 SaaS 工具、采用辖区专属接入节点的支付处理系统，以及经由主区域统一转发的日志与可观测性链路。上述每一种场景都可能形成对单一区域的强绑定依赖。即便核心基础设施已完成规范的多区域改造，这类依赖仍会导致整体服务无法正常运行。
主权弹性设计模式
结合上述的架构影响，可归纳出五种设计模式。其中三种值得展开深入探讨，剩余两种将在本节末尾简要说明。
可感知管辖权的数据抽象层
其核心思路是一个在写入时强制执行数据驻留的路由和存储层，而非依赖事后合规审计。每个写入请求都会附带管辖权标签与数据分类标识，数据抽象层在向调用方确认写入结果前会校验目标存储节点是否匹配对应规则以及是否符合合规要求。
团队往往会低估分类模型本身带来的挑战。路由逻辑的实现相对简单，但要持续维护数据类型与合规管辖区域之间准确、可审计的映射关系，并跟进监管政策的变动，难度极大。这类架构隐患通常会在六至十二个月后集中暴露：当监管规则更新，需要对已按旧标签写入数据的系统进行分类模型迭代升级时，问题便会凸显。针对存量历史数据开展追溯分类，并核验历史写入记录在新规则下依旧合规，其整改成本远高于初期的系统搭建。
延迟带来的影响客观存在，但幅度有限。写入链路中的合规校验只会增加数毫秒延迟，而影响更为明显的核心因素是合规存储端点与应用服务之间的地理距离。
主权内复制模型
大多数复制拓扑默认采用全局化设计，仅在特殊场景下才受管辖权限定约束。而该模式颠覆了这一固有逻辑，将跨境复制视作受限特权操作，要求其必须经过显式定义、版本化管理且支持随时终止。
其实现方式通常需要维护两个复制拓扑：一个为持续运行的主权内复制，另一个为跨境复制。跨境数据流转需要在版本化策略文件中明确罗列，可单独暂停，且不会影响主权内复制的正常运行。在现有全局复制架构上改造落地该模式的团队普遍遇到同一类问题：原有 RPO 指标一直隐性依赖跨境复制，仅靠区域内复制无法达成既定的合规与业务目标。因此，若要让跨境复制安全转为可关停模式，首要前提是重新设计并优化区域内复制拓扑结构。
区域撤离手册
一份成文归档且经过实战演练的操作手册，用于在时效紧迫的场景下将业务负载快速迁出故障区域。本节末尾的图 4 列出了关键的执行约束：必须先冻结复制，再执行 DNS 故障转移，并优先完成数据导出。忽略该流程的团队都会遇到同样的故障——写入分裂，即撤离区域与目标迁移区域会在短期内同时写入数据，导致两端数据状态出现分歧。这个问题虽可修复，但在紧急运维的高压场景下处理过程会异常棘手。
操作手册还必须兼顾那些隐蔽的区域性依赖。认证服务、功能开关系统、内部证书颁发机构等组件表面上看似全局可用，实际上却部署在单一主区域，没有主权级容灾备份。检验手册质量最有效的方式是开展无预告的应急演练，并搭配清晰明确的决策权限流程，明确区域撤离操作的触发责任人。仅有技术流程、缺少权限分工的操作手册往往会在关键环节陷入停滞。
关于其余两种模式的说明
各法律管辖边界下的多云部署与合同退出预案是实现主权弹性的有效手段，但这类举措主要取决于采购与法务决策，而非技术架构设计。若云厂商在特定辖区的合规监管地位存在重大风险，就值得投入运营成本，搭建多云隔离架构。数据可移植性条款与数据导出服务等级协议也应在风险爆发前提前协商敲定。以上两项举措均无法替代上述的三种架构模式，只能作为配套的风险管理补充手段。
图 4：区域撤离有严格的顺序约束：复制必须在 DNS 故障转移之前停止，否则会导致写入分裂和产生合规监管风险。
针对区域级故障的混沌工程
将混沌工程的实践范围拓展至主权故障域所遵循的核心原则与可用区级故障注入完全一致：梳理系统固有假设，设计针对性实验进行压力校验，暴露薄弱环节与故障点，再据此完成架构加固与优化。
以下实验用于验证前文所述的各类架构模式，每项实验均对应故障模型中的一项特定前提假设。
区域失效模拟
这项实验的核心目标是验证多区域部署能否真正实现运维的独立隔离，而不仅仅是依赖集中管控的数据平面冗余。实验会阻断所有到目标区域的出站流量，包括控制平面端点、密钥管理服务等，不仅仅是应用层流量。
在 AWS 环境中，最稳妥的实现方式是结合使用 VPC 安全组规则与网络 ACL。安全组是有状态的，作用于实例层级；而网络 ACL 是无状态的，作用于子网层级。若要完成完整的区域级故障模拟，网络 ACL 是最优选择。它可管控所有离开子网的流量，不受实例层面配置的影响：
# Identify the IP ranges for the target region# AWS publishes these in ip-ranges.jsonaws ec2 describe-managed-prefix-lists \ --filters Name=prefix-list-name,Values="com.amazonaws.us-east-1.*"# Create a NACL rule blocking all egress to those rangesaws ec2 create-network-acl-entry \ --network-acl-id acl-xxxxxxxx \ --rule-number 90 \ --protocol -1 \ --rule-action deny \ --egress \ --cidr-block <us-east-1-ip-range>
对于采用混沌工程平台的团队而言，Gremlin 的网络黑洞攻击能够以更少的手动配置、更简洁的回滚流程实现同等效果：
{ "type": "network", "subtype": "blackhole", "args": { "hostname": ["amazonaws.com"], "egress_ports": ["443", "80"], "length": 300 }, "target": { "type": "Container", "tags": { "region": "us-west-2" } }}
无论采用何种实现方式，观测检查清单是一样的。自动故障转移是否在预期的 RTO 时限内正常触发？运维人员能否通过备用控制平面完成配置变更，还是因主区域配置接口失联导致系统进入只读或降级运行状态？密钥管理服务、证书续期流程及功能开关服务能否持续正常运转，或是会随着主区域端点不可用而悄然降级？最后一类组件往往是最先出现故障的薄弱环节。
跨区域流量黑洞封堵
为了实现跨区域流量黑洞封堵，需要在预发环境的网络层设置区域间硬性隔离，以此模拟主权边界失效所对应的网络分区故障。与只会引发超时与重试的平滑区域降级不同，硬性网络隔离会直接拒绝连接。围绕优雅降级假设而设计的系统往往无法妥善应对这类极端场景。这种演练方式可全面校验故障转移路由逻辑、网络强隔离下的数据库分区容错能力，以及客户端重试机制与熔断器的正确性。
合规分区演练
通过主动禁用相关复制来模拟跨境复制被突然禁止的场景，验证系统能否在不破坏数据完整性的前提下持续承载区域内业务流量。这项演练与区域中断演练存在本质区别：整体服务并未中断，只有跨越主权管辖边界的特定数据流转被禁止。
这种方法用于验证主权域内的复制模型和具备管辖边界感知能力的数据抽象层。那些未将跨境数据流显式设计为可终止的系统，在遭遇此类限制时往往会发生故障，且难以干净恢复。
依赖移除注入
选择性切断系统对各类区域性依赖的访问，包括认证服务、支付处理机构及 SaaS 集成组件，并观测系统的降级表现。目标是提前识别这一类隐蔽依赖：看似全局可用、实际仅部署在单一区域，避免在生产环境遭遇主权合规事件时集中暴露风险。
多区域部署何时值得投入，何时得不偿失
多区域架构（将计算、存储、数据传输与负载均衡复制至第二区域）通常会使基础基础设施成本近乎翻倍，同时还会提升运维复杂度，带来更难平衡的数据一致性取舍，并要求持续投入资源来完善运维手册、混沌工程演练与依赖项审计。并非所有系统都值得承担这类投入。业界更实用的评估框架是借鉴安全风险建模领域的年度预期损失（Annual Loss Expectancy，ALE）模型：
ALE = ARO × SLE
其中
ARO = 年度发生率（给定区域每年发生主权破坏事件的估计概率）
SLE = 单次损失预期（完整区域中断事件造成的总体业务影响）
SLE 有必要进行逐项拆解，因为团队在测算时往往只统计停机带来的营收损失，从而严重低估整体影响：
SLE = 年度营收 / 365 × 预估停机天数 + 平台重构与合规整改成本 + 客户流失潜在损失
以下是某中型 B2B SaaS 平台示例，年度经常性收入（ARR）5000 万美元，业务覆盖欧盟与亚太地区（文中数值仅作演示参考，实际使用时请替换为自己的预估数据）：
ARO = 0.05（区域级主权隔离事件的年度发生概率为 5%）
SLE = 250 万美元（假设：5000 万美元 ARR / 365 天 × 18 天估计 RTO 用于计划外主权退出，加上重新平台化成本和客户流失风险）
ALE = 0.05 × 250 万美元 = 12.5 万美元 / 年
如果主权弹性改造的年度增量成本低于 12.5 万美元，单从预期收益角度判断，该项投入就是合理的。这一测算还没有计入监管处罚、声誉影响或在竞争对手无法运营的管辖权中可信运营的期权价值。
这里有一个需要注意的点：鉴于 ARO 的估算难度较高，建议分别按照 1%、5%、10% 三种年度概率进行测算。如果投资在三种情景下均具备合理性，说明相关决策对不确定性具备较强抗风险能力。若仅在 10% 的高概率场景下可行，则说明方案高度依赖概率估算的精准度，需采取更为保守的投入策略。
合理的问题应为：“对于当前系统而言，区域级中断会造成多少损失？这些损失是否足以证明投入成本打造主权弹性能力具备合理性？”
以下是一个简单的决策框架：
系统是否跨主权边界运营，在多个管辖区域内服务用户或处理数据？
系统是否存在认证服务、支付处理机构、SaaS 集成等区域性依赖，且缺少跨主权容灾备用方案？
若某区域因法规限制彻底无法访问（并非单纯技术降级），造成的业务影响范围是否在可接受范围内？
系统是否需遵守数据本地化合规要求，且此类要求会在主权隔离场景下受跨境复制机制影响？
若以上任一问题的答案是肯定的，投入建设主权弹性能力便具备合理性。诸多落地方案（如管辖边界感知的数据抽象层、主权域内复制机制、区域撤离运维手册等）仅需花费多区域多主部署的小部分成本就能显著提升系统抗风险弹性。核心原则是：投入规模与系统实际面临的主权合规风险相匹配，避免对所有架构盲目过度改造、无效镀金。
结论：重新定义架构假设
将区域作为隔离边界的设计假设在主要威胁为硬件故障、自然灾害与软件缺陷的场景下是合理的。在这些前提下，故障模型逻辑清晰：优先在单区域内构建冗余能力，将跨区域容灾作为兜底手段，并围绕可快速恢复的故障场景进行设计。但这套模型需要被扩展，以便覆盖基础设施实际运行所面临的复杂环境与风险条件。
从业者需要重新审视并梳理现有的故障模型。如果当前架构设定的最大故障影响范围为单区域，则需要评估突破该边界所需的各类风险条件。逐一排查所有外部依赖，识别是否存在仅限单区域部署且无跨主权容灾备份的组件。梳理数据复制拓扑结构，明确其跨越的所有管辖区域。至少要明确区域业务撤离的完整执行条件与流程，并评估团队能否在紧急压力下高效落地执行。
主权故障域并非现有故障模型的替代方案，而是延伸补充。这一层级让架构师能够以对待硬件、网络故障同等严谨的思路去考量一个正变得愈发相关的风险类别。
全球云生态系统的碎片化是一个系统可靠性问题。架构师唯有正视该问题并开展针对性工程设计才能打造韧性更强、影响更为深远的系统——不仅可抵御硬件故障，更能适配基础设施在全球实际运行中面临的各类复杂场景与约束条件。
【声明：本文由 InfoQ 翻译，未经许可禁止转载。】
查看英文原文：https://www.infoq.com/articles/sovereign-fault-domains-cloud-resilience/
