当超大规模云服务商仅在一个地理区域内部署时，架构选择相对简单。工程师只需要针单个区域的可用性进行优化，选择合适的数据库一致性模型，并调整自动扩展策略。成本结构透明，延迟特征可预测。而增加第二个或第十四个区域，则会同时从根本上改变这两个维度，而且几乎从来都不会只有好处。
我曾经多次在跨区域部署过程中做过这种权衡。塑造这一框架的关键决策包括：采用同步还是异步复制、哪些依赖关系需要跨区域边界进行连接，以及在何种情况下新增区域能降低成本而非增加成本。
多区域决策框架：为何简单的数学方法行不通
在接触区域扩展的初期，我曾经将这种决策视为一个简单的算术问题。我们在亚洲的用户面临着 250 毫秒的延迟。在新加坡新增一个区域可以将延迟降至 30 毫秒。如果该区域的月成本为 X 美元，改善延迟带来的收入为 Y 美元，那么当 Y > X 时则进行扩展。
随着时间的推移，这种模型被证明是不够完善的。区域成本并非固定不变，复杂性会不断累积，而且延迟改善中有相当大一部分往往是源于路由优化，而非增加区域本身。
新增区域的真实成本剖析
新增区域的总拥有成本包括一些在初步商业案例中通常被低估的方面。
基础设施资本支出
硬件、网络与设施成本（含跨区域网络架构），在我们绝大多数服务上线项目中，约占区域基础设施总成本的 25%。
服务上线开销
在新增区域中运行的每项服务都会产生配置、验证和上线成本。在数百项服务中，我们在正式上线前识别并解决了数千个服务间的依赖关系问题（例如：未记录、循环依赖、冗余，以及在成本或性能方面未达到最优）。
复制与同步成本
跨区域同步复制可能会使写入延迟增加多达一百毫秒。而异步复制虽然能减轻对写入延迟的影响，但会引入最终一致性窗口，需要应用程序层进行处理。
运营开销
运营开销包括额外的值班覆盖、部署管道以及事件响应范围。我们的自动化工作（在十二个月内使数十个服务团队的手动工作量减少了 89%）正是出于防止运营开销随区域覆盖范围扩大呈线性增长的考虑。例如，以前在每次里程碑发布时，区域服务部署都需要由技术项目经理（TPM）手动协调各团队的就绪信号。通过将这些检查点信号自动化，并直接从服务监控中提取健康指标（而非依赖人工确认），我们消除了协调工作中最大的一块协调时间。
跨区域流量成本
跨区域数据传输是云基础设施中每千兆字节成本最高的项目之一。需要频繁进行跨区域数据交换的架构，其持续产生的成本可能在 12 到 18 个月内就会超过一次性部署的投资。
延迟：你真正购买的是什么
降低延迟是扩展区域时最常被提及的理由，却也是最常被误解的。在决定承担新区域的成本之前，值得仔细分析你的延迟预算究竟花在了哪里。
延迟预算分解
表 1：按组成和区域可寻址性划分的延迟预算分解
从本质上讲，网络传播是唯一与地理位置相关的因素，因此必须通过物理上的邻近性来解决。所有其他因素均可以通过架构调整、CDN 部署、连接池、查询优化以及消除依赖关系等方式加以改进；相比新增区域，每种方案的成本都更低。
实际上，经过仔细地延迟监测，结果一再表明，观测到的延迟中很大一部分（通常接近一半）源于非地理因素。优先解决这些问题几乎总是更明智的投资。
什么时候新增区域才是正确的答案
尽管有上述提醒，但在某些场景下，新增区域确实是合理的选择。
数据主权与合规要求
当数据必须根据《通用数据保护条例》（GDPR）、联邦风险与授权管理计划（FedRAMP）或类似框架的要求，在特定司法管辖区内物理存储时，新增一个区域便成为合规的必要条件，而非针对延迟的投资。成本分析的重点也从“每美元的延迟成本”转向“每美元的合规风险”。数据主权与地缘政治风险——无论是源于监管不稳定、政府的数据访问要求，还是供应链连续性方面的担忧——如今已成为区域选择的首要考量因素，对于企业和政府客户而言尤其如此。
要求延迟低于 50 毫秒的一级用户群体
对于实时交易、互动游戏和视频会议而言，受光速传播的物理限制，当大规模用户群体距离现有最近的服务区域超过 3000 公里时，地理就近部署就成了硬性要求。
满足 Active-Active 要求的灾难恢复
若恢复时间目标（RTO）需要控制在 15 分钟以内，则必须在至少两个地理位置上相互隔离的区域部署主动式基础设施。这是一项针对系统韧性的投资；延迟改善则是其带来的一个有益的副作用。
通过本地化运营实现市场扩张
在与具有低延迟 API 要求的本地支付处理商、身份提供商或政府系统进行集成时，出于功能性考虑，无论终端用户的延迟情况如何，可能都需要部署本地区域。
部署架构模式及其权衡
一旦决定增加一个区域，所选的架构模式将决定后续延迟优势与运维成本之间的动态平衡关系。
模式 1：全栈 Active-Active 模式
每个区域都托管着应用程序栈的一个完整且独立运行的副本。用户将被路由到距离最近的区域；每个区域同时处理读写操作。数据以异步方式进行复制，通常采用“最后写入者胜出”机制来处理写入冲突。该模式能带来最大的延迟优势，但运营成本也最高：需要完全复制基础设施、持续进行跨区域数据传输、处理应用层的一致性、解决冲突，以及整个集群的可观测性。
最适合的情况是：写入密集型工作负载且用户分布于全球各地，即在所服务的每个司法管辖区内都有数据驻留要求的系统。
模式 2：本地读取 / 全局写入
其中一个区域是全局写入区域；所有区域均通过本地副本处理读取请求。来自非主区域的写入请求在获得确认前会被代理到全局写入区域。读取请求在本地处理，从而在全球范围内提供比较低的读取延迟，但非主区域用户的写入延迟会受到跨区域往返时延的影响。
模式 3：Active-Passive 模式（带自动故障转移）
一个功能完备的主区域处理所有生产流量；辅助区域接收持续复制，但在正常情况下不处理任何流量。辅助区域可以缩减规模（即转为温备）或仅在存储层进行配置（即指示灯模式），这使得该模式在三种模式中具有最佳的成本效益。其权衡在于故障转移时间：5 到 20 分钟，而 Active-Active 模式的故障转移时间则不到 30 秒。
其中存在一个隐性的运营风险：从未经过测试的故障转移路径在实际调用时往往会发生故障。请定期进行测试，并在规划中纳入实际故障转移时间，而非理论上的恢复时间目标（RTO）。
表 2：多区域部署模式比较
有一项设计考量贯穿了这三种模式：一致性策略应设定在数据类型层面，而非系统层面。在我们的存储服务中，对象元数据需要强一致性；而复制状态则可以容忍暂时的不一致。那些对所有数据统一应用单个一致性策略的系统，要么对不需要复制的数据进行了过度投资，要么对数据保护不足。Active-Active 模式尤其容易犯这种错误，因为其复杂性使得按类型分析一致性变得更加困难。
经济高效地运营多区域基础设施
是否新增一个区域的决策，与如何经济高效地运营所有区域密不可分。在我们至少三次发布中，运营成本在前两年内的增长速度超过了客户采用率的支撑能力。最具杠杆效应的成本控制措施主要集中在三个方面。
消除关键路径中的跨区域依赖关系
大多数跨区域边界的同步调用都会增加延迟并产生成本。对跨区域请求路径进行分布式追踪时，经常会发现令人惊讶的依赖链：对区域 A 的请求会触发区域 B 的配置查询，进而又触发区域 A 的授权检查，这使得原本通过合理的数据布局便可以在 20 毫秒内完成的操作，将延迟增加了超过 100 毫秒。
解决之道在于实现区域数据自给自足：每个区域都保留处理请求所需的所有数据的本地副本，从而避免在热路径中进行跨区域调用。虽然复制基础设施需要前期投资，但在规模扩大后能带来复利回报，因为跨区域调用的成本会随流量增长而增加，而复制成本则基本是固定的。
在我们的扩展计划中，填补数千个服务依赖缺口——其中大部分是未记录的跨区域调用依赖关系——是发布准备工作中效益最高的举措之一。每个缺口的填补都意味着可靠性的提升和成本的降低。
优化基础设施规模并投资于自动化
无论流量成熟度如何，在各区域采用相同的基础设施规模都会导致新区域的容量利用率不足。通过审核成熟区域中的资源浪费，并合理调整新部署的规模，能够不断降低每次上线的资本支出（CapEx）。那些能够揭示现有区域中资源浪费的容量分析技能，直接提升了新区域规划所需的严谨性。
另一项倍增器是自动化。多区域集群的运营成本主要由人力投入构成，例如部署、配置变更、健康检查和事件响应。一个每个区域需要四小时人工协调的流程，在 3 个区域时尚可应对；但在拥有数百项服务的 14 个区域中，同一流程每年累计耗时将达数千小时。我们在 12 个月内通过跨数十个服务团队的人工干预接近为零的自动化，将人工工作量减少了 89%。这正是源于以下现实：自动化投资的收益与区域规模成正比，在规模化运营中绝非可有可无。
项目管理维度：大规模上线执行
在不影响现有区域运营的前提下，快速将新区域推向市场，其重要性不亚于架构本身，却往往未受到应有的重视。
关键路径优化
多区域发布涉及数百至数千项任务的依赖关系图。关键路径（即最长的顺序链）决定了无论投入多少资源，项目能达成的最短时间表。在我们的项目中，最具影响力的举措是识别出那些仅因“我们一直都这样做”而非真正存在技术顺序要求而必须按顺序执行的任务。围绕真实的依赖关系重新调整执行计划，在无需额外工程投入的情况下，将时间表压缩了约 25%。
可视化与上线后优化
要在保持开发速度的同时，确保数十个服务团队、基础设施部门和高管利益相关方之间的协同一致，需要专门构建的可视化基础设施。一个自助式数据湖和洞察仪表盘消除了跨多个 TPM 的手动报告工作，其投资回报率将远超预期，使原本需要数天汇总工作才能进行的、基于数据的优先级讨论成为可能。
工作不会在正式上线后结束。生产运营的前 90 天通常会出现客户需求变化、延迟异常以及复制调优需求等情况。一个结构化的上线后优化阶段，配备专门资源进行持续的监控和调整，与初始部署配置相比，可以使成本效率提高 20% 至 30%。
一个用于多区域扩展的决策框架
表 3：多区域扩展决策框架
扩展至新区域：实际案例
在一次区域扩展发布中，我们接到任务，需要为亚洲地区快速增长的用户群改善延迟问题。初步指标显示，端到端延迟约为 260 毫秒。当即提出的方案是上线一个新区域。
在正式实施前，我们对完整的延迟路径进行了模拟。结果发现，仅约 45% 的延迟源于地理因素，其余部分则来自低效的服务依赖关系、重复的身份验证调用以及未重用连接。
我们评估了三种方案：
立即上线一个新区域。
优化路由并消除跨区域依赖关系。
分阶段采用这两种方法。
我们选择了分阶段实施的方法。
关于下文中的数据说明：本案例研究中的延迟数值（260 毫秒、160 毫秒和 60 毫秒）是实际上线时测得的数值，已进行四舍五入处理。22% 的复制开销和 35% 的延迟降低率均来自实际测量的遥测数据，而非概括性估计。
首先，我们引入了基于延迟的路由机制，并从请求路径中移除了两个关键的跨区域服务调用。仅此一项就将延迟降低了约 35%，使其降至约 160 毫秒，不需要任何新的基础设施投资。通过优化数据库访问模式并启用连接池，又进一步缩短了 30 毫秒。
直到此时，我们才着手上线新区域。由于系统已经过优化，增量效益更加明显，成本效益也更为合理。上线后，本地用户的延迟降至 60 毫秒以下。
成本方面的实际情况却更为复杂。在高峰时段，跨区域数据传输产生的复制开销比预测值高出约 22%，这主要归因于元数据的扇出效应。每次向新区域写入对象时，都会触发该对象本身及其关联元数据（包括访问控制记录、版本标记、复制状态标志）的复制，而这些元数据均作为独立的操作通过跨区域链路进行传输。在高峰时段，仅元数据流量就占到了总复制流量的约三分之一。这是我们上线前的流量模型未能捕捉到的因素，因为元数据写入在应用层是不可见的。第二个主要驱动因素是复制重试流量：当跨区域链路在峰值负载下性能下降时，复制失败会触发重试，而这些重试又给本已拥堵的链路增加了负载，这种反馈循环导致传输成本远远超过了稳态预测值。处理这些故障占用了本来应该分配给其他任务的工程资源。关键的经验教训在于：操作顺序至关重要。在扩展之前优化架构并实现运维自动化，既能保证我们从新区域中获取到最大价值，又能避免不必要的成本激增。
小结
多区域架构的选择是云基础设施中影响最为深远的决策之一。其优势显而易见：降低延迟、提升灾难恢复能力、符合监管要求以及拓展市场。但随之而来的成本也不容忽视：基础设施冗余、复制复杂性、一致性权衡，以及随规模扩大而不断累积的运营开销。
那些能够有效地应对这一选择的企业，会将区域扩展视为一个持续的优化问题，而非一次性的建设。他们会积极部署监控工具、对成本进行纵向建模、不懈地推进自动化，并保持架构选择与业务成果之间的可追溯性。
根据上线多个区域以及运营 PB 和 EB 级全球基础设施的实践经验，我们得出的结论是一致的：在多区域成本效率方面取得成功的团队，并非那些在上线时选择最便宜架构的团队。相反，成功的团队是那些投资于系统、自动化以及协调基础设施的团队，这些投资使他们能够在上线后持续进行优化。最困难的部分并非上线一个区域，而是长期运营得当。
原文链接：https://www.infoq.com/articles/multi-region-latency-cost-tradeoffs/
