Azure 网站

  • 项目

构建使用 Azure 网站的云

Apurva Joshi
Sunitha Muthukrishna

 

在设计云解决方案时，设计始终要为故障做好准备。这一点很重要，应牢记。然而，许多应用程序并非按照这种方式构建。出现这种情况的主要原因是对如何使用 Microsoft Azure 网站设计体系结构以使其有足够复原能力的意识不足。因此，如何构建足够强大的、能够处理故障的云解决方案？本文将探讨您在设计这类系统时可以使用的技术。

单个网站实例

Azure 网站提供多个层次上的托管计划： 免费、共享、基本和标准。“免费”和“共享”层次向网站提供共享的基础结构，这表示您的网站与其他网站共享资源。在“基本”和“标准”层次中，将向您的网站提供专用的基础结构，这表示只有您选择与您的计划相关联的一个或多个网站将运行这些资源。

在这些层次中，您可以配置您的 Web 托管计划，以使用一个或多个虚拟机 (VM) 实例。这些层次可以支持小型、中型和大型实例。提供商将以您的名义管理这些 VM，这表示您永远不必担心 OS 更新或安全和配置更新。

对于在 Azure 网站上运行生产级网站，则根据您的应用程序大小以及流向您的网站的通信量，建议采用“基本”或“标准”层次。了解您的应用程序要求是良好的起点：

  1. 您的应用程序需要哪些组件：数据库、电子邮件提供程序、缓存等？
  2. 哪些组件存在出现故障的风险，并且需要复制？
  3. 需要哪些功能：SSL、过渡槽等？
  4. 您的网站应该能够管理多少流量？

带着这些答案，您可以创建单个网站，并视需要将相关组件（如数据库和缓存）添加到您的应用程序。在图 1 中，您可以看到可能构建单个网站及其依赖的组件的方式。

在单个网站方案中，最大的警告是：任何组件（网站、数据库或缓存服务）出现与服务有关的故障时，您的网站在故障期间将无法访问，因此对您的客户和业务造成一定的影响。

Standard Architecture for a Single Web Site
图 1 单个网站的标准体系结构

此设计并不考虑云解决方案涉及的风险，也不包含某种方法来降低这些风险。在云环境中，您的设计目标应该是创建高可用性的网站，从而使故障期间的停机时间降低到最短并加快恢复速度。

目标——高可用性

Azure 网站中的典型 Web 应用程序堆栈由 Web 应用程序、数据库、Azure 存储空间和某种形式的缓存构成。所有这些组件会紧密耦合在一起，以避免单个实体或组件成为单一故障点 (SPOF)。这是构建任意云解决方案的主要设计标准。以下是相关目标：

  • 在您的设计中避免 SPOF
  • 设计中每层之间的冗余

Azure 网站提供 99.9% 的 SLA。这表示您可以预料到由于计划的部署或 Azure 网站服务执行的升级而产生的每周 10 分钟左右的停机时间。10 分钟的停机时间对您的业务仍有很大的影响。您的目标是设计可减少此停机时间并能够服务客户的解决方案，从而降低影响带来的风险。您应该努力构建一个高可用性的 Web 体系结构，如图 2 中所示。

Example of a Highly Available Web Architecture
图 2 高可用性 Web 体系结构的示例

Web 应用程序层的高可用性

Azure 网站为您的 Web 应用程序创建无状态的云解决方案。在应用程序级别上设计高可用性时，您需要考虑以下几点：

  1. 为您的网站使用“标准”模式，并对其进行配置以使用至少两个网站实例。
  2. 基于您的流量模式，通过不同的工具（例如，Visual Studio 和 Apache JMeter）(jmeter.apache.org) 模拟加载测试，以识别实例大小和您的网站管理实际流量级别所需的实例数量。
  3. 确保用户和会话数据存储在集中系统中，如数据库或分布式缓存层。Azure 网站中，在“标准”模式下运行时，所有的 VM 共享“文件”服务器。
  4. 至少在 Azure 网站支持的两个区域中复制 Web 应用程序层。
  5. 您的网站上传或管理的用户内容（如媒体和文档）应存储在 Azure 存储空间帐户中。确保存储帐户与网站位于相同的地理区域，以减少延迟时间。
  6. 始终遵循安全的编码实践，以使您的应用程序对于恶意攻击具有迅速复原能力。

