Azure App 服務 Web Apps 功能的 Azure 架構良好架構檢視方塊

  • 發行項

Azure App 服務 是一種平臺即服務 （PaaS） 計算解決方案，可用來在 Azure 平臺上裝載工作負載。 這是一項完全受控的服務，可將基礎計算抽象化，並卸除建置、部署及調整至平台的責任。 應用程式服務一律以 App Service 方案執行。 您選擇的服務方案會決定工作負載執行所在的區域、計算組態和操作系統。 App Service 提供多個計費模型。

本文假設身為架構設計人員，您已檢閱 計算判定樹 ，並選擇App Service作為工作負載的計算。 本文中的指引提供架構建議，這些建議會對應至 Azure 妥善架構架構要素的原則。

重要

如何使用本指南

每個區段都有一個 設計檢查清單 ，可呈現關注的架構區域，以及當地語系化至技術範圍的設計策略。

此外， 也包含可協助具體化這些策略的技術功能建議 。 這些建議並不代表 Azure App 服務 及其相依性之 Web Apps 功能可用之所有組態的完整清單。 相反地，他們會列出對應至設計檢視方塊的主要建議。 使用建議來建置概念證明或優化現有的環境。

示範重要建議的基礎架構： App Service 基準架構。

技術範圍

此檢閱著重於下列 Azure 資源的相關決策：

  • App Service 方案
  • Web Apps

其他 Azure 供應專案會與 App Service 相關聯，例如 Azure Functions、Azure Logic Apps 和 App Service 環境。 這些供應專案已脫離本文的範圍。 App Service 環境 偶爾會參考，以協助釐清核心 App Service 供應專案的功能或選項。

可靠性

可靠性支柱的目的是要藉由 建立足夠的復原能力和從失敗中快速復原的能力，來提供持續的功能。

可靠性設計原則提供適用於個別元件、系統流程和整個系統的高階設計策略。

設計檢查清單

