適用於 Java 的可靠 Web 應用程式模式

Azure App Service

Azure Front Door

本文提供實作 Reliable Web 應用程式模式的指引。此模式概述如何修改（replatform） Web 應用程式以進行雲端移轉。它提供符合良好架構架構原則的規範架構、程式代碼和設定指引。

為什麼適用於 Java 的 Reliable Web 應用程式模式？

Reliable Web App 模式是一組原則和實作技術，可定義移轉至雲端時應該如何重新建立 Web 應用程式。其著重於在雲端中成功所需的最少程式碼更新。下列指引會在整個過程中使用參考實作作為範例，並遵循虛構公司 Contoso Fiber 的重新平臺旅程，為您的旅程提供商務內容。在實作適用於 Java 的可靠 Web 應用程式模式之前，Contoso Fiber 具有使用 Spring Boot 架構的整合式內部部署客戶帳戶管理系統（CAMS）。

提示

GitHub 標誌。可靠的 Web 應用程式模式有參考實作（範例）。它代表 Reliable Web App 實作的結束狀態。這是生產等級的 Web 應用程式，其中包含本文所討論的所有程式代碼、架構和組態更新。部署並使用參考實作來引導您實作 Reliable Web 應用程式模式。

如何實作 Reliable Web 應用程式模式

本文包含實作 Reliable Web 應用程式模式的架構、程式代碼和設定指引。使用下列連結瀏覽至您需要的特定指引：

商務內容：將此指引與您的商務內容對齊，並瞭解如何定義可推動重新制定決策的立即和長期目標。
架構指引：瞭解如何選取正確的雲端服務，並設計符合您業務需求的架構。
程序代碼指引：實作三種設計模式，以改善雲端 Web 應用程式的可靠性與效能效率：重試、斷路器和快取擱置模式
設定指引：設定驗證和授權、受控識別、許可權化環境、基礎結構即程式代碼和監視。

商務內容

重新格式化 Web 應用程式的第一個步驟是定義您的商務目標。您應該設定立即目標，例如服務等級目標和成本優化目標，以及 Web 應用程式的未來目標。這些目標會影響您在雲端中選擇的雲端服務和 Web 應用程式的架構。定義 Web 應用程式的目標 SLO，例如 99.9% 執行時間。計算影響 Web 應用程式可用性之所有服務的複合 SLA。

例如，Contoso Fiber 想要擴充其內部部署客戶帳戶管理系統（CAMS） Web 應用程式以連線到其他區域。為了符合 Web 應用程式增加的需求，他們建立了下列目標：

套用低成本、高價值的程式代碼變更
達到服務等級目標 99.9%
採用DevOps做法
建立成本優化的環境
改善可靠性和安全性

Contoso Fiber 判斷其內部部署基礎結構不是調整應用程式符合成本效益的解決方案。因此，他們決定將 CAMS Web 應用程式移轉至 Azure 是達成其立即和未來目標最符合成本效益的方式。

架構指導

Reliable Web 應用程式模式有一些基本的架構元素。您需要 DNS 來管理端點解析、Web 應用程式防火牆來封鎖惡意 HTTP 流量，以及負載平衡器來保護和路由輸入使用者要求。應用程式平台會裝載 Web 應用程式程式碼，並透過虛擬網路中的私人端點呼叫所有後端服務。應用程式效能監視工具會擷取計量和記錄，以瞭解您的 Web 應用程式。

圖 1. Reliable Web 應用程式模式的基本架構元素。

設計架構

設計基礎結構以支持復原計量，例如復原時間目標（RTO）和恢復點目標（RPO）。 RTO 會影響可用性，且必須支援您的 SLO。判斷恢復點目標（RPO），並設定數據備援以符合 RPO。

選擇基礎結構可靠性。 判斷您需要多少個可用性區域和區域，以符合您的可用性需求。新增可用性區域和區域，直到複合 SLA 符合您的 SLO 為止。 Reliable Web 應用程式模式支持主動-主動或主動-被動設定的多個區域。例如，參考實作會使用主動-被動設定來符合 99.9% 的 SLO。

