共用方式為


Azure App Service 的最佳做法

本文將摘要說明使用 Azure App Service的最佳作法。

共置

Azure App Service 解決方案包含用於儲存內容或資料的 Web 應用程式和資料庫或儲存體帳戶。 當這些資源位於不同的區域時,這個情況可能會產生下列影響:

  • 資源之間的通訊延遲更久
  • 跨區域的輸出資料傳輸需要收費,如 Azure 價格頁面所示

對於構成解決方案的 Azure 資源而言,共置是最佳選擇。 建立資源時,除非您有特定的商務或設計理由,否則請確定這些資源都位於相同的 Azure 區域。 您可以使用進階 App Service 方案可用的 App Service 複製功能,將 App Service 應用程式移至資料庫所在的相同區域。

憑證關聯

憑證關聯是一種做法,即應用程式只允許特定可接受憑證授權 (CA)、公開金鑰及指紋的清單,或憑證階層的任何部分。

應用程式不應該具有硬式相依性或釘選到預設萬用字元 (*.azurewebsites.net) TLS 憑證。 App Service 是平台即服務 (PaaS),因此您可以隨時輪替此憑證。 如果服務會輪替預設萬用字元 TLS 憑證,則憑證關聯的應用程式會中斷並干擾硬式編碼至特定憑證屬性集合的應用程式連線。 輪替憑證也不保證週期性,因為輪替頻率可以隨時變更。

依賴憑證關聯的應用程式也不應該硬式依賴 App Service 受控憑證。 App Service 受控憑證可以隨時輪替,導致依賴穩定憑證屬性的應用程式發生類似問題。 最佳做法是針對依賴憑證關聯的應用程式,提供自訂 TLS 憑證。

如果應用程式需要依賴憑證關聯行為,建議將自訂網域新增至 Web 應用程式,並提供網域自訂 TLS 憑證。 然後,應用程式即可依賴自訂 TLS 憑證進行憑證關聯。

記憶體資源

當監視或服務建議指出應用程式耗用的記憶體超過預期時,請考慮 App Service 自動修復功能。 您可以使用 web.config 來設定自動修復。

自動修復功能的其中一個選項是根據記憶體閾值來採取自訂動作。 動作包括電子郵件通知、透過記憶體傾印來調查,乃至於回收背景工作處理序以當場緩和情況。

CPU 資源

當監視或服務建議指出應用程式耗用的記憶體超出預期,或 CPU 用量連續暴增時,請考慮相應增加或相應放大 App Service 方案。 如果應用程式是具狀態的情況,相應增加便是唯一的選項。 如果應用程式是無狀態,相應放大可提供更大的彈性和更高的調整潛力。

如需 App Service 調整和自動調整選項的詳細資訊,請參閱在 Azure App Service 中相應增加應用程式的規模

通訊端資源

輸出 TCP 連線遭到耗盡的常見原因是,使用的用戶端程式庫 未重複使用 TCP 連線,或是未使用更高階的通訊協定 (例如 HTTP - Keep-Alive)。

檢閱 App Service 方案中的應用程式參考之每個程式庫的文件。 請確定程式碼中已設定或存取程式庫,以便有效率地重複使用輸出連線。 此外,請遵循程式庫文件指引,適當地建立和釋放或清除,以免連線流失。 在進行這類用戶端程式庫調查時,您可相應放大至多個執行個體來緩和影響。

Node.js 和傳出 HTTP 要求

使用 Node.js 和許多傳出 HTTP 要求時,HTTP - Keep-Alive 的處理非常重要。 您可以使用 agentkeepalivenpm 封裝,使之得以更輕鬆地在程式碼中運作。

即使您在處理常式中沒有任何操作,也請一律處理 http 回應。 如果未正確地處理回應,應用程式最終會因為已無其他可用的通訊端而停滯。

以下是當您使用 httphttps 套件時處理回應的範例:

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

