本文提供了用于了解在单个区域中的 Azure 应用程序服务上运行 Web 应用程序的基本体系结构。
重要
此体系结构不用于生产应用程序。 它旨在作为一种介绍性体系结构，可用于学习和概念证明 (POC) 目的。 设计生产 Azure 应用服务应用程序时，请参阅基线高可用性区域冗余 Web 应用程序。
重要
该指导由一个示例实现提供支持，该示例实现展示了 Azure 上的此基本应用程序服务实现。 此实现可用作您使用 Azure 应用服务体验的 POC 的基础。
体系结构
图 1：基本 Azure 应用服务体系结构
下载此体系结构的 Visio 文件。
工作流
- 用户向 azurewebsites.net 上的应用程序服务默认域发出 HTTPS 请求。 此域自动指向您的应用程序服务的内置公共 IP。 系统建立了从客户端直接到应用程序服务的 TLS 连接。 此证书完全由 Azure 管理。
- 简易身份验证是 Azure 应用程序服务的一项功能，可确保访问站点的用户通过 Microsoft Entra ID 进行身份验证。
- 部署到应用程序服务的应用程序代码会处理该请求。 例如，该代码可能使用在配置为应用设置的应用程序服务中配置的连接字符串连接到 Azure SQL 数据库实例。
- Application Insights 中记录了有关向应用程序服务的原始请求和对 Azure SQL 数据库的调用的信息。
组件
- Microsoft Entra ID 是 Microsoft 推出的基于云的标识和访问管理服务。 它提供单个标识控制平面，可用于管理访问 Web 应用程序的用户的权限和角色。 它与应用程序服务集成，并简化了 Web 应用的身份验证和授权。
- 应用程序服务是用于构建、部署和缩放 Web 应用程序的完全托管平台。
- Azure Monitor 是一项监视服务，可收集、分析部署中的遥测数据并对其执行操作。
- Azure SQL 数据库是面向关系型数据的托管关系数据库服务。
建议和注意事项
此体系结构中列出的组件链接到 Azure Well-Architected 服务指南。 这些服务指南详细介绍了特定服务的建议和注意事项。 本部分通过重点介绍适用于此体系结构的关键 Azure Well-Architected Framework 建议和注意事项来扩展该指南。 有关详细信息，请参阅 Microsoft Azure 架构良好的框架。
此基本体系结构不适用于生产部署。 该体系结构更注重简单性和成本效益而不是功能，以便让您评估和学习 Azure 应用程序服务。 以下部分概述了此基本体系结构的一些缺陷以及建议和注意事项。
可靠性
可靠性可确保应用程序符合你对客户的承诺。 有关详细信息，请参阅可靠性设计评审核对清单。
由于此体系结构并不是针对生产部署而设计，因此下面概述了此体系结构中省略的一些关键可靠性功能：
- 为没有 Azure 可用性区域支持的
Standard层配置应用程序服务计划。 如果实例、机架或托管实例的数据中心出现问题，应用程序服务将不可用。 - 为不支持区域冗余的
Basic层配置Azure SQL 数据库。 这意味着不会跨 Azure 可用性区域复制数据，并且在发生服务中断时会面临丢失已提交数据的风险。 - 部署到此体系结构可能会导致应用程序部署停机，因为大多数部署技术需要重启所有正在运行的实例。 在此过程中，用户可能会遇到 503 错误。 可通过部署槽位在基线体系结构中解决此问题。 需要谨慎处理应用程序设计、架构管理和应用程序配置来支持并发槽位部署。 使用此 POC 设计和验证基于槽位的生产部署方法。
- 此基本体系结构中未启用自动缩放。 若要防止由于缺少可用的计算资源而出现可靠性问题，需要过度预配，以便始终使用足够的计算资源运行来处理最大并发容量。
请参阅基线高可用性区域冗余 Web 应用程序中的可靠性部分，了解如何克服这些可靠性问题。
如果此工作负荷最终需要多区域主动-主动或主动-被动体系结构，请参阅以下资源：
- 多区域App 服务应用灾难恢复方法，以指导跨多个区域部署App 服务托管工作负荷。
- 适用于遵循主动-被动方法的参考体系结构的高可用性多区域 Web 应用程序 。
安全性
安全性针对蓄意攻击及滥用宝贵数据和系统提供保障措施。 有关详细信息，请参阅可靠性设计审查检查表。
由于此体系结构并非针对生产部署而设计，因此下面概述了此体系结构中省略的一些关键安全功能，以及其他可靠性建议和注意事项：
此基本体系结构未实现网络隐私。 资源（如 Azure 应用服务和 Azure SQL Server）的数据和管理平面可通过公共 Internet 访问。 如果省略专用网络，则会显著增加体系结构的攻击面。 若要了解实现专用网络如何确保以下安全功能，请参阅基线高可用性区域冗余 Web 应用程序的网络部分：
- 客户端流量的单个安全入口点
- 系统在数据包级别和 DDoS 级别筛选网络流量。
- 通过使用专用链接将流量保留在 Azure 中，最大限度地减少数据外泄
- 网络资源通过网络分段进行逻辑分组和相互隔离。
此基本体系结构不包括 Azure Web 应用程序防火墙的部署。 此 Web 应用程序无法免受常见攻击和漏洞的侵害。 请参阅基线实现，了解如何在 Azure 应用服务体系结构中使用 Azure 应用程序网关实现 Web 应用程序防火墙。
此基本体系结构将机密（例如 Azure SQL Server 连接字符串）存储在应用设置中。 虽然应用设置已加密，但在迁移到生产环境时，请考虑在 Azure Key Vault 中存储机密以加强治理。 更好的解决方案是使用托管标识进行身份验证，而不是将机密存储在连接字符串中。
可以在开发或概念证明阶段启用远程调试和 Kudu 终结点。 迁移到生产环境时，应该禁用不必要的控制平面、部署或远程访问。
在开发或概念证明阶段，可以启用 FTP 和 SCM 站点部署的本地身份验证方法。 迁移到生产环境时，应该禁用对这些终结点的本地身份验证。
无需在概念证明阶段启用 Microsoft Defender for App Service。 迁移到生产环境时，应该启用 Defender for App Service 以生成应实施的安全建议，以改善安全状况，并检测对应用程序服务的多个威胁。
Azure 应用程序服务在子域
azurewebsites.net中免费包含一个 SSL 终结点。 默认情况下，HTTP 请求会重定向到 HTTPS 终结点。 对于生产部署，通常会在应用程序服务部署前使用与应用程序网关或 API 管理关联的自定义域。将集成的身份验证机制用于应用程序服务（“EasyAuth”）。 EasyAuth 简化了将标识提供者集成到 Web 应用的过程。 它可在 Web 应用外部处理身份验证，因此无需进行重大代码更改。
将托管标识用于工作负载标识。 使用托管标识，开关人员将无需管理身份验证凭据。 基本体系结构通过连接字符串中的密码向 SQL Server 进行身份验证。 请考虑使用托管标识向 Azure SQL Server 进行身份验证。
有关其他一些安全注意事项，请参阅保护 Azure 应用程序服务中的应用。
卓越运营
卓越运营涵盖了部署应用程序并使其在生产环境中保持运行的运营流程。 有关详细信息，请参阅设计卓越运营的审查清单。
以下部分提供有关应用程序服务应用程序的配置、监视和部署的指导。
应用配置
由于基本体系结构不适用于生产，因此它使用应用程序服务配置来存储配置值和机密。 对于 PoC 阶段，可以将机密存储在应用程序服务配置中。 你未使用真正的机密，也不需要生产工作负荷所需的机密治理。
以下是配置建议和注意事项：
- 首先使用应用程序服务配置在概念证明部署中存储配置值和连接字符串。 在启动时注入到应用中之前，系统会对应用设置和连接字符串进行加密和解密。
- 进入生产阶段时，请将机密存储在 Azure Key Vault 中。 使用 Azure Key Vault 可通过以下两种方式改进机密治理：
- 如果外部化到 Azure Key Vault 的机密存储，则可以集中存储机密。 你可以在一个位置管理机密。
- 使用 Azure Key Vault，可以记录与机密的每个交互，包括每次访问机密的时间。
- 进入生产环境时，可以使用密钥库引用来维护 Azure Key Vault 和应用程序服务配置的使用。
诊断和监控
在概念证明阶段，请务必了解可以捕获哪些日志和指标。 以下是在概念证明阶段进行监视的建议和注意事项：
- 为所有项日志源启用诊断日志记录。 配置所有诊断设置的使用有助于了解为你提供了哪些现成的日志和指标，以及在应用程序代码中使用日志记录框架需要弥补的任何差距。 迁移到生产环境时，应该消除不增加值的日志源，并将噪音和成本添加到工作负荷的日志接收器中。
- 配置日志记录以使用 Azure Log Analytics。 Azure Log Analytics 提供了一个用于集中进行易于查询的日志记录的可缩放平台。
- 使用 Application Insights 或其他应用程序性能管理 (APM) 工具发出遥测和日志来监视应用程序性能。
部署
下面列出了有关部署应用程序服务应用程序的指南。
- 按照使用 Azure Pipelines 实现 Azure Web 应用的 CI/CD 中的指导自动部署应用程序。 开始在 PoC 阶段生成部署逻辑。 如果在开发过程中尽早实现 CI/CD，则向生产环境迁移时可以快速安全地迭代应用程序。
- 使用 ARM 模板部署 Azure 资源及其依赖项。 务必在 PoC 阶段启动此过程。 在向生产环境迁移时，你希望能够自动部署基础结构。
- 使用不同的 ARM 模板并将其与 Azure DevOps 服务集成。 通过此设置，可创建不同的环境。 例如，仅在需要时才能复制类似生产的方案或负载测试环境，从而节省成本。
有关详细信息，请参阅 Azure 架构良好的框架中的“DevOps”部分。
容器
基本体系结构可用于将支持的代码直接部署到 Windows 或 Linux 实例中。 或者，应用程序服务也是用于运行容器化 Web 应用程序的容器托管平台。 应用程序服务提供各种内置容器。 如果使用自定义或多容器应用进一步微调运行时环境或支持本机不支持的代码语言，则你将需要引入容器注册表。
控制面板
在 POC 阶段，熟悉通过 Kudu 服务公开的 Azure 应用服务控制平面。 此服务公开常见的部署 API，例如 ZIP 部署，并公开原始日志和环境变量。
如果使用容器，请务必了解 Kudu 能够打开容器的 SSH 会话来支持高级调试功能。
性能效率
性能效率是指工作负荷能够以高效的方式扩展以满足用户对它的需求。 有关详细信息，请参阅性能效率设计评审核对清单。
由于此体系结构并非针对生产部署而设计，因此下面概述了此体系结构中省略的一些关键的性能效率功能，以及其他建议和注意事项。
概念证明的结果应该是你估计适合工作负荷的 SKU 选择。 工作负荷应调整应用服务计划中部署的计算实例数，通过水平缩放来有效地满足需求。 不要将系统设计为通过更改计算 SKU 来满足需求。
- 此基本体系结构中的应用程序服务未实现自动缩放。 该服务不会动态横向扩展或缩减来有效地满足需求。
- 如果需要为 SQL 数据库使用更高的服务层级或性能级别，请按照在不关闭应用程序的情况下纵向扩展单个数据库的指导进行操作。
部署此方案
该指导由一个示例实现提供支持，该示例实现展示了 Azure 上的一个基本应用程序服务实现。
后续步骤
相关资源
产品文档：
- 应用程序服务概述
- Azure Monitor 概述
- Azure 应用程序服务计划概述
- Azure Monitor 中的 Log Analytics 概述
- 什么是 Microsoft Entra ID？
- 什么是 Azure SQL 数据库？
Microsoft Learn 模块：