确保 Windows Azure 应用程序成功设计的十种方法

引言

Windows Azure SQL Database 是 Microsoft SQL Server 2012 的托管版本，由 Microsoft 在 Windows Azure 数据中心托管。SQL Database 是 Windows Azure 平台的核心功能。

SQL Database 是一个多租户系统，其中许多数据库实例托管在运行在物理服务器或节点上的单个 SQL Server 实例中。因此，它与纯 SQL Server 具有不同的性能特征。特别是，通过将数据水平扩展到多个实例或分片来实现高数据可伸缩性和高性能。为提供高可用性并满足严格的 SLA，每个 SQL Database 实例都存储为主副本和两个辅助副本。当节点发生故障时，其托管的主副本和辅助副本将在其他节点上重新创建。SQL Database 使用法定提交，只要主副本和两个辅助副本中的一个已完成提交，提交就会被视为成功。

本白皮书描述了在部署到 SQL Database 时出现的十大问题，并解释了如何缓解这些问题。

问题 #1：安全性

SQL Database 作为 Windows Azure 云中的一项服务提供，因此安全性必须与本地企业数据库采取不同的方法。在云中处理业务数据安全时，尤其需要关注：

• 安全连接的使用
• 网络访问管理
• 用户授权和身份验证

确保安全连接

为确保安全连接，仅支持在端口 1433 上使用安全加密的 TDS 协议进行连接。

请注意，如果您希望允许从本地数据库连接到 SQL Database，则本地网络不应阻止到该端口上的 SQL Database 的出站流量（例如，公司路由器 ACL 中不应有阻止到端口 1433 的出站流量的限制）。

网络访问管理

要管理网络访问，请使用处理网络访问控制的 SQL Database 服务防火墙。您可以配置防火墙规则来授予或拒绝对特定 IP 或 IP 范围的访问。防火墙规则可以在两个单独的级别创建：

• 服务器级别 – 您可以管理对整个 SQL Database 服务器及其所有关联实例的访问。
• 数据库实例级别 – 您可以精细调整每个独立数据库的访问连接粒度。这些规则可以为使用同一 SQL Database 服务器的多个应用程序提供良好的逻辑隔离。

如果您正在使用 SQL Database 联合（Federations）并且涉及数据库防火墙规则，请记住每个规则都必须单独配置在每个数据库上。

处理用户授权和身份验证

SQL Database 提供与 SQL Server 类似的安全管理功能来创建登录名和用户。数据库级别的安全管理与 SQL Server 几乎相同。但是，由于 SQL Database 由不同的物理机组成，因此服务器级别的管理有所不同。因此，SQL Database 在服务器级别管理中使用 master 数据库来管理用户和登录名。

要管理网络访问，请使用处理网络访问控制的 SQL Database 服务防火墙。您可以配置防火墙规则来授予或拒绝对特定 IP 或 IP 范围的访问。

问题 #2：维护高可用性

避免连接超时

SQL Database 开箱即用地提供高可用性（HA），它在数据中心的不同节点上维护三个副本，并在两个副本更新后将事务视为完成。此外，如果需要，故障检测机制将自动启动数据库副本之一：当检测到故障时，主副本将被次副本替换。但是，这可能会触发 SQL Database 管理中的短期配置修改，并导致数据库连接出现短暂的超时（最多 30 秒）。

为降低此连接超时的风险，最佳实践是实现应用程序重试策略，以便重新连接到数据库。为减少总重连时间，请考虑使用回退重连策略，该策略会增加每次连接尝试的时间。

将 SQL Database 实例备份到另一个数据中心

HA 也在数据中心范围内强制执行；地理位置之间没有数据冗余。这意味着任何重大的数据中心故障都可能导致数据永久丢失。

为保护您的数据，请务必将 SQL Database 实例备份到另一个数据中心的 Windows Azure 存储。为减少数据传输成本，您可以选择同一区域内的数据中心。

问题 #3：将 Entity Framework (EF) 与 SQL Database 结合使用

什么是 Entity Framework (EF)？

Entity Framework (EF) 是一个对象关系映射器，它使 .NET 开发人员能够使用领域特定的对象来处理关系数据。由于 EF 消除了开发人员通常需要编写的大部分数据访问代码，因此它经常在应用程序中与 SQL Server 一起使用。但是，在使用 EF 时，开发人员需要注意一些问题。

防止连接池中连接关闭导致的异常

首先，EF 使用 ADO.Net 来处理数据库连接。由于创建数据库连接可能耗时，因此会使用连接池，这可能会导致问题。具体来说，SQL Database 和云环境可能会因各种原因（例如网络问题或资源短缺）而关闭数据库连接。但是，即使连接已关闭，它仍然保留在连接池中，EF ObjectContext 会尝试从池中获取已关闭的连接，从而导致异常。

