多云 FinOps：一种用于跨云成本优化的工程框架

多云架构为团队提供了灵活性，使其能够针对可用性、供应商能力及地理覆盖范围进行优化。但这种灵活性也因数据在云服务提供商之间的迁移增加了隐性成本。通过服务部署决策、通信模式和扩展行为，这些成本会不断累积，并随着时间的推移呈复利增长。等到账单上显示出来时，架构层面的问题早已形成。

大多数组织采取的都是被动应对措施，例如审查账单、协商费率以及生产环境上线后进行调优，但这些措施都没有从根本上解决问题。在多云系统中，成本效率应该在设计阶段就确定下来。

本文将后端 FinOps 应用于多云架构。内容涵盖通过 FOCUS 实现成本可视化、减少跨云数据传输策略，以及工作负载部署、同步模型和集成到 CI/CD 流程中的成本治理等工程实践。其目标是让成本控制成为系统的结构性特性，而非事后才考虑的因素。要设计出架构本身就能有效控制成本的系统。

在维护一个零售订单和支付平台的生产环境时，我注意到，单个结账请求可能会涉及促销评估、支付授权、订单持久化以及履约服务等多个环节。分布式追踪数据显示，下游的瞬时故障可能会通过重试和反复检索订单上下文，将一个逻辑操作转化为多次网络调用。这一问题促使我们将真正的面向客户关键路径的交互，与无需阻塞订单确认的下游处理区分开来。所带来的实际效益在于降低了故障耦合度，并使结账延迟更加可以预测：非关键的下游消费者不会再拖慢客户响应速度。我特意省略了专有交易量和提供商拓扑信息。本文后面的受控实验将这一生产模式推广到了多云环境，并量化了其成本影响。

表 1. 按提供商划分的实际出站流量成本结构（2026 年 1 月），数据来源：AWS、Azure 和 GCP（*通过 NAT 网关传输的私有子网流量）

行业研究表明，许多组织都低估了这些成本。问题的核心在于结构性因素。数据传输成本由架构和数据流动模式所决定，但这些成本通常只有在部署完成后，通过账单报告才能发现。

“后端 FinOps：在云端构建高性价比的微服务”一文阐述了如何在单个云边界内优化微服务，多云环境还需要进一步关注。如下文所述，有四种模式占了可避免的出站流量开支的绝大部分。

在许多多云系统中，单个用户请求会经过由不同云提供商托管的服务。虽然这种方法提高了灵活性，但也产生了隐性的网络传输成本。云之间的每次同步请求都会产生出站流量和网关费用，而且这些费用会随着流量的增加而上升。

下面的基准测试基于已公布的 2026 年第一季度的定价，模拟了一个典型的企业部署场景。产品目录服务运行在 AWS 的 EKS 上，推荐引擎运行在 Google Cloud 上，欺诈检测服务运行在微软 Azure 上。客户交易过程会同步调用每项服务。

AWS Well-Architected Framework 和 Google Cloud Multi-Cloud Guidance 均指出，跨云数据传输是多云环境中一项显著的成本驱动因素。

from enum import Enumclass TrafficClass(Enum): INTERACTIVE = "interactive" BACKGROUND = "background"class CrossCloudGateway: def init(self, realtime_client, batch_queue): self.realtime_client = realtime_client self.batch_queue = batch_queue def dispatch(self, request, traffic_class): if traffic_class is TrafficClass.INTERACTIVE: # Customer is waiting, e.g., for payment authorization. return self.realtime_client.send(request) # Customer is not waiting, e.g., for an analytics export. self.batch_queue.enqueue(request) return {"status": "accepted"}# Usagegateway = CrossCloudGateway(realtime_client, batch_queue)gateway.dispatch(payment_request, TrafficClass.INTERACTIVE)gateway.dispatch(analytics_event, TrafficClass.BACKGROUND)

复制代码

这个简化的网关示例清晰地展示了流量分类。支付授权属于交互式操作，因为客户需要立即得到响应，所以该请求以同步方式发送。分析事件属于后台操作，因为客户无需等待，所以可以将其放入队列，随后进行批处理、压缩，或在更接近数据源的位置进行处理。关键的设计决策并非网关实现本身，而是要在工作负载跨越服务提供商边界之前对其进行分类，从而确保交互式流量和后台流量不会自动共享相同的延迟、可用性和成本特性。

