Azure Well-Architected 框架觀點之 Azure App Service （Web Apps）
Azure App Service 是一種平臺即服務 （PaaS），可提供完全受控的裝載環境，以建置、部署及調整 Web 應用程式。 作為 PaaS 解決方案，App Service 會抽象化基礎結構，讓您專注於應用程式開發。 App Service（Web App）會在 App Service 方案中運行您的應用程式，該方案決定用來託管應用程式的資源、作業系統、區域和定價模型（Sku）。
本文假設身為架構設計人員，您已檢閱 計算判定樹，並選擇 App Service 作為工作負載的計算。 本文中的指引提供架構建議，這些建議會對應至 Azure 框架支柱Well-Architected 的原則。
重要
如何使用本指南
每個區段都包含 設計檢查清單， 強調 Azure App Service 的架構考量與策略。 建議 提供實作這些策略的特定指引。
這些建議並不代表 Azure App Service 及其相依性之 Web Apps 功能可用之所有組態的完整清單。 相反地，他們會列出主要建議，以對應到設計觀點。 使用建議來建置概念證明或優化現有的環境。
示範主要建議的基礎架構：App Service 基準架構。
技術範圍
此檢閱著重於下列 Azure 資源的相關決策：
- App Service 方案
- 網頁應用程式
其他 Azure 供應專案會與 App Service 相關聯，例如 Azure Functions、Azure Logic Apps 和 App Service 環境。 這些內容不在這篇文章的討論範圍內。 偶爾會參考 App Service 環境，以協助釐清核心 App Service 服務的功能或選項。
可靠性
可靠性支柱的目的是藉由 建置足夠的復原能力，以及從失敗快速復原的能力，來提供持續的功能。
可靠性設計原則 提供適用於個別元件、系統流程和整個系統的高階設計策略。
設計檢查清單
根據可靠性 的設計檢閱檢查清單，啟動您的設計策略。 請判斷其與您的業務需求的相關性，同時記住 App Service 及其相依性項目的層級和功能。 擴充策略，以視需要包含更多方法。
設定使用者流程的優先順序：並非所有流程都同樣重要。 識別應用程式中的重要路徑，並將優先順序指派給每個流程，以引導您的設計決策。 使用者流程設計可能會影響您為 App Service 方案和設定選擇的服務層級和實例數目。
例如，您的應用程式可能包含透過訊息代理程式通訊的前端和後端層。 您可以選擇分割多個 Web 應用程式中的階層，以允許獨立調整、生命週期管理和維護。 將大型應用程式放在單一方案中可能會導致記憶體或CPU問題並影響可靠性。
您可能需要前端上的更多實例，才能在UI端達到最佳效能。 不過，後端可能不需要相同數量的實例。
預測潛在失敗：規劃潛在失敗的風險降低策略。 下表顯示失敗模式分析的範例。
失敗 減緩 基礎或抽象的 App Service 元件失敗 在實例和相依性中具有元件備援。 監視實例、網路效能和記憶體效能的健康情況。 外部依賴失敗 使用設計模式，例如 重試模式 和 斷路器模式。 監視外部依賴並設定適當的超時。 由於流量被路由至不健康的實例而失敗 監視實例健康情況。 請考慮回應性，並避免將要求傳送至狀況不良的實例。 建置備援：在應用程式和支援基礎結構中建置備援。 將實例分散至各可用區，以提升容錯能力。 如果某個區域故障，流量會被導向到其他區域。 跨多個區域部署您的應用程式，以確保您的應用程式仍可供使用，即使整個區域發生中斷也一樣。
在相依服務中建置類似的備援層級。 例如，應用程式實例會系結至 Blob 記憶體。 如果應用程式使用區域備援部署，請考慮使用區域備援記憶體 （ZRS） 來設定相關聯的記憶體帳戶。
使用多個實例：只在一個實例上執行您的應用程式是立即的單一失敗點。 將多個實例配置給您的應用程式，以確保高可用性。 如果某個實例失敗，其他實例仍然可以處理連入要求。 請記住，您的應用程式程式代碼應該能夠在讀取或寫入數據源時處理多個實例，而不會發生同步處理問題。
網路元件中應具備冗餘。 例如，使用區域備援IP位址和負載平衡器。
有可靠的調整策略：應用程式上的非預期負載可能會使其不可靠。 根據您的工作負載特性考慮正確的調整方法。 水平調整（相應放大）可讓您新增更多實例來分散負載，而垂直調整（相應增加）則牽涉到增加現有實例的容量（CPU、記憶體）。 請小心過度布建，因為新增不必要的實例會增加成本，而不會帶來實際的效能改善。
有時您可以擴展處理能力來應對負載。 不過，如果負載持續增加，請擴展至新的實例。 偏好使用自動化與自動調整規模的方法，而不是手動操作。 在調整作業期間一律維護額外的容量緩衝區，以防止效能降低[選擇 App Service 的調整選項]（Azure App Service 中的自動調整選項）
您選擇的 App Service 方案層 會影響實例數目和計算單位的縮放比例。
請確定適當的應用程式初始化，讓新的實例快速熱身，而且可以接收要求。
盡可能追求無狀態的應用程式。 使用新實例來可靠地擴展狀態可能會增加複雜性。 如果您需要儲存應用程式狀態，請考慮可以獨立調整的外部資料存放區。 當應用程式或 App Service 發生問題時，將會話狀態儲存在記憶體中可能會導致會話狀態遺失。 它也會限制將負載分散到其他實例的可能性。
定期測試您的自動調整規則。 模擬負載案例，以確認您的應用程式會如預期般調整。 您應該記錄調整事件，以便針對可能發生的問題進行疑難解答，並隨著時間優化調整策略。
App Service 對方案內的實例數目有限制，這可能會影響調整可靠性。 其中一個策略是使用相同的部署戳記，每個運行中的 App Service計劃實例都有自己的端點。 您必須在所有戳記前面加上外部負載平衡器，以將流量分散到它們之間。 使用 Azure 應用程式閘道進行單一區域部署，並使用 Azure Front Door 進行多區域部署。 這種方法非常適合可靠性至關重要的任務關鍵性應用程式。 如需詳細資訊，請參閱 使用 App Service 的任務關鍵性基準。
規劃復原能力：備援對於商務持續性至關重要。 如果無法連線到某個例項，請切換至另一個例項。 探索 App Service 中的自動修復功能，例如自動修復實例。
實作設計模式來處理暫時性故障的優雅降級，例如因網路連線問題而產生的故障，以及區域性中斷等大規模事件。 請考慮下列設計模式：
Bulkhead 模式 將應用程式分割成隔離群組，以防止失敗影響整個系統。
Queue-Based 負載均衡模式 排列工作項目，作為緩衝區，以便平滑處理流量尖峰。
重試模式 處理因網路故障、中斷的資料庫連線或忙碌服務而發生的暫時性失敗。
斷路器模式 可防止應用程式重複嘗試執行可能失敗的作業。
您可以使用 WebJobs 在 Web 應用程式中執行背景工作。 若要可靠地執行這些工作，請確保運行工作任務的應用程式依排程或事件驅動持續執行。
進行可靠性測試：進行負載測試，以評估應用程式負載下的可靠性與效能。 測試計劃應包含驗證自動化復原作業的案例。
使用故障注入來刻意引入故障, 並驗證自我修復和自我保護機制。 探索 Azure Chaos Studio 所提供的故障庫。
App Service 會對託管的應用程式施加資源限制。 App Service 計畫會決定這些限制。 請確定您的測試確認應用程式在那些資源限制內執行。 如需詳細資訊，請參閱 Azure 訂用帳戶和服務限制、配額和條件約束。
使用健康情況檢查功能來識別沒有回應的工作者：App Service 具有內建功能，可定期偵測 Web 應用程式的特定路徑。 平臺會 Ping 此路徑，以判斷您的應用程式是否狀況良好並回應要求。 當您的網站擴展至多個實例時，App Service 會將任何不健康的實例排除於處理請求之外，以提升整體可用性。 應用程式的健康檢查路徑應該檢查應用程式的重要元件，例如您的資料庫、快取或傳訊服務。 這可確保健康情況檢查路徑傳回的狀態是應用程式整體健康情況的準確畫面。 設定你的健康檢查路徑
使用自動修復功能：有時候，您的應用程式可能會遇到未預期的行為，此類行為可以透過簡單的重新啟動來解決。 自動癒合功能可讓您定義「條件」，以觸發自動癒合，而自動癒合會在符合條件時起始的「動作」。 App Service 診斷工具和自動癒合功能
App Service 復原分數報告：若要檢閱量身訂做的最佳做法建議，請參閱復原分數報告。App Service 復原分數報告
建議
| 建議 | 好處 |
|---|---|
| （App Service）針對生產工作負載，選擇 App Service 方案的進階 v3 層。 根據您的容量規劃，設定工作人員的最大和最小數量。 如需詳細資訊，請參閱 App Service 方案概觀。 |
進階 V3 App Service 方案提供進階調整功能，並確保發生失敗時備援。 |
| （App Service） 啟用區域備援。 請考慮布建三個以上的實例，以增強容錯能力。 檢查區域冗餘的支援內容，因為並非所有地區都提供這項功能。 |
當多個實例分散到區域時，您的應用程式可以承受單一區域中的失敗。 如果某個區域無法使用，流量會自動轉移到其他區域中狀況良好的實例，並維護應用程式可靠性。 |
| （Web 應用程式）請考慮停用應用程式要求路由 （ARR） 親和性功能。 ARR 親和性會建立黏性會話，以將使用者重新導向至處理先前要求的節點。 | 當您停用ARR親和性時，連入要求會平均分散到所有可用的節點。 平均分散式要求可防止流量壓倒任何單一節點。 如果節點無法使用，可以將要求順暢地重新導向至其他狀況良好的節點。 為了確保您的 App Service 實例保持無狀態，請避免使用會話親和性。 無狀態 App Service 可降低複雜度，並確保節點之間的一致行為。 移除會話黏著，以便 App Service 可以新增或移除實例以進行水平擴展。 |
| （Web App） 根據要求計數、慢速要求、記憶體限制和其他屬於效能基準的指標，定義自動修復規則。 將此設定視為調整策略的一部分。 | 自動修復規則可協助您的應用程式自動從非預期的問題中復原。 設定的規則會在違反臨界值時觸發修復動作。 自動癒合功能使預防性維護變得自動。 |
| （Web App） 啟用健康情況檢查功能 並提供回應健康狀態檢查要求的路徑。 | 健康情況檢查可以提早偵測到問題。 然後系統可以在健康情況檢查要求失敗時自動採取更正動作。 負載平衡器會將流量從不健康的實例轉移，將使用者引導至健康的節點。 |
安全
安全性要素的目的是為工作負載提供 機密性、完整性和可用性 保證。
安全性設計原則 藉由將方法套用至 App Service 上裝載的技術設計，為達成這些目標提供高階的設計策略。
設計檢查清單
根據安全性設計檢閱檢查清單來啟動您的設計策略，並識別弱點和控件，以改善安全性狀態。 擴充策略，以視需要包含更多方法。
檢閱安全性基準：若要增強App Service方案上裝載之應用程式的安全性狀態，請檢閱App Service 安全性基準。
使用最新的運行時間和連結庫：先徹底測試應用程式組建，再進行更新，以提早攔截問題，並確保順利轉換至新版本。 App Service 支援 語言執行時支援政策，以更新現有的堆疊並停止支援不再支援的堆疊。
透過隔離界限建立分割區，以防止漏洞：應用身份分割。 例如，實作角色型訪問控制 （RBAC） 以根據角色指派特定許可權。 請遵循最小權限原則，將訪問權限限制為僅限必要部分。 在網路層級亦須建立分段。 在 Azure 虛擬網路中插入 App Service 應用程式 以進行隔離，並定義網路安全組 （NSG） 來篩選流量。
App Service 方案提供具高度隔離的 App Service 環境層級。 透過 App Service 環境，您會取得專用的計算和網路功能。
對身分識別套用存取控制：限制對 Web 應用程式的向內存取，並限制從 Web 應用程式向外部資源的存取。 此設定會套用身分識別的訪問控制，並協助維護工作負載的整體安全性狀態。
針對所有驗證和授權需求，請使用Microsoft Entra ID。 使用內建角色，例如 Web 方案參與者、網站參與者，以及 泛型參與者、讀者和擁有者。
套用網路安全性控制：整合 App Service 與虛擬網路 （VNet） 來控制輸出流量。 使用私有端點來控制入站流量，限制從你的 VNet 訪問 App Service，並停用公共網路存取。 保護您的網路，控制輸入和輸出流量
部署 Web 應用程式防火牆 （WAF） 以防止常見的弱點。 應用程式閘道和 Azure Front Door 都有整合式 WAF 功能。
適當地設定反向 Proxy 規則和網路設定，以達到所需的安全性和控制層級。 例如，對私有端點子網新增 NSG 規則，以僅接受來自反向代理的流量。
從應用程式到其他 PaaS 服務的輸出流量應該透過私人端點。 請考慮放置防火牆元件來限制對公用因特網的輸出流量。 這兩種方法都會防止數據外流。
如需完整檢視，請參閱 App Service 網路功能。
加密數據：使用端對端傳輸層安全性來保護傳輸中的數據（TLS）。 使用客戶管理的金鑰來完整加密靜態數據。 如需詳細資訊，請參閱 使用客戶管理的金鑰的靜態加密。
請勿使用舊版通訊協定，例如 TLS 1.0 和 1.1。 請確定所有 Web 應用程式都只使用 HTTPS，並強制執行 TLS 1.2 或更高版本。 預設的最小 TLS 版本為 1.2。 如需詳細資訊，請參閱 App Service TLS 概觀。
您的 App Service 的所有實例都有預設的網域名稱。 使用自定義網域，並使用憑證保護該網域。
端對端 TLS 加密：進階 App Service 方案中提供端對端 TLS 加密。 這項功能會在整個交易中加密您的流量，將流量攔截的風險降至最低。
減少受攻擊面：移除您不需要的預設組態。 例如，停用遠端偵錯、原始檔控制管理員 （SCM） 網站的本機驗證，以及基本身份驗證。 停用不安全的通訊協定，例如 HTTP 和檔案傳輸通訊協定 （FTP）。 透過 Azure 原則強制執行設定。 如需詳細資訊，請參閱 Azure 原則。
實作嚴格的跨原始來源資源分享 （CORS） 原則：在 Web 應用程式中使用限制性的 CORS 原則，只接受來自允許網域、標頭和其他準則的要求。 使用內建的 Azure 原則定義強制執行 CORS 原則。
使用受控識別：啟用 App Service 的受控識別，以安全地存取其他 Azure 服務，而不需要管理認證。 瞭解受控識別。
保護應用程式秘密：您需要處理敏感性資訊，例如 API 金鑰或驗證令牌。 您可以在應用程式設定中使用 Azure Key Vault 參考，而不是將這些秘密直接編碼到您的應用程式程式碼或組態檔中。 應用程式啟動時，App Service 會使用應用程式的受控識別，自動從 Key Vault 擷取秘密值。
啟用應用程式的資源記錄：啟用應用程式的資源記錄，以建立完整的活動線索，以在調查期間提供遵循安全性事件的重要數據。 如需詳細指引，請參閱 記錄監視指引。
當您評估威脅時，請考慮記錄作為威脅模型化程式的一部分。
建議
| 建議 | 效益 |
|---|---|
| （Web 應用程式） 將受控識別 指派給 Web 應用程式。 若要維護隔離界限，請勿跨應用程式共用或重複使用身分識別。 如果您使用容器進行部署，請務必 安全地連線到容器登錄。 |
應用程式會從 Key Vault 擷取秘密，以驗證應用程式的向外通訊。 Azure 會管理身分識別，而且不需要您配置或輪替任何機密資訊。 您擁有不同的身分識別，便於精細控制。 個別身分識別的存在，使得在身分識別遭到入侵時，可以更容易地進行撤銷。 |
| （Web 應用程式）為應用程式設定 自定義網域。 停用 HTTP，並只接受 HTTPS 要求。 |
自定義網域會使用傳輸層安全性 （TLS） 通訊協定，透過 HTTPS 啟用安全通訊，以確保敏感數據的保護，並建立使用者信任。 |
| （Web App） 評估 App Service 內建驗證 是否為驗證存取您應用程式之使用者的正確機制。 App Service 內建驗證會與 Microsoft Entra ID 整合。 此功能可跨多個登入提供者處理令牌驗證和使用者身分識別管理，並支援 OpenID Connect。 使用這項功能時，您沒有細微層級的授權，而且沒有測試驗證的機制。 | 當您使用這項功能時，您不需要在應用程式程式代碼中使用驗證連結庫，這可降低複雜性。 當要求到達應用程式時，用戶已經通過驗證。 |
| （Web 應用程式）為應用程式配置 虛擬網路整合。 針對 App Service 應用程式使用 私有端點。 封鎖所有公用流量。 透過虛擬網路 整合路由傳送 容器映像。 所有 從應用程式 傳出的流量都會透過虛擬網路。 |
取得使用 Azure 虛擬網路的安全性優點。 例如，應用程式可以安全地存取網路內的資源。 新增私人端點以協助保護您的應用程式。 私人端點會限制直接公開至公用網路，並允許透過反向 Proxy 進行受控存取。 |
| （Web 應用程式）若要實作強化： - 停用使用使用者名稱和密碼的基本身份驗證，以利於Microsoft Entra ID 型驗證。 - 關閉遠端偵錯，以避免啟用入站埠。 - 啟用 CORS 原則 以收緊傳入要求。 - 停用通訊協定，例如 FTP。 |
我們不建議使用基本身份驗證作為安全的部署方法。 Microsoft Entra ID 採用 OAuth 2.0 令牌型驗證，可提供許多優點和增強功能，以解決與基本身份驗證相關聯的限制。 原則會限制對應用程式資源的存取、只允許來自特定網域的要求，以及保護跨區域要求。 |
| （Web 應用程式）一律使用鍵值庫參考作為應用程式設定。 |
機密會與應用程式的設定分開。 應用程式設定會在靜止時加密。 App Service 也會管理秘密輪替。 |
| （App Service） 為 App Service 啟用適用於雲端的 Microsoft Defender。 | 取得即時保護，為在 App Service 方案中執行的資源提供保障。 防範威脅並增強整體安全性狀態。 |
| （App Service） 啟用診斷記錄，並將檢測新增至您的應用程式。 記錄會傳送至 Azure 記憶體帳戶、Azure 事件中樞和 Log Analytics。 如需稽核記錄類型的詳細資訊，請參閱 支援的記錄類型。 | 記錄會擷取存取模式。 它會記錄相關事件，以深入瞭解使用者與應用程式或平臺的互動方式。 此資訊對於責任、合規性和安全性用途而言非常重要。 |
成本優化
成本優化著重於 偵測支出模式、將投資放在重要領域，並將其他 優化，以符合組織的預算，同時符合商務需求。
成本優化設計原則 提供高階設計策略，以達成這些目標，並在與 Web 應用程式和執行環境相關的技術設計中視需要進行取捨。
設計檢查清單
根據 設計檢閱檢查清單和成本優化 的指引來開始你的設計策略，並微調設計，確保工作負載與配置給工作負載的預算相符。 您的設計應該使用正確的 Azure 功能、監視投資，以及尋找經過一段時間優化的機會。
估計初始成本：作為成本模型化練習的一部分，請使用 Azure 定價計算機，根據您打算執行的實例數目，評估與各層相關聯的近似成本。 每個 App Service 層都提供不同的計算選項。
持續監視成本模型以追蹤支出。
評估折扣選項：較高階層級包含專用計算執行個體。 如果您的工作負載具有可預測且一致的使用模式，您可以申請預訂折扣。 請務必分析使用量數據，以判斷適合您工作負載的保留類型。 如需詳細資訊，請參閱使用 App Service 保留實例方案節省成本。
瞭解使用量計量：Azure 會根據 App Service 方案的定價層，按每小時費率以秒計費。 費用會根據您分配 VM 實例的時間，套用至您計劃中的每個擴展實例。 請注意使用不足的計算資源，這些資源可能會因為選擇次佳SKU或縮小配置不佳，導致過度配置而增加成本。
額外的 App Service 功能，例如自定義網域註冊和自定義憑證，可能會增加成本。 其他資源，例如用來隔離解決方案的虛擬網路或用來保護工作負載機密的密鑰保存庫，與您的 App Service 資源整合時，也可能增加成本。 如需詳細資訊，請參閱 App Services 計費模型。
考慮密度與隔離之間的取捨：您可以使用App Service 方案在同一個計算上裝載多個應用程式，以節省共用環境的成本。 如需詳細資訊，請參閱 取捨。
評估調整策略對成本的影響：您必須在實作自動調整時，正確設計、測試及設定以進行擴展和縮減。 設定自動調整的精確最大和最小限制。
為了可靠擴展，主動初始化應用程式。 例如，請勿等到 CPU 達到 95% 使用量。 相反地，在大約 65% 觸發調整，以允許在調整程式期間配置和初始化新實例有足夠的時間。 不過，此策略可能會導致未使用的容量。
建議您結合和平衡垂直擴展和水平擴展的機制。例如，應用程式可以在某段時間內進行垂直擴展，然後根據需要進行水平擴展。 探索提供大量容量且有效率的資源使用量的高階層。 根據使用模式，較高的進階層通常會更有成本效益，因為它們更有能力。
將環境成本優化：請考慮基本層或免費層來執行生產前環境。 這些層級的效能較低且成本較低。 如果您使用基本層或免費層，請使用控管來強制執行該層、限制實例和 CPU 數目、限制調整和限制記錄保留。
實作設計模式：此策略可減少工作負載所產生的要求量。 請考慮使用像是 前端為後端設計模式 和 閘道聚合模式，這樣可以減少請求數量並降低成本。
定期檢查數據相關成本：延長的數據保留期間或昂貴的儲存層可能會導致高儲存成本。 由於頻寬使用量和長時間保留記錄數據，可能會累積更多費用。
請考慮實作快取，以將數據傳輸成本降至最低。 從本機記憶體內部快取開始，然後探索分散式快取選項，以減少後端資料庫的要求數目。 如果您的資料庫位於不同的區域，請考慮與跨區域通訊相關聯的頻寬流量成本。
優化部署成本：利用部署位置將成本優化。 插槽會在與生產實例相同的計算環境中執行。 在藍綠部署等需要在插槽之間切換的情境中，請策略性地使用它們。 這種方法可將停機時間降到最低，並確保順暢的轉換。
請小心使用部署插槽。 您可以引入可能會影響現有實例和新實例的問題，例如例外狀況或記憶體流失。 請務必徹底測試所有變更。 若需作業指引，請參閱 卓越營運。
建議
| 建議 | 好處 |
|---|---|
| （App Service） 針對較低環境選擇免費或基本層。 我們建議這些層用於實驗性用途。 當您不再需要階層時，請移除這些層。 | 相較於更高級別的方案，免費層和基本層更具經濟實惠。 它們為不需要進階方案的完整功能和效能的非生產環境提供符合成本效益的解決方案。 |
| （App Service）利用折扣並探索下列專案的優惠定價： - 較低的環境使用 開發/測試計劃。 - Azure 保留 和 Azure 節省方案，以用於您在 Premium V3 層和 App Service 環境中配置的專用運算資源。 針對具有可預測使用模式的穩定工作負載使用保留實例。 |
開發/測試計劃可為 Azure 服務提供降低的費率，使其符合非生產環境的成本效益。 使用預留實例來預付計算資源費用並獲得顯著的折扣。 |
| （Web App） 監視 App Service 資源所產生的 成本。 在 Azure 入口網站中執行成本分析工具。 建立預算和警示， 通知相關人員。 |
您可以儘早找出成本尖峰、效率低下或非預期的費用。 這種主動式方法可協助您提供預算控制，以防止超支。 |
| （App Service）當需求減少時相應縮小。 若要縮小規模，請定義縮放規則以減少 Azure 監控中的實例數目，。 | 防止浪費並降低不必要的費用。 |
卓越營運
卓越營運主要著重於 開發流程、可觀察性和發布管理。
營運卓越設計原則 提供高階設計策略，以達成工作負載作業需求的目標。
設計檢查清單
根據 設計檢閱檢查清單開始您的設計策略，以達成營運卓越，並定義與網頁應用程式相關的可觀察性、測試和部署流程。
管理發行：使用部署插槽有效地管理發行。 您可以將應用程式部署至位置、執行測試，以及驗證其功能。 驗證之後，您可以順暢地將應用程式移至生產環境。 此過程不會產生額外的成本，因為插槽運行在與生產實例相同的虛擬機環境中。
使用 Swap with Preview （多階段交換）。 與預覽交換功能允許您在預備插槽中測試應用程式，以符合生產環境的設置並對應用程式進行預熱。 執行測試並熱身所有必要路徑之後，您就可以完成交換，應用程式會開始接收生產流量，而不需要重新啟動。
執行自動化測試：在發佈您的 Web 應用程式版本之前，請徹底測試其效能、功能以及與其他元件的整合。 使用 Azure Load Testing，其與 Apache JMeter 整合，這是效能測試的熱門工具。 探索其他類型的測試自動化工具，例如用於功能測試的Phantom工具。
自動化部署：使用 CI/CD 管線搭配 Azure DevOps 或 GitHub Actions 來自動化部署並減少手動工作量 ，持續部署至 Azure App Service。
部署不可變單位：實作 部署戳記模式， 將 App Service 分割成不可變的戳記。 App Service 支援使用原本不可變的容器。 請考慮使用 自定義容器 以支援您的 App Service Web 應用程式。
每個戳記都代表一個獨立單位，您可以快速相應放大或相應縮小。 以這個戳記為基礎的單位是暫時的和無狀態的。 無狀態設計可簡化作業和維護。 此方法非常適合任務關鍵性應用程式。 如需範例，請參閱 關鍵任務基準以及 App Service。
使用基礎結構即程序代碼 （IaC） 技術，例如 Bicep，來淘汰具有重複性和一致性的單位。
保護生產環境安全：建立個別的 App Service 方案以執行生產環境與生產前環境。 請勿直接在生產環境中進行變更，以確保穩定性和可靠性。 獨立的實例可讓您在將變更推送至生產環境之前，在開發和測試方面具有彈性。
使用低環境以隔離的方式探索新功能和組態。 保持開發和測試環境暫時性。
管理憑證：針對自定義網域，您需要管理 TLS 憑證。
有程式可進行採購、更新及驗證憑證。 如果可能，將這些流程移至 App Service。 如果您使用自己的憑證，則必須管理其更新。 選擇最符合您安全性需求的方法。
| 建議 | 效益 |
|---|---|
| （Web App） 監視您的實例健康狀況， 並啟動健康探測。 設定處理健康情況探查要求的特定路徑。 |
您可以立即偵測問題，並採取必要的動作來維護可用性和效能。 |
| （Web App） 為應用程式和實例啟用診斷記錄。 頻繁的記錄可能會降低系統的效能、增加記憶體成本，並在您有不安全的記錄存取權時帶來風險。 請遵循下列最佳做法： - 記錄正確的資訊層級。 - 設定保留原則。 - 保留授權存取的稽核記錄和未經授權嘗試。 - 將記錄視為數據並套用數據保護控制項。 |
診斷記錄可讓您深入瞭解應用程式的行為。 監視流量模式並識別異常狀況。 |
| （Web 應用程式）利用 App Service 受控憑證，將認證管理卸除至 Azure。 | App Service 會自動處理憑證採購、憑證驗證、憑證更新，以及從 Key Vault 匯入憑證等程式。 或者，將憑證上傳至 Key Vault，並授權 App Service 資源提供者存取它。 |
| （App Service） 先驗證預備位置中的應用程式變更，再將它與生產位置交換。 | 避免停機和錯誤。 如果您在交換之後偵測到問題，請快速還原為最後已知的良好狀態。 |
效能效率
效能效率與 維護用戶體驗有關，即使藉由管理容量來增加負載 也一定。 此策略包括調整資源、識別和優化潛在的瓶頸，以及優化尖峰效能。
效能效率設計原則 提供針對預期使用量達成這些容量目標的高階設計策略。
設計檢查清單
根據 設計檢閱檢查清單和效能效率，啟動您的設計策略，為 Web 應用程式根據關鍵性能指標定義基準。
識別並監視效能指標：設定應用程式關鍵指標的目標，例如傳入要求的數量、應用程式回應要求所需的時間、擱置的要求，以及 HTTP 回應中的錯誤。 請考慮將關鍵指標視為工作負載效能基準的一部分。
擷取構成效能指標基礎的 App Service 計量。 收集記錄以深入瞭解資源使用量和活動。 使用應用程式效能監視 （APM） 工具，例如 Application Insights，從應用程式收集和分析效能數據。 如需詳細資訊，請參閱 App Service 監視資料參考。
包含程式代碼層級檢測、交易追蹤和效能分析。
評估容量：模擬各種使用者案例，以判斷您需要處理預期流量的最佳容量。 使用負載測試來瞭解應用程式在不同負載層級下的行為。
選擇正確的層級：針對生產環境負載使用專用的計算。 進階 V3 層提供較大的 SKU，並增加記憶體和 CPU 容量、更多實例和更多功能，例如區域備援。 如需詳細資訊，請參閱 進階 V3 定價層。
優化調整策略：可能的話，請使用 自動調整，而不是在應用程式負載變更時手動調整實例數目。 使用自動調整時，App Service 會根據預先定義的規則或觸發程式調整伺服器容量。 請確定您進行適當的效能測試，併為正確的觸發程式設定正確的規則。
如果您在初始設定期間設定簡化優先順序，請使用不需要您定義規則且只需要設定限制的自動調整選項。
有足夠的資源可供使用，以確保最佳效能。 適當地配置資源以維護效能目標，例如響應時間或輸送量。 視需要考慮過度配置資源。
當您定義自動調整規則時，請記下應用程式初始化所需的時間。 當您做出所有調整決策時，請考慮此額外負荷。
使用快取：從不常變更且存取成本較高的資源擷取資訊會影響效能。 複雜的查詢，包括連接和多個查閱，會增加執行時間。 執行快取，以將處理時間和延遲降到最低。 快取查詢結果，以避免重複往返資料庫或後端，並減少後續要求的處理時間。
如需在工作負載中使用本機和分散式快取的詳細資訊，請參閱 快取。
檢閱效能反模式：若要確定 Web 應用程式會根據您的業務需求執行和調整，請避免 典型的反模式。 以下是 App Service 修正的一些反模式。
反模式 描述 忙碌前端 資源密集型工作可以增加使用者要求的回應時間，並造成高延遲。
將耗用大量資源的處理程式移至個別的後端。 使用訊息代理程式將資源密集型工作排入佇列，讓後臺以異步方式處理。沒有快取 在後端資料庫前面提供來自中繼快取的要求，以減少延遲。 嘈雜的鄰居 多租用戶系統會在租用戶之間共享資源。 一個租用戶的活動可能會對另一個租用戶的系統使用產生負面影響。 App Service 環境提供完全隔離且專用的環境來執行 App Service 應用程式。
建議
| 建議 | 效益 |
|---|---|
| （App Service） 當應用程式共用單一 App Service 方案時，啟用 Always On 設定。 App Service 應用程式會在閒置時自動卸除以節省資源。 下一個請求會觸發冷啟動，這可能會導致請求逾時。 | 當啟用了 Always On 時，應用程式將永不停止運行。 |
| （Web Apps） 考慮使用 HTTP/2 來提升通訊協定效率。 | 選擇 HTTP/2 而非 HTTP/1.1，因為 HTTP/2 完全多工連線、重複利用連接以減少額外負擔，並壓縮標頭以將資料傳輸降到最低。 |
取捨
如果您使用柱子檢查清單中的方法，您可能需要進行設計取捨。 以下是一些優點和缺點範例。
密度和隔離
高密度：共置相同 App Service 方案中的多個應用程式，以將資源降到最低。 所有應用程式都會共用 CPU 和記憶體等資源，以節省成本並降低作業複雜度。 此方法也會優化資源使用量。 如果負載模式隨著時間變更，應用程式可以使用來自另一個應用程式的閑置資源。
也請考慮缺點，例如資源爭用。 例如，應用程式使用量或不穩定的尖峰可能會影響其他應用程式的效能。 一個應用程式中的事件也可以滲透到共用環境中的其他應用程式，這可能會影響安全性。 對於需要高可用性和效能的重要應用程式，App Service Environment V3 （ASE） 等隔離環境 提供專用資源，但成本較高。 請考慮針對非關鍵性工作負載使用共用環境，以及針對任務關鍵性應用程式使用隔離的環境。
較高的隔離：隔離有助於避免干擾。 此策略適用於開發、測試和生產環境的安全性、效能，甚至隔離。
App Service 環境提供更佳的安全性與數據保護控制，因為每個應用程式都可以有自己的安全性設定。 您的環境可能會包含缺口，因為隔離會限制爆破半徑。 從效能的觀點來看，資源爭用會最小化。 隔離可根據特定需求和個別容量規劃進行獨立調整。
作為缺點，這種方法成本更高，而且需要嚴謹的運作。
可靠的調整策略
妥善定義的調整策略可確保您的應用程式可以處理各種負載，而不會影響效能。 不過，成本方面有一些取捨。 調整作業需要時間。 配置新的資源時，必須先正確初始化應用程式，才能有效地處理要求。 您可以過度布建資源（預先部署實例），以提供安全網。 如果沒有額外的容量，在初始化階段，服務要求可能會延遲，這會影響用戶體驗。 自動調整作業應該提早觸發，以確保在客戶使用資源時，資源初始化已妥當完成。
作為缺點，資源過度配置會導致成本更高。 每個實例每秒都會向您收費，包括預先設定的實例。 較高層包含預先設定的實例。 判斷具有更昂貴層的功能是否值得投資。
建置備援
備援提供復原功能，但也會產生成本。 工作負載的服務等級目標（SLO）會決定可接受的效能閾值。 如果冗餘超過 SLO 需求，就會變得浪費。 評估多餘的備援是否可改善 SLO，或增加不必要的複雜度。
也請考慮缺點。 例如，多區域備援可提供高可用性，但會因為數據同步處理、故障轉移機制和區域間通訊而增加複雜度和成本。 判斷區域備援是否符合您的 SLO。
Azure 原則
Azure 提供一組與 App Service 及其相依性相關的大量內建原則。 一組 Azure 原則可以稽核上述一些建議。 例如，您可以檢查是否：
適當的網路控制已就緒。 例如，您可以透過虛擬網路注入將 App Service 放入 Azure 虛擬網路中，以實現網路分割，進而更好地控制網路配置。 應用程式沒有公用端點，並透過私人端點連線到 Azure 服務。
身分識別控管已準備就緒。 例如，應用程式會使用受控識別來向其他資源驗證自己。 App Service 內建驗證 （Easy Auth） 會驗證傳入要求。
遠端偵錯和基本身份驗證等功能已停用，以減少受攻擊面。
如需全面治理，請檢閱 Azure 原則內建定義，以及其他可能會影響計算層安全性的原則。
Azure Advisor 建議
Azure Advisor 是個人化雲端顧問，可協助您遵循最佳做法來優化 Azure 部署。 以下是一些建議，可協助您改善 Web 應用程式實例的可靠性、安全性、成本效益、效能和營運卓越性。
後續步驟
請考慮下列文章做為資源，展示本文所強調的建議。
使用這些參考架構作為如何將這些建議套用至工作負載的範例。
如果您從未部署過 Web 應用程式，請參閱 基本 Web 應用程式。
如需基礎架構作為生產等級部署的起點，請參閱 基準高可用性區域備援 Web 應用程式。
使用下列產品檔來建置您的實作專業知識：