可缩放的云应用程序和站点可靠性工程 (SRE)

云解决方案的成功取决于其可靠性。 可靠性大体上可定义为系统在指定环境条件下在指定时间内按预期运行的概率。 站点可靠性工程 (SRE) 是一组原则和做法，可用于创建可缩放的且高度可靠的软件系统。 在数字服务的设计过程中，用户越来越多地使用 SRE 来确保更高的可靠性。

有关 SRE 策略的详细信息，请参阅 AZ-400：制订站点可靠性工程 (SRE) 策略。

可能的用例

本文中的概念适用于：

• 基于 API 的云服务。
• 面向公众的 Web 应用程序。
• 基于 IoT 或基于事件的工作负载。

体系结构

下载此体系结构的 PowerPoint 文件。

此处考虑的体系结构是可缩放 API 平台的体系结构。 该解决方案包含多个使用各种数据库和存储服务的微服务，包括服务型软件 (SaaS) 解决方案（如 Dynamics 365 和 Microsoft 365）。

本文考虑使用一种解决方案来处理高级商城和电子商务用例，以演示关系图中显示的信息块。 用例包括：

• 产品浏览。
• 注册和登录。
• 查看新闻文章等内容。
• 订单和订阅管理。

Web 应用、移动应用和服务应用程序等客户端应用程序通过统一的访问路径 https://api.contoso.com 使用 API 平台服务。

组件

• Azure Front Door 为解决方案的所有请求提供安全统一的入口点。 有关详细信息，请参阅路由体系结构概述。
• Azure API 管理基于所有发布的 API 提供管理层。 你可以使用 Azure API 管理策略在 API 层上应用其他功能，例如访问限制、高速缓存和数据转换。 API 管理支持标准层和高级层自动缩放。
• Azure Kubernetes 服务 (AKS) 是开放源代码 Kubernetes 群集的 Azure 实现。 作为一个托管的 Kubernetes 服务，Azure 可以自动处理运行状况监视和维护等关键任务。 由于 Kubernetes 主节点由 Azure 管理，因此你只需要管理和维护代理节点。 在此体系结构中，所有微服务都部署在 AKS 中。
• Azure 应用程序网关是应用程序传送控制器服务。 此服务在第 7 层（应用程序层）运行，具有各种负载均衡功能。 应用程序网关入口控制器 (AGIC) 是一种 Kubernetes 应用程序，它使 Azure Kubernetes 服务 (AKS) 客户能够使用 Azure 的本机应用程序网关 L7 负载均衡器将云软件发布到 Internet。 v2 SKU 支持自动缩放和区域冗余。
• Azure 存储、Azure Data Lake Storage、Azure Cosmos DB 和 Azure SQL 可以存储结构化和非结构化内容。 Azure Cosmos DB 容器和数据库可以使用自动缩放吞吐量进行创建。
• Microsoft Dynamics 365 是 Microsoft 提供的服务型软件 (SaaS) 产品，可提供适用于客户服务、销售、营销和财务的多种商务应用程序。 在此体系结构中，Dynamics 365 主要用于管理产品目录和客户服务管理。 缩放单元为 Dynamics 365 应用程序提供复原能力。
• Microsoft 365（以前称为 Office 365）用作基于 Office 365 SharePoint Online 的企业内容管理系统。 此系统用于创建、管理和发布媒体资产和文档等内容。

备选方法

此解决方案使用高度可缩放的基于微服务的体系结构，因此请考虑对计算平面使用以下备选项：

• Azure Functions（对于无服务器 API 服务）
• Azure Spring Apps（对于基于 Java 的微服务）

适当的可靠性

解决方案所需的可靠性程度取决于业务环境。 对于营业 14 小时并在该时段内达到系统使用率峰值的零售商店，对可靠性的要求与随时接受订单的网店不同。 为达到适当的可靠性级别，可以定制 SRE 做法。

可靠性可使用服务级别目标 (SLO) 来定义和衡量，该目标用于定义服务的目标可靠性级别。 达到目标级别可确保使用者满意。 SLO 目标会根据业务需求不断发展或更改。 但服务所有者应始终根据 SLO 来衡量可靠性，以检测问题并采取纠正措施。 SLO 通常定义为一段时间的百分比成果。

另一个要注意的重要术语是服务级别指标 (SLI)，该指标用于计算 SLO。 SLI 基于数据分析，后者是根据客户使用服务时捕获的数据生成的。 SLI 始终从客户的角度进行衡量。

SLO 和 SLI 始终密切相关，而且通常以迭代方式进行定义。 SLO 基于关键业务目标，而 SLI 基于进行服务时可能要衡量的内容。

监视的指标、SLI 和 SLO 之间的关系如下所述：

在定义 SLI 指标以计算 SLO 中，更详细地介绍了此关系。

对缩放和性能预期建模

对于软件系统，性能通常是指系统在指定时间内执行操作时的总体响应能力，而可伸缩性是指系统在性能无损的情况下处理增加的用户负载的能力。

