Windows Azure 的成本架构

TechNet 杂志文章 http://technet.microsoft.com/zh-cn/magazine/gg213848.aspx

Windows Azure 这类云计算和平台被宣为 IT 行业中的“下一个大题材”。想到云计算集万千优势于一身，这么说似乎确实不为过。

您可以随时按需使用计算和存储，而且只需为有效使用付费。不过，这也带来一个问题。如果像设计普通应用程序那样设计一个云应用程序，该应用程序的成本很可能将不容乐观。

不同的度量标准

在传统 IT 行业中，IT 人员将购买一套硬件（网络基础结构、服务器等），对其进行设置、执行配置过程并连接到 Internet。这是一次性投资，由员工来控制“旋钮”和“螺栓” — 就是这样。

而对于云计算，成本模型将替代该投资模型。根据服务器功能和存储的有效使用支付这类资源的费用。对于 Windows Azure 这类云平台，您可以使用下列度量值计算月度费用：

• 保留虚拟机 (VM) 的小时数 — 表示为已部署的应用程序付费，即使该应用程序当前没有运行
• VM 中 CPU 的数量
• 带宽（以每次传入/传出 GB 为单位）
• 使用的存储量（以 GB 为单位）
• 存储中的事务数
• SQL Azure 中的数据库大小
• Windows Azure 平台 AppFabric 中的连接数

您可以在 Windows Azure 网站 microsoft.com/windowsazure/offers 上找到所有定价详细信息。从以上列表中可以看出，要考虑许多因素。

限制虚拟机

下面从实用角度进行分析。限制正在运行的 VM 的数量是一种很好的节约成本的方式，但是对于 Web 角色，最好具有至少两个可用的 VM 来实现负载平衡。使用 Windows Azure 诊断 API 测量这些实例中的 CPU 使用率、HTTP 请求量和内存使用率并在适当时缩小应用程序的大小。

每月在 Windows Azure 上运行的任意角色的每一个实例都会使帐单上的小时数增加一倍。例如，在几乎没有任何工作负荷的情况下，平均运行 3 个角色实例（有时 2 个，有时 4 个）将比始终运行 4 个实例便宜 25%。

对于工作者角色，也最好具有至少两个角色实例来执行后台处理。这样有助于确保当其中一个角色实例出现故障，需要更新或重新启动角色时，应用程序仍然可用。您可以使用 Windows Azure 提供的工具将某个工作者角色直接配置为仅供执行某一个任务专用。

例如，如果您正在运行照片共享网站，您需要使用一个工作者角色来调整图像大小，使用另一个角色来发送电子邮件通知。遵循“至少 2 个实例”规则将意味着运行 4 个工作者角色实例，这将产生相当大的一笔费用。调整图像大小和发送电子邮件实际上不占用 CPU，因此，仅两个工作者角色就应足以完成这两个任务。对运行 Windows Azure 来说，这将节省 50% 的月度费用。在工作者角色中实现线程机制以使各个线程执行其专门负责的工作也相当容易。

Windows Azure 提供了下列四种大小的 VM：小型、中型、大型和特大型。各个大小之间的区别在于可用的 CPU 数量、可用的内存和本地存储量以及 I/O 性能。在为 Windows Azure 实际部署 VM 之前，最好想清楚适当的 VM 大小是多少。一旦应用程序开始运行，就无法更改大小。

当您收到月度清单时，您将注意到所有计算小时在帐单上都被转换为小型实例小时。例如，一个中型计算实例的 1 小时将按照小型实例比率显示为两个小型计算实例小时。如果您正在运行两个中型实例，将按 720 x 2 x 2 个小时付费。

请在调整 VM 的大小时考虑此因素。您可以使用小型实例实现几乎相同的计算能力。假设您有四个小型实例，则按 720 x 4 个小时付费。价钱是一样的。您可以在适当时缩减到两个实例，即按 720 x 2 个小时付费。如果您不需要更多 CPU、更多内存或更多存储，请坚持使用小型实例，因为相对于大型实例来说，小型实例的调整级别更为精细。