針對多區域 Web 應用程式，請設定負載平衡器，以根據您的業務需求，將流量路由傳送至第二個區域，以支持主動-主動或主動-被動設定。這兩個區域需要相同的服務，但其中一個區域有連接區域的中樞虛擬網路。採用中樞和輪輻網路拓撲來集中和共用資源，例如網路防火牆。如果您有虛擬機，請將防禦主機新增至中樞虛擬網路，以安全地管理它們（請參閱圖 2）。

圖 2. 具有第二個區域和中樞和輪輻拓撲的 Reliable Web 應用程式模式。
選擇網路拓撲。 為您的 Web 和網路需求選擇正確的網路拓撲。如果您打算擁有多個虛擬網路，請使用中樞和輪輻網路拓撲。它提供內部部署和虛擬網路混合式連線選項的成本、管理和安全性優點。

挑選正確的 Azure 服務

當您將 Web 應用程式移至雲端時，您應該選取符合商務需求的 Azure 服務，並符合內部部署 Web 應用程式的目前功能。對齊有助於將重新調整工作降到最低。例如，使用可讓您保留相同資料庫引擎並支援現有中間件和架構的服務。下列各節提供為 Web 應用程式選取正確 Azure 服務的指引。

例如，在移至雲端之前，Contoso Fiber 的 CAMS Web 應用程式是內部部署的整合型 Java Web 應用程式。它是具有 PostgreSQL 資料庫的 Spring Boot 應用程式。 Web 應用程式是企業營運支援應用程式。這是員工面向的。 Contoso Fiber 員工會使用應用程式來管理客戶的支援案例。 Web 應用程式在延展性和功能部署方面面臨常見的挑戰。這個起點，他們的業務目標，SLO 推動他們的服務選擇。