例如，如果 AWS 中的结账服务在订单完成之前调用 Azure 中的欺诈检测服务，那么现在结账的延迟和可用性就取决于这两个服务提供商以及它们之间的网络。

重试、超时以及下游的扇出效应会进一步增加跨云调用次数和传输字节数。因此，设计的关键问题在于：调用方是否真的需要即时响应？如果确实需要，那么团队应采用严格的超时设置、备用方案、小数据包以及受控的重试机制；如果不需要，则可以将这种依赖关系替换为异步消息传递。

大多数工程团队会持续地在云服务提供商之间传输数据，因为从运营的角度来看，实时处理似乎是正确的。但在实际操作中，很少会根据实际的使用模式对这一假设进行验证。分析管道、机器学习重新训练工作流以及合规系统主要以小时或天为周期运行，而且每次数据传输都会产生按 GB 计费的出站费用。其结果就是，企业最终为数据传输支付的费用是基于数据的生成速度，而非实际的使用情况。

在这种情况下，问题并不在于应用程序之间的同步耦合。客户不需要等待分析系统。问题在于数据传输频率快于业务对数据时效性的要求。通过定义一个可接受的数据时效阈值（例如五分钟、一小时或一天），便可以在传输前对记录进行批处理、去重、压缩或聚合。

Expedia Group 发布的一个案例清楚地说明了这一问题。应用程序在不同的 AWS 区域之间反复获取相同的数据集，导致跨区域出站成本居高不下，尽管底层数据几乎没有变化。为了避免反复传输相同的数据，Expedia 引入了 Alluxio 缓存层，在本地提供频繁访问的数据。这使得跨区域传输成本降低了 50%，同时还提升了应用程序的性能，而这一切均未对业务逻辑或数据本身做任何改变

主要的成本因素是跨区域数据传输的频率，而非每 GB 的费用，对于没有严格数据时效性要求的用户而言尤其如此。

将原始事务日志、特征数据或点击流数据跨越云边界进行传输以供下游处理，是成本最高的数据迁移模式之一。其低效之处不仅在于传输的数据量，还在于这些数据在到达目的地后最终会被过滤、聚合或丢弃。

行业指南均将“近源处理”视为首要的成本优化策略。无论是 Azure Well-Architected Framework，还是 Google Cloud 的混合架构文档，都主张在数据跨越服务商边界之前对其进行压缩，而不是依赖目标端来执行压缩操作。实际应用案例进一步印证了这一原则。西门子重新设计了其分析管道，仅在源头处理增量变化，而非在每次运行时传输完整的数据集副本，从而将管道维护成本降低了 90%，并将每日加载时间从 6 小时缩短至 25 分钟。

这一原则在平台架构中得到了越来越充分的体现。以 Google BigQuery Omni 为例，它将计算任务转移到数据所在的 AWS 或 Azure 环境中，而非将数据传输到 Google Cloud，从而完全免除了符合条件的跨云分析工作负载的出站数据传输费用。架构方面的共识非常明确：在数据的源头进行处理，仅传输处理结果。

在游戏和物联网平台等事件驱动型系统中，单次状态更新通常会同时广播给多个云服务提供商。尽管每个云服务提供商接收到的信息相同，但数据会独立地传输到每个目的地，从而导致冗余的跨云流量，并使出站成本成倍地增加。

更高效的方法是将更新信息一次性地发布到共享的分发层，例如内容分发网络（CDN）或中央枢纽云，并允许其他环境在本地检索该信息。这种方法确保了相同信息的传递，同时避免了跨服务商进行重复传输。

该模式已经在生产系统中得到了应用。Amazon CloudFront 和 Cloudflare 等服务会在边缘进行内容缓存，因此，重复的请求可以在本地得到响应，而无需反复跨越服务提供商的边界。在分析领域，Google Cloud 的 BigQuery Omni 也遵循类似的原则，在数据所在的位置进行处理，而非在不同的环境之间复制数据集。

该实验模拟了一个常见的电子商务结账流程。在结账过程中，客户提交购物车，由 AWS 托管的结账服务负责验证价格和库存、计算税费和折扣、授权支付、创建订单，并返回订单确认信息。