根據 可靠性的設計檢閱檢查清單，啟動您的設計策略。 決定其與您的商務需求相關性，同時記住 App Service 及其相依性的階層和功能。 擴充策略，以視需要包含更多方法。

  • 設定使用者流程的優先順序：並非所有流程都同樣重要。 將優先順序指派給每個流程，以引導您的設計決策。 使用者流程設計可能會影響您為 App Service 方案和設定選擇的服務層級和實例。

    例如，您的應用程式可能包含透過訊息代理程式通訊的前端和後端層。 您可以選擇分割多個 Web 應用程式中的階層，以允許獨立調整、生命週期管理和維護。 將大型應用程式放在單一方案中可能會導致記憶體或CPU問題並影響可靠性。

    您可能需要前端上的更多實例，才能在UI端達到最佳效能。 不過，後端可能不需要相同數目的實例。

  • 預期潛在失敗：規劃潛在失敗的風險降低策略。 下表顯示失敗模式分析的範例。

    失敗 風險降低
    基礎或抽象的 App Service 元件失敗 在實例和相依性中具有元件備援。 監視實例、網路效能和記憶體效能的健康情況。
    外部相依性失敗 使用設計模式，例如 重試模式 和 斷路器模式。 監視外部相依性並設定適當的逾時。
    由於流量路由傳送至狀況不良的實例而失敗 監視實例健康情況。 請考慮回應性，並避免將要求傳送至狀況不良的實例。

    如需詳細資訊，請參閱 Azure 應用程式的失敗模式分析。

  • 建置備援：在應用程式和支援基礎結構中建置備援。 將實例分散到可用性區域，以改善容錯。 如果某個區域失敗，將流量路由傳送至其他區域。 跨多個區域部署您的應用程式，以確保您的應用程式仍可供使用，即使整個區域發生中斷也一樣。

    在相依服務中建置類似的備援層級。 例如，應用程式實例會系結至 Blob 記憶體。 如果應用程式使用區域備援部署，請考慮使用區域備援記憶體 （ZRS） 來設定相關聯的記憶體帳戶。

    在網路元件中具有備援性。 例如，使用區域備援IP位址和負載平衡器。

  • 有可靠的調整策略：應用程式上的非預期負載可能會使其不可靠。 根據您的工作負載特性考慮正確的調整方法。 您有時可以相應增加以處理負載。 不過，如果負載持續增加，請相應放大至新的實例。 偏好使用自動調整，而不是手動方法。 在調整作業期間一律維護額外容量的緩衝區，以避免效能降低。

    您選擇的 App Service 方案層會影響實例數目和計算單位的縮放比例。

    請確定適當的應用程式初始化，讓新的實例快速熱身，而且可以接收要求。

    盡可能爭取無狀態應用程式。 使用新實例可靠地調整狀態可能會增加複雜度。 如果您需要儲存應用程式狀態，請考慮可以獨立調整的外部資料存放區。 當應用程式或 App Service 發生問題時，將會話狀態儲存在記憶體中可能會導致會話狀態遺失。 它也會限制將負載分散到其他實例的可能性。

    定期測試您的自動調整規則。 模擬負載案例，以確認您的應用程式會如預期般調整。 您應該記錄調整事件，以便針對可能發生的問題進行疑難解答，並隨著時間優化調整策略。

    App Service 對方案內的實例數目有限制，這可能會影響調整可靠性。 其中一個策略是使用相同的部署戳記，每個執行中的App Service方案實例都有自己的端點。 您必須在所有戳記前面加上外部負載平衡器，以將流量分散到它們之間。 針對單一節點部署使用 Azure 應用程式閘道，並使用 Azure Front Door 進行多區域部署。 這種方法非常適合可靠性至關重要的任務關鍵性應用程式。 如需詳細資訊，請參閱 App Service 的任務關鍵基準。

    App Service 方案會將流量分散到實例，並監視其健康情況。 請注意，外部負載平衡器可能不會立即偵測到某個實例是否失敗。

  • 規劃復原能力：備援對於商務持續性至關重要。 如果無法連線到某個實例，請故障轉移至另一個實例。 探索 App Service 中的自動修復功能，例如自動修復實例。

    實作設計模式來處理暫時性失敗的正常降低，例如網路連線問題，以及區域性中斷等大規模事件。 請考慮下列設計模式：

    • Bulkhead 模式 會將您的應用程式分割成隔離群組，以防止失敗影響整個系統。

    • 佇列型負載撫平模式 會將作為緩衝區的工作專案排入佇列，以緩和流量尖峰。

    • 重試模式 會因網路故障、卸除的資料庫連線或忙碌服務而處理暫時性失敗。

    • 斷路器模式 可防止應用程式重複嘗試執行可能失敗的作業。

    您可以使用 WebJobs 在 Web 應用程式中執行背景工作。 若要可靠地執行這些工作，請確定裝載作業的應用程式會依排程或事件驅動觸發程式持續執行。

    如需詳細資訊，請參閱 可靠性模式。

  • 進行可靠性測試：進行負載測試，以評估應用程式負載下的可靠性與效能。 測試計劃應包含驗證自動化復原作業的案例。

    使用錯誤插入刻意引入失敗，並驗證自我修復和自我保護機制。 探索 Azure Chaos Studio 所提供的錯誤連結庫。

    App Service 會對託管的應用程式施加資源限制。 App Service 方案會決定這些限制。 請確定您的測試確認應用程式在那些資源限制內執行。 如需詳細資訊，請參閱 Azure 訂用帳戶和服務限制、配額與條件約束。

  • 使用健康情況探查來識別沒有回應的背景工作：App Service 具有內建功能，可定期偵測 Web 應用程式的特定路徑。 未回應的實例會從負載平衡器中移除，並以新的實例取代。

建議
服務或方案 建議 優點
App Service 方案 針對生產工作負載，選擇 App Service 方案的 進階版 層。