應用程式平臺：使用 Azure App 服務作為您的應用程式平臺。 Contoso Fiber 選擇 Azure App 服務作為應用程式平臺，原因如下：
- 自然進展： Contoso Fiber 在其內部部署伺服器上部署 Spring Boot jar 檔案，並想要將該部署模型的重新架構數量降到最低。 App Service 提供執行 Spring Boot 應用程式的健全支援，而 Contoso Fiber 使用 App Service 是自然進展。 Azure Container Apps 也是此應用程式的有吸引力的替代方案。如需詳細資訊，請參閱什麼是 Azure Spring Apps？和 Azure Container Apps 上的 Java 概觀。
- 高 SLA： 其具有符合生產環境需求的高 SLA。
- 降低管理負擔： 這是完全受控的裝載解決方案。
- 容器化功能： App Service 可與 Azure Container Registry 等私人容器映射登錄搭配使用。 Contoso Fiber 未來可以使用這些登錄來容器化 Web 應用程式。
- 自動調整： Web 應用程式可以根據使用者流量，快速相應增加、減少、縮小和相應放大。
身分識別管理： 使用 Microsoft Entra ID 作為您的身分識別和存取管理解決方案。 Contoso Fiber 基於下列原因選擇 Microsoft Entra ID ：
- 驗證和授權： 應用程式需要驗證和授權來電中心員工。
- 可調整： 可調整以支援較大的案例。
- 使用者身分識別控制： 客服中心員工可以使用其現有的企業身分識別。
- 授權通訊協議支援： 它支援適用於受控識別的 OAuth 2.0。
資料庫： 使用可讓您保留相同資料庫引擎的服務。使用數據存放區判定樹。 Contoso Fiber 選擇適用於 PostgreSQL 的 Azure 資料庫和彈性伺服器選項，原因如下：
- 可靠性： 彈性伺服器部署模型支援跨多個可用性區域的區域備援高可用性。此設定會在相同 Azure 區域內的不同可用性區域中維護暖待命伺服器。組態會將數據同步復寫至待命伺服器。
- 跨區域復寫： 它具有讀取複本功能，可讓您以異步方式將數據復寫到另一個區域中的只讀複本資料庫。
- 效能： 它提供可預測的效能和智慧型手機微調，以使用實際的使用量數據來改善資料庫效能。
- 降低管理負擔： 這是一項完全受控的 Azure 服務，可降低管理義務。
- 移轉支援： 它支援從內部部署單一伺服器 PostgreSQL 資料庫進行資料庫移轉。他們可以使用移轉工具來簡化移轉程式。
- 與內部部署設定的一致性： 它支援不同的 PostgreSQL 社群版本，包括 Contoso Fiber 目前使用的版本。
- 復原功能。 彈性伺服器部署會自動建立伺服器備份，並使用區域備援記憶體（ZRS）儲存在同一區域內。他們可以將其資料庫還原到備份保留期間內的任何時間點。備份和還原功能會建立比 Contoso Fiber 建立內部部署更好的 RPO（可接受的數據遺失量）。
應用程式效能監視： 使用 Application Insights 分析應用程式上的遙測。 Contoso Fiber 選擇使用 Application Insights 的原因如下：
- 與 Azure 監視器整合： 它提供與 Azure 監視器的最佳整合。
- 異常偵測： 它會自動偵測效能異常。
- 疑難解答： 它可協助您診斷執行中應用程式的問題。
- 監視： 它會收集使用者如何使用應用程式的相關信息，並可讓您輕鬆地追蹤自定義事件。
- 可見度差距： 內部部署解決方案沒有應用程式效能監視解決方案。 Application Insights 可讓您輕鬆地與應用程式平台和程式代碼整合。
快取： 選擇是否要將快取新增至 Web 應用程式架構。 Azure Cache for Redis 是 Azure 的主要快取解決方案。它是以 Redis 軟體為基礎的受控記憶體內部數據存放區。 Contoso Fiber 已新增 Azure Cache for Redis，原因如下：
- 速度和磁碟區： 它具有高數據輸送量和低延遲讀取，適用於經常存取、變更緩慢的數據。
- 各種支援性： 這是 Web 應用程式的所有實例都可以使用的統一快取位置。
- 外部數據存放區。 內部部署應用程式伺服器執行 VM 本機快取。此設定不會卸除高度頻繁的數據，而且無法使數據失效。
- 非粘性會話： 快取可讓 Web 應用程式外部化工作階段狀態，並使用非粘性工作階段。大部分在內部部署執行的 Java Web 應用程式都會使用記憶體內部、用戶端快取。記憶體內部、用戶端快取無法正常調整，並增加主機上的記憶體使用量。藉由使用 Azure Cache for Redis，Contoso Fiber 具有完全受控、可調整的快取服務，以改善其應用程式的延展性和效能。 Contoso Fiber 使用快取抽象架構（Spring Cache），只需要最少的組態變更來交換快取提供者。它允許他們從 Ehcache 提供者切換到 Redis 提供者。
負載平衡器：使用 PaaS 解決方案的 Web 應用程式應該使用 Azure Front Door、Azure 應用程式閘道，或根據 Web 應用程式架構和需求。使用負載平衡器判定樹來挑選正確的負載平衡器。 Contoso Fiber 需要第 7 層負載平衡器，才能跨多個區域路由傳送流量。 Contoso Fiber 需要多區域 Web 應用程式，才能符合 SLO 的 99.9%。 Contoso Fiber 選擇 Azure Front Door 的原因如下：
- 全域負載平衡： 這是第 7 層負載平衡器，可跨多個區域路由傳送流量。
- Web 應用程式防火牆：它會以原生方式與 Azure Web 應用程式防火牆整合。
- 路由彈性： 它可讓應用程式小組設定輸入需求，以支援應用程式未來的變更。
- 流量加速： 它會使用 anycast 到達最接近的 Azure 存在點，並尋找通往 Web 應用程式的最快路由。
- 自定義網域： 它支援具有彈性網域驗證的自定義功能變數名稱。
- 健康情況探查： 應用程式需要智慧型健康情況探查監視。 Azure Front Door 會使用來自探查的回應來判斷路由用戶端要求的最佳來源。
- 監視支援： 它支援內建報表，其中包含 Front Door 和安全性模式的全方位儀錶板。您可以設定與 Azure 監視器整合的警示。它可讓應用程式記錄每個要求和失敗的健康情況探查。
- DDoS 保護： 它有內建第 3-4 層 DDoS 保護。
- 內容傳遞網路： 它會將 Contoso Fiber 定位為使用內容傳遞網路。內容傳遞網路提供網站加速。
Web 應用程式防火牆：使用 Azure Web 應用程式防火牆提供集中式保護，防止常見的 Web 惡意探索和弱點。 Contoso Fiber 使用 Azure Web 應用程式防火牆的原因如下：
- 全域保護： 它提供改良的全域 Web 應用程式保護，而不會犧牲效能。
- Botnet 保護： 小組可以監視和設定設定，以解決與歹屍網路相關的安全性考慮。
- 與內部部署相同： 內部部署解決方案是在IT所管理的Web應用程式防火牆後方執行。
- 易於使用：Web 應用程式防火牆與 Azure Front Door 整合。
秘密管理員：如果您有在 Azure 中管理秘密，請使用 Azure 金鑰保存庫。 Contoso Fiber 使用金鑰保存庫的原因如下：
- 加密： 它支援待用和傳輸中的加密。
- 受控識別支援： 應用程式服務可以使用受控識別來存取秘密存放區。
- 監視和記錄： 它有助於稽核存取，並在儲存的秘密變更時產生警示。
- 整合：它提供與 Azure 組態存放區（應用程式組態）和 Web 主控平臺（App Service）的原生整合。
端點安全性： 使用 Azure Private Link 透過虛擬網路中的私人端點存取平臺即服務解決方案。虛擬網路與服務之間的流量會跨越Microsoft骨幹網路。 Contoso Fiber 選擇 Private Link 的原因如下：
- 增強的安全性通訊： 它可讓應用程式私下存取 Azure 平臺上的服務，並減少數據存放區的網路使用量，以協助防止數據外洩。
- 最少的努力： 私人端點支援 Web 應用程式所使用的 Web 應用程式平臺和資料庫平臺。這兩個平臺都會鏡像現有的內部部署組態，以取得最少的變更。
網路安全性：使用 Azure 防火牆來控制網路層級的輸入和輸出流量。使用 Azure Bastion 安全地連線到虛擬機，而不需要公開 RDP/SSH 埠。 Contoso Fiber 採用中樞和輪輻網路拓撲，並想要將共用網路安全性服務放在中樞。 Azure 防火牆藉由檢查輪輻的所有輸出流量來提高網路安全性，以改善安全性。 Contoso Fiber 需要 Azure Bastion，才能從 DevOps 子網中的跳躍主機進行安全部署。

