你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
有关Azure App 服务的 Azure 良好架构框架视角（Web 应用）
Azure App 服务是一种平台即服务（PaaS）计算解决方案，可用于在 Azure 平台上托管工作负荷。 它是一项完全托管的服务，它抽象化基础计算并卸载生成、部署和缩放到平台的责任。 应用服务始终在应用服务计划中运行。 选择的服务计划确定工作负荷在其中运行的区域、计算配置和操作系统。 多个计费模型可用于App 服务。
本文假设作为架构师，你查看了计算决策树，并选择了App 服务作为工作负荷的计算。 本文中的指南提供了映射到 Azure 良好架构框架支柱原则的体系结构建议。
重要
如何使用本指南
每个部分都有一个设计检查列表，其中显示了关注的体系结构区域以及本地化为技术范围的设计策略。
还包括有关有助于具体化这些策略的技术功能的建议。 这些建议并不表示可用于Azure App 服务及其依赖项Web 应用功能的所有配置的详尽列表。 而是列出映射到设计透视的关键建议。 使用建议生成概念证明或优化现有环境。
演示关键建议的基础体系结构：App 服务基线体系结构。
技术范围
此评审重点介绍以下 Azure 资源的相关决策：
- 应用服务计划
- Web 应用
其他 Azure 产品/服务与 App 服务（例如 Azure Functions、Azure 逻辑应用 和 App 服务 环境）相关联。 这些产品/服务没有本文的范围。 偶尔会引用App 服务环境，以帮助阐明核心App 服务产品/服务的功能或选项。
可靠性
可靠性支柱的目的是通过 构建足够的复原能力和从故障中快速恢复的能力来提供持续的功能。
可靠性设计原则为各个组件、系统流和整个系统提供高级设计策略。
设计清单
根据设计评审检查可靠性列表启动设计策略。 确定其与业务需求的相关性，同时记住App 服务及其依赖项的层和功能。 扩展策略以根据需要包含更多方法。
设置用户流的优先级：并非所有流都同样重要。 为每个流分配优先级，以指导设计决策。 用户流设计可能会影响为App 服务计划和配置选择的服务层和实例数。
例如，应用程序可能包括通过消息代理进行通信的前端和后端层。 可以选择将多个 Web 应用中的层分段，以允许独立缩放、生命周期管理和维护。 将大型应用程序放在单个计划中可能会导致内存或 CPU 问题并影响可靠性。
可能需要前端上的更多实例才能在 UI 端获得最佳性能。 但是，后端可能不需要相同数量的实例。
预测潜在故障：规划潜在故障的缓解策略。 下表显示了故障模式分析的示例。
失败 缓解措施 基础组件或抽象App 服务组件的失败 在实例和依赖项中具有组件冗余。 监视实例、网络性能和存储性能的运行状况。 外部依赖项失败 使用设计模式，例如 重试模式 和 断路器模式。 监视外部依赖项并设置适当的超时。 由于流量路由到不正常的实例而失败 监视实例运行状况。 考虑响应能力，避免将请求发送到运行不正常的实例。 有关详细信息，请参阅 Azure 应用程序的故障模式分析。
生成冗余：在应用程序和支持基础结构中生成冗余。 将实例分散到可用性区域以提高容错能力。 如果一个区域发生故障，流量将路由到其他区域。 跨多个区域部署应用程序，以确保应用保持可用状态，即使整个区域遇到中断也是如此。
在依赖服务中生成类似的冗余级别。 例如，应用程序实例绑定到 Blob 存储。 如果应用程序使用区域冗余部署，请考虑使用区域冗余存储（ZRS）配置关联的存储帐户。
在网络组件中具有冗余。 例如，使用区域冗余 IP 地址和负载均衡器。
具有可靠的缩放策略：应用程序上的意外负载会使它不可靠。 根据工作负荷特征考虑正确的缩放方法。 有时可以纵向扩展以处理负载。 但是，如果负载继续增加，请横向扩展到新实例。 首选自动缩放而不是手动方法。 在缩放操作期间始终保留额外的容量缓冲区，以防止性能下降。
选择的App 服务计划层会影响实例数和计算单元数的缩放。
确保应用初始化正确，以便新实例快速预热，并且可以接收请求。
尽量争取无状态应用程序。 使用新实例可靠地缩放状态会增加复杂性。 如果需要存储应用程序状态，请考虑可以独立缩放的外部数据存储。 当应用程序或 Azure 应用服务出现问题时，将会话状态存储在内存中可能会导致会话状态丢失。 它还会限制将负载分散到其他实例的可能性。
定期测试自动缩放规则。 模拟负载方案，以验证应用是否按预期缩放。 应记录缩放事件，以便排查可能出现的问题，并随着时间的推移优化缩放策略。
App 服务对计划中实例数有限制，这可能会影响缩放可靠性。 一种策略是使用相同的部署标记，每个运行App 服务计划实例及其自己的终结点。 必须在所有标记前面加上外部负载均衡器，以跨它们分配流量。 将Azure 应用程序网关用于单区域部署，将 Azure Front Door 用于多区域部署。 此方法非常适合可靠性至关重要的任务关键型应用程序。 有关详细信息，请参阅具有App 服务的任务关键基线。
App 服务计划跨实例分配流量并监视其运行状况。 请注意，外部负载均衡器可能不会立即检测一个实例是否失败。
规划可恢复性：冗余对于业务连续性至关重要。 如果一个实例无法访问，故障转移到另一个实例。 探索App 服务中的自动修复功能，例如自动修复实例。
实现设计模式以处理暂时性故障（例如网络连接问题）和大规模事件（如区域性中断）的正常降级。 请考虑以下设计模式：
Bulkhead 模式 将应用程序细分为独立组，以防止故障影响整个系统。
基于队列的负载调配模式 队列将工作项用作缓冲区，以平整流量高峰。
重试模式处理由于网络故障、丢弃数据库连接或繁忙服务而导致的暂时性故障。
断路器模式 可防止应用程序反复尝试执行可能失败的操作。
可以使用 WebJobs 在 Web 应用中运行后台任务。 若要可靠地运行这些任务，请确保托管作业的应用按计划或基于事件驱动的触发器连续运行。
有关详细信息，请参阅 可靠性模式。
进行可靠性测试：执行负载测试以评估应用程序负载下的可靠性和性能。 测试计划应包括验证自动恢复操作的方案。
使用故障注入有意引入故障并验证自我修复和自我保护机制。 浏览 Azure Chaos Studio 提供的故障库。
App 服务对托管应用施加资源限制。 App 服务计划确定这些限制。 确保测试确认应用在这些资源限制内运行。 有关详细信息，请参阅 Azure 订阅和服务限制、配额与约束。
使用运行状况探测来识别无响应的辅助角色：App 服务具有内置功能，可定期 ping Web 应用程序的特定路径。 从负载均衡器中删除无响应实例，并替换为新实例。
建议
| 建议 | 好处 |
|---|---|
| （App 服务计划） 为生产工作负荷选择App 服务计划的高级版层。 根据容量规划设置最大和最小辅助角色数。 有关详细信息，请参阅App 服务计划概述。 |
高级App 服务计划提供高级缩放功能，并在发生故障时确保冗余。 |
| （App 服务计划） 启用区域冗余。 考虑预配三个以上的实例以提高容错能力。 检查区域对区域冗余的支持，因为并非所有区域都提供此功能。 |
当多个实例分布在多个区域时，应用程序可以承受单个区域中的故障。 如果一个区域不可用，流量会自动转移到其他区域中的正常实例，并维护应用程序可靠性。 |
| （App 服务） 请考虑禁用应用程序请求路由 （ARR） 关联功能。 ARR 相关性创建粘滞会话，用于将用户重定向到处理其先前请求的节点。 | 禁用 ARR 关联时，传入请求均匀分布在所有可用节点中。 均匀分布的请求可防止流量压倒任何单个节点。 如果节点不可用，则请求可以无缝重定向到其他正常节点。 避免会话关联，以确保App 服务实例保持无状态。 无状态App 服务可降低复杂性，并确保跨节点的行为一致。 删除粘滞会话，以便App 服务可以添加或删除实例以水平缩放。 |
| （App 服务） 根据请求计数、慢速请求、内存限制和其他属于性能基线的指示器定义自动修复规则。 将此配置视为缩放策略的一部分。 | 自动修复规则可帮助应用程序从意外问题中自动恢复。 当违反阈值时，配置的规则会触发修复操作。 自动修复可实现自动主动维护。 |
| （App 服务） 启用运行状况检查功能并提供响应运行状况检查请求的路径。 | 运行状况检查可以尽早检测问题。 然后，当运行状况检查请求失败时，系统可以自动采取纠正措施。 负载均衡器将流量从不正常的实例路由，从而将用户定向到正常运行的节点。 |
安全性
安全支柱的目的是为工作负荷提供 机密性、完整性和可用性 保证。
安全设计原则通过对托管App 服务上的技术设计方法应用方法，为实现这些目标提供了高级设计策略。
设计清单
根据安全设计评审检查列表启动设计策略，并确定漏洞和控制，以提高安全态势。 扩展策略以根据需要包含更多方法。
查看安全基线：若要增强App 服务计划中托管的应用程序的安全状况，请查看App 服务的安全基线。
使用最新的运行时和库：在进行更新之前彻底测试应用程序内部版本，以提前捕获问题，并确保顺利过渡到新版本。 App 服务支持用于更新现有堆栈和停用终止支持堆栈的语言运行时支持策略。
通过隔离边界创建分段以包含违规：应用标识分段。 例如，实现基于角色的访问控制（RBAC），以基于角色分配特定权限。 遵循最低特权原则，将访问权限限制为仅必要权限。 还可以在网络级别创建分段。 在 Azure 虚拟网络中注入App 服务应用进行隔离，并定义网络安全组（NSG）以筛选流量。
App 服务计划提供提供高度隔离的App 服务环境层。 使用 App 服务 环境，可以获得专用的计算和网络。
对标识应用访问控制：限制对 Web 应用的内向访问，以及从 Web 应用向外访问到其他资源。 此配置对标识应用访问控制，并帮助维护工作负荷的整体安全态势。
对所有身份验证和授权需求使用 Microsoft Entra ID。 使用内置角色，例如 Web 计划参与者、网站参与者和通用参与者、读者和所有者。
控制传入和传出应用程序的网络流量：不要向公共 Internet 公开应用程序终结点。 而是在放置在专用子网中的 Web 应用上添加专用终结点。 使用与该专用终结点通信的反向代理将应用程序置于前面。 请考虑出于该目的使用 应用程序网关 或 Azure Front Door。
部署 Web 应用程序防火墙（WAF），以防止常见漏洞。 应用程序网关和 Azure Front Door 都集成了 WAF 功能。
适当配置反向代理规则和网络设置，以实现所需的安全性和控制级别。 例如，在专用终结点子网上添加 NSG 规则以仅接受来自反向代理的流量。
从应用程序流出到其他 PaaS 服务的出口流量应通过专用终结点。 请考虑放置防火墙组件以限制流出流量到公共 Internet。 这两种方法都可防止数据外泄。
有关全面视图，请参阅App 服务网络功能。
加密数据：使用端到端传输层安全性保护传输中的数据（TLS）。 使用客户管理的密钥对静态数据进行完全加密。 有关详细信息，请参阅 使用客户管理的密钥进行静态加密。
请勿使用旧版协议，例如 TLS 1.0 和 1.1。 默认情况下，App 服务启用 1.2。 有关详细信息，请参阅 App 服务 TLS 概述。
App 服务的所有实例都具有默认域名。 使用自定义域并保护具有证书的域。
减少攻击面：删除不需要的默认配置。 例如，禁用远程调试、源代码管理管理器（SCM）站点的本地身份验证和基本身份验证。 禁用不安全的协议，如 HTTP 和文件传输协议（FTP）。 通过 Azure 策略强制实施配置。 有关详细信息，请参阅 Azure 策略。
实现限制性的跨域资源共享（CORS）策略：在 Web 应用中使用限制性的 CORS 策略仅接受来自允许域、标头和其他条件的请求。 使用内置的 Azure 策略定义强制实施 CORS 策略。
保护应用程序机密：需要处理敏感信息，例如 API 密钥或身份验证令牌。 可以在应用设置中使用 Azure 密钥库引用，而不是将这些机密直接编码到应用程序代码或配置文件中。 应用程序启动时，App 服务通过使用应用的托管标识自动从密钥库检索机密值。
为应用程序启用资源日志：为应用程序启用资源日志，以创建全面的活动线索，以便在调查期间提供有价值的数据，这些数据遵循安全事件。
评估威胁时，请考虑将日志记录作为威胁建模过程的一部分。
建议
| 建议 | 好处 |
|---|---|
| （App 服务） 将托管标识分配给 Web 应用。 若要维护隔离边界，请不要在应用程序之间共享或重复使用标识。 如果使用容器进行部署，请确保 安全地连接到容器注册表 。 |
应用程序从密钥库检索机密，以验证来自应用程序的外向通信。 Azure 管理标识，不需要预配或轮换任何机密。 具有不同的标识，用于控制粒度。 如果标识遭到入侵，不同的标识会使吊销变得容易。 |
| （App 服务） 为应用程序配置自定义域。 禁用 HTTP 并仅接受 HTTPS 请求。 |
自定义域使用传输层安全性 （TLS） 协议通过 HTTPS 实现安全通信，这可以确保敏感数据的保护并生成用户信任。 |
| （App 服务） 是否对App 服务内置身份验证是对访问应用程序的用户进行身份验证的正确机制。 App 服务内置身份验证与 Microsoft Entra ID 集成。 此功能跨多个登录提供程序处理令牌验证和用户标识管理，并支持 OpenID 连接。 使用此功能时，你没有精细级别的授权，并且没有测试身份验证的机制。 | 使用此功能时，无需在应用程序代码中使用身份验证库，从而减少复杂性。 请求到达应用程序时，用户已进行身份验证。 |
| （App 服务） 配置应用程序进行虚拟网络集成。 对App 服务应用使用专用终结点。 阻止所有公共流量。 路由 容器映像拉取通过虚拟网络 集成。 来自应用程序的所有传出流量都通过虚拟网络传递。 |
获取使用 Azure 虚拟网络的安全优势。 例如，应用程序可以安全地访问网络中的资源。 添加专用终结点以帮助保护应用程序。 专用终结点会限制直接公开到公共网络，并允许通过反向代理进行受控访问。 |
| （App 服务） 实现强化： - 禁用使用用户名和密码的基本身份验证 ，以支持基于 Microsoft Entra ID 的身份验证。 - 关闭远程调试，以便不会打开入站端口。 - 启用 CORS 策略 以收紧传入请求。 - 禁用协议，例如 FTP。 |
不建议使用基本身份验证作为安全部署方法。 Microsoft Entra ID 采用基于 OAuth 2.0 令牌的身份验证，它提供了许多优势和增强功能，解决了与基本身份验证相关的限制。 策略限制对应用程序资源的访问，仅允许来自特定域的请求，以及保护跨区域请求。 |
| （App 服务） 始终使用密钥库引用作为应用设置。 |
机密与应用的配置分开。 应用设置是静态加密的。 App 服务还管理机密轮换。 |
| （App 服务计划） 启用 Microsoft Defender for Cloud for App 服务。 | 获取对在App 服务计划中运行的资源的实时保护。 防范威胁，增强整体安全态势。 |
| （App 服务计划） 启用诊断日志记录并将检测添加到应用。 日志将发送到Azure 存储帐户、Azure 事件中心和 Log Analytics。 有关审核日志类型的详细信息，请参阅 支持的日志类型。 | 日志记录捕获访问模式。 它记录相关事件，这些事件提供有关用户与应用程序或平台交互方式的宝贵见解。 此信息对于责任、合规性和安全目的至关重要。 |
成本优化
成本优化侧重于 检测支出模式、优先考虑关键领域的投资，并优化其他 领域以满足组织预算，同时满足业务需求。
成本优化设计原则为实现这些目标并提供高级设计策略，并在与 Web 应用及其运行环境相关的技术设计中根据需要进行权衡。
设计清单
根据投资成本优化的设计评审检查列表开始设计策略，并微调设计，使工作负荷与为工作负荷分配的预算保持一致。 设计应使用正确的 Azure 功能，监视投资，并查找随时间推移进行优化的机会。
估算初始成本：作为成本建模练习的一部分，使用 Azure 定价计算器 根据计划运行的实例数评估与各个层关联的近似成本。 每个App 服务层提供不同的计算选项。
持续监视成本模型以跟踪支出。
评估折扣选项：较高层包括专用计算实例。 如果工作负荷具有可预测的且一致的使用模式，则可以应用预留折扣。 请确保分析使用情况数据，以确定适合工作负荷的预留类型。 有关详细信息，请参阅使用App 服务预留实例节省成本。
了解使用情况计量：Azure 根据App 服务计划的定价层按小时费率按比例计算为第二。 根据分配 VM 实例的时间，费用适用于计划中的每个横向扩展实例。 请注意由于选择欠佳 SKU 或配置不当而增加成本的未充分利用计算资源。
额外的App 服务功能（如自定义域注册和自定义证书）可能会增加成本。 其他资源（如虚拟网络）隔离解决方案或密钥保管库以保护工作负荷机密，与App 服务资源集成还可以增加成本。 有关详细信息，请参阅App 服务计费模型。
考虑密度与隔离之间的权衡：可以使用App 服务计划在同一计算中托管多个应用程序，从而节省共享环境的成本。 有关详细信息，请参阅 “权衡”。
评估缩放策略对成本的影响：必须在实现自动缩放时正确设计、测试和配置横向扩展和缩减。 建立自动缩放的精确最大值和最小限制。
主动初始化应用程序以实现可靠的缩放。 例如，不要等到 CPU 使用率达到 95%。 相反，触发缩放大约 65% 以允许在缩放过程中分配和初始化新实例的足够时间。 但是，此策略可能会导致未使用的容量。
建议合并和平衡用于纵向扩展和横向扩展的机制。例如，应用可以纵向扩展一段时间，然后根据需要进行横向扩展。 探索提供大容量和高效资源使用情况的高层。 根据使用模式，更高的高级版层通常更具成本效益，因为它们更有能力。
优化环境成本：考虑基本层或免费层以运行预生产环境。 这些层的性能较低，成本较低。 如果使用“基本”或“免费”层，请使用治理来强制实施层、限制实例数和 CPU 数、限制缩放和限制日志保留。
实现设计模式：此策略可减少工作负荷生成的请求量。 请考虑使用前端模式和网关聚合模式等模式，从而最大程度地减少请求数并降低成本。
定期检查与数据相关的成本：延长的数据保留期或昂贵的存储层可能会导致较高的存储成本。 由于带宽使用量和日志记录数据的长时间保留，可能会累积更多费用。
考虑实现缓存以最大程度地降低数据传输成本。 从本地内存中缓存开始，然后浏览分布式缓存选项以减少后端数据库的请求数。 如果数据库位于其他区域，请考虑与跨区域通信关联的带宽流量成本。
优化部署成本：利用部署槽位来优化成本。 槽在与生产实例相同的计算环境中运行。 在策略上将它们用于在槽之间切换的蓝绿部署等方案。 此方法可最大程度地减少停机时间，并确保平稳过渡。
请谨慎使用部署槽位。 可以引入可能影响现有实例和新实例的问题，例如异常或内存泄漏。 请确保彻底测试更改。 有关操作指南，请参阅 卓越运营。
建议
| 建议 | 好处 |
|---|---|
| （App 服务计划） 为较低环境选择“免费”或“基本”层。 建议使用这些层进行实验性使用。 不再需要层时，请删除这些层。 | 与较高层相比，免费层和基本层是预算友好的。 它们为不需要高级计划的完整功能和性能的非生产环境提供经济高效的解决方案。 |
| （App 服务计划） 利用折扣并探索首选定价： - 使用 开发/测试计划降低环境。 - Azure 预留和 Azure 节省用于在 高级版 V3 层和App 服务环境中预配的专用计算计划。 对具有可预测使用模式的稳定工作负荷使用预留实例。 |
开发/测试计划为 Azure 服务提供更低的费率，这使得它们对非生产环境具有成本效益。 使用预留实例预付计算资源费用，并获得重大折扣。 |
| （App 服务） 监视App 服务资源产生的成本。 在Azure 门户中运行成本分析工具。 创建预算和警报 以通知利益干系人。 |
可以提前确定成本峰值、效率低下或意外支出。 这种主动方法可帮助你提供预算控制，以防止超支。 |
| （App 服务计划） 需求减少时缩小规模。 若要缩减，请定义缩放规则以减少 Azure Monitor 中的实例数。 | 防止浪费并减少不必要的费用。 |
卓越运营
卓越运营主要侧重于开发 实践、可观测性和发布管理的过程。
卓越运营设计原则提供了一种高级设计策略，用于实现这些目标以满足工作负荷的操作要求。
设计清单
根据针对 Operational Excellence 的设计评审检查列表启动设计策略，以定义与Web 应用相关的可观测性、测试和部署过程。
管理版本：使用部署槽位有效地管理发布。 可以将应用程序部署到槽位、执行测试并验证其功能。 验证后，可以无缝地将应用移动到生产环境。 此过程不会产生额外的成本，因为槽与生产实例在同一虚拟机（VM）环境中运行。
运行自动测试：在提升 Web 应用的发布之前，请全面测试其性能、功能和与其他组件的集成。 使用 Azure 负载测试，它与 Apache JMeter 集成，这是一种用于性能测试的常用工具。 探索用于其他类型的测试的自动化工具，例如用于功能测试的幻影。
部署不可变单元：实现部署标记模式，将App 服务隔离为不可变标记。 App 服务支持使用本质上是不可变的容器。 请考虑为 App 服务 Web 应用自定义容器。
每个印章表示一个独立单元，你可以快速横向扩展或横向扩展。 基于此标记的单位是临时的和无状态的。 无状态设计简化了操作和维护。 此方法非常适合任务关键型应用程序。 有关示例，请参阅具有App 服务的任务关键基线。
使用基础结构即代码（IaC）技术（如 Bicep）来淘汰具有可重复性和一致性的单元。
确保生产环境安全：创建单独的App 服务计划来运行生产和预生产环境。 不要直接在生产环境中进行更改，以确保稳定性和可靠性。 在将更改提升到生产环境之前，单独的实例可以灵活地进行开发和测试。
使用低环境以隔离的方式探索新功能和配置。 保持开发和测试环境暂时性。
管理证书：对于自定义域，需要管理 TLS 证书。
制定流程来采购、续订和验证证书。 如果可能，将这些进程卸载到App 服务。 如果使用自己的证书，则必须管理其续订。 选择最符合安全要求的方法。
| 建议 | 好处 |
|---|---|
| （App 服务） 监视实例的运行状况并激活实例运行状况探测。 设置用于处理运行状况探测请求的特定路径。 |
可以及时检测问题，并采取必要的措施维护可用性和性能。 |
| （App 服务） 为应用程序和实例启用诊断日志。 频繁的日志记录可能会降低系统的性能，增加存储成本，并在对日志进行不安全访问时带来风险。 遵循以下最佳做法： - 记录正确的信息级别。 - 设置保留策略。 - 保留授权访问和未经授权的尝试的审核线索。 - 将日志视为数据并应用数据保护控件。 |
诊断日志提供对应用行为的宝贵见解。 监视流量模式并识别异常。 |
| （App 服务） 利用App 服务托管证书，将认证管理卸载到 Azure。 | App 服务自动处理证书采购、证书验证、证书续订和从密钥库导入证书等过程。 或者，将证书上传到密钥库，并授权App 服务资源提供程序访问它。 |
| （App 服务计划） 在将应用交换到生产槽之前，先验证过渡槽中的应用更改。 | 避免停机和错误。 如果在交换后检测到问题，快速还原到最后一个已知良好状态。 |
性能效率
性能效率与保持用户体验有关 ，即使通过管理容量增加负载 也是如此。 该策略包括缩放资源、识别和优化潜在瓶颈，以及优化峰值性能。
性能效率设计原则提供了一种高级设计策略，用于针对预期使用情况实现这些容量目标。
设计清单
根据设计评审检查列表启动设计策略，以便根据Web 应用的关键绩效指标定义基线。
确定和监视性能指标：为应用程序的关键指标设置目标，例如传入请求量、应用程序响应请求所需的时间、挂起的请求和 HTTP 响应中的错误。 将关键指标视为工作负荷性能基线的一部分。
捕获构成性能指标基础的App 服务指标。 收集日志以获取资源使用情况和活动见解。 使用应用程序性能监视（APM）工具（如 Application Insights）从应用程序收集和分析性能数据。 有关详细信息，请参阅App 服务监视数据参考。
包括代码级检测、事务跟踪和性能分析。
评估容量：模拟各种用户方案，以确定处理预期流量所需的最佳容量。 使用负载测试了解应用程序在不同负载级别下的行为方式。
选择适当的层：对生产工作负荷使用专用计算。 高级版层提供更大的 SKU，内存和 CPU 容量增加，实例更多，以及更多功能，例如区域冗余。 有关详细信息，请参阅 高级版 V3 定价层。
优化缩放策略：尽可能使用 自动缩放 ，而不是在应用程序加载更改时手动调整实例数。 通过自动缩放，App 服务根据预定义的规则或触发器调整服务器容量。 请确保执行足够的性能测试，并为正确的触发器设置正确的规则。
如果在初始设置过程中优先考虑简单性，请使用不需要定义规则且只需设置限制的自动缩放选项。
有足够的资源可供使用，以确保最佳性能。 适当分配资源以维护性能目标，例如响应时间或吞吐量。 如有必要，请考虑过度分配资源。
定义自动缩放规则时，请考虑到应用程序初始化所需的时间。 在做出所有缩放决策时，请考虑此开销。
使用缓存：从不频繁更改且访问成本高昂的资源检索信息会影响性能。 复杂的查询（包括联接和多个查找）有助于运行时。 执行缓存以最大程度地减少处理时间和延迟。 缓存查询结果，以避免重复往返数据库或后端，并减少后续请求的处理时间。
有关在工作负荷中使用本地缓存和分布式缓存的详细信息，请参阅 缓存。
查看性能反模式：若要确保 Web 应用程序按照业务需求执行和缩放，请避免 典型的反模式。 下面是App 服务更正的一些反模式。
反模式 说明 繁忙前端 资源密集型任务可能增大用户请求的响应时间，使延迟提高。
将消耗大量资源的进程移到独立的后端。 使用消息中转站将后端提取到异步处理的资源密集型任务排队。无缓存 在后端数据库前提供来自中间缓存的请求，以减少延迟。 近邻干扰 多租户系统在租户之间共享资源。 一个租户的活动可能会对另一个租户使用系统产生负面影响。 App 服务环境提供了一个完全隔离且专用的环境，用于运行App 服务应用。
建议
| 建议 | 好处 |
|---|---|
| 当应用程序共享单个App 服务计划时启用 AlwaysOn 设置。 App 服务应用在空闲时自动卸载以节省资源。 下一个请求触发冷启动，这可能会导致请求超时。 | 在启用 AlwaysOn 的情况下，永远不会卸载该应用程序。 |
| 请考虑对应用程序使用 HTTP/2 来提高协议效率。 | 选择 HTTP/2 over HTTP/1.1，因为 HTTP/2 完全多路复用连接、重复使用连接以减少开销，并压缩标头以最大程度地减少数据传输。 |
权衡
如果使用支柱检查列表中的方法，可能需要进行设计权衡。 下面是一些优点和缺点示例。
密度和隔离
更高的密度：在同一App 服务计划内并置多个应用，以最大程度地减少资源。 所有应用共享 CPU 和内存等资源，从而节省资金并减少操作复杂性。 此方法还优化了资源使用情况。 如果负载模式随时间变化，应用可以使用另一个应用中的空闲资源。
另请考虑缺点。 例如，应用使用或不稳定的峰值可能会影响其他应用的性能。 一个应用中的事件还可以渗透到共享环境中的其他应用，这可能会影响安全性。
更高的隔离：隔离有助于避免干扰。 此策略适用于开发、测试和生产环境的安全性、性能甚至隔离。
App 服务环境可以更好地控制安全和数据保护，因为每个应用都可以有自己的安全设置。 你的环境可以包含违规，因为隔离会限制爆炸半径。 从性能的角度来看，资源争用已最小化。 隔离允许根据特定需求和单个容量规划进行独立缩放。
作为一个缺点，这种方法的成本更高，需要操作严格。
可靠的缩放策略
定义完善的缩放策略可确保应用程序可以处理各种负载，而不会影响性能。 但是，成本有权衡。 缩放操作需要一段时间。 分配新资源时，必须先正确初始化应用程序，然后才能有效地处理请求。 可以过度预配资源（预热实例），以提供安全网。 如果没有额外的容量，在初始化阶段，服务请求可能会延迟，这会影响用户体验。 自动缩放操作可能提前触发，以便在客户使用资源时启用适当的资源初始化。
作为缺点，过度预配的资源成本更高。 每个实例（包括预热的实例）按秒收费。 较高层包括预热的实例。 确定具有更昂贵层的功能是否值得投资。
构建冗余
冗余提供复原能力，但也会产生成本。 工作负荷的服务级别目标（SLO）决定了可接受的性能阈值。 如果冗余超过 SLO 要求，则会浪费它。 评估多余的冗余是提高 SLO 还是增加了不必要的复杂性。
另请考虑缺点。 例如，多区域冗余提供高可用性，但由于数据同步、故障转移机制和区域间通信，增加了复杂性和成本。 确定区域冗余是否可以满足 SLO。
Azure 策略
Azure 提供了一组与App 服务及其依赖项相关的大量内置策略。 一组 Azure 策略可以审核上述一些建议。 例如，可以检查是否：
适当的网络控制已到位。 例如，可以通过虚拟网络注入将App 服务置于 Azure 虚拟网络，从而更好地控制网络配置，从而合并网络分段。 应用程序没有公共终结点，并且通过专用终结点连接到 Azure 服务。
标识控件已到位。 例如，应用程序使用托管标识对其他资源自行进行身份验证。 App 服务内置身份验证（Easy Auth）验证传入的请求。
禁用远程调试和基本身份验证等功能，以减少攻击面。
若要进行全面的治理，请查看 Azure Policy 内置定义 和其他可能影响计算层安全性的策略。
Azure 顾问建议
Azure 顾问是个性化的云顾问程序，可帮助遵循最佳做法来优化 Azure 部署。 下面是一些建议，可帮助你提高 Web 应用程序实例的可靠性、安全性、成本效益、性能和卓越运营能力。
后续步骤
将以下文章视为演示本文中突出显示的建议的资源。
使用这些参考体系结构作为如何将这些建议应用于工作负荷的示例。
如果从未部署过 Web 应用，请参阅 基本 Web 应用程序。
有关基础体系结构作为生产级部署的起点，请参阅 基线高度可用的区域冗余 Web 应用程序。
使用以下产品文档生成实施专业知识：