应用服务的任务关键型基线

本文介绍如何使用 Azure 应用服务部署任务关键型 Web 应用程序。 体系结构使用 可靠的 Web 应用模式 作为起点。 如果有旧工作负载，并且想要采用平台即服务（PaaS）服务，请使用此体系结构。

适用于 .NET 的可靠 Web 应用模式 提供了更新或重新创建迁移到云的 Web 应用的指南。 此方法可帮助你最大程度地减少所需的代码更改，并将服务级别目标 （SLO） 设定为 99.9%。 任务关键型工作负荷具有较高的可靠性和可用性要求。 若要达到 99.95%、99.99%或更高版本的 SLO，需要应用补充任务关键型设计模式和作严谨性。 本文介绍关键技术领域以及如何引入和实施任务关键型设计实践。

以下部分介绍如何：

• 查看现有工作负荷以了解其组件、用户和系统流以及可用性和可伸缩性要求。
• 开发和实现 缩放单元体系结构，通过隔离化优化端到端可伸缩性，并标准化添加和删除容量的过程。
• 实现无状态、临时缩放单元或部署标记，以实现可伸缩性和零停机时间部署。
• 确定是否可以将工作负荷拆分为组件，以便为可伸缩性做好准备。 对于可伸缩性和分离流，需要单个组件。
• 通过跨多个 Azure 区域部署工作负荷来准备 全局分发，以提高与客户的距离并准备潜在的区域中断。
• 分离组件并实现事件驱动的体系结构。

建筑

下图将前面的注意事项应用于 可靠的 Web 应用模式。

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

红色框表示一个缩放单元，其中包含一起缩放的服务。 若要有效地将它们一起缩放，请优化每个服务的大小、SKU 和可用 IP 地址。 例如，Azure 应用配置提供的最大请求数与缩放单元提供的每秒请求数相关联。 在区域中添加更多容量时，还必须添加更多单独的缩放单元。

这些单个缩放单元彼此没有任何依赖关系，并且仅与单个缩放单元外部的共享服务通信。 可以在 蓝绿部署 中使用这些缩放单元，方法是推出新的缩放单元，验证它们正常运行，并逐步将生产流量移到它们上。

在此方案中，我们将缩放单元视为临时单元，从而优化推出过程，并在区域内和跨区域提供可伸缩性。 采用此方法时，应仅将数据存储在数据库中，因为数据库将复制到次要区域。 如果需要将数据存储在缩放单元中，请考虑使用 Azure Redis 缓存在缩放单元中存储。 如果必须放弃缩放单元，则重新填充缓存可能会增加延迟，但不会导致中断。

Application Insights 从缩放单元中排除。 排除存储或监视数据的服务。 使用自己的生命周期将它们分成自己的资源组。

替换缩放单元或部署新单元时，请保留历史数据，并为每个区域使用一个实例。

有关详细信息，请参阅 azure 上任务关键型工作负荷的应用程序设计。

组件

此体系结构使用以下组件。

• 应用服务 是应用程序托管平台。
• Azure Redis 缓存 缓存请求。
• 应用配置 存储配置设置。
• Azure SQL 是后端数据库。
• Application Insights 从应用程序获取遥测数据。

选择

在可靠的 Web 应用模式中，可以：

• 使用 Azure Kubernetes 服务（AKS） 而不是应用服务。 此选项适用于具有大量微服务的复杂工作负荷。 AKS 提供对底层基础结构的更多控制，并允许复杂的多层设置。
• 容器化工作负荷。 应用服务支持容器化，但在此示例中，工作负荷不会容器化。 使用容器提高可靠性和可移植性。

有关详细信息，请参阅 Azure 上任务关键型工作负荷应用程序平台注意事项。

高可用性注意事项

无论选择哪种应用程序平台，我们建议优先使用生产工作负荷的可用性区域。

可用性集 将部署分散在数据中心内的多个容错域和更新域中。 可用性区域 将部署分散到 Azure 区域内的各个数据中心。 可用性区域通常优先，但使用的策略取决于工作负荷。 例如，延迟敏感或闲聊的工作负荷可能受益于确定可用性集的优先级。 如果将工作负荷分散到可用性区域，则可能会增加跨区域流量的延迟和成本。 使用可用性区域时，请确保缩放单元中的所有服务都支持它们。 可靠 Web 应用模式中的所有服务都支持可用性区域。

选择数据平台