程序代碼指引

若要成功將 Web 應用程式移至雲端，您必須使用重試模式、斷路器模式和快取保留設計模式來更新 Web 應用程式程式代碼。

圖 3. 設計模式的角色。

每個設計模式都提供工作負載設計優點，以配合建構良好架構架構的其中一個支柱。以下是您應該實作的模式概觀：

重試模式：重試模式會重試間歇性失敗的作業來處理暫時性失敗。在所有對其他 Azure 服務的輸出呼叫上實作此模式。
斷路器模式：斷路器模式可防止應用程式重試非暫時性的作業。在所有對其他 Azure 服務的輸出呼叫中實作此模式。
Cache-Aside 模式：Cache-Aside 模式會比數據存放區更頻繁地新增和擷取快取。在對資料庫的要求上實作此模式。

設計模式	可靠性（RE）	效能效率（PE）	支援 WAF 原則
重試模式	✔		RE：07
斷路器模式	✔	✔	RE：03 RE：07 PE：07 PE：11
快取擱置模式	✔	✔	RE：05 PE：08 PE：12

實作重試模式

將重試模式新增至您的應用程式程式代碼，以解決暫時服務中斷的問題。這些中斷稱為暫時性錯誤。暫時性錯誤通常會在幾秒內自行解決。重試模式可讓您重新傳送失敗的要求。它也可讓您設定要求延遲和失敗前嘗試次數。

使用輕量型容錯連結庫 Resilience4j，在 Java 中實作重試模式。例如，參考實作會使用 Retry 註釋裝飾 Service Plan Controller 的 listServicePlans 方法，以新增重試模式。如果初始呼叫失敗，程式代碼會從資料庫重試對服務方案清單的呼叫。參考實作會設定重試原則，包括重試次數上限、等候持續時間，以及應重試哪些例外狀況。重試原則是在中 application.properties設定。

    @GetMapping("/list")
    @PreAuthorize("hasAnyAuthority('APPROLE_AccountManager')")
    @CircuitBreaker(name = SERVICE_PLAN)
    @Retry(name = SERVICE_PLAN)
    public String listServicePlans(Model model) {
        List<serviceplandto> servicePlans = planService.getServicePlans();
        model.addAttribute("servicePlans", servicePlans);
        return "pages/plans/list";
    }

實作斷路器模式