根據您的容量規劃，設定背景工作角色數目上限和最小值。 如需詳細資訊，請參閱 App Service 方案概觀。		 進階 App Service 方案提供進階調整功能，並確保發生失敗時備援。
App Service 方案 啟用區域備援。

請考慮布建三個以上的實例，以增強容錯能力。

檢查區域備援的區域支援，因為並非所有區域都提供這項功能。		 當多個實例分散到區域時，您的應用程式可以承受單一區域中的失敗。 如果某個區域無法使用，流量會自動轉移到其他區域中狀況良好的實例，並維護應用程式可靠性。
應用程式服務 請考慮停用應用程式要求路由 （ARR） 親和性功能。 ARR 親和性會建立黏性會話，以將使用者重新導向至處理先前要求的節點。 當您停用ARR親和性時，連入要求會平均分散到所有可用的節點。 平均分散式要求可防止流量壓倒任何單一節點。 如果節點無法使用，可以將要求順暢地重新導向至其他狀況良好的節點。

請避免會話親和性，以確保App Service 實例保持無狀態。 無狀態 App Service 可降低複雜度，並確保節點之間的一致行為。

拿掉黏性會話，讓 App Service 可以新增或移除實例以水平調整。
應用程式服務 根據要求計數、慢速要求、記憶體限制和其他屬於效能基準的指標，定義自動修復規則 。 將此設定視為調整策略的一部分。 自動修復規則可協助您的應用程式自動從非預期的問題中復原。 設定的規則會在違反臨界值時觸發修復動作。

自動修復可自動主動維護。
應用程式服務 啟用健康情況檢查功能 ，並提供回應健康情況檢查要求的路徑。 健康情況檢查可以提早偵測到問題。 然後系統可以在健康情況檢查要求失敗時自動採取更正動作。

負載平衡器會將流量從狀況不良的實例路由傳送，以將使用者導向狀況良好的節點。

安全性

安全性要素的目的是為工作負載提供 機密性、完整性和可用性 保證。

安全性 設計原則 提供高階設計策略，可藉由將方法套用至 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 方案參與者、網站參與者，以及一般參與者、讀者和擁有者。

  • 控制來自應用程式的網路流量：請勿向公用因特網公開應用程式端點。 相反地，在放置於專用子網的 Web 應用程式上新增私人端點。 使用與該私人端點通訊的反向 Proxy，將應用程式前端。 請考慮針對該用途使用 應用程式閘道 或 Azure Front Door。

    部署 Web 應用程式防火牆 （WAF） 以防止常見的弱點。 應用程式閘道 和 Azure Front Door 都有整合式 WAF 功能。

    適當地設定反向 Proxy 規則和網路設定，以達到所需的安全性和控制層級。 例如，在私人端點子網上新增NSG規則，以只接受來自反向 Proxy 的流量。

    從應用程式到其他 PaaS 服務的輸出流量應該透過私人端點。 請考慮放置防火牆元件來限制對公用因特網的輸出流量。 這兩種方法都會防止數據外流。

    如需完整的檢視，請參閱 App Service 網路功能。

  • 加密數據：使用端對端傳輸層安全性來保護傳輸中的數據（TLS）。 使用客戶管理的金鑰來完整加密待用數據。 如需詳細資訊，請參閱 使用客戶管理的密鑰進行待用加密。

    請勿使用舊版通訊協定，例如 TLS 1.0 和 1.1。 App Service 預設會啟用 1.2。 如需詳細資訊，請參閱 App Service TLS 概觀。

    App Service 的所有實例都有預設功能變數名稱。 使用自定義網域，並使用憑證保護該網域。

  • 減少受攻擊面：移除您不需要的預設組態。 例如，停用遠端偵錯、原始檔控制管理員 （SCM） 網站的本機驗證，以及基本身份驗證。 停用不安全的通訊協定，例如 HTTP 和檔案傳輸通訊協定 （FTP）。 透過 Azure 原則強制執行設定。 如需詳細資訊，請參閱 Azure 原則。

    實作限制性的跨原始資源分享 （CORS） 原則：在 Web 應用程式中使用限制性的 CORS 原則，只接受來自允許網域、標頭和其他準則的要求。 使用內建的 Azure 原則定義強制執行 CORS 原則。

  • 保護應用程式秘密：您需要處理敏感性資訊，例如 API 金鑰或驗證令牌。 您可以在應用程式設定中使用 Azure 金鑰保存庫 參考，而不是將這些秘密直接編碼到您的應用程式程式代碼或組態檔中。 應用程式啟動時，App Service 會使用應用程式的受控識別，自動從 金鑰保存庫 擷取秘密值。

  • 啟用應用程式的資源記錄：啟用應用程式的資源記錄，以建立完整的活動線索，在調查期間提供遵循安全性事件的重要數據。

    當您評估威脅時，請考慮記錄作為威脅模型化程式的一部分。