为缓解此问题，请对实体连接使用重试策略，这由 Transient Fault Handling Application Block 提供，以便可以多次尝试来完成命令。

急切加载可防止性能问题

其次，在 Windows Azure 中，性能下降可能很显著，因为许多开发人员不了解 EF 中的查询是如何执行的。EF 提供两个选项：延迟加载和急切加载。

延迟加载允许查询仅在实际需要时获取数据。虽然这种方法听起来通常是最佳的，但如果数据分布在不同的表中，它实际上很可能导致延迟问题，因为遍历每个对象需要多次往返。

通过使用急切加载可以消除此问题，急切加载允许在单个查询中将不同表中的信息（通过外键连接）连接起来。要使用急切加载，请在 LINQ 查询中使用 Include 关键字。

避免使用涉及分布式事务的 EF LINQ 查询

最后，SQL Database 目前不支持分布式事务。分布式事务包括一个或多个语句，这些语句单独或组合更新分布式数据库上两个或多个不同节点的数据。（这与在单个数据库上执行的本地事务不同。）

因此，请避免使用涉及分布式事务的 EF LINQ 查询，否则将遇到异常。而是使用显式 SqlTransaction 连接等替代方法。

在 Windows Azure 中，性能下降可能很显著，因为许多开发人员不了解 EF 中的查询是如何执行的。通过使用急切加载可以消除此问题，急切加载允许在单个查询中将不同表中的信息连接起来。

问题 #4：处理连接失败

了解 SQL Database 连接失败的类型

SQL Database 是一个分布式系统，应用程序通过 Windows Azure 数据中心中的网络进行访问。此网络上的连接可能会发生故障，从而导致连接被终止。

具体来说，当数据节点或其托管的 SQL Server 实例发生故障时，SQL Database 会将活动从该节点或实例移出。其托管的每个主副本都会被降级，关联的次副本会被提升。作为此过程的一部分，与已降级的主服务器的连接会被终止。但是，可能需要几秒钟时间，新主副本的信息才能在 SQL Database 中传播，因此应用程序必须适当地处理这种瞬时故障至关重要。

此外，SQL Database 是一个多租户系统，其中每个数据节点托管许多实例。与这些实例的连接会争夺数据节点提供的资源。在高负载时，SQL Database 可能会限制消耗大量资源的连接。这种限制是应用程序需要适当地处理的另一种瞬时故障。

（应用程序也可能遇到持续时间过长而无法视为瞬时的 SQL Database 连接问题（例如 SQL Database 停机），但这些问题需要与此处描述的不同处理方式。）

设计应用程序以处理连接失败

处理连接失败的第一步是确定失败是否为瞬时故障。如果是，应用程序应等待片刻以使瞬时问题得到解决，然后重试操作，直到成功为止。

处理瞬时连接失败的细节可能很复杂。Windows Azure 客户咨询团队的 Valery Mizonov 开发了一种瞬时故障处理机制，Microsoft 模式与实践团队现已将其作为 Enterprise Library 中的 Transient Fault Handling Application Block 发布。Transient Fault Handling Application Block 支持各种生成重试延迟时间间隔的标准方法，包括固定间隔、递增间隔（间隔按标准量增加）和指数回退（间隔会加倍并随机变化）。

处理连接失败的第一步是确定失败是否为瞬时故障。如果是，应用程序应等待片刻以使瞬时问题得到解决，然后重试操作，直到成功为止。

问题 #5：节流

何时会节流应用程序？

SQL Database 的多租户性质意味着数据节点上的物理资源由许多应用程序共享。Microsoft 目前不提供任何方法来预留保证级别的资源可用性。相反，SQL Database 会限制消耗过多资源的实例的连接。

SQL Database 以 10 秒为间隔来考虑资源使用情况，称为节流睡眠间隔。在这些间隔内过度使用资源的实例可能会被节流一个或多个节流睡眠间隔，直到总体资源使用达到可接受的水平。根据资源使用限制被超出有多严重，分为软节流和硬节流两种。节流的影响从应用程序无法执行任何插入到应用程序无法执行任何读取和写入不等。

诊断节流问题

受到节流影响的应用程序会遇到瞬时连接失败。与失败相关的错误号指示了节流的具体原因。可以记录此信息，并在必要时修改应用程序以降低节流的风险。

问题 #6：频繁通信的应用程序

SQL Database 的延迟高于 SQL Server

