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

简介 多云架构为团队提供了灵活性，使其能够针对可用性、供应商能力及地理覆盖范围进行优化。但这种灵活性也因数据在云服务提供商之间的迁移增加了隐性成本。通过服务部署决策、通信模式和扩展行为，这些成本会不断累积，并随着时间的推移呈复利增长。等到账单上显示出来时，架构层面的问题早已形成。 大多数组织采取的都是被动应对措施，例如审查账单、协商费率以及生产环境上线后进行调优，但这些措施都没有从根本上解决问题。在多云系统中，成本效率应该在设计阶段就确定下来。 本文将后端 FinOps 应用于多云架构。内容涵盖通过 FOCUS " 实现成本可视化、减少跨云数据传输策略，以及工作负载部署、同步模型和集成到 CI/CD 流程中的成本治理等工程实践。其目标是让成本控制成为系统的结构性特性，而非事后才考虑的因素。要设计出架构本身就能有效控制成本的系统。 生产观测 在维护一个零售订单和支付平台的生产环境时，我注意到，单个结账请求可能会涉及促销评估、支付授权、订单持久化以及履约服务等多个环节。分布式追踪数据显示，下游的瞬时故障可能会通过重试和反复检索订单上下文，将一个逻辑操作转化为多次网络调用。这一问题促使我们将真正的面向客户关键路径的交互，与无需阻塞订单确认的下游处理区分开来。所带来的实际效益在于降低了故障耦合度，并使结账延迟更加可以预测：非关键的下游消费者不会再拖慢客户响应速度。我特意省略了专有交易量和提供商拓扑信息。本文后面的受控实验将这一生产模式推广到了多云环境，并量化了其成本影响。 跨云数据传输的隐性成本结构 广告宣传的出站费率只是起点，不是全部。表 1 展示了截至 2026 年 1 月，经与官方提供商商定价核对后确认的分层成本结构。 表 1. 按提供商划分的实际出站流量成本结构（2026 年 1 月），数据来源： AWS "、 Azure " 和 GCP "（*通过 NAT 网关传输的私有子网流量） 公布的出站费率仅反映了数据传输的基础成本。实际上，诸如 NAT 网关处理 "、跨区域及 中转流量 "等其他费用会显著推高每千兆字节的实际成本。例如，在 AWS 中，通过 NAT 网关路由流量会导致实际出站成本比广告宣传的费率高出 50% 以上。所有主要提供商都存在类似的成本层，尤其是针对跨可用区和跨区域的流量。 行业研究 "表明，许多组织都低估了这些成本。问题的核心在于结构性因素。数据传输成本由架构和数据流动模式所决定，但这些成本通常只有在部署完成后，通过账单报告才能发现。 多云微服务中的四个架构问题 “ 后端 FinOps：在云端构建高性价比的微服务 "”一文阐述了如何在单个云边界内优化微服务，多云环境还需要进一步关注。如下文所述，有四种模式占了可避免的出站流量开支的绝大部分。 问题 1：跨云同步通信 在许多多云系统中，单个用户请求会经过由不同云提供商托管的服务。虽然这种方法提高了灵活性，但也产生了隐性的网络传输成本。云之间的每次同步请求都会产生出站流量和网关费用，而且这些费用会随着流量的增加而上升。 下面的基准测试基于已公布的 2026 年第一季度的定价，模拟了一个典型的企业部署场景。产品目录服务运行在 AWS 的EKS上，推荐引擎运行在 Google Cloud 上，欺诈检测服务运行在微软 Azure 上。客户交易过程会同步调用每项服务。 主要发现 每增加一次跨云服务跳转都会推高运营成本。对于相同的工作负载，单云部署可以完全避免跨服务商的传输成本。这些成本取决于架构设计决策，而非运行时配置。 AWS Well-Architected Framework " 和 Google Cloud Multi-Cloud Guidance " 均指出，跨云数据传输是多云环境中一项显著的成本驱动因素。 from enum import Enum class 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"} # Usage gateway = CrossCloudGateway(realtime_client, batch_queue) gateway.dispatch(payment_request, TrafficClass.INTERACTIVE) gateway.dispatch(analytics_event, TrafficClass.BACKGROUND) 这个简化的网关示例清晰地展示了流量分类。支付授权属于交互式操作，因为客户需要立即得到响应，所以该请求以同步方式发送。分析事件属于后台操作，因为客户无需等待，所以可以将其放入队列，随后进行批处理、压缩，或在更接近数据源的位置进行处理。关键的设计决策并非网关实现本身，而是要在工作负载跨越服务提供商边界之前对其进行分类，从而确保交互式流量和后台流量不会自动共享相同的延迟、可用性和成本特性。 例如，如果 AWS 中的结账服务在订单完成之前调用 Azure 中的欺诈检测服务，那么现在结账的延迟和可用性就取决于这两个服务提供商以及它们之间的网络。 重试、超时以及下游的扇出效应会进一步增加跨云调用次数和传输字节数。因此，设计的关键问题在于：调用方是否真的需要即时响应？如果确实需要，那么团队应采用严格的超时设置、备用方案、小数据包以及受控的重试机制；如果不需要，则可以将这种依赖关系替换为异步消息传递。 问题 2：在不需要实时的情况下进行不必要的实时数据传输 大多数工程团队会持续地在云服务提供商之间传输数据，因为从运营的角度来看，实时处理似乎是正确的。但在实际操作中，很少会根据实际的使用模式对这一假设进行验证。分析管道、机器学习重新训练工作流以及合规系统主要以小时或天为周期运行，而且每次数据传输都会产生按 GB 计费的出站费用。其结果就是，企业最终为数据传输支付的费用是基于数据的生成速度，而非实际的使用情况。 在这种情况下，问题并不在于应用程序之间的同步耦合。客户不需要等待分析系统。问题在于数据传输频率快于业务对数据时效性的要求。通过定义一个可接受的数据时效阈值（例如五分钟、一小