Azure 应用服务最佳实践

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

并置

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

• 增大资源之间通信的延迟
• 跨区域出站数据传输的收费，如 Azure 带宽定价页面所述

场地租用是最适合构成解决方案的 Azure 资源。 创建资源时，确保资源位于同一 Azure 区域，除非有具体的业务或设计理由需要将其放在不同的区域。 可使用高级应用服务计划应用可用的应用服务克隆功能，将应用服务应用移至数据库所在的区域。

证书固定

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

应用程序绝不能对默认的通配符 (*.azurewebsites.net) TLS 证书设置硬性依赖或固定绑定。 应用服务是一个平台即服务 (PaaS)，因此可以随时轮换此证书。 如果服务轮换了默认通配符 TLS 证书，则证书固定的应用程序将破坏并中断在一组特定证书属性中硬编码的应用程序的连接。 证书的轮换周期方面没有保证，因为轮换频率随时可能更改。

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

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

内存资源

如果监视或服务建议提示应用消耗的内存超出预期值，请考虑使用应用服务自动修复功能。 可以使用 web.config 配置自动修复。

自动修复功能的选项之一是根据内存阈值采取自定义操作。 这些操作的范围包括发出电子邮件通知、通过内存转储提供调查依据，以及通过回收工作进程在现场消除问题。

CPU 资源

当监视或服务建议指示应用消耗的 CPU 数超过预期，或者反复出现 CPU 高峰，请考虑纵向扩展或横向扩展应用服务计划。 如果应用程序是有状态的，则纵向扩展是唯一选项。 如果应用程序是无状态的，则横向扩展可以为你提供更多的灵活性和更高的扩展潜力。

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

套接字资源

耗尽出站 TCP 连接的一个常见原因是使用了不会复用 TCP 连接的客户端库，或者未使用诸如 HTTP keep-alive 之类的高层协议。

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

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 计算机上运行应用服务应用程序，另一个最佳做法是使用 PM2 启动多个 Node.js 进程来运行应用程序。 可以通过指定容器的启动命令来执行此操作。

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

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

应用备份

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

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

出现备份失败时，请查看最新结果以了解具体是哪种类型的故障。 如果存储访问失败，请查看并更新备份配置中的存储设置。 如果数据库访问失败，请在应用程序设置中检查并更新连接字符串。 然后继续更新备份配置，以正确包含所需的数据库。

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

Node.js 应用

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

IoT 设备

在运行连接到应用服务的物联网 (IoT) 设备时，可以改进你的环境。

对于 IoT 设备，一种常见的做法是“证书固定”。 为了避免因服务托管证书发生更改而导致任何不可预见的故障时间，切勿将证书固定为默认的 *.azurewebsites.net 证书或应用服务托管证书。 如果系统需要依赖证书固定行为，建议将自定义域添加到 Web 应用并为域提供自定义 TLS 证书。 然后，应用程序可以依赖自定义 TLS 证书进行证书固定。 有关详细信息，请参阅本文的证书固定部分。

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

在应用服务中，可将相同的自定义域添加到多个 Web 应用，但前提是这些 Web 应用托管在不同的区域。 此功能可以确保在需要固定证书时，还可以固定你提供的自定义 TLS 证书。

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

特定于资源的最佳做法

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

1. 在 Azure 门户中转到 Web 应用。

2. 通过在边栏菜单中选择诊断并解决问题，打开应用服务诊断。

3. 在搜索框中，输入 “可用性与性能最佳做法 ”或 “最佳配置 最佳做法”，以查看应用的当前状态，了解这些最佳做法。