订单完成后，位于另一云平台上的报表平台也需要相同的订单数据，用于销售仪表盘展示和运营分析。虽然这个报表步骤并非完成客户购买的必要环节，但若架构设计不当，仍然可能将其直接置于结账流程中。

在同步传输方式下，结账服务将完整的订单负载发送至远程报表平台，并在收到响应后才确认订单。

在每小时批量传输模式下，结账服务会立即确认订单，将报告事件放入 AWS 队列，随后以每小时为单位批量传输经过去重和压缩的记录。

在近源处理模式下，AWS 会在本地计算所需的仪表盘指标，并仅将汇总结果传输至远程平台。

这三种方法均支持相同的每小时生成报表的要求。因此，该实验专门分析了通信模式对结账延迟、跨云流量以及网络成本的影响。

该测试使用了十万个合成的已完成订单。每个订单产生的跨云有效载荷平均为 250 KB，其中包括订单详情、明细行、支付元数据和履约信息。

网络成本计算采用每 GB 0.09 美元的示例传输费率。另一项计算则采用每 GB 0.135 美元的费率，其中包含每 GB 0.09 美元的传输费，以及每 GB 0.045 美元的示例网关处理费。

批处理架构通过数据去重和压缩，将传输数据量减少了 60%。近源处理则将数据量减少了 95%，因为只有订单数量、销售总额、付款分配以及其他仪表盘指标会跨界传输。

同步通信既增加了延迟，又加剧了故障耦合。结账确认依赖于远程报表平台。远程延迟、超时和重试会直接影响客户交易。

批处理在成本和可靠性方面均有所提升。将报表功能从结账流程中移除后，p95 延迟从 420 毫秒降至 145 毫秒，同时预计网络成本降低了 60%。

近源处理带来的成本效益最大。仅传输汇总后的仪表盘结果，在包含网关处理费的情况下，将预计月成本从 3375 美元降至 168.75 美元，降幅达 95%，每年可节省约 38475 美元。

架构的影响大于服务商定价。将基础传输费率从每 GB 0.087 美元调整为 0.12 美元，会使同步传输的月成本增加 825 美元。而将架构从同步传输改为近源处理，即使不计入网关费用，每月也能节省超过 2000 美元。

实验表明，最大的经济效益来源于减少跨越云边界传输的数据量，而不仅仅是选择出站费率较低的云服务提供商。异步处理将远程报表平台从面向客户的交易路径中移除，而批处理、压缩和源头聚合则降低了重复传输数据的成本。

由于报表平台需要的是每小时的汇总数据，而不是完整的实时订单记录，所以近源处理是合适的选择。而对于需要立即做出欺诈决策、授权响应或交易级审计数据的工作负载，可能仍然需采用同步或记录级通信。

可持续的成本控制并非源于定期账单审查，而是源于将成本视为一项非功能性需求，并以与对待延迟或可靠性相同的严谨态度来加以管理。

图 1 说明了如何将成本管理作为一项持续的工程关注点，而非事后进行的财务核算。该循环将软件生命周期的关键阶段——设计、构建和运行时——整合为一个统一的反馈系统。

该流程始于设计阶段。在这个阶段，团队应预先定义成本预期，其中包括估算数据传输量、了解服务部署位置，以及为跨云交互设定成本预算。这些早期决策为后续所有阶段确立了基准。

在实施阶段，可以通过一个轻量级的验证步骤，基于部署元数据、预期请求量和有效载荷大小来估算预计的月出站流量。如果估算的网络成本超过预定义的阈值，那么管道可能会要求在部署前进行架构审查。与安全门或质量门类似，这种方法使工程团队能够在低效的通信模式转化为运营成本之前将其识别出来。

在构建阶段，这些预期通过 CI/CD 管道得到落实。自动化检查会验证新增变更（如新增的跨云调用或更大的有效载荷）是否仍然处于定义的成本范围内。这种自动化机制可以防止低效的模式进入生产环境。

在运行时，系统会持续地监控实际成本。当支出偏离预期预算时，系统会直接向负责该服务的团队发送警报。这种警报机制可以确保成本问题能够像性能或可靠性事件一样得到快速处理。

jobs: cost-impact-analysis: steps: - name: Estimate cross-cloud egress impact run: python3 scripts/estimate_egress_cost.py - name: Require review if threshold exceeded run: | if [ "$EGRESS_DELTA" -gt "$THRESHOLD" ]; then echo "Cross-cloud egress impact requires architecture review" exit 1 fi

