使用多云有好处，但也可能会产生昂贵的成本。要管理好成本，请检查你的供应商数据访问费用，以及你的应用设计。

几乎每个企业以及大部分的中等规模企业都会将他们的一些应用部署到公有云上。规模较大，尤其是那些运营地域很广的公司，很可能会使用多个公有云服务，而这在某些情况下，会导致产生令人瞠目的费用。对于任何有多云预期的用户来说，了解成本如何失控，以及怎样做才能挽救预算至关重要。

控制多云的成本需要了解你的云服务供应商的收费。云服务提供商的收费一般分为四大类：CPU资源、存储、访问和特殊Web服务。如果供应商的云定价模型都类似，那么将应用分割到多个云提供商将不会影响整体成本。遗憾的是，事实不大可能是这样。大多数多云成本的挑战来自两个因素：存储成本和访问费用。当创建一个跨多个云的应用的云成本管理计划时，可以从检查这两个方面着手。

多云成本是如何累积的？

多云定价模型的最大挑战是访问费用，或者你的云应用信息转移所产生的流量费用。将一个应用或组件从你的主云平台迁移到另一个云时往往意味着云和云之间的工作流。一个简单的事务可能会从用户到云A，从云A到云B，从云B回到云A，然后再返回给用户。这样一种工作流可能会增加一倍的访问费用，而这在单一的云提供商下却不会发生。

在多云部署中，存储的费用也可能突涨，并增加访问的费用。如果同样的应用跑在两个不同的云上，或者分散到两个云上运行，并且所有的组件都需要访问数据时，你会面临一个艰难的选择。如果你在你的数据中心或仅在一个云里托管数据库，你就必须支付访问费用才能获取数据。然而，在不同的云之间访问数据库可能涉及大量的数据移动以及大量的成本。另一种方法是在你使用的所有云平台里都托管一份数据库副本，但那又引入了额外的数据存储成本和同步的问题。

特殊Web服务也会造成类似的问题，因为他们的一些成本是基于对功能的访问，这在与多个云定价模型打交道时会变得困难。例如，如果你的一个应用需要用到某个特殊的服务，而你将该应用进行分布式部署，这样该功能会在多个云中需要，你得在所有这些地方都支付使用该功能的费用。而且，由于使用费用通常是较高的使用率则收费较低，你也失去了规模经济的优势。

如果你将应用发布到多个云，CPU的费用甚至都有可能变高。其中一个原因，又是规模经济的问题；更高的使用率通常意味着更低的每分钟费用。另一个原因是，许多企业购买了专用实例，而当他们在多个云之间分配应用时通常没有充分利用这些实例。

设计云成本管理计划

如果你打算从云到云动态迁移应用，那么成本将很难控制，甚至难以预估。但你可以采取一些措施来控制成本。

云成本管理从工作流和数据路径的映射开始。每个应用的每个组件都有输入，输出以及对数据库访问和特殊功能的显性需要。这会有些琐碎，并且最后的图表分析起来可能很复杂，但是多云成本管理的一个好的开始方法就是绘制出你计划在云中托管的那些应用之间的关系。这会有助你找出多云部署时的边界，哪里会产生费用或需要复制托管数据和功能。

该映射关系往往显示了多云部署一个重要事实，那就是开发人员通常会将应用构建在不同的层上。最上层是应用的前端，负责设备支持和GUI创建。该层将工作传到一个中间层，加上基本的数据编辑，然后转交给传统的事务处理组件。了解应用程序的结构可以帮助你在多云部署中节省成本。

前端的应用程序组件跨多云分布相对容易些，因为它们很少用到数据库的功能，基于性能的设计实例化成多个副本，通常会将工作移交给单个合作层。使用多云相比较单个云可能会在定价上影响你的规模经济，但你可能不会遇到在访问或存储成本上的大幅增加问题。

有些应用会将基础数据库同中间层组件集成用于编辑和验证。在这一层不要忘记在多个云里复制数据的成本。在此中间层的处理越复杂，让一个应用及其组件跨云提供商就越困难。如果你想要评估其影响，可以在你计划在多云环境中使用的组件周围画一个圈，看看哪些工作流和数据路径被切断了。那些就是需要支付额外费用的地方。

由于应用的底层，实际交易和查询处理的部分，可能涉及到很多实时数据库的访问，尽量避免将这一层分散到多个云供应商。现在，以及在未来短时间内，大多数公司都会将这项关键任务的处理放在企业内部。

当建立一个运行在多个平台上的应用程成本管理计划时，不要忽视集成和生命周期管理相关的潜在问题。用户有很强的理由在多个公有云部署，但也有风险，包括成本和复杂性的增加。了解云定价模型，并尽早解决这些复杂性以获得成功的实践经历。