建議
服務或方案 建議 優點
應用程式服務 將受控識別 指派給 Web 應用程式。 若要維護隔離界限，請勿跨應用程式共用或重複使用身分識別。

如果您使用容器進行部署，請務必安全地連線到容器登錄。		 應用程式會從 金鑰保存庫 擷取秘密，以驗證應用程式的向外通訊。 Azure 會管理身分識別，而且不需要您布建或輪替任何秘密。

您有不同的身分識別，可用於控制數據粒度。 如果身分識別遭到入侵，不同的身分識別會讓撤銷變得容易。
應用程式服務 設定 應用程式的自定義網域 。

停用 HTTP，並只接受 HTTPS 要求。		 自定義網域會使用安全套接字層 （SSL） 或 TLS 通訊協定，透過 HTTPS 啟用安全通訊，以確保敏感數據的保護並建立使用者信任。
應用程式服務 評估 App Service 內建驗證是否為驗證使用者存取應用程式的正確機制。 App Service 內建驗證會與 Microsoft Entra ID 整合。 此功能可跨多個登入提供者處理令牌驗證和使用者身分識別管理，並支援 OpenID 連線。 使用這項功能時，您沒有細微層級的授權，而且沒有測試驗證的機制。 當您使用這項功能時，您不需要在應用程式程式代碼中使用驗證連結庫，這可降低複雜性。 當要求到達應用程式時，用戶已經通過驗證。
應用程式服務 設定虛擬網路整合的應用程式。

針對 App Service 應用程式使用私人端點。 封鎖所有公用流量。

透過虛擬網路整合路由傳送容器映像提取。 來自應用程式的所有連出流量都會通過虛擬網路。		 取得使用 Azure 虛擬網路的安全性優點。 例如，應用程式可以安全地存取網路內的資源。

新增私人端點以協助保護您的應用程式。 私人端點會限制直接公開至公用網路，並允許透過反向 Proxy 進行受控存取。
應用程式服務 若要實作強化：
- 停用使用使用者名稱和密碼的基本身份驗證 ，以利於 Microsoft Entra ID 型驗證。
- 關閉遠端偵錯，讓輸入埠未開啟。
- 啟用 CORS 原則 以收緊傳入要求。
- 停用通訊協定，例如 FTP。		 我們不建議使用基本身份驗證作為安全的部署方法。 Microsoft Entra ID 採用 OAuth 2.0 令牌型驗證，可提供許多優點和增強功能，以解決與基本身份驗證相關聯的限制。

原則會限制對應用程式資源的存取、只允許來自特定網域的要求，以及保護跨區域要求。
應用程式服務 一律使用 金鑰保存庫 參考作為應用程式設定。
秘密會與應用程式的組態分開。 應用程式設定會在待用時加密。 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 節省方案可用於您在 進階版 V3 層和 App Service 環境 中布建的專用計算。