如果以动态形式提供基础资源来支持负载增加，则需将系统视为可缩放的系统。 云应用程序必须设计为可缩放程序，因此有时难以预测流量。 季节性高峰会增加缩放要求，尤其是在服务处理多个租户的请求时。

设计应用程序是一种很好的做法，云资源因此可以根据需要自动增加和减少以满足负载要求。 简单而言，系统应该通过增量预配或分配资源来适应工作负载增加的情况，以此满足需求。 可伸缩性不仅适用于计算实例，还适用于数据存储和消息传送基础结构等其他元素。

本文介绍如何通过对工作负载方案进行缩放和性能建模，并使用这些结果定义监视器、SLI 和 SLO，来确保云应用程序具有适当的可靠性。

注意事项

有关构建可缩放的可靠应用程序的指南，请参阅 Azure 架构良好的框架中的可靠性和性能效率支柱。

本文探讨如何应用可伸缩性和性能建模技术来微调解决方案体系结构和设计。 使用这些技术可发现事务流的变化，获得最佳用户体验。 你可以根据解决方案的非功能性要求做出技术决策。 过程如下：

• 确定可伸缩性要求。
• 对预期负载建模。
• 定义用户方案的 SLI 和 SLO。

捕获可伸缩性要求

假设使用以下峰值负载指标：

• 使用 API 平台的使用者数：150 万
• 每小时处于活动状态的使用者数（150 万的 30%）：450,000
• 各项活动的负载百分比：
  • 产品浏览：75%
  • 注册（包括配置文件创建和登录）：10%
  • 订单和订阅的管理：10%
  • 内容查看：5%

在一般峰值负载环境下，此负载需要平台托管的 API 满足以下缩放要求：

• 产品微服务：每秒请求数 (RPS) 约为 500
• 配置文件微服务：RPS 约为 100
• 订单和付款微服务：RPS 约为 100
• 内容微服务：RPS 约为 50

这些缩放要求未考虑季节性和随机峰值，以及市场营销促销等特殊事件期间的峰值。 在峰值期间，与一般峰值负载相比，某些用户活动的缩放要求高达 10 倍。 在为微服务做出设计选择时，请记住这些约束条件和预期。

定义 SLI 指标以计算 SLO

SLI 指标指示服务提供满意体验的程度，可以表示为良好事件在全部事件中的比率。

对于 API 服务，事件是指在执行期间以遥测或处理的数据形式捕获的特定于应用程序的指标。 此示例具有以下 SLI 指标：

下面是 SLI 的示例：

• （在 1,000 毫秒内成功完成的请求数）/（请求数）
• （在三秒钟内返回发布到目录的任何产品的搜索结果数）/（搜索数）

定义 SLI 后，需确定要捕获哪些事件或遥测数据来衡量这些指标。 例如，若要衡量可用性，可以捕获指示 API 服务是否成功处理请求的事件。 对于基于 HTTP 的服务，成功或失败是使用 HTTP 状态代码指示的。 API 设计和实现必须提供正确的代码。 通常，SLI 指标是 API 实现的重要输入。

对于基于云的系统，可以使用可用于资源的诊断和监视支持来获取一些指标。 Azure Monitor 是一个全面的解决方案，可用于通过云服务收集、分析和处理遥测数据。 根据具体 SLI 要求，可以捕获更多监视数据来计算指标。

使用百分位数分布

某些 SLI 是使用百分位数分布技术来计算的。 如果有离群值影响平均值或中值分布等其他技术，则结果会更好。

例如，假设指标是 API 请求的延迟，三秒是获得最佳性能的阈值。 API 请求一小时的排序响应时间表明，几乎没有请求需要超过三秒的时间，并且大多数请求在阈值限制内收到响应。 这是系统的预期行为。

百分位数分布旨在排除间歇性问题导致的离群值。 例如，如果正常的服务响应位于第 90 或第 95 百分位数，则视为符合 SLO 要求。

选择适当的衡量周期

定义 SLO 的衡量周期非常重要。 在此周期内，必须捕获到活动，而不是赋闲无事，而且对用户体验而言结果必须是有意义的。 此时段可以是五分钟到 24 小时，具体取决于你想如何监视和计算 SLI 指标。

建立性能管理流程

在弃用或停用之前，必须从始至终地管理 API 的性能。 必须建立可靠的管理流程，才能确保尽早检测到性能问题并进行修复，以免造成重大服务中断，进而影响业务。

下面是性能管理要素：

• 性能目标：为业务方案定义理想性能 SLO。
• 性能建模：确定业务关键型工作流和事务，并进行建模以了解与性能相关的影响。 以粒度级别捕获此信息，实现更准确的预测。
• 设计准则：准备性能设计准则，并建议适当的业务工作流修改。 确保团队了解这些准则。
• 履行准则：为解决方案组件履行性能设计准则，包括用于捕获指标的检测。 进行性能设计评审。 使用不同团队的体系结构积压工作项跟踪这些目标至关重要。
• 性能测试：根据负载配置文件分布执行负载和压力测试，以捕获与平台运行状况相关的指标。 还可以对有限负载执行这些测试，以对解决方案基础结构要求进行基准检验。
• 瓶颈分析：使用代码检查和代码评审来识别、分析和消除各种组件的性能瓶颈。 确定支持峰值负载所需的水平或垂直缩放增强功能。
• 持续监视：在 DevOps 过程中建立持续监视和警报基础结构。 当响应时间较之基准显著减少时，请确保相关团队收到通知。
• 性能管理：建立性能管理流程，其中包含定义明确的流程和团队，以保持性能 SLO。 在每个版本发布后跟踪合规性，以避免因版本升级出现任何降级情况。 定期进行评审，评估负载是否增加，以确定解决方案是否升级。