数据库层的高可用性

数据是指真正为任何应用程序生成值的内容，因此应有效地管理数据。为了使应用程序正常运行，关键要避免数据库层上出现单一故障点。Azure 网站支持 Azure SQL 数据库和 ClearDB MySQL 服务。以上两者提供从低档到优质解决方案的选项。

Azure SQL 数据库 Premium 为使用 Azure 网站的云应用程序提供预测性更强的性能和更大的容量。它指定数据库（包括其内置数据库的复制功能）保留容量的固定量。保留容量非常适于以下情况：

  • 高峰负载： 需要占用大量 CPU、内存或 I/O 来完成操作的应用程序非常适于使用 Premium 数据库。
  • 许多并发请求： 一些数据库应用程序提供许多并发请求。Azure SQL 数据库的常用 Web 版和企业版的并发请求数限于 180 个。请求更多连接的应用程序应使用 Premium 数据库，其具有适当的保留大小来处理最大数量的请求。
  • 可预测的延迟时间： 一些应用程序需要保证最短的数据库响应时间。如果指定的存储过程作为更广泛客户操作的一部分进行调用，则可能要求 99% 的情况下在 20 毫秒内从该调用中返回。这种应用程序将从 Premium 数据库中受益，以确保提供计算能力。

ClearDB 提供高可用性的 SQL 路由器（或 CDBR），这些路由器是自定义的智能流量管理器，用于监测数据库群集。当数据库节点不正常时，CDBR 自动重定向至您的辅助主服务器。这有助于确保数据库的运行时间，从而确保 Web 应用程序的运行时间。在构建此设计时，请记住有 ClearDB 支持这类方案的推荐区域配对，如：

  1. 如果您选择位于美国东部的某个数据库，则配对数据库应位于美国西部。
  2. 如果您选择位于欧洲北部的某个数据库，则配对数据库应位于欧洲南部。

各区域之间的高可用性

目前，Azure 网站支持多个区域。它还致力于扩展它的基础结构。可将使用多个区域的体系结构分成主动-主动网站和主动-被动网站。

主动-主动网站： 在主动-主动 Web 体系结构中，您将在各区域的多个网站中提供相同的应用程序。在这种情况下，需要在所有网站之间管理流量，因此将它们视为主动。

主动-被动网站： 在主动-被动体系结构中，只有一个网站作为主网站。这将为所有的客户流量提供内容。在此站点出现故障期间，客户将被重定向至配置的其他站点，并且与缓解故障的不同数据中心中的主网站同步。

在设计您的体系结构以跨多个区域进行操作时，需要考虑以下几种挑战：

  • 数据同步： 这是指跨不同区域实时复制数据库的能力。任何复杂的系统都具有数据库、文件服务器、外部存储和缓存（这里仅列举几个组件）。在设计您的体系结构时，需要确保跨多个区域复制的数据保持同步，以防止 Web 应用程序损坏。这可能需要对您的应用程序代码进行某些更改，以支持这种方案。Azure 网站支持运行名为“Web Jobs”的后台进程，这可让您创建自定义工具以管理数据同步。
  • 网络流： 这是指跨多个区域管理网络流量的能力。通过 Azure 流量管理器，您可以在多个托管网站中对传入的流量进行负载平衡，不管它们是在相同的数据中心中运行，还是在不同的数据中心中运行。通过有效地管理流量，您可以确保您的应用程序的高性能、高可用性以及高复原能力。