使用斷路器模式來處理非暫時性錯誤的服務中斷。斷路器模式可防止應用程式持續嘗試存取非回應服務。它會釋放應用程式，並避免浪費 CPU 週期，讓應用程式保留其終端使用者的效能完整性。

使用 Spring Circuit Breaker 和 Resilience4j 檔來實作斷路器模式。例如，參考實作會使用斷路器屬性裝飾方法，以實作斷路器模式。

實作 Cache-Aside 模式

將 Cache-Aside 模式新增至 Web 應用程式，以改善記憶體內部數據管理。此模式會指派應用程式處理數據要求的責任，並確保快取與持續性記憶體之間的一致性，例如資料庫。其可縮短響應時間、增強輸送量，並減少更多調整的需求。它也會降低主要數據存放區上的負載，以改善可靠性和成本優化。若要實作 Cache-Aside 模式，請遵循下列建議：

設定應用程式以使用快取。 若要啟用快取，請將套件新增 spring-boot-starter-cache 為檔案 pom.xml 中的相依性。此套件提供 Redis 快取的預設組態。
快取高需求數據。 在高需求數據上套用 Cache-Aside 模式，以放大其有效性。使用 Azure 監視器來追蹤資料庫的 CPU、記憶體和記憶體。這些計量可協助您判斷在套用 Cache-Aside 模式之後，是否可以使用較小的資料庫 SKU。若要快取程式代碼中的特定數據，請新增 @Cacheable 批注。此批注會告知 Spring 哪些方法應該快取其結果。
讓快取數據保持最新狀態。 排程定期快取更新，以與最新的資料庫變更同步。根據數據波動性和使用者需求，判斷最佳的重新整理速率。這種做法可確保應用程式使用 Cache-Aside 模式來提供快速存取和目前資訊。默認快取設定可能不適合您的 Web 應用程式。您可以在檔案或環境變數中 application.properties 自定義這些設定。例如，您可以修改 spring.cache.redis.time-to-live 值（以毫秒表示）來控制數據在收回之前應該保留在快取中的時間長度。
確保數據一致性。 實作機制，以在任何資料庫寫入作業之後立即更新快取。使用事件驅動更新或專用數據管理類別，以確保快取一致性。一致地同步處理快取與資料庫修改是 Cache-Aside 模式的核心。

設定指引

下列各節提供實作組態更新的指引。每個區段都與一或多個「架構良好架構」的支柱對齊。

組態	可靠性（RE）	安全性（SE）	成本優化（CO）	卓越營運（OE）	效能效率（PE）	支援 WAF 原則
設定使用者驗證和授權		✔		✔		SE：05 OE：10
實作受控識別		✔		✔		SE：05 OE：10
正確大小環境			✔			CO：05 CO：06
實作自動調整	✔		✔		✔	RE：06 CO：12 PE：05
自動資源部署				✔		OE：05
實作監視			✔	✔	✔	OE：07 PE：04

設定使用者驗證和授權

當您將 Web 應用程式移轉至 Azure 時，請設定使用者驗證和授權機制。依照下列建議進行：

使用身分識別平臺。 使用Microsoft身分識別平台來設定 Web 應用程式驗證。此平台支援使用單一Microsoft Entra 目錄、來自不同組織的多個Microsoft Entra 目錄，以及Microsoft身分識別或社交帳戶的應用程式。

適用於 Microsoft Entra 識別碼的 Spring Boot Starter 可簡化此程式，並利用 Spring Security 和 Spring Boot 輕鬆設定。它提供各種驗證流程、自動令牌管理和可自定義的授權原則，以及 Spring Cloud 元件的整合功能。這可讓您直接Microsoft Entra ID 和 OAuth 2.0 與 Spring Boot 應用程式整合，而不需要手動連結庫或設定設定。

例如，參考實作會使用 Microsoft 身分識別平台（Microsoft Entra ID）作為 Web 應用程式的識別提供者。它會使用 OAuth 2.0 授權碼授與，以使用 Microsoft Entra 帳戶登入使用者。下列 XML 代碼段會定義 OAuth 2.0 授權碼授與流程的兩個必要相依性。相依性 com.azure.spring: spring-cloud-azure-starter-active-directory 可在 Spring Boot 應用程式中啟用Microsoft Entra 驗證和授權。相依性 org.springframework.boot: spring-boot-starter-oauth2-client 支援 Spring Boot 應用程式中的 OAuth 2.0 驗證和授權。
```
<dependency>
    <groupid>com.azure.spring</groupid>
    <artifactid>spring-cloud-azure-starter-active-directory</artifactid>
</dependency>
<dependency>
    <groupid>org.springframework.boot</groupid>
    <artifactid>spring-boot-starter-oauth2-client</artifactid>
</dependency>
```

