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