針對具有可預測使用模式的穩定工作負載使用保留實例。		 開發/測試計劃可為 Azure 服務提供降低的費率，使其符合非生產環境的成本效益。

使用保留實例預付計算資源並取得重大折扣。
應用程式服務 監視App Service 資源所產生的成本 。 在 Azure 入口網站 中執行成本分析工具。

建立預算和警示 以通知項目關係人。		 您可以儘早找出成本尖峰、效率低下或非預期的費用。 這種主動式方法可協助您提供預算控制，以防止超支。
App Service 方案 當需求減少時相應縮小。 若要相應縮小，請定義調整規則以減少 Azure 監視器中的實例數目。 防止浪費並降低不必要的費用。

卓越營運

卓越營運主要著重於開發實務、可觀察性和發行管理的程式。

營運卓越設計原則提供高階設計策略，以達成這些目標，以達到工作負載的作業需求。

設計檢查清單

根據 Operational Excellence 的設計檢閱檢查清單，開始您的設計策略，以定義與 Web Apps 相關的可觀察性、測試和部署程式。

  • 管理版本：使用部署位置有效地管理版本。 您可以將應用程式部署至位置、執行測試，以及驗證其功能。 驗證之後，您可以順暢地將應用程式移至生產環境。 此程式不會產生額外的成本，因為位置會在與生產實例相同的虛擬機 （VM） 環境中執行。

  • 執行自動化測試：在升級 Web 應用程式的發行之前，請先徹底測試其效能、功能和與其他元件的整合。 使用 Azure 負載測試，其與 Apache JMeter 整合，這是效能測試的熱門工具。 探索其他類型的測試自動化工具，例如用於功能測試的虛設。

  • 部署不可變單位：實 作部署戳記模式 ，將App Service分割成不可變的戳記。 App Service 支援使用原本不可變的容器。 請考慮 App Service Web 應用程式的自訂容器 。

    每個戳記都代表一個獨立單位，您可以快速相應放大或相應縮小。 以這個戳記為基礎的單位是暫時的和無狀態的。 無狀態設計可簡化作業和維護。 此方法非常適合任務關鍵性應用程式。 如需範例，請參閱 App Service 的任務關鍵基準。

    使用基礎結構即程序代碼 （IaC） 技術，例如 Bicep，來淘汰具有重複性和一致性的單位。

  • 保護生產環境安全：建立個別的App Service方案以執行生產環境與生產前環境。 請勿直接在生產環境中進行變更，以確保穩定性和可靠性。 不同的實例可讓您在將變更升階至生產環境之前，在開發和測試方面具有彈性。

    使用低環境以隔離的方式探索新功能和組態。 保持開發和測試環境暫時性。

  • 管理憑證：針對自定義網域，您必須管理 TLS 憑證。

    有程式可進行採購、更新及驗證憑證。 如果可能，將這些程式卸除至 App Service。 如果您使用自己的憑證，則必須管理其更新。 選擇最符合您安全性需求的方法。

服務或方案 建議 優點
應用程式服務 監視實例 的健康情況，並啟動實例健康情況探查。

設定處理健康情況探查要求的特定路徑。		 您可以立即偵測問題，並採取必要的動作來維護可用性和效能。
應用程式服務 啟用應用程式和實例的診斷記錄 。

頻繁的記錄可能會降低系統的效能、增加記憶體成本，並在您有不安全的記錄存取權時帶來風險。 請遵循下列最佳做法：
- 記錄正確的資訊層級。
- 設定保留原則。
- 保留授權存取的稽核線索和未經授權的嘗試。
- 將記錄視為數據並套用數據保護控制項。		 診斷記錄可讓您深入瞭解應用程式的行為。 監視流量模式並識別異常狀況。
應用程式服務 利用 App Service 受控憑證 ，將認證管理卸載至 Azure。 App Service 會自動處理憑證採購、憑證驗證、憑證更新，以及從 金鑰保存庫 匯入憑證等程式。 或者，將您的憑證上傳至 金鑰保存庫，並授權 App Service 資源提供者存取它。
App Service 方案 先驗證預備位置 中的應用程式變更，再將它與生產位置交換。 避免停機時間和錯誤。