SQL Database 是一个分布式系统，应用程序（最好）在 Windows Azure 数据中心内部连接，（最坏）通过互联网连接。此外，使用商品硬件意味着 SQL Database 的性能特征不如高端服务器。结果是，在 SQL Database 应用程序中完成单个数据库操作的延迟可能高于在 SQL Server 应用程序中。

减少应用程序的频繁通信

在将应用程序从 SQL Server 迁移到 SQL Database 时，应考虑到这种增加的延迟。应注意应用程序不应过于频繁地通信，例如，进行许多不必要的数据库调用。这可能需要对应用程序进行重新架构，以修改数据库操作的数量和性质。

一种技术是缓存数据，这样就不必为频繁使用的数据查询 SQL Database 实例。Windows Azure 缓存（预览版）支持在专用角色中创建缓存，或通过共享现有角色的可用内存来创建缓存。在缓存旁边的模式中，数据检索操作仅在缓存中找不到相关数据时才访问 SQL Database 实例，并且每当从 SQL Database 检索到数据时，都会将其添加到缓存中。此模式减少了应用程序数据层的频繁通信，从而提高了应用程序性能。

另一种技术是将多个操作合并为一个数据库调用。例如，可以使用表值参数将单个数据库调用参数化，以便它可以将多行插入表中，而不是每行使用一次数据库调用。这可以显著减少到 SQL Database 的网络流量量，从而有助于降低应用程序延迟。

问题 #7：监控限制

SQL Database 的监控选项比 SQL Server 少

SQL Server 中可用的各种监控方法，例如审计登录、运行跟踪和性能计数器，在 SQL Database 中不受支持。然而，一种监控选项，即动态管理视图（DMV），是受支持的，尽管不如 SQL Server 中那样广泛。

SQL Database 仅支持动态管理视图 (DMV) 的一个子集

要了解 SQL Database 中支持哪些 DMV，请使用以下查询

"select * from sys.all_views where name
like ‘%dm%’.

SQL Database 中的 DMV 大致可分为三类：

• 数据库相关（以 sys.dm_db 开头）
• 执行相关（以 sys.dm_exec 开头）
• 事务相关（以 sys.dm_tran 开头）

总的来说，SQL Database 以逻辑级别公开监控信息，隐藏物理部分。

例如，在数据库相关的 DMV 中，注意缺少 sys. dm_db_file_space_usage DMV，该 DMV 可用于监控每个数据库文件的确切磁盘使用情况。（请注意，您可以使用 sys.dm_db_partition_state 来估算数据库中的数据量。）同样，tempdb 页分配 DMV 也不可用（sys. dm_db_session_space_usage 和 sys. dm_db_task_space_usage），因为物理部分再次被隐藏。

在执行相关的 DMV 中缺少 sys.dm_exec_query_optimizer_info，这意味着无法显示优化计数器，例如每次优化的平均耗时和查询优化执行的优化次数。

最后，在事务相关的 DMV 中缺少当前会话事务和当前快照事务的统计信息。

问题 #8：备份和还原

SQL Database 通过使用每个已提交数据的三个副本在内部提供容错能力。然而，即使是最强大的数据库服务器也无法防止由于硬件故障、内部应用程序故障或人为错误导致的数据损坏。因此，任何应用程序的 DBA 都需要关注数据库备份和还原。我们建议采取以下做法。

首先考虑每天安排一个备份任务以创建最近的还原点。

其次，考虑将备份目标设置为 Azure 存储，方法是从 SQL Database 创建 BACPAC 文件并导出到 Windows Azure Blob 存储；您可以使用 Windows Azure 门户或 API 命令（请参阅 sqldacexamples 以获取更多信息）。务必使链接具体化。如果您确实选择备份到 Windows Azure 存储，请确保存储帐户位于不同的数据中心（但在同一区域内以最大限度地减少数据传输速率），以防止在发生重大数据中心故障时丢失数据。

第三，考虑使用 Microsoft SQL Data Sync 在 SQL Database 实例之间同步数据（副本冗余），或将 SQL Database 实例同步到本地 Microsoft SQL Server 数据库（请注意，SQL Data Sync 目前不提供版本控制）。最后，值得一提的是，如果您计划进行重大的应用程序升级，您应该手动备份数据库以防止意外的回归。

SQL Database 通过使用每个已提交数据的三个副本在内部提供容错能力。然而，即使是最强大的数据库服务器也无法防止数据损坏。因此，任何应用程序的 DBA 都需要关注数据库备份和还原。

问题 #9：数据库横向扩展

SQL Database 实例大小有限，且不保证性能

SQL Database 是一个多租户系统，其中物理资源由许多租户共享。这种资源共享影响了 SQL Database 支持的最大实例大小以及每个实例的性能特征。Microsoft 目前将实例大小限制为 150 GB，并且不保证特定的性能级别。