复制代码

这类检查不应该拦截每一次部署操作。其目的是发现重大变更，例如新增的跨云依赖关系、更大的有效载荷或新的实时同步机制。

优化循环利用这些运行时数据来识别低效之处，并实施有针对性的改进，例如减少数据传输、压缩有效载荷或调整同步频率。这些优化所获得的洞察将用于事后复盘，团队可以借此完善成本模型并优化未来的设计。

所有阶段的基础都是 FOCUS 1.4 标准化层。它对各云服务提供商的成本数据进行了标准化处理。这种标准化确保了服务层面的成本可见性可以保持一致，从而能够跟踪、比较和管理整个生命周期中的成本。

总而言之，该图示展示了一个闭环系统：将成本的规划、执行、监控和持续优化直接集成到工程工作流中，而非被视为一项独立的财务活动。

虽然 FOCUS 能解决计费标准化的问题，但其本身并不能提供基于因果关系的服务级归因。企业折扣、云市场服务费、NAT 和跨区域费用，以及共享平台分配，仍然可能需要针对特定的提供商进行映射匹配。此外，账单导出数据具有回溯性，它们仅显示实际收取的费用，而无法指出是哪次运行时请求、重试或扇出操作产生了该流量。实际上，标准化之后的成本数据必须与所有权标签、分布式追踪以及网络流量日志进行关联。因此，FOCUS 是一个标准化的基础，并不能替代可观测性或内部费用分摊逻辑。

最终形成一个闭环模型：在设计阶段估算成本，在交付过程中进行核查，在生产环境中进行观测，并将结果反馈到架构决策中。由此，成本成为工程生命周期的一部分，而非独立的财务活动。

利用 AWS、Azure 和 GCP 提供的兼容 FOCUS 的输出，将所有服务提供商的账单导出数据整合到一个数据仓库中。在所有环境中统一资源标记规范，以便将成本分摊给相应的负责团队和服务。构建一个仪表盘，用于回答一个核心问题：上个月每对跨云服务产生了多少出站流量？如果没有这个基准，后续的每项决策都将基于估算而非事实依据。

利用第一阶段的归因数据，识别主要的出站流量成本驱动因素。优先实施回报最高的干预措施：在产生最高支出的路径上实施压缩、批处理调度和 CDN 路由。这些变更不需要迁移服务，却通常可以在目标路径上减少 30% 至 60% 的出站流量。更新部署策略，阻止未经审核的新增跨云集成进入生产环境。目标是在两到四个月内实现可量化的成本削减，从而增强组织信心，为第三阶段提供资金支持。

在实现短期成果并建立归因数据后，应着手解决结构性成本驱动因素。换言之，你应当将高频调用服务整合在同一云服务商的共享边界内，重新设计数据管道以在源头进行处理而非传输原始数据，并将成本审查纳入架构决策记录中。到本阶段结束时，成本治理应该已经成为常规流程：在设计阶段进行审查，在部署阶段落实，并在运行阶段归因于服务所有者。

这三个阶段遵循 FinOps 成熟度序列：首先是度量，其次是优化，最后是制度化。每个阶段都为下一阶段提供支持。

虽然每月总出站流量有参考价值，但其下降可能仅仅是因为需求减少了。以下指标更具有诊断意义，因为它们将账单与系统行为联系了起来。

多云成本控制是一门工程学科，而非计费问题。所花费的每一美元的出站流量，都会反映出设计阶段所做的部署决策、同步频率或数据迁移模式，并产生运行时账单。

改进之路宜循序渐进：首先建立归因机制，其次进行优化，最后调整架构。那些在缺乏可视化的情况下直接跳过归因环节进行优化的团队，往往会在错误的路径上削减成本。而那些首先建立起可视化的团队，则能生成有力的证据，为更具挑战性的架构变更提供合理的依据。

从 FOCUS 计费查询入手，对前五大跨云出站路径进行排序。询问每条路径是否以正确的形式、正确的频率、跨越正确的边界进行数据传输。这个问题的答案比任何费率谈判都更有价值。

原文链接：https://www.infoq.com/articles/multi-cloud-finops-cost-optimization/