建立應用程式註冊。 Microsoft Entra 識別碼需要在主要租用戶中註冊應用程式。應用程式註冊可確保可存取 Web 應用程式的使用者在主要租使用者中具有身分識別。例如，參考實作會使用 Terraform 來建立Microsoft Entra ID 應用程式註冊，以及應用程式特定的帳戶管理員角色。

resource "azuread_application" "app_registration" {
  display_name     = "${azurecaf_name.app_service.result}-app"
  owners           = [data.azuread_client_config.current.object_id]
  sign_in_audience = "AzureADMyOrg"  # single tenant

  app_role {
    allowed_member_types = ["User"]
    description          = "Account Managers"
    display_name         = "Account Manager"
    enabled              = true
    id                   = random_uuid.account_manager_role_id.result
    value                = "AccountManager"
  }
}

在應用程式中強制執行授權。 使用角色型訪問控制（RBAC）將最低許可權指派給應用程式角色。為不同的使用者動作定義特定角色，以避免重疊並確保清楚。將用戶對應至適當的角色，並確保他們只能存取必要的資源和動作。設定 Spring Security 以針對 Microsoft Entra 識別碼使用 Spring Boot Starter。此連結庫允許與 Microsoft Entra ID 整合，並協助您確保使用者安全地進行驗證。設定及啟用Microsoft驗證連結庫（MSAL）可讓您存取更多安全性功能。這些功能包括令牌快取和自動令牌重新整理。

例如，參考實作會建立應用程式角色，以反映 Contoso Fiber 帳戶管理系統中的使用者角色類型。角色會在授權期間轉譯為許可權。 CAMS 中應用程式特定角色的範例包括客戶經理、第一級（L1）支援代表和現場服務代表。帳戶管理員角色具有新增應用程式用戶和客戶的許可權。現場服務代表可以建立支援票證。屬性 PreAuthorize 會限制對特定角色的存取。

    @GetMapping("/new")
    @PreAuthorize("hasAnyAuthority('APPROLE_AccountManager')")
    public String newAccount(Model model) {
        if (model.getAttribute("account") == null) {
            List<ServicePlan> servicePlans = accountService.findAllServicePlans();
            ServicePlan defaultServicePlan = servicePlans.stream().filter(sp -> sp.getIsDefault() == true).findFirst().orElse(null);
            NewAccountRequest accountFormData = new NewAccountRequest();
            accountFormData.setSelectedServicePlanId(defaultServicePlan.getId());
            model.addAttribute("account", accountFormData);
            model.addAttribute("servicePlans", servicePlans);
        }
        model.addAttribute("servicePlans", accountService.findAllServicePlans());
        return "pages/account/new";
    }
    ...

若要與 Microsoft Entra 識別元整合，參考實作會使用 OAuth 2.0 授權碼授與流程。此流程可讓使用者使用 Microsoft 帳戶登入。下列代碼段示範如何設定 SecurityFilterChain ，以使用 Microsoft Entra ID 進行驗證和授權。

@Configuration(proxyBeanMethods = false)
@EnableWebSecurity
@EnableMethodSecurity
public class AadOAuth2LoginSecurityConfig {
    @Bean
    SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http.apply(AadWebApplicationHttpSecurityConfigurer.aadWebApplication())
            .and()
                .authorizeHttpRequests()
            .requestMatchers(EndpointRequest.to("health")).permitAll()
            .anyRequest().authenticated()
            .and()
                .logout(logout -> logout
                            .deleteCookies("JSESSIONID", "XSRF-TOKEN")
                            .clearAuthentication(true)
                            .invalidateHttpSession(true));
        return http.build();
    }
}
...