使用分片和 SQL Database 联合来横向扩展数据库

数据库大小问题和性能问题的解决方案是通过一种称为分片的技术将数据库横向扩展到多个数据库实例。

SQL Database 联合是 SQL Database 的托管分片功能。联合数据库包括一个所有连接都指向其中的根数据库以及一个或多个联合。每个联合包括一个或多个 SQL Database 实例，数据根据联合键的值分发到这些实例，联合键必须存在于每个联合表中。限制是联合键必须存在于联合表中的每个聚集索引或唯一索引中。目前支持的唯一分发算法是范围，联合键仅限于少数几种数据类型。

SQL Database 联合提供了显式支持来将联合实例分成两个，并确保以事务一致的方式将联合数据分配到正确的数据库。SQL 联合还提供了合并两个实例的支持，但这会导致其中一个实例中的数据丢失。

使用联合数据库的应用程序连接到根数据库，并指定 USE FEDERATION 语句来指示连接应路由到哪个实例。这提供了客户端和服务器上连接池的好处。

SQL 联合提供了将 SQL Database 应用程序横向扩展到单个实例无法提供的更大聚合大小的能力。由于每个单独的实例都具有相同的性能特征，因此 SQL 联合允许应用程序通过使用多个实例来扩展性能。

数据库大小问题和性能问题的解决方案是通过一种称为分片的技术将数据库横向扩展到多个数据库实例。

问题 #10：同步数据以最大限度地提高性能

SQL Database 实例应位于何处？

Windows Azure 是一项全球性云服务，可在三个大陆的八个数据中心提供。一个网站可以托管在多个 Windows Azure 数据中心，并且可以配置 Windows Azure Traffic Manager 以允许用户访问最近的数据中心。因此，出现了一个问题，即应在何处放置 SQL Database 实例来存储应用程序数据。它应该位于哪个数据中心？

混合解决方案的兴趣日益浓厚，其中应用程序的一部分保留在本地，一部分迁移到 Windows Azure。同样，数据处理问题也出现了。它应该存储在本地，然后设置 VPN 以允许托管在 Windows Azure 中的云服务访问它吗？还是应该存储在云中？

使用 Microsoft SQL Data Sync

Microsoft SQL Data Sync 为这两种情况都提供了解决方案。它可用于配置两个 SQL Database 实例之间的双向数据同步，或者配置 Microsoft SQL Server 数据库和 SQL Database 实例之间的双向数据同步。它使用一种中心辐射拓扑，其中中心必须是 SQL Database 实例。

因此，Microsoft SQL Data Sync 可与 Windows Azure Traffic Manager 一起使用，以创建真正的全球应用程序，其中云服务和 SQL Database 实例都位于每个数据中心的本地。这最大限度地减少了应用程序延迟，从而改善了用户体验。

同样，Microsoft SQL Data Sync 可以配置为在本地 SQL Server 数据库和 SQL Database 实例之间同步数据。这消除了优先考虑一个位置而非另一个位置的需要，并且通过将数据库保持在应用程序附近再次提高了应用程序性能。

摘要

了解开发人员和 DBA 面临的 Windows Azure SQL Database 的主要问题对于成功部署至关重要。本白皮书解释了以下十大问题：

SQL Database 使用传统的 SQL Server 安全技术，但还允许指定服务器和数据库实例级别的防火墙以限制对实例的访问。SQL Database 存储每个已提交数据的三个副本，以在数据节点发生故障时提供高可用性。然而，为最大限度地减少性能问题，应用程序必须处理 SQL Database 降级主副本时发生的瞬时故障。Entity Framework 可与 SQL Database 一起使用，但应注意避免不必要的数据库实例往返。

与传统 SQL Server 相比，SQL Database 中的连接失败更为常见，但可以使用 Transient Fault Handling Application Block 来限制其影响。SQL Database 是一个多租户系统，它会限制连接以确保公平的资源分配，并且这些瞬时故障也可以由 Transient

Fault Handling Application Block 处理。由于 SQL Database 是一个分布式系统，因此限制应用程序和 SQL Database 之间的频繁通信很重要。作为托管服务，SQL Database 不需要支持全部管理 DMV。然而，它确实提供了许多可用于监控性能的 DMV。

SQL Database 不提供时间点还原，因此考虑替代的备份/还原策略很重要。SQL Database 联合是托管的分片功能，支持使用 SQL Database 的应用程序进行数据和性能的横向扩展。Microsoft SQL Data Sync 提供了在 Microsoft SQL Server 和 SQL Database 实例之间同步数据的功能。

了解开发人员和 DBA 面临的 Windows Azure SQL Database 的主要问题对于成功部署至关重要。