您可以使用流量管理器确保您的应用程序的高可用性和高响应能力。流量管理器提供三种负载平衡方法：

  1. 故障转移： 在您想为所有流量使用主终结点，但提供了一个或多个备用终结点以防主终结点或备用终结点不可用时，使用此方法。
  2. 循环： 通过此方法，您可以将流量平均分布到相同的数据中心或不同的数据中心中的一组终结点。
  3. 性能： 通过此方法，可以请求客户/用户使用最近的终结点，以通过提供不同地理位置中的终结点来减少延迟时间。

缓存层的高可用性

要提高您网站的性能，缓存层很关键。使用您的应用程序处理数据时，需要了解缓存可能如何影响您的数据和应用程序。在选择您的缓存层时，考虑是否需要保留不同缓存实例中存储的数据的一致性。要避免出现数据不一致，您应该使用分布式缓存机制。由于分布式缓存可以使用多个服务器，因此其大小可以调整，并且通过减少对数据库的调用数量来存储驻留在数据库中的应用程序数据。

有许多您可以与 Azure 网站进行集成的基于云的缓存解决方案，如 Azure 缓存和 Memcached Cloud。这些可通过 Azure 管理门户中的 Azure 应用商店获得。

性能监控

既然您已理解了用于您网站的高可用性策略，那么您将需要评估您的监控选项。Azure 网站在 Azure 管理门户中提供两种类型的监控：

  1. 使用网站指标监控： 每个网站仪表板都含有一个“监控”页面。该页面为每个站点提供性能统计数据，如 CPU 使用量、请求数量以及网站发送的数据等。
  2. 终结点监控： 通过终结点监控，您可以配置从地理分布位置进行 Web 测试，以测试 Web URL 的响应时间和运行时间。每个配置的位置每隔五分钟进行一次测试。通过 HTTP 响应代码对运行时间进行监控。响应时间以毫秒计算。当响应时间小于 30 秒且 HTTP 状态代码小于 400 时，运行时间被视为 100%。当响应时间大于 30 秒或 HTTP 状态代码大于 400 时，运行时间被视为 0%。在配置终结点监控后，您可以深入到各个终结点，以查看每个测试位置中监控间隔的响应时间和运行时间状态的详细信息。

通过 Azure 预览门户，您可以执行更详细、更灵活的监控。您可以在此处创建完备的 DevOps 仪表板。图 3 显示了运行 Azure 网站时 DevOps 仪表板的外观。

A Typical DevOps Dashboard
图 3 典型的 DevOps 仪表板

在开发云时，应用程序计划、开发和测试通常在其他位置进行，如 Visual Studio Online。可能在其他门户（如 Application Insights）中监控这些应用程序的运行状况，并对问题进行排查。在单独的页面上显示帐单。是否注意到此处的模式？

这一新门户将所有的云资源、团队成员和您的应用程序生命周期的各阶段集合在一起。它为您提供了一个集中的地方进行计划、开发、测试、设置、部署、衡量和监控这些应用程序。这种方法有助于团队通过一种有意义的方式将开发和操作功能及视角集中在一起，从而利用 DevOps 区域性。有关这一方面的更多信息，您可以访问 bit.ly/1sYNRtK，并查看“使用新的 Azure 预览门户创建您理想的 DevOps 仪表板”博文。

恢复选项

有时，好的应用程序也会发生糟糕的事情。Azure 网站可以帮助您自动从应用程序故障中恢复。通常，当您的监控系统检测到问题时，它会以某种方式提醒运营人员。然后，运营人员会直接重启网站，以恢复运行。

您可以在应用程序中配置 web.config 文件，以进行检测，并对某些状况作出应对。例如，如果 X 个请求需要花费 Y 时间量以在 Z 时间量内执行，那么执行操作 ABC（这可能将重启网站、记录该事件或运行自定义操作）。另一个示例可能是，如果我的进程占用的内存量为 X，那么执行操作 ABC。有关恢复过程的更多信息，请访问 bit.ly/LOSEvS 上的 Microsoft Azure 博客。