偏好暫時存取記憶體。 使用暫時權限來防範未經授權的存取和缺口，例如共用存取簽章（SASs）。在授與暫時存取權時，使用使用者委派 SAS 將安全性最大化。這是唯一使用 Microsoft Entra ID 認證且不需要永久記憶體帳戶密鑰的 SAS。
在 Azure 中強制執行授權。 使用 Azure RBAC 將最低許可權指派給使用者身分識別。 Azure RBAC 會決定哪些 Azure 資源身分識別可以存取、這些資源可以做什麼，以及他們可存取哪些區域。
避免永久提高的許可權。 使用 Microsoft Entra Privileged Identity Management 授與特殊許可權作業的 Just-In-Time 存取權。例如，開發人員通常需要系統管理員層級的存取權，才能建立/刪除資料庫、修改數據表架構，以及變更用戶權力。使用 Just-In-Time 存取權時，使用者身分識別會收到執行特殊許可權工作的暫時許可權。

實作受控識別

針對支援受控識別的所有 Azure 服務使用受控識別。受控識別可讓 Azure 資源（工作負載身分識別）在不管理認證的情況下，向其他 Azure 服務進行驗證並與其互動。混合式和舊版系統可以保留內部部署驗證解決方案，以簡化移轉，但應儘快轉換為受控識別。若要實作受控識別，請遵循下列建議：

挑選正確的受控識別類型。當您有兩個或多個需要相同許可權集的 Azure 資源時，偏好使用使用者指派的受控識別。此設定比為每個資源建立系統指派的受控識別更有效率，並將相同的許可權指派給所有資源。否則，請使用系統指派的受控識別。
設定最低許可權。 使用 Azure RBAC 只授與對作業至關重要的許可權，例如資料庫中的 CRUD 動作或存取秘密。工作負載身分識別許可權是持續性的，因此您無法提供工作負載身分識別的 Just-In-Time 或短期許可權。如果 Azure RBAC 未涵蓋特定案例，請使用 Azure 服務層級存取原則來補充 Azure RBAC。
保護剩餘的秘密。 將任何剩餘的秘密儲存在 Azure 金鑰保存庫。在應用程式啟動時從金鑰保存庫載入秘密，而不是在每個 HTTP 要求期間載入。 HTTP 要求內的高頻率存取可能會超過金鑰保存庫交易限制。將應用程式組態儲存在 Azure 應用程式組態中。

正確大小環境

使用 Azure 服務的效能層級（SKU），以符合每個環境的需求，而不需要過多。若要適當調整您的環境大小，請遵循下列建議：

預估成本。 使用 Azure 定價計算機來估計每個環境的成本。
成本優化生產環境。 生產環境需要符合生產環境所需的服務等級協定（SLA）、功能和規模所需的 SKU。持續監視資源使用量，並調整 SKU 以符合實際效能需求。
成本優化生產前環境。生產前環境應該使用低成本的資源、停用不必要的服務，並套用折扣，例如 Azure 開發/測試定價。請確定生產前環境與生產環境完全類似，以避免引入風險。此平衡可確保測試保持有效，而不會產生不必要的成本。
使用基礎結構即程式代碼定義 SKU（IaC）。 實作 IaC 以根據環境動態選取並部署正確的 SKU。此方法可增強一致性並簡化管理。

例如，參考實作具有可部署不同 SKU 的選擇性參數。環境參數會指示 Terraform 範本選取開發 SKU。

azd env set APP_ENVIRONMENT prod

實作自動調整

自動調整可確保 Web 應用程式保持復原性、回應性，且能夠有效率地處理動態工作負載。若要實作自動調整，請遵循下列建議：

自動化向外延展。 使用 Azure 自動調整來自動化生產環境中的水平調整。設定自動調整規則，以根據關鍵效能計量相應放大，讓應用程式可以處理不同的負載。
精簡調整觸發程式。 如果您不熟悉應用程式的調整需求，請以 CPU 使用率作為初始調整觸發程式開始。精簡調整觸發程式，以包含其他計量，例如 RAM、網路輸送量和磁碟 I/O。目標是要符合 Web 應用程式的行為，以提升效能。
提供向外延展緩衝區。 設定調整閾值以觸發，再達到最大容量。例如，將調整設定為以 85% 的 CPU 使用率發生，而不是等到達到 100%。這種主動式方法有助於維護效能，並避免潛在的瓶頸。

自動資源部署

使用自動化在所有環境中部署和更新 Azure 資源和程序代碼。依照下列建議進行：