如果您在交換之後偵測到問題，請快速還原為最後已知的良好狀態。

效能效率

效能效率是維護用戶體驗， 即使藉由管理容量增加負載 也一定。 此策略包括調整資源、識別和優化潛在的瓶頸，以及優化尖峰效能。

效能效率設計原則提供針對預期使用量達成這些容量目標的高階設計策略。

設計檢查清單

根據 效能效率 的設計檢閱檢查清單，根據 Web Apps 的關鍵效能指標來定義基準，開始您的設計策略。

  • 識別和監視效能指標：為應用程式設定關鍵指標的目標，例如連入要求的數量、應用程式回應要求所需的時間、擱置的要求，以及 HTTP 回應中的錯誤。 請考慮將關鍵指標視為工作負載效能基準的一部分。

    擷取構成效能指標基礎的 App Service 計量。 收集記錄以深入瞭解資源使用量和活動。 使用應用程式效能監視 （APM） 工具，例如 Application Insights，從應用程式收集和分析效能數據。 如需詳細資訊，請參閱 App Service 監視數據參考。

    包含程式代碼層級檢測、交易追蹤和效能分析。

  • 評估容量：模擬各種使用者案例，以判斷處理預期流量所需的最佳容量。 使用負載測試來瞭解應用程式在不同負載層級下的行為。

  • 選取正確的階層：針對生產工作負載使用專用計算。 進階版 層提供較大的 SKU，並增加記憶體和 CPU 容量、更多實例，以及更多功能，例如區域備援。 如需詳細資訊，請參閱 進階版 V3 定價層。

  • 優化調整策略：可能的話，請使用 自動 調整，而不是在應用程式負載變更時手動調整實例數目。 使用自動調整時，App Service 會根據預先定義的規則或觸發程式調整伺服器容量。 請確定您進行適當的效能測試，併為正確的觸發程式設定正確的規則。

    如果您在初始設定期間設定簡化優先順序，請使用不需要您定義規則且只需要設定限制的自動調整選項。

    有足夠的資源可供使用，以確保最佳效能。 適當地配置資源以維護效能目標，例如響應時間或輸送量。 視需要考慮過度配置資源。

    當您定義自動調整規則時，請記下應用程式初始化所需的時間。 當您做出所有調整決策時，請考慮此額外負荷。

  • 使用快取：從不會經常變更且存取成本高昂的資源擷取資訊會影響效能。 複雜的查詢，包括聯結和多個查閱，都有助於運行時間。 執行快取，以將處理時間和延遲降到最低。 快取查詢結果，以避免重複往返資料庫或後端，並減少後續要求的處理時間。

    如需在工作負載中使用本機和分散式快取的詳細資訊，請參閱 快取。

  • 檢閱效能反模式：若要確定 Web 應用程式會根據您的業務需求執行和調整，請避免 典型的反模式。 以下是 App Service 修正的一些反模式。

    Antipattern 描述
    忙碌前端 資源密集型工作可以增加使用者要求的回應時間，並造成高延遲。
    將耗用大量資源的處理程式移至個別的後端。 使用訊息代理程式將後端所挑選的資源密集型工作排入佇列，以異步方式處理。
    沒有快取 在後端資料庫前面提供來自中繼快取的要求，以減少延遲。
    嘈雜的鄰居 多租用戶系統會在租用戶之間共享資源。 一個租用戶的活動可能會對另一個租用戶的系統使用產生負面影響。 App Service 環境 提供完全隔離且專用的環境來執行App Service 應用程式。