尽管地理位置冗余的体系结构提供防止出现基础结构相关故障的保护，但是诸如自动恢复的功能有助于创建应用程序层恢复能力。进入云计算阶段之后，当网站出现故障时，相较于执行完备的诊断，用户始终更热衷于首先从故障恢复。换句话说，在其他情况和方案中，诊断必不可少。

诊断工具

诊断就像剥掉坏洋葱的表皮。您从不知道需要剥掉多少层。Azure 网站是完全管理的、多租户的“平台即服务”(PaaS) 产品，并且其本身不支持 VM 中的远程诊断。这带来了一组新的挑战。以下是可用的工具列表以及这些工具可挥很大作用的诊断方案。

默认情况下，该项服务提供多种有助于故障排除的记录。有一些日志包括 Web 服务器记录、详细的错误记录、应用程序记录及失败的请求跟踪等。有关记录服务的更多信息，请访问 bit.ly/1i0MSou。

Kudu 控制台是另外一种诊断工具。我们的多用途软件配置管理终结点客户将频繁地用此进行诊断。在记录入 Kudu 终结点时，您将在顶部的功能区中看到不同的诊断选项（请参阅图 4）。

The Kudu Console Provides Diagnostic Tools
图 4 Kudu 控制台提供诊断工具

“环境”选项卡向您提供了诸如以下内容的只读视图：系统信息、应用程序设置、连接字符串、环境变量、系统路径、HTTP 标头以及特定于您的网站和 VM 的服务器变量。这始终可有效地帮助对不同数据点进行后续调查。

“调试控制台”选项卡向您提供基于 CMD 或基于 Windows PowerShell 的远程执行控制台以及可访问您站点的文件浏览器。您可以使用该控制台执行最标准的控制台操作和任意外部命令（如 Git 命令）、导航文件夹 UI、下载文件和文件夹、使用拖放功能上传文件和文件夹以及查看和编辑文本文件等。有关这一方面的更多信息，您可以访问 bit.ly/1h0ZZoR，并观看 YouTube 视频“Azure 网站诊断控制台”。

“进程资源管理器”选项卡向您提供您的应用程序可以查看并可在 Azure 网站沙箱内进行通信的当前活动进程的列表。此视图将向您提供有关进程内存和 CPU 使用量的信息。此外，您还可以查看有关指定进程的详细信息，生成并下载离线诊断的完整内存转储等。

“诊断转储”选项卡向您提供了可以下载的 .zip 文件形式的内存转储。然后，您可以使用 DebugDiag 之类的转储分析器快速地分析内存转储，并获得一些说明性指南。

“日志流”选项卡允许您将流式 HTTP 或应用程序日志直接记录到控制台。这有助于对活动问题进行故障排除。有关这一方面的更多信息，请访问 bit.ly/1jXwy7q，并阅读 Scott Hanselman 的博文“Azure 命令行（加 Glimpse！）中的流式诊断跟踪记录”。

无论如何，这并非完整的调试工具列表。Microsoft 计划创建更加复杂的诊断，其中一些最常用的方案只需单击一下即可使用。届时，尽情地创建可迅速从故障中恢复的良好应用程序吧。

Apurva Joshi 是 Microsoft 的高级项目经理，供职于 Azure 网站团队。 他于 2002 年加入 Microsoft，并一直致力于各种 Web 技术，例如 IIS 和 ASP.NET。

Sunitha Muthukrishna 是 Microsoft 的项目经理，供职于 Azure 网站团队。 她于 2011 年加入 Microsoft，并一直致力于 Windows Web Application Gallery 和 Azure 网站。 以前，她致力于一些非盈利机构（如位于西雅图沃什的社区营造网络 (Community Empowerment network) 和系统生物学研究所 (Institute of Systems Biology)）的 IT 项目。

衷心感谢以下技术专家对本文的审阅： Microsoft Azure 生产管理团队