选择的数据库平台会影响总体工作负荷体系结构，尤其是平台的主动-主动或主动-被动配置支持。 可靠的 Web 应用模式使用 Azure SQL，它本身不支持在多个实例中具有写入作的活动-主动部署。 在此配置中，数据平台仅限于主动-被动策略。 如果所有区域中都有只读副本，并且你只写入单个区域，则可以在应用程序级别执行（部分）主动-主动策略。

多个数据库在复杂的体系结构中很常见，例如微服务体系结构，每个服务都有一个数据库。 多个数据库允许采用多主写入数据库（如 Azure Cosmos DB），从而提高高可用性和低延迟。 跨区域延迟可能会造成限制。 考虑非功能要求和因素（如一致性、可作性、成本和复杂性）至关重要。 使单个服务能够使用单独的数据存储和专用数据技术来满足其独特要求。 有关详细信息，请参阅 Azure 上任务关键型工作负荷的数据平台注意事项。

定义运行状况模型

在分布在多个数据中心和地理区域的复杂多层工作负荷中，必须定义运行状况模型。

定义运行状况模型：

• 定义用户和系统流
• 指定和了解服务之间的依赖关系
• 了解某个服务中断或性能下降对整体工作负荷的影响
• 监视和可视化客户体验，以启用适当的监视并改进手动和自动化作。

上图显示了单个组件的中断或降级（如应用配置）如何为客户带来潜在的性能下降。 将组件分成缩放单元时，可以停止将流量发送到应用程序受影响的部分，例如受影响的缩放单元或整个区域。

确定缩放单元运行状况的条件在运行状况模型中定义。 然后，此模型连接到缩放单元 运行状况终结点，这样全局负载均衡器就可以查询缩放单元的运行状况状态，并使用该信息进行路由决策。

有关详细信息，请参阅 Azure上任务关键型工作负荷的运行状况建模和可观测性。

安全性和网络

任务关键型工作负荷具有严格的网络和安全要求。 特别是对从本地环境迁移的工作负荷应用勤奋，因为并非所有已建立的本地安全做法都转换为云环境。 建议在应用程序迁移期间重新评估安全要求。

标识通常是云原生模式的主要安全外围。 企业客户可能需要更实质性的安全措施。 为了满足其网络安全要求，Azure PaaS 服务可以使用 Azure 专用链接将网络实现为安全外围。 专用链接有助于确保只能从虚拟网络内部访问服务。 然后，只能通过专用终结点访问所有服务。 下图显示了唯一面向 Internet 的公共终结点是 Azure Front Door。

若要使可靠的 Web 应用模式将网络设置为安全外围，必须使用：

• 支持它的所有服务的专用链接。
• Azure Front Door Premium 是唯一面向 Internet 的公共终结点。
• 通过 Azure Bastion 访问服务的跳转框。
• 可以访问服务的自承载生成代理。

任务关键型应用程序的另一个常见网络要求是限制出口流量，以防止数据外泄。 通过适当的防火墙设备路由 Azure 防火墙来限制出口流量。 然后，使用设备筛选流量。 具有网络控制的 Azure 任务关键型基线体系结构 使用防火墙和专用链接。

部署和测试

错误发布或人为错误导致的停机时间可能是需要始终可用的工作负荷的问题。 以下是需要考虑的一些关键领域：

• 零停机时间部署
• 临时蓝绿部署
• 单个组件和分组组件的生命周期分析
• 持续验证

零停机部署 对于任务关键型工作负荷至关重要。 需要始终启动并运行的工作负荷不能有一个维护时段来推出较新版本。 若要解决此限制，Azure 任务关键型体系结构遵循零停机时间部署模式。 更改将作为新的缩放单元或标记推出，这些单元或标记在以增量方式路由到它们之前，测试的标记将结束。 将所有流量路由到新标记后，旧的标记将被禁用并删除。

有关详细信息，请参阅 azure 上任务关键型工作负荷的部署和测试。

后续步骤

• 学习路径：在 Azure 上生成任务关键型工作负荷
• 挑战项目：设计任务关键型 Web 应用程序
• Learn 模块：为任务关键型工作负荷设计运行状况模型

相关资源

• 在 Azure 上 任务关键型基线体系结构
• 使用网络控制 任务关键型基线体系结构
• 在 Azure 登陆区域中 任务关键型基线体系结构
• 使用 Azure 负载测试和 Azure Chaos Studio 持续验证