作为渐进式处理过程的一部分，确保在解决方案开发过程中重复执行这些步骤。

使用积压工作跟踪性能目标和预期

跟踪性能目标，帮助确保达到这些目标。 捕获要跟踪的精细和详细的用户案例。这有助于确保开发团队将性能管理活动设为高优先级。

为目标解决方案建立理想 SLO

下面是考虑的 API 平台解决方案的理想 SLO 示例：

• 一天内 95% 的读请求在一秒内响应。
• 一天内 95% 的创建和更新请求在三秒内响应。
• 一天内 99% 的请求在五秒内响应，无失败。
• 一天内 99.9% 的请求在五分钟内成功响应。
• 在高峰一小时时段内，不到 1% 的请求出错。

SLO 可以进行定制，以满足特定应用程序要求。 但是，必须足够精细，以清晰的思维确保可靠性。

根据日志中的数据衡量初始 SLO

使用 API 服务时，系统会自动创建监视日志。 假设一周的数据显示以下内容：

• 请求数：123,456
• 成功的请求数：123,204
• 第 90 百分位数延迟：497 毫秒
• 第 95 百分位数延迟：870 毫秒
• 第 99 百分位数延迟：1,024 毫秒

使用此数据可生成以下初始 SLI：

• 可用性 = (123,204 / 123,456) = 99.8%
• 延迟 = 至少 90% 的请求在 500 毫秒内得到处理
• 延迟 = 大约 98% 的请求在 1000 毫秒内得到处理

假设在计划期间，理想延迟 SLO 目标为 90% 的请求在 500 毫秒内得到处理，并且一周内的成功率为 99%。 使用日志数据，可以轻松确定是否达到 SLO 目标。 如果这种类型的分析持续几周时间，就可以开始看到 SLO 合规性的趋势。

技术风险缓解指南

使用以下建议做法清单可降低可伸缩性和性能风险：

• 针对缩放和性能进行设计。
  • 确保捕获每个用户方案和工作负载（包括季节性和峰值工作负载）的缩放要求。
  • 进行性能建模以确定系统约束条件和瓶颈
• 管理技术债务。
  • 对性能指标进行广泛跟踪。
  • 考虑使用脚本在具有一系列用户负载（例如 50 到 100 RPS）的开发过渡环境中运行 K6.io、Karate 和 JMeter 等工具。 这样会在日志中提供检测设计和实现问题的信息。
  • 在持续部署 (CD) 过程中集成自动测试脚本，以检测编译中断。
• 采用生产思维模式。
  • 根据运行状况统计信息指示调整自动缩放阈值。
  • 首选水平缩放技术，而非垂直缩放技术。
  • 主动进行缩放以处理季节性负载。
  • 首选基于环形的部署。
  • 使用错误预算进行试验。

定价

可靠性、性能效率和成本优化密切相关。 用于体系结构的 Azure 服务有助于降低成本，因为这些服务可自动缩放以适应不断变化的用户负载。

对于 AKS，最初可以从节点池中标准大小的 VM 入手。 然后，可以在开发或生产使用期间监视资源要求，并相应地做出调整。

成本优化是 Microsoft Azure 架构良好的框架中的支柱内容。 有关详细信息，请参阅成本优化支柱概述。 若要估算 Azure 产品和配置的成本，请使用定价计算器。

作者

本文由 Microsoft 维护， 它最初是由以下贡献者撰写的。

主要作者：

• Subhajit Chatterjee | 首席软件工程师

后续步骤

• Azure 文档
• Microsoft Azure 架构良好的框架
• 微服务体系结构样式
• 扩大式设计
• 选择用于应用程序的 Azure 计算服务
• 设计和实现模式
• Azure Kubernetes 服务上的微服务体系结构
• 什么是 Azure Front Door？
• 关于 API 管理
• 什么是应用程序网关入口控制器？
• Azure Kubernetes 服务
• 自动缩放和区域冗余应用程序网关 v2
• 自动缩放群集以满足 Azure Kubernetes 服务 (AKS) 上的应用程序需求
• 创建具有自动缩放吞吐量的 Azure Cosmos DB 容器和数据库
• Microsoft Dynamics 365 文档
• Microsoft 365 文档
• 站点可靠性工程文档
• AZ-400：制定站点可靠性工程 (SRE) 策略

相关资源

• 具有区域冗余的基线 Web 应用程序
• Azure 上的 Web 应用程序监视