如果您在具有多核心的 Linux 機器上執行 App Service 應用程式,另一個最佳做法是使用 PM2 啟動多個 Node.js 處理序來執行應用程式。 您可以為容器指定啟動命令來進行此操作。

例如,使用此命令啟動四個執行個體:

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

應用程式備份

備份通常會依排程執行,而且需要存取儲存體 (用於輸出的備份檔案) 和資料庫 (用於複製和讀取要包含於備份中的內容)。 無法存取這其中一個資源的結果就是備份一律會失敗。

應用程式備份為什麼會失敗有兩個最常見的原因:儲存體設定無效和資料庫設定無效。 這些失敗通常是在儲存體或資料庫資源變更之後,或在變更認證以存取這些資源之後發生。 例如,您在備份設定中選取的資料庫認證可能會加以更新。

發生備份失敗時,請檢閱最新的結果,以了解發生了哪種類型的失敗。 針對儲存體存取失敗,請檢閱並更新備份設定中的儲存體設定。 針對資料庫存取失敗,請檢閱並更新連接字串作為應用程式設定的一部分。 然後繼續更新備份設定,以適當地包含必要的資料庫。

如需應用程式備份的詳細資訊,請參閱在 Azure App Service 中備份和儲存應用程式

Node.js 應用程式

適用於 Node.js 應用程式的 Azure App Service 預設設定是為了符合大部分常用應用程式的需求。 如果您想要將 Node.js 應用程式的預設設定個人化,以改善效能或最佳化 CPU、記憶體或網路資源的資源使用量,請參閱 Azure App Service 上節點應用程式的最佳做法和疑難排解指南。 本文說明您可能需要為 Node.js 應用程式設定的 iisnode 設定。 其中也說明如何解決應用程式的情節或問題。

IoT 裝置

執行連線至 App Service 的物聯網 (IoT) 裝置時,您可以改善環境。

IoT 裝置其中一個常見的做法是「憑證關聯」。 為避免對服務受控憑證所做的變更導致任何未預期的停機,建議您不要將憑證釘選為預設 *.azurewebsites.net 憑證或 App Service 受控憑證。 如果系統需要依賴憑證關聯行為,建議將自訂網域新增至 Web 應用程式,並提供網域自訂 TLS 憑證。 然後,應用程式即可依賴自訂 TLS 憑證進行憑證關聯。 如需詳細資訊,請參閱本文的憑證關聯一節。

若要提升環境中的復原能力,建議所有裝置都不要依賴單一端點。 為避免單一失敗點,請在至少兩個不同的區域中裝載 Web 應用程式,並準備容錯移轉流量。

在 App Service 中,只要這些 Web 應用程式裝載在不同的區域,即可將相同的自訂網域新增至不同的 Web 應用程式。 此功能可確保如果您需要釘選憑證時,也可以釘選在您提供的自訂 TLS 憑證。

另一個選項是在 Web 應用程式前端使用負載平衡器 (例如 Azure Front Door 或 Azure 流量管理員),以確保 Web 應用程式的高可用性。 如需詳細資訊,請參閱快速入門:建立適用於高可用性全域 Web 應用程式的 Front Door 執行個體使用 Azure 流量管理員控制 Azure App Service 流量

下一步

若要取得資源特有的可行最佳做法,請使用 App Service 診斷

  1. Azure 入口網站中移至 Web 應用程式。
  2. 選取左窗格上的 [診斷與解決問題],以開啟 App Service 診斷。
  3. 選取 [最佳做法] 圖格。
  4. 選取 [可用性和效能的最佳做法] 或 [最佳設定的最佳做法],從這些最佳做法,檢視應用程式的目前狀態。

您也可以使用此連結,直接為資源開啟 App Service 診斷:https://portal.azure.com/?websitesextension_ext=asd.featurePath%3Ddetectors%2FParentAvailabilityAndPerformance#@microsoft.onmicrosoft.com/resource/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Web/sites/{siteName}/troubleshoot