本文介绍如何使用 Azure 应用程序服务部署任务关键型 Web 应用程序。 该体系结构使用可靠的 Web 应用模式作为起点。 如果你有遗留工作负载并希望采用平台即服务 (PaaS) 服务，请使用此体系结构。
适用于 .NET 的可靠 Web 应用模式提供了有关更新或重新构建迁移到云的 Web 应用平台、最大限度地减少所需代码更改以及将服务级别目标 (SLO) 定为 99.9% 的指导。 任务关键型工作负载具有较高的可靠性和可用性要求。 若要达到 99.95%、99.99% 或更高的 SLO，需要应用补充任务关键型设计模式和操作严谨性。 本文介绍了关键技术领域以及如何实施和引入关键任务设计实践。
注意
本文中的知道基于体系结构完善的框架任务关键型工作负载系列中的设计方法和最佳实践。
以下各部分介绍如何执行以下操作：
- 查看现有工作负载以了解其组件、用户和系统流程以及可用性和可伸缩性要求。
- 开发和实施缩放单元体系结构，通过分区来优化端到端可伸缩性，并使添加和删除容量的过程标准化。
- 实施无状态、临时缩放单元或部署标记，以实现可伸缩性和零停机时间部署。
- 确定是否可以将工作负载拆分为多个组件，以便为可伸缩性做好准备。 可伸缩性和解耦流程需要单独的组件。
- 通过跨多个 Azure 区域部署工作负载，为全球分发做好准备，更加靠近客户，并为潜在的区域中断做好准备。
- 解耦组件并实施事件驱动的体系结构。
体系结构
下图将前面的注意事项应用于可靠的 Web 应用模式。
下载此体系结构的 Visio 文件。
红色框表示一个缩放单元，其中包含一起缩放的服务。 为了有效地将这些服务一起缩放，请优化每个服务的大小、SKU 和可用 IP 地址。 例如，Azure 应用程序配置提供的最大请求数与缩放单元提供的每秒请求数相关联。 在区域中添加更多容量时，还必须添加更多单独的缩放单元。
这些单独的缩放单元相互之间没有任何依赖关系，并且仅与单个缩放单元外部的共享服务通信。 可以提前测试独立的缩放单元。 为了避免影响其他部署领域，请推出独立的缩放单元，并在新版本中引入替换服务的选项。
对于任务关键型工作负载，独立缩放单元是临时的，可优化推出过程，并在区域内部和跨区域提供可伸缩性。 避免将状态存储在独立的缩放单元中。 考虑使用 Azure Cache for Redis 在缩放单元中进行存储，并且仅存储关键状态或同时存储在数据库中的数据。 如果发生缩放单元中断或切换到另一个缩放单元，速度可能会变慢或需要重新登录，但 Azure Cache for Redis 仍在运行。
缩放单元中不包括 Application Insights。 排除存储或监视数据的服务。 将它们划分为具有各自生命周期的资源组。
替换缩放单元或部署新缩放单元时，请保留历史数据，并为每个区域使用一个实例。
有关详细信息，请参阅 Azure 上任务关键型工作负载的应用程序设计。
组件
此体系结构使用以下组件。
- 应用程序服务是应用程序托管平台。
- Azure Cache for Redis 缓存请求。
- 应用程序配置存储配置设置。
- Azure SQL 是后端数据库。
- Application Insights 从应用程序获取遥测数据。
备选方法
在可靠的 Web 应用模式中，你可以：
- 使用 Azure Kubernetes 服务 (AKS) 而不是应用程序服务。 此选项适用于具有大量微服务的复杂工作负载。 AKS 可以更好地控制底层基础结构，并允许进行复杂的多层设置。
- 容器化工作负载。 应用程序服务支持容器化，但在此示例中，工作负载未容器化。 使用容器来提高可靠性和可移植性。
有关详细信息，请参阅 Azure 上任务关键工作负载的应用程序平台注意事项。
选择应用程序平台
可用性级别取决于应用程序平台的选择和配置。 请考虑以下任务关键型指导：
- 尽可能使用可用性区域。
- 为工作负载选择适当的平台服务。
- 容器化工作负载。
可用性集将部署分散到数据中心内的多个容错域和更新域。 可用性区域将部署分散到 Azure 区域内的各个数据中心。 可用性区域通常具有优先级，但使用哪种策略取决于工作负载。 例如，对延迟敏感或琐碎的工作负载可能会从可用性集的优先级划分中受益。 如果跨可用性区域分散工作负载，可能会增加跨区域流量的延迟和成本。 使用可用性区域时，请确保缩放单元中的所有服务都支持它们。 可靠 Web 应用模式中的所有服务都支持可用性区域。
选择数据平台
选择的数据库平台会影响整体工作负载体系结构，尤其是平台的主动-主动或主动-被动配置支持。 可靠的 Web 应用模式使用 Azure SQL，该平台本身不支持在多个实例中使用写入操作的主动-主动部署。 因此，数据库级别仅限于主动-被动策略。 如果存在只读副本并且仅写入单个区域，则可以在应用程序级别执行主动-主动策略。
下载此体系结构的 Visio 文件。
多个数据库在复杂的体系结构中很常见，例如每个服务都有一个数据库的微服务体系结构。 多个数据库允许采用 Azure Cosmos DB 等多主写入数据库，从而改善高可用性和低延迟。 跨区域延迟可能会带来一些限制。 考虑非功能性要求和一致性、可操作性、成本和复杂性等因素至关重要。 使单个服务能够使用单独的数据存储和专用数据技术来满足其独特的要求。 有关详细信息，请参阅 Azure 上任务关键工作负载的数据平台注意事项。
定义运行状况模型
在分布在多个数据中心和地理区域的复杂多层工作负载中，必须定义运行状况模型。 定义用户和系统流，指定和了解服务之间的依赖关系，了解服务中断或性能下降对整体工作负载的影响，并监视和可视化客户体验，以实现适当的监视并改进手动和自动化操作。
上图显示了单个组件（如应用程序配置）的中断或降级如何导致客户潜在的性能下降。
将组件划分为缩放单元时，可以停止将流量发送到应用程序的受影响部分，例如受影响的缩放单元或整个区域。
有关详细信息，请参阅 Azure 上任务关键型工作负载的运行状况建模和可观测性。
安全和网络
对于从本地企业部署迁移的工作负载，有严格的网络和安全要求。 并非所有已建立的本地进程都会转换为云环境。 如果这些要求适用于云环境，请对其进行评估。
标识通常是云原生模式的主要安全外围。 企业客户可能需要更实质性的安全措施。 为了满足网络安全要求，大多数 Azure PaaS 服务都可以使用 Azure 专用链接 来实施网络作为安全外围。 专用链接可以确保只能通过虚拟网络访问服务。 只能通过专用终结点访问所有服务。 下图显示了为何唯一面向 Internet 的公共终结点是 Azure Front Door。
下载此体系结构的 Visio 文件。
若要使可靠 Web 应用模式将网络设置为安全外围，它必须：
- 对支持它的所有服务使用专用链接。
- 使用 Azure Front Door 高级版作为唯一面向 Internet 的公共终结点。
- 使用跳转框以通过 Azure Bastion 访问服务。
- 使用可以访问服务的自承载生成代理。
任务关键型应用程序的另一个常见网络要求是限制出口流量，以防止数据外泄。 通过适当的防火墙设备路由 Azure 防火墙并使用设备对其进行筛选来限制出口流量。 具有网络控制的 Azure 任务关键型基线体系结构使用防火墙和专用链接。
部署和测试
对于需要始终可用的工作负载来说，错误发布或人为错误导致的停机时间可能是一个问题。 下面是需要注意的一些主要方面：
- 零停机时间部署
- 临时蓝/绿部署
- 分析各个组件的生命周期并将其分组在一起
- 持续验证
零停机时间部署是任务关键型工作负载的关键。 需要始终正常运行的工作负载无法腾出维护时段来推出较新版本。 为了绕过此限制，Azure 任务关键型体系结构遵循零停机时间部署模式。 更改作为新的缩放单元或标记推出，这些缩放单元或标记在流量以增量方式路由到它们之前经过端到端测试。 将所有流量路由到新标记后，旧标记将被禁用并删除。
有关详细信息，请参阅 Azure 上任务关键型工作负载的部署和测试。