你当前正在访问 Microsoft Azure Global Edition 技术文档网站。如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

Azure App 服务最佳做法

项目
01/10/2024

本文汇总了有关使用 Azure 应用服务的最佳实践。

并置

Azure App 服务解决方案包括用于保存内容或数据的 Web 应用和数据库或存储帐户。当这些资源位于不同的区域时，情况可能会产生以下影响：

增大资源之间通信的延迟
Azure 定价页上所述，跨区域出站数据传输的货币费用

归置最适合构成解决方案的 Azure 资源。创建资源时，请确保它们位于同一 Azure 区域，除非有特定的业务或设计原因，否则它们不会成为。可以使用高级版 App 服务计划中提供的App 服务克隆功能，将App 服务应用移动到数据库所在的同一区域。

证书固定

证书固定是一种做法，即应用程序仅允许特定列表的可接受证书颁发机构（CA）、公钥、指纹或证书层次结构的任何部分。

应用程序绝不应具有硬依赖项或固定到默认的 wild卡（*.azurewebsites.net） TLS 证书。 App 服务是一个平台即服务（PaaS），因此可以随时轮换此证书。如果服务轮换默认的 wild卡 TLS 证书，证书固定的应用程序将中断并中断硬编码到特定证书属性集的应用程序的连接。证书轮换的周期性也不保证，因为轮换频率可以随时更改。

依赖于证书固定的应用程序也不应对App 服务托管证书有硬依赖关系。 App 服务托管证书随时可以轮换，从而导致依赖于稳定证书属性的应用程序出现类似问题。最佳做法是为依赖于证书固定的应用程序提供自定义 TLS 证书。

如果应用程序需要依赖证书固定行为，建议将自定义域添加到 Web 应用并为域提供自定义 TLS 证书。然后，应用程序可以依赖自定义 TLS 证书进行证书固定。

内存资源

当监视或服务建议指示应用消耗的内存超过预期时，请考虑App 服务自动修复功能。可以使用 web.config 配置自动修复。

自动修复功能的选项之一是基于内存阈值执行自定义操作。操作范围从电子邮件通知到通过内存转储到现场缓解（通过回收工作进程）进行调查。

CPU 资源

当监视或服务建议指示应用消耗的 CPU 数超过预期，或者遇到重复的 CPU 峰值时，请考虑纵向扩展或横向扩展App 服务计划。如果应用程序是有状态的，则纵向扩展是唯一选项。如果应用程序是无状态的，则横向扩展可提供更大的灵活性和更高的缩放潜力。

有关App 服务缩放和自动缩放选项的详细信息，请参阅在Azure App 服务中纵向扩展应用。

套接字资源

耗尽出站 TCP 连接的常见原因是使用客户端库，这些库不会重复使用 TCP 连接，或者不使用更高级别的协议（如 HTTP 保持连接）。

查看App 服务计划参考中应用的每个库的文档。确保在代码中配置或访问库，以便高效重复使用出站连接。此外，请遵循有关正确执行创建和发布或清理操作的库指导文档，以避免连接泄漏。虽然对客户端库的此类调查正在进行中，但可以通过横向扩展到多个实例来缓解影响。

Node.js 和传出 HTTP 请求

使用 Node.js 和许多传出 HTTP 请求时，处理 HTTP 保持活动非常重要。可以使用 agentkeepalivenpm 包更容易地在代码中实现此功能。

始终处理 http 响应，即使在处理程序中不执行任何操作，也要如此。如果未正确处理响应，应用程序最终会卡住，因为没有更多的套接字可用。

下面是在处理 http 或 https 包时处理响应的示例：

const request = https.request(options, function(response) {
    response.on('data', function() { /* do nothing */ });
});

如果要在具有多个核心的 Linux 计算机上运行App 服务应用，另一种最佳做法是使用 PM2 启动多个 Node.js 进程来运行应用程序。可以通过指定容器的启动命令来执行此操作。

例如，使用此命令启动四个实例：

pm2 start /home/site/wwwroot/app.js --no-daemon -i 4

应用备份

备份通常按计划运行并且只需访问存储（以便输出备份后的文件）和数据库（以便复制和读取备份中要包含的内容）。访问其中任一资源失败的结果是一致的备份失败。

应用备份失败的两个最常见原因是存储设置无效和数据库配置无效。这些失败通常发生在对存储或数据库资源的更改之后，或者在访问这些资源的凭据更改之后发生。例如，可能会在备份设置中选择的数据库更新凭据。

发生备份失败时，请查看最新的结果，以了解发生哪种类型的故障。对于存储访问失败，请查看和更新备份配置中的存储设置。对于数据库访问失败，请查看并更新连接字符串作为应用设置的一部分。然后继续更新备份配置，以正确包含所需的数据库。

有关应用备份的详细信息，请参阅在Azure App 服务中备份和还原应用。

Node.js 应用

Node.js 应用的Azure App 服务默认配置最适合最常见的应用的需求。若要个性化 Node.js 应用的默认配置以提高性能或优化 CPU、内存或网络资源的资源使用情况，请参阅有关 Azure App 服务上的 Node 应用程序的最佳做法和故障排除指南。本文介绍可能需要为 Node.js 应用配置的 iisnode 设置。它还介绍了如何解决应用的方案或问题。

IoT 设备

运行连接到App 服务的物联网（IoT）设备时，可以改善环境。

IoT 设备的一种常见做法是证书固定。为了避免由于服务托管证书更改而导致的任何意外停机，不应将证书固定到默认*.azurewebsites.net证书或App 服务托管证书。如果你的系统需要依赖证书固定行为，我们建议将自定义域添加到 Web 应用并为域提供自定义 TLS 证书。然后，应用程序可以依赖自定义 TLS 证书进行证书固定。有关详细信息，请参阅本文的证书固定部分。

若要提高环境中的复原能力，请不要依赖于所有设备的单个终结点。在至少两个区域中托管 Web 应用，以避免单一故障点，并准备好故障转移流量。

在App 服务中，只要这些 Web 应用托管在不同的区域中，就可以向多个 Web 应用添加相同的自定义域。此功能可确保如果需要固定证书，还可以固定提供的自定义 TLS 证书。

另一个选项是在 Web 应用（例如 Azure Front Door 或 Azure 流量管理器）前面使用负载均衡器，以确保 Web 应用的高可用性。有关详细信息，请参阅快速入门：为高度可用的全局 Web 应用程序创建 Front Door 实例，或使用Azure 流量管理器控制Azure App 服务流量。

后续步骤

若要获取特定于资源的可操作最佳做法，请使用App 服务诊断：

转到Azure 门户中的 Web 应用。
选择“诊断”并在左侧窗格中解决问题，打开App 服务诊断。
选择“最佳做法”磁贴。
选择 “可用性与性能 最佳做法”或 “最佳配置 最佳做法”以查看应用当前状态，了解这些最佳做法。

还可以使用此链接直接打开资源的App 服务诊断： https://portal.azure.com/?websitesextension_ext=asd.featurePath%3Ddetectors%2FParentAvailabilityAndPerformance#@microsoft.onmicrosoft.com/resource/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Web/sites/{siteName}/troubleshoot