有关 Azure 应用服务的最佳实践Best Practices for Azure App Service

本文汇总了有关使用 Azure App Service 的最佳实践。This article summarizes best practices for using Azure App Service.

共置Colocation

如果将编写解决方案(例如 Web 应用和数据库)的 Azure 资源定位在不同的区域,可能产生以下影响:When Azure resources composing a solution such as a web app and a database are located in different regions, it can have the following effects:

  • 增大资源之间通信的延迟Increased latency in communication between resources
  • Azure 定价页中列出了跨区域出站数据传输的收费。Monetary charges for outbound data transfer cross-region as noted on the Azure pricing page.

相同区域中的共置最适合用于组成解决方案的 Azure 资源(例如 Web 应用),以及用于保存内容或数据的数据库或存储帐户。Colocation in the same region is best for Azure resources composing a solution such as a web app and a database or storage account used to hold content or data. 创建资源时,确保它们位于同一个 Azure 区域,除非有具体的业务或设计理由需要将它们放在不同的区域。When creating resources, make sure they are in the same Azure region unless you have specific business or design reason for them not to be. 可使用高级应用服务计划应用当前可用的应用服务克隆功能,将应用服务应用移至数据库所在的区域。You can move an App Service app to the same region as your database by using the App Service cloning feature currently available for Premium App Service Plan apps.

当应用消耗的内存超出预期时When apps consume more memory than expected

如果通过监视或者参考服务建议,发现应用消耗的内存超出指定的预期值,请考虑使用应用服务自动修复功能When you notice an app consumes more memory than expected as indicated via monitoring or service recommendations, consider the App Service Auto-Healing feature. 自动修复功能的选项之一是根据内存阈值采取自定义操作。One of the options for the Auto-Healing feature is taking custom actions based on a memory threshold. 这些操作的范围包括发出电子邮件通知、通过内存转储提供调查依据,以及通过回收工作进程在现场消除问题。Actions span the spectrum from email notifications to investigation via memory dump to on-the-spot mitigation by recycling the worker process. 可以根据这篇有关 应用服务支持站点扩展的博文中所述,通过 web.config 或者友好的用户界面来配置自动修复。Auto-healing can be configured via web.config and via a friendly user interface as described at in this blog post for the App Service Support Site Extension.

当应用消耗的 CPU 超出预期时When apps consume more CPU than expected

如果通过监视或者参考服务建议,发现应用消耗的 CPU 超出预期,或者反复出现 CPU 高峰,请考虑向上缩放或向外缩放应用服务计划。When you notice an app consumes more CPU than expected or experiences repeated CPU spikes as indicated via monitoring or service recommendations, consider scaling up or scaling out the App Service plan. 如果应用程序是有状态的,则纵向扩展是唯一选项;如果应用程序是无状态的,则横向扩展提供更高的灵活性和更大的缩放潜力。If your application is stateful, scaling up is the only option, while if your application is stateless, scaling out gives you more flexibility and higher scale potential.

当套接字资源耗尽时When socket resources are exhausted

耗尽出站 TCP 连接的一个常见原因是使用的客户端库,未实施为重复使用 TCP 连接,或者使用了较高级别的协议(如 HTTP),因而未使用 Keep-Alive。A common reason for exhausting outbound TCP connections is the use of client libraries, which are not implemented to reuse TCP connections, or when a higher-level protocol such as HTTP - Keep-Alive is not used. 请查看应用服务计划中的应用引用的每个库,以确保在代码中配置或访问这些库时,能够有效地重复使用出站连接。Review the documentation for each of the libraries referenced by the apps in your App Service Plan to ensure they are configured or accessed in your code for efficient reuse of outbound connections. 此外,请遵循有关正确执行创建和发布或清理操作的库指导文档,以避免连接泄漏。Also follow the library documentation guidance for proper creation and release or cleanup to avoid leaking connections. 在展开此类客户端库调查的过程中,可以通过向外扩展到多个实例来消除影响。While such client libraries investigations are in progress, impact may be mitigated by scaling out to multiple instances.

Node.js 和传出 http 请求Node.js and outgoing http requests

使用 Node.js 和许多传出 http 请求时,处理 HTTP(保持活动状态)很重要。When working with Node.js and many outgoing http requests, dealing with HTTP - Keep-Alive is important. 可以使用 agentkeepalive npm 包更容易地在代码中实现此功能。You can use the agentkeepalive npm package to make it easier in your code.

始终处理 http 响应,即使在处理程序中不执行任何操作,也要如此。Always handle the http response, even if you do nothing in the handler. 如果未正确处理响应,由于没有更多套接字可用,最终应用程序会停止响应。If you don't handle the response properly, your application gets stuck eventually because no more sockets are available.

例如,使用 httphttps 包时:For example, when working with the http or https package:

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

如果在具有多个核心的计算机中的 Linux 应用服务 上运行,另一种最佳做法是使用 PM2 启动多个 Node.js 进程执行应用程序。If you are running on App Service on Linux on a machine with multiple cores, another best practice is to use PM2 to start multiple Node.js processes to execute your application. 可以通过指定容器的启动命令来执行此操作。You can do it by specifying a startup command to your container.

例如,若要启动四个实例:For example, to start four instances:

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

当应用备份开始失败时When your app backup starts failing

应用备份失败的两个最常见原因:存储设置无效和数据库配置无效。The two most common reasons why app backup fails are: invalid storage settings and invalid database configuration. 这些失败通常发生在对存储或数据库资源或其访问方式进行了更改(例如更新了备份设置中所选数据库的凭据)时。These failures typically happen when there are changes to storage or database resources, or changes for how to access these resources (for example, credentials updated for the database selected in the backup settings). 备份通常按计划运行并且只需访问存储(以便输出备份后的文件)和数据库(以便复制和读取备份中要包含的内容)。Backups typically run on a schedule and require access to storage (for outputting the backed-up files) and databases (for copying and reading contents to be included in the backup). 其中任一资源访问失败会导致持续备份失败。The result of failing to access either of these resources would be consistent backup failure.

出现备份失败时,请查看最新结果以了解所出现失败的类型。When backup failures happen, review most recent results to understand which type of failure is happening. 如果存储访问失败,请查看并更新备份配置中使用的存储设置。For storage access failures, review and update the storage settings used in the backup configuration. 如果数据库访问失败,请查看并更新应用设置中的连接字符串,然后继续将备份配置更新为正确地包括所需数据库。For database access failures, review and update your connections strings as part of app settings; then proceed to update your backup configuration to properly include the required databases. 有关应用备份的详细信息,请参阅在 Azure 应用服务中备份 Web 应用For more information on app backups, see Back up a web app in Azure App Service.

当新的 Node.js 应用部署到 Azure 应用服务时When new Node.js apps are deployed to Azure App Service

适用于 Node.js 应用的 Azure 应用服务默认配置旨在符合最常见应用的需求。Azure App Service default configuration for Node.js apps is intended to best suit the needs of most common apps. 如果 Node.js 应用的配置可从个性化调整中受益,并提高性能或优化 CPU /内存/网络资源的资源使用情况,请参阅有关 Azure 应用服务上节点应用程序的最佳做法和故障排除指南If configuration for your Node.js app would benefit from personalized tuning to improve performance or optimize resource usage for CPU/memory/network resources, see Best practices and troubleshooting guide for Node applications on Azure App Service. 本文介绍了可能需要为 Node.js 应用配置的 iisnode 设置,描述了应用可能面临的各种情况或问题,并说明了如何解决这些问题。This article describes the iisnode settings you may need to configure for your Node.js app, describes the various scenarios or issues that your app may be facing, and shows how to address these issues.