Windows Azure 服务从您部署应用程序开始计费，无论角色实例处于活动状态，还是已关闭。Windows Azure 门户中有很清楚的说明。该门户上有一个大型图像框。“当该框显示为灰色时，大可放心。当该框显示为蓝色时，开始计费。”（感谢 Brian H. Prince 的这句俏皮话。）

在您将应用程序部署到暂存或运行环境并在使用后将其关闭时，请不要忘了还要取消部署应用程序。您不希望为任何不活动的应用程序付费。另外还要记住在适当时缩减应用程序。这将直接影响月度运营成本。

增加和缩减应用程序时，最好使一个角色实例至少运行一个小时，因为您是按小时付费的。在工作者角色中创建多个工作者线程。这样，工作者角色就可以执行多个任务，而不是仅仅执行一个任务。如果您不需要更多 CPU、更多内存或更多存储，请坚持使用小型实例。再次重申，当您不使用应用程序时，请确保取消部署。

带宽、存储和事务

带宽和事务是两个比较复杂的度量标准。除了查看月度费用以外，目前没有什么很好的方法来测量这些数据。没有您可以查阅和用来调整应用程序的实时监视。带宽在这两个度量标准中比较容易测量。使用的网络流量越少，成本越低。就是这么简单。

在多个 Windows Azure 区域内部署应用程序时，事情会复杂一些。假设您在“北美”区域内运行 Web 角色，在“西欧”区域内运行存储帐户。在这种情况下，用于 Web 角色和存储之间的通信的带宽将计费。

如果 Web 角色和存储都位于同一区域（例如，都位于“北美”区域），则 Web 角色和存储之间的通信将不产生带宽费用。请记住，设计异地分布式应用程序时，最好使搭配使用的服务位于同一 Windows Azure 区域内。

使用 Windows Azure 内容传送网络 (CDN) 时，您可以利用另一项有趣的降低成本的措施。CDN 的计量方式与 Blob 存储相同，即按每月每 GB 存储量计费。向 CDN 发出请求后，它将从 Blob 存储中获取原始内容（包括已计费的带宽消耗）并对其进行本地缓存。

如果将缓存过期时间 header 报文设置得太短，它将消耗更多带宽，因为 CDN 缓存将更频繁地进行自我更新。如果将缓存过期时间设置得太长，Windows Azure 会延长内容在 CDN 中存储的时间并按每月每 GB 存储量计费。针对每个应用程序考虑此因素，以便确定最佳缓存过期时间。

Windows Azure 诊断监视器还将 Blob 存储用于诊断数据，如性能计数器、跟踪日志、事件日志等。它按照预先指定的时间间隔将此数据写入您的应用程序。每分钟写入将增加存储中的事务计数，从而导致额外成本。将写入的时间间隔设置为 15 分钟就会使存储事务减少。不过，这样做有一个缺点，即诊断数据将始终是至少 15 分钟以前的数据。

此外，Windows Azure 诊断监视器不会清除其数据。如果您不亲自清除数据，就可能要为许多只包含旧的、已过期的诊断数据的存储付费。

按 10.000/事务计费。这个数字可能看起来很高，但实际上您得为事务付费。存储帐户中的每项操作都是一个事务。创建一个 Blob 容器、列出 Blob 容器的内容、将数据存储在表存储上的表中、浏览队列中的消息 — 所有这些都是事务。例如，当执行 Blob 存储这类操作时，您将首先检查 Blob 容器是否存在。如果不存在，则必须创建一个，然后存储一个 Blob。这至少是两个（可能 3 个）事务。

此计数方式同样适用于在 Blob 存储中承载静态内容。如果您的网站在一页上承载了 40 个小图像，就相当于 40 个事务。这可在高流量应用程序的带动下快速增加。只需确保在应用程序启动时存在 Blob 容器并跳过检查每个后续操作，您就可以将事务数量减少几乎 50%。通过这样的巧妙处理，可以减少费用。

索引可能很昂贵