使用基礎結構即程序代碼。 透過持續整合和持續傳遞（CI/CD）管線，將基礎結構部署為程式代碼。 Azure 已針對每個 Azure 資源預先製作 Bicep、ARM （JSON）和 Terraform 範本。
使用持續整合/持續部署（CI/CD）管線。 使用 CI/CD 管線將程式代碼從原始檔控制部署到各種環境，例如測試、預備和生產環境。如果您使用適用於 GitHub 專案的 Azure DevOps 或 GitHub Actions，請使用 Azure Pipelines。
整合單元測試。 排定管線內所有單元測試的執行優先順序，並在任何部署至 App Services 之前通過。納入 SonarQube 之類的程式碼質量和涵蓋範圍工具，以達到完整的測試涵蓋範圍。
採用模擬架構。 若要測試涉及外部端點，請使用模擬架構。這些架構可讓您建立仿真的端點。它們不需要設定實際的外部端點，並確保跨環境都一致測試條件。
執行安全性掃描。 使用靜態應用程式安全性測試（SAST）來尋找原始程式碼中的安全性缺陷和編碼錯誤。此外，進行軟體組合分析（SCA），以檢查第三方連結庫和元件是否有安全性風險。這些分析的工具可以輕鬆地整合到 GitHub 和 Azure DevOps 中。

設定監視

實作應用程式和平台監視，以提升 Web 應用程式的卓越營運和效能效率。若要實作監視，請遵循下列建議：

收集應用程式遙測。 在 Azure 應用程式 Insights 中使用自動結構來收集應用程式遙測，例如要求輸送量、平均要求持續時間、錯誤和相依性監視，而不需要變更程式代碼。 Spring Boot 會在 Application Insights 中註冊數個核心計量，例如 Java 虛擬機（JVM）、CPU、Tomcat 等。 Application Insights 會自動從 Log4j 和 Logback 等記錄架構收集。例如，參考實作會使用透過 Terraform 啟用的 Application Insights 作為 App Service 設定的 app_settings 一部分。（請參閱下列程序代碼）。
```
app_settings = {
    APPLICATIONINSIGHTS_CONNECTION_STRING = var.app_insights_connection_string
    ApplicationInsightsAgent_EXTENSION_VERSION = "~3"
    ...
}
```
如需詳細資訊，請參閱
建立自定義應用程式計量。 實作程式代碼型檢測，藉由新增ApplicationInsights SDK並使用其API來擷取自定義應用程式遙測。

監視平臺。 啟用所有支援服務的診斷，並將診斷傳送至與應用程式記錄相同的目的地，以便相互關聯。 Azure 服務會自動建立平台記錄，但只會在您啟用診斷時加以儲存。針對支援診斷的每個服務啟用診斷設定。參考實作會使用 Terraform 在所有支援的服務上啟用 Azure 診斷。下列 Terraform 程式代碼會設定 App Service 的診斷設定。

# Configure Diagnostic Settings for App Service
resource "azurerm_monitor_diagnostic_setting" "app_service_diagnostic" {
  name                           = "app-service-diagnostic-settings"
  target_resource_id             = azurerm_linux_web_app.application.id
  log_analytics_workspace_id     = var.log_analytics_workspace_id
  #log_analytics_destination_type = "AzureDiagnostics"

  enabled_log {
    category_group = "allLogs"

  }

  metric {
    category = "AllMetrics"
    enabled  = true
  }
}

部署參考實作

參考實作會引導開發人員完成從內部部署 Java 應用程式到 Azure 的模擬移轉，並在初始採用階段強調必要的變更。此範例使用虛構公司 Contoso Fiber 的客戶帳戶管理系統（CAMS） Web 應用程式應用程式。 Contoso Fiber 為其 Web 應用程式設定下列目標：

實作低成本、高價值的程式代碼變更
達到服務等級目標 99.9%
採用DevOps做法
建立成本優化的環境
增強可靠性和安全性

Contoso Fiber 判斷其內部部署基礎結構不是符合這些目標的符合成本效益的解決方案。他們決定將 CAMS Web 應用程式移轉至 Azure 是達成其立即和未來目標最符合成本效益的方式。下列架構代表 Contoso Fiber 可靠 Web 應用程式模式實作的結束狀態。

圖 4.參考實作的架構。下載此架構的 Visio 檔案。

參考實作

共用方式為