建議
建議 優點
當應用程式共用單一 App Service 方案時，啟用 AlwaysOn 設定。 App Service 應用程式會在閒置時自動卸除以節省資源。 下一個要求會觸發冷啟動，這可能會導致要求逾時。 應用程式永遠不會在啟用 Always On 時卸除。
請考慮針對應用程式使用 HTTP/2 以改善通訊協定效率。 選擇 HTTP/2 over HTTP/1.1，因為 HTTP/2 完全多任務連接、重複使用聯機以減少額外負荷，並壓縮標頭以將數據傳輸降到最低。

取捨

如果您使用柱子檢查清單中的方法，您可能需要進行設計取捨。 以下是一些優點和缺點範例。

密度

在相同的 App Service 方案中共置多個應用程式，以將資源降到最低。 所有應用程式都會共用 CPU 和記憶體等資源，以節省成本並降低作業複雜度。 此方法也會優化資源使用量。 如果負載模式隨著時間變更，應用程式可以使用來自另一個應用程式的閑置資源。

也請考慮缺點。 例如，應用程式使用量或不穩定的尖峰可能會影響其他應用程式的效能。 一個應用程式中的事件也可以滲透到共用環境中的其他應用程式，這可能會影響安全性。

隔離

隔離有助於避免干擾。 此策略適用於開發、測試和生產環境的安全性、效能，甚至隔離。

App Service 環境 提供更好的安全性和數據保護控制，因為每個應用程式都可以有自己的安全性設定。 您的環境可能會包含缺口，因為隔離會限制爆破半徑。 從效能的觀點來看，資源爭用會最小化。 隔離可根據特定需求和個別容量規劃進行獨立調整。

作為缺點，這種方法成本更高，而且需要操作嚴謹。

可靠的調整策略

妥善定義的調整策略可確保您的應用程式可以處理各種負載，而不會影響效能。 不過，成本有取捨。 調整作業需要時間。 配置新的資源時，必須先正確初始化應用程式，才能有效地處理要求。 您可以過度布建資源（預先部署實例），以提供安全網。 如果沒有額外的容量，在初始化階段，服務要求可能會延遲，這會影響用戶體驗。 自動調整作業可能會提前觸發，以便客戶使用資源時啟用適當的資源初始化。

作為缺點，過度布建的資源成本更高。 我們會向您收取每個執行個體每秒的費用，包括預熱的執行個體。 較高層包含預先設定的實例。 判斷具有更昂貴層的功能是否值得投資。

建置備援

備援提供復原功能，但也會產生成本。 工作負載的服務等級目標（SLO）會決定可接受的效能閾值。 如果備援超過 SLO 需求，就會變得浪費。 評估多餘的備援是否可改善 SLO，或增加不必要的複雜度。

也請考慮缺點。 例如，多區域備援可提供高可用性，但會因為數據同步處理、故障轉移機制和區域間通訊而增加複雜度和成本。 判斷區域備援是否符合您的 SLO。

Azure 原則

Azure 提供一組與 App Service 及其相依性相關的大量內建原則。 一組 Azure 原則可以稽核上述一些建議。 例如，您可以檢查是否：

  • 適當的網路控制已就緒。 例如，您可以藉由透過虛擬網路插入將App Service 放在 Azure 虛擬網絡 以進一步控制網路組態，以納入網路分割。 應用程式沒有公用端點，並透過私人端點連線到 Azure 服務。

  • 身分識別控件已就緒。 例如，應用程式會使用受控識別來向其他資源驗證自己。 App Service 內建驗證會驗證傳入要求。

  • 您可以停用遠端偵錯和基本身份驗證等功能，以減少受攻擊面。

如需全面治理，請檢閱 Azure 原則 內建定義和其他可能會影響計算層安全性的原則。

Azure Advisor 建議

Azure Advisor 是個人化的雲端顧問，可協助您遵循最佳做法來將 Azure 部署最佳化。 以下是一些建議，可協助您改善 Web 應用程式實例的可靠性、安全性、成本效益、效能和營運卓越性。

下一步

請考慮下列文章做為資源，示範本文所醒目提示的建議。