SQL Azure 是一种很有趣的产品。您能以极低的月价购买 1GB、5GB、10GB、20GB、30GB、40GB 或 50GB 的数据库。您完全可以直接购买 5GB 的 SQL Azure 数据库，这非常安全。即便您仅使用其中 2GB 的容量也不打紧，因为您实际用的并不是按使用情况付费模型，对不对？

在某些情况下，将您的数据分发给不同的 SQL Azure 数据库比使用一个大型数据库可能更经济高效。例如，您可以使用一个 5GB 和一个 10GB 的数据库，而不是使用一个包含 5GB 的未使用容量的 20GB 的数据库。如果您巧妙地处理此类型的策略存储并且此存储方式适用于您的数据类型，对您减少所付的费用将极有好处。

每个对象都占用存储空间。索引和表可能会占用大量数据库存储容量。大型表可能占用数据库的 10%，某些索引可能占用数据库的 0.5%。

如果您按数据库大小划分 SQL Azure 订阅的月度成本，将得出一个按存储情况计算成本的单位。考虑一下您数据库中的对象。如果索引 X 每月的成本为 50 分且实际上并没有使性能显著提高，那么只需将其丢弃。虽然半美元并不多，但是如果您消除一些表和一些索引，这许多个半美元加起来就是一笔可观的数目。可在 SQL Azure 团队博客文章“索引的实际成本”(blogs.msdn.com/b/sqlazure/archive/2010/08/19/10051969.aspx) 中找到与此相关的一个有趣示例。

应用程序开发方面有一项巨大转变，即不再在数据库中使用存储过程，而是在应用程序逻辑中对数据使用对象关系映射程序并执行大量计算。

这种做法本身并无任何问题，但考虑到 Windows Azure 和 SQL Azure 时，就有意思了。在应用程序中执行数据计算可能需要其他 Web 角色或工作者角色实例。如果改成在 SQL Azure 中进行这些计算，则在这种情况下您将节省一个角色实例。因为 SQL Azure 是按存储情况（而不是 CPU 使用率）计费的，所以您实际上可在数据库中获得免费 CPU 周期。

开发人员影响

编写代码的开发人员对成本有直接影响。例如，构建以 Windows Azure 为宿主的 ASP .NET 网站时，您可以使用 Windows Azure 备份存储会话状态提供程序在不同的角色实例间进行分发。此提供程序将会话数据存储在 Windows Azure 表服务中。将度量该表服务中使用的存储量、使用的带宽量和事务计数以进行计费。请看以下用于确定每个请求中的用户语言的代码段：

复制代码

if (Session["culture"].ToString() == "en-US") {

  // .. set to English ...

}

if (Session["culture"].ToString() == "nl-BE") {

  // .. set to Dutch ...

}

没有任何问题？技术上是没有问题，但您可以从成本角度对它进行优化以使成本降低 50%：

复制代码

string culture = Session["culture"].ToString();

if (culture == "en-US") {

  // .. set to English ...

}

if (culture == "nl-BE") {

  // .. set to Dutch ...

}

这两个代码段的功能完全一样。第一个代码段读取了两次会话数据，而后者仅读取了一次。这就意味着后者将在带宽和事务计数方面节约 50% 的成本。对队列来说同样如此。每次读取一条消息，读取 20 次，将比一次读取 20 条消息昂贵得多。

可以看出，云计算为承载应用程序带来了不同的经济和定价细节。与传统数据中心相比，云计算可以算是运营成本方面的一项重大改进，但是在设计云时，您必须注意应用程序体系结构中的一些注意事项。

Maarten Balliauw 是 RealDolmen（比利时最大的一家 ICT 公司）的 Web 技术领域的技术顾问。他主要研究 ASP.NET MVC、PHP 和 Windows Azure。他是 Microsoft 最有价值的 ASP .NET 专家，已在 PHP 和 .NET 文献中发表了许多文章，例如《MSDN 杂志》、《Belgium》和《PHP Architect》。Balliauw 经常在各种国家/地区和国际活动中发表演讲。请访问 blog.maartenballiauw.be 查看他的博客。