弥补缺口：最新的 Windows Azure 发布包增加数据库和负载均衡

作为市场领导者的 AWS 在这个特定领域跨越式发展的同时，Microsoft 副总裁 Scott Guthrie 也宣布了他们对 Windows Azure 做的一系列更新，填补了其平台的空白。新的数据库导出服务提供了一个非常必须的备份功能（虽然定价存在争议），同时更新后的流量管理器提供了跨平台的负载均衡体验，该功能好像要优于 AWS 所提供的服务。

Guthrie 在他的一篇博客中介绍了为 Windows Azure SQL Database 提供的新计划备份功能。

我们经常会听到的一个常见的、用户要求添加的功能就是为客户提供执行循环、全自动化、将一个 SQL 数据库导出到存储帐号的能力。从今天开始，这些都将是 Windows Azure 的内置功能。现在你能够按照某个周期（你能够任意定义）自动地将 SQL 数据库的事务一致性副本导出到某个存储帐号中的一个.bacpac 文件中。

这个新的导出服务的执行频率能够被计划为一天执行一次，同时用户也可以指定间隔多少天执行一次。另外，新数据库能够基于任意一个导出的备份创建。

Windows Azure SQL Database 是托管的数据库，它具有能够扩展和维护 SQL Server 数据库的设置。但是，该服务现在还缺少先进的管理能力，例如自动地备份和恢复功能。虽然能够通过人工的方式复制数据库，也有容错规划的参考资料，但是借助于这个新功能 Windows Azure 的客户在定义容灾计划的时候将更加轻松。无论如何，设计的这个解决方案也有一些代价。Guthrie 解释了它的架构和它对用户账单的影响。

在执行自动导出的时候，Windows Azure 首先会在创建.bacpac 文件之前，将你的数据库完全复制到一个临时数据库。这是唯一能够确保导出是事务一致的方式（在导出完成之后这个备份会被自动删除）。当然，在你运行导出的那一天你需要为这个数据库备份付费。因为数据库是按天收费的，所以如果你每天都会导出，那么理论上数据库成本会加倍。而如果你每周执行一次导出那么成本要低得多。

除了需要为备份过程中的这个临时数据库付费之外，客户还需要为备份所消耗的存储空间和网络带宽付费（如果数据库存在于一个和 Windows Azure 存储账户不同的区域）。评论者们在 Guthrie 的博客上表达了他们对这个功能收费如此之高的不满，认为这“非常令人失望”、“完全不切实际”。该服务的定价模型不同于 Amazon 相关数据库服务 (RDS) 所提供的模型。

Amazon RDS——也是一个托管的数据库平台——提供了更多的备份和恢复功能但价格更低。一个 RDS 数据库默认会启用备份，同时支持时间点恢复。AWS 并不针对备份服务本身收费，如果备份大小小于预分配的数据库大小也不会对存储空间收费。

Microsoft 还透露了一个新的 Windows Azure SQL Database“保险”层，它使用预留的能力为云应用提供可预见的性能。Guthrie 指出了客户会购买该层的三个关键原因：

• 高峰负载 ——完成自己的操作需要占用大量 CPU、内存或者 IO 的应用。例如，如果一个数据库操作需要占用几个 CPU 内核很长一段时间，那么它就可能需要使用一个保险数据库。
• 大量并发请求 ——有些数据库应用服务于很多并发请求。常见的 Web 和企业版本的 SQL 数据库有 180 个并发请求数量的限制。需要更多连接的应用应该使用一个具有合适预留大小的保险数据库去处理最大数量的请求。
• 可预见的延迟时间——有些应用需要保证在最短的时间内从数据库获得响应。如果一个给定的存储过程作为一个大客户操作的一部分被调用，那么可能会要求在 99% 的时间内该调用需要在 20 毫秒之内返回。这种类型的应用可能会从一个保险数据库中受益，它能确保可以使用专用的计算能力。

该服务现在能够在预览模式下使用，并且价格也有折扣，它提供了两种数据库预留大小。P1 大小提供了1 个CPU 核心、150IOPS、8GB 内存和高达2000 的活动会话。更大的P2 大小提供了2 个CPU 核心、300IOPS、16GB 内存和高达4000 的活动会话。Microsoft 还为用户提供了帮助他们选择和管理保险数据库的白皮书。比较而言，Amazon RDS 中的一个需要保证性能的SQL Server 数据库能够有高达10000 的预留IOPS 。

Microsoft 正在建立自己强势地位的一个区域在于为地理分布式、高可用的 Web 应用提供支持。 Windows Azure 流量管理器——虽然它的存在已经接近两年了，但是最近才可以在 Windows Azure 门户中使用——提供了一个比 AWS 弹性负载均衡（ELB）具有更多功能的复杂负载均衡器。和 ELB 不同的是，ELB 仅支持单个区域中的轮循负载均衡，而 Windows Azure 流量管理器可以让用户把流量导向到任意 Windows Azure 区域中的云服务。对一个给定的流量管理器概要而言，Microsoft 还支持三个唯一的路由方法：Performance（性能），Failover（故障恢复）和 Round Robin（轮循）。 Performance 方法会将流量路由到托管应用的最近的地理位置。 Failover 方法会将流量路由到一个单独的数据中心，同时会使用另一个作为备份；而 Round Robin 方法则会在所有收录的云服务之间均匀地分配负载。公平地说，AWS 通过 ELB 和 Amazon 路由 53 （DNS）服务的结合提供了这些能力的并集，但是 Microsoft 对它做了简化，并且为开发者提供了一个单独的、容易访问的位置去配置云服务和将流量路由到它们的策略。

最后，Microsoft 对它最近发布的自动扩展服务做了一些提升。首先，Windows Azure 现在的移动后端即服务（MBaaS）特性支持自动扩展。Guthrie 解释了如何根据需要自动扩展移动服务，并在每天早晨重置它。

如果启用了该特性，Windows Azure 将会定期地检查每天对移动服务和来自于移动服务的 API 调用数量，如果超过了 API 限额的 90% 那么便会通过一个额外的单元按比例扩展（直到达到你希望启用的实例的最大数量）。

在每天（UTC）开始的时候，Windows Azure 则会将它缩减到配置的最小数。这让你能够最小化运行移动服务实例的数量，从而节约成本。

Windows Azure 自动扩展服务还支持与 Windows Azure 服务总线队列深度结合的规则。如果一个队列太满了——可能意味着线上没有足够的后端服务能够处理积压的消息——自动扩展功能就会增加新的虚拟机或者云服务处理工作负载。

查看英文原文： Closing the Gap: Latest Windows Azure Release Beefs Up Database, Load Balancing