本文提供實作可靠 Web 應用程式模式的指引。 此模式說明如何重新平台 Web 應用程式以進行雲端移轉。 它提供符合 Azure Well-Architected Framework 原則的規範性架構、程式碼和設定指引。
為什麼要使用 Java 的可靠 Web 應用程式模式？
可靠的 Web 應用程式模式是一組原則和實作技術，可定義當您將 Web 應用程式移轉至雲端時，如何重新平台 Web 應用程式。 它強調最少的程式碼更新，以確保在雲端取得成功。 本指南會使用參考實作作為一致的範例。 它遵循虛構公司 Contoso Fiber 的重新平台化過程，為您的移轉提供商業背景。 在 Contoso Fiber 實作適用於 Java 的可靠 Web 應用程式模式之前，它會先操作使用 Spring Boot 架構建置的整合型內部部署客戶帳戶管理系統 （CAMS）。
小提示
可靠 Web 應用程式模式的 參考實作 （範例） 代表已完成實作的最終狀態。 此生產級 Web 應用程式包含本文所述的所有程式碼、架構和設定更新。 部署並使用參考實作，以協助引導您自己的 Reliable Web App 模式實作。
如何實作可靠的 Web 應用程式模式
在本文的下列各節中尋找您需要的特定指引：
業務環境：將本指南與您的業務環境保持一致，並學習定義推動平台重組決策的近期和長期目標。
架構指導：選擇合適的雲端服務，設計符合您業務需求的架構。
程式碼指引：實作重試、斷路器和 Cache-Aside 設計模式，以提高雲端中 Web 應用程式的可靠性和效能效率。
設定指引：設定驗證和授權、受控身分識別、合適大小的環境、基礎結構即程式碼（IaC）和監視。
業務背景
重新建立 Web 應用程式平台的第一步是定義您的業務目標。 設定即時目標，例如服務等級目標 （SLO） 和成本最佳化目標，以及 Web 應用程式的未來目標。 這些目標會影響您選擇雲端服務，以及雲端中應用程式的架構。 定義 Web 應用程式的目標 SLO，例如 99.9% 正常運行時間。 計算影響 Web 應用程式可用性之所有服務的複合服務等級協定 （SLA）。
Contoso Fiber 想要擴充其內部部署 CAMS Web 應用程式，以連線到其他區域。 為了滿足對網絡應用程序日益增長的需求，該公司制定了以下目標：
- 套用低成本、高價值的程式碼變更。
- 達到 99.9%的 SLO 。
- 採用 DevOps 實踐。
- 建立成本最佳化的環境。
- 提高可靠性和安全性。
Contoso Fiber 判斷其內部部署基礎結構不是調整應用程式的符合成本效益的解決方案。 該公司認為，將 CAMS Web 應用程序遷移到 Azure 是實現其當前和未來目標的最經濟高效的方式。
架構指導
可靠的 Web 應用程式模式具有一些基本的架構元素。 您需要網域名稱系統 （DNS） 來管理端點解析、Web 應用程式防火牆來封鎖惡意 HTTP 流量，以及負載平衡器來路由並協助保護傳入使用者請求。 應用程式平臺會裝載您的 Web 應用程式程式碼，並透過虛擬網路中的私人端點呼叫後端服務。 應用程式效能監控工具會擷取指標和記錄，以協助您瞭解 Web 應用程式。
設計架構
設計您的基礎結構以支援 復原指標，例如復原時間目標 （RTO） 和復原點目標 （RPO）。 RTO 會影響可用性，且必須支援您的 SLO。 確定 RPO 並設定 資料備援 以滿足 RPO。
選擇基礎結構可靠性。 決定滿足可用性需求所需的可用區域和區域數目。 新增可用區域和區域，直到複合 SLA 符合您的 SLO 為止。 「可靠的 Web 應用程式」模式支援主動-主動或主動-被動配置的多個區域。 例如，參考實作使用主動-被動組態來滿足 99.9%的 SLO 。
針對多區域 Web 應用程式，請設定負載平衡器，以將流量路由傳送至第二個區域，以支援主動-主動或主動-被動設定，視您的商務需求而定。 這兩個區域需要相同的服務。 但其中一個區域具有連接區域的中樞虛擬網路。 採用中心輻射型網路拓撲來集中和共用資源，例如網路防火牆。 如果您有虛擬機器 （VM），請將堡壘主機新增至中樞的虛擬網路，以加強安全性來管理它們。
選取網路拓撲。 選擇適合您的 Web 和網路需求的網路拓撲。 如果您打算使用多個虛擬網路，請使用 中樞和輪輻網路拓撲。 它為內部部署和虛擬網路提供成本、管理和安全優勢，以及混合式連線選項。
選取正確的 Azure 服務
當您將 Web 應用程式移至雲端時，請選擇符合您商務需求並符合內部部署 Web 應用程式功能的 Azure 服務。 這種對齊有助於最大限度地減少重新構建平台過程中的工作量。 例如，使用允許您保持相同資料庫引擎並支援現有中介軟體和框架的服務。
在移轉之前，Contoso Fiber 的 CAMS Web 應用程式是內部部署整合型 Java 應用程式。 這是一個帶有 PostgreSQL 數據庫的 Spring Boot 應用程序。 Web 應用程式是員工的企業營運 （LOB） 支援應用程式。 他們用它來管理客戶支援案例。 該應用程式在可擴展性和功能部署方面遇到常見挑戰。 這個起點以及業務目標和 SLO 會影響他們的服務選擇。
下列清單提供為您的 Web 應用程式選取正確 Azure 服務的指引，並說明 Contoso Fiber 選取特定服務的原因：
應用平台： 使用 Azure App Service 作為您的應用程式平台。 Contoso Fiber 使用應用程式服務的原因如下：
自然進展： Contoso Fiber 會在其內部部署伺服器上部署 Spring Boot JAR 檔案，並想要將該部署模型的重新架構數量降到最低。 App Service 提供強大的支援來執行 Spring Boot 應用程式，這使其成為合適的選項。 Azure 容器應用程式也是此應用程式的合適選項。 如需詳細資訊，請參閱 Container Apps 概觀 和 Container Apps 上的 Java 概觀。
高SLA： App Service 提供符合生產需求的高 SLA。
減少管理開銷： App Service 是受控裝載解決方案。
容器化能力： App Service 會與私人容器映像登錄整合，例如 Azure Container Registry。 Contoso Fiber 未來可以使用這些登錄來容器化 Web 應用程式。
自動調整： Web 應用程式可以根據使用者流量快速擴展、縮減、擴容及縮容。
身分管理： 使用 Microsoft Entra ID 作為身分識別和存取管理解決方案。 Contoso Fiber 使用 Microsoft Entra ID 的原因如下：
身份驗證和授權： 應用程式需要驗證和授權呼叫中心員工。
可擴展性：Microsoft Entra ID 可調整以支援較大的案例。
使用者身分控制： 呼叫中心員工可以使用其現有的企業身分識別。
授權協定支援： Microsoft Entra ID 支援受控識別的 OAuth 2.0。
資料庫： 使用可讓您保留相同資料庫引擎的服務。 使用 資料存放區決策樹 來引導您的選取。 Contoso Fiber 會使用適用於 PostgreSQL 的 Azure 資料庫彈性伺服器部署模型，原因如下：
可靠性： 彈性伺服器部署模型支援跨多個可用性區域的區域備援高可用性。 此設定會在相同 Azure 區域內的不同可用性區域中維護暖待命伺服器。 配置會同步地將資料抄寫至待命伺服器。
跨區域複寫： 適用於 PostgreSQL 的 Azure 資料庫提供僅供讀取複本功能，可將資料以非同步方式複寫至 另一個區域中的唯讀複本資料庫。
效能： 適用於 PostgreSQL 的 Azure 資料庫提供可預測的效能和智慧型調整，可使用實際使用量資料來改善資料庫效能。
減少管理開銷： 此受控 Azure 服務可減少管理義務。
遷移支援： 它支援從內部部署單一伺服器 PostgreSQL 資料庫進行資料庫移轉。 Contoso Fiber 可以使用 移轉工具 來簡化移轉程式。
與內部部署設定的一致性： 它支援 不同的社群版本的 PostgreSQL，包括 Contoso Fiber 目前使用的版本。
彈性： 彈性伺服器部署會自動建立 伺服器備份 ，並將其儲存在相同區域內的區域備援儲存體 （ZRS） 中。 Contoso Fiber 可以將資料庫還原至備份保留期間內的任何時間點。 與本地環境相比，備份和還原功能可建立更好的 RPO。
應用程式效能監控： 使用 Application Insights 來分析應用程式上的遙測。 Contoso Fiber 使用 Application Insights 的原因如下：
與 Azure 監視器整合： 它提供與 Azure 監視器的最佳整合。
異常偵測： 它會自動偵測效能異常。
疑難排解： 它有助於診斷正在運行的應用程序中的問題。
監控： 它收集應用程式的使用資料並追蹤自訂事件。
能見度差距： 內部部署解決方案沒有應用程式效能監視解決方案。 Application Insights 可讓您輕鬆與應用程式平台和程式碼整合。
緩存： 選擇是否要將快取新增至 Web 應用程式架構。 Azure 受控 Redis 是主要的 Azure 快取解決方案。 它是基於 Redis 軟體的託管記憶體內資料存放區。 Contoso Fiber 新增 Azure 受控 Redis 的原因如下：
速度和音量： 它為頻繁存取、變化緩慢的資料提供高資料輸送量和低延遲讀取。
多樣化的可支援性： 這是 Web 應用程式的所有實例都可以使用的統一快取位置。
外部資料存放區： 內部部署應用伺服器會使用 VM 本地快取。 此設定不會卸載經常存取的資料，也無法使過時的資料失效。
非黏性會話： 快取將讓 Web 應用程式外部化會話狀態，並使用非黏性會話。 大多數在內部部署執行的 Java Web 應用程式都依賴記憶體內用戶端快取。 這種方法無法很好地擴展並增加主機上的記憶體佔用量。 Azure 受控 Redis 提供受控、可調整的快取服務，以改善應用程式的延展性和效能。 Contoso Fiber 使用 Spring Cache 作為其快取抽象架構，而且只需要最少的組態變更，即可從 Ehcache 提供者切換至 Redis 提供者。
負載平衡器： 使用平臺即服務 （PaaS） 解決方案的 Web 應用程式應該使用 Azure Front Door、Azure 應用程式閘道或兩者，視 Web 應用程式架構和需求而定。 使用 負載平衡器決策樹 來選取正確的負載平衡器。 Contoso Fiber 需要可以跨多個區域路由傳送流量的第 7 層負載平衡器，以及多區域 Web 應用程式，以符合 99.9%的 SLO。 該公司使用 Azure Front Door 的原因如下：
全域負載平衡： 此第 7 層負載平衡器可以跨多個區域路由流量。
Web 應用程式防火牆： 它與 Azure Web 應用程式防火牆原生整合。
路由靈活性： 它可讓應用程式團隊設定輸入需求，以支援應用程式的未來變更。
流量加速： 它會使用任播路由來連線到最近的 Azure 存在點，並尋找 Web 應用程式的最快路由。
自訂網域： 它支援具有靈活網域驗證的自訂網域名稱。
健康情況探查： 應用程式需要智慧型健康情況探測監視。 Azure Front Door 會使用探查的回應來判斷路由用戶端要求的最佳來源。
監控支援： Azure Front Door 支援內建報表，其中包含適用於 Azure Front Door 和安全性模式的全方位儀表板。 它提供與 Azure 監視器整合的警示。 Azure Front Door 可讓應用程式記錄每個要求和失敗的健康檢查。
分散式阻斷服務 （DDoS） 保護： 它在第 3 層和第 4 層內建 DDoS 保護。
內容傳遞網路： 它使 Contoso Fiber 能夠使用內容傳遞網路。 內容交付網路提供網站加速。
Web 應用程式防火牆： 使用 Azure Web 應用程式防火牆 來提供集中式保護，防止常見的 Web 惡意探索和弱點。 Contoso Fiber 使用 Azure Web 應用程式防火牆的原因如下：
全球保護： 它提供改進的全域 Web 應用程式保護，同時保持效能。
殭屍網路防護： 該團隊可以監控和配置設置，以解決與殭屍網路相關的安全問題。
與內部部署同位： 內部部署解決方案在 IT 管理的 Web 應用程式防火牆後面執行。
易於使用：Azure Web 應用程式防火牆與 Azure Front Door 整合。
秘密管理器： 如果您有要在 Azure 中管理的秘密，請使用 Azure 金鑰保存庫 。 Contoso Fiber 使用 Key Vault 的原因如下：
加密： 它支援靜態和傳輸中的加密。
受控識別支援： 應用程式服務可以使用受控識別來存取秘密存放區。
監控和日誌記錄： Key Vault 可協助稽核存取，並在儲存的秘密變更時產生警示。
整合： Key Vault 提供與 Azure 組態存放區 （Azure App Configuration） 和 Web 裝載平台 （App Service） 的原生整合。
端點安全： 使用 Azure Private Link 透過虛擬網路中的私人端點存取 PaaS 解決方案。 虛擬網路與服務之間的流量會透過 Microsoft 骨幹網路傳輸。 Contoso Fiber 使用 Private Link 的原因如下：
增強的安全通信：它可讓應用程式私下存取 Azure 平臺上的服務，並減少資料存放區的網路使用量，以協助防止資料外洩。
最小的努力： 私人端點支援 Web 應用程式使用的 Web 應用程式平台和資料庫平台。 這兩個平台都會鏡像現有的內部部署設定，因此只需要最少的變更。
網路安全： 使用 Azure 防火牆 來控制網路層級的輸入和輸出流量。 使用 Azure Bastion 連線到具有增強安全性的 VM，而不需公開遠端桌面通訊協定/安全殼層 （RDP/SSH） 連接埠。 Contoso Fiber 採用中樞和輪輻網路拓撲，並將共用網路安全性服務放在中樞中。 Azure 防火牆會檢查來自輪輻的輸出流量，以增強網路安全性。 該公司使用 Azure Bastion 從 DevOps 子網中的跳躍主機進行增強安全性部署。
程式碼指引
若要成功將 Web 應用程式移至雲端，您必須使用重試、斷路器和 Cache-Aside 模式來更新 Web 應用程式程式碼。
下列設計模式提供與一個或多個 Well-Architected Framework 架構原則相對應的工作負載優勢：
重試模式 會藉由重試可能間歇性失敗的作業來處理暫時性失敗。 在對其他 Azure 服務的所有輸出呼叫上實作此模式。
斷路器模式 可防止應用程式重試非暫時性的作業。 在對其他 Azure 服務的所有輸出呼叫中實作此模式。
Cache-Aside 模式會 根據需求將資料從資料庫載入快取。 在對資料庫的請求上實作此模式。
| 設計模式 | 可靠性 （RE） | 安全性 （SE） | 成本優化 （CO） | 卓越營運管理（OE） | 效能效率 （PE） | 支援 WAF 原則 |
|---|---|---|---|---|---|---|
| 重試模式 | ✔ | 回覆：07 | ||||
| 斷路器設計模式 | ✔ | ✔ |
RE：03 回覆：07 體育：07 體益：11 |
|||
| Cache-Aside 模式 | ✔ | ✔ |
RE：05 體育：08 體育：12 |
實作重試模式
將 重試模式 新增至您的應用程式程式碼，以解決暫時服務中斷。 這些中斷稱為 暫時性故障。 暫時性故障 通常會在幾秒鐘內自行解決。 您可以使用重試模式來重新傳送失敗的要求。 它還允許您配置重試之間的延遲以及承認失敗之前的嘗試次數。
使用 Resilience4j （輕量級容錯程式庫） 在 Java 中實作重試模式。 若要新增重試模式，參考實作會使用 Retry 註釋來裝飾服務計劃控制器的 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 Cloud Circuit Breaker 和 Resilience4j 來實現Circuit Breaker模式。 參考實作會套用 Circuit Breaker 模式，方法是使用 Circuit Breaker 屬性來裝飾方法。
實作 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 模式的核心。
配置指導方針
下列各節提供如何實作組態更新的指引。 每個區段都與 Well-Architected 框架的一或多個支柱保持一致。
| 設定 | 可靠性 （RE） | 安全性 （SE） | 成本優化 （CO） | 卓越營運管理（OE） | 效能效率 （PE） | 支援 WAF 原則 |
|---|---|---|---|---|---|---|
| 設定使用者驗證和授權 | ✔ | ✔ |
東南：05 OE:10 |
|||
| 實作受控識別 | ✔ | ✔ |
東南：05 OE:10 |
|||
| 調整至適合的環境 | ✔ |
CO：05 CO：06 |
||||
| 實施自動擴展 | ✔ | ✔ | ✔ |
RE：06 一氧化碳：12 體育：05 |
||
| 自動化資源部署 | ✔ | OE:05 | ||||
| 實作監控 | ✔ | ✔ | ✔ |
OE:07 體育：04 |
設定使用者驗證和授權
當您將 Web 應用程式移轉至 Azure 時，請設定使用者驗證和授權機制。 請遵循這些建議：
使用身分識別平台。 使用 Microsoft 身分識別平台供開發人員設定 Web 應用程式驗證。 此平臺支援使用單一 Microsoft Entra 目錄、來自不同組織的多個 Microsoft Entra 目錄，以及 Microsoft 身分識別或社交帳戶的應用程式。
[適用於 Microsoft Entra ID 的 Spring Boot Starter]（/azure/developer/java/spring-framework/spring-boot-starter-for-entra-developer-guide） 使用 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 ID 需要在主要租用戶中註冊應用程式。 應用程式註冊有助於確保可存取 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 安全性，以針對 Microsoft Entra ID 使用 Spring Boot Starter。 此程式庫可讓您與 Microsoft Entra ID 整合，並協助確保使用者安全地進行驗證。 設定並啟用 Microsoft 驗證程式庫 （MSAL） 以存取更多安全性功能。 這些功能包括令牌快取和令牌自動刷新。
參考實作會建立應用程式角色，以反映 Contoso Fiber 帳戶管理系統中的使用者角色類型。 角色會在授權過程中轉換為權限。 CAMS 中應用程式特定角色的範例包括客戶經理、層級 1 （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 ID 整合，參考實作會使用 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(); } } ...
偏好暫時存取儲存空間。 使用臨時權限來防止未經授權的存取和違規。 例如，您可以使用 共用存取簽章 （SAS） 將存取限制為一段時間。 使用使用者委派 SAS 在授與暫時存取權時將安全性最大化。 這是唯一使用 Microsoft Entra ID 認證且不需要永久儲存體帳戶金鑰的 SAS。
在 Azure 中強制執行授權。 使用 Azure RBAC） 將最低許可權指派給使用者身分識別。 Azure RBAC 會定義身分識別可以存取的 Azure 資源、他們可以使用這些資源執行的動作，以及他們有權存取的區域。
避免永久性提升權限。 使用 Microsoft Entra Privileged Identity Management （PIM） 授與特殊許可權作業的即時 （JIT） 存取權。 例如，開發人員通常需要管理員層級的存取權限來建立和刪除資料庫、修改表模式以及變更使用者權限。 當您使用 JIT 存取時，使用者身分會獲得執行高權限任務的暫時許可權。
實作受控識別
針對支援受控識別的所有 Azure 服務使用 受控識別 。 受控識別可讓 Azure 資源 （特別是 工作負載身分識別） 向其他 Azure 服務進行驗證並與之互動，而不需要您管理認證。 若要簡化移轉，您可以繼續針對混合式和舊版系統使用內部部署驗證解決方案，但您應該盡快將它們轉換成受控識別。 若要實作受控識別，請遵循下列建議：
選取正確的受控識別類型。 當您有兩個或多個需要相同許可權集的 Azure 資源時，請偏好使用者指派的受控識別。 此方法比為每個資源建立系統指派的受控識別，並將相同的許可權指派給所有資源更有效率。 否則，請使用系統指派的受控識別。
設定最低權限。 使用 Azure RBAC 只授與作業至關重要的許可權，例如資料庫中的建立、讀取、更新和刪除 （CRUD） 動作或存取秘密。 工作負載身分許可是持續性的，因此您無法為工作負載身分提供 JIT 或短期許可。 如果 Azure RBAC 未涵蓋特定案例，請使用 Azure 服務層級存取原則來補充 Azure RBAC。
為剩下的秘密提供安全性。 將任何剩餘的秘密儲存在 金鑰保存庫中。 在應用程式啟動時從金鑰庫載入機密，而不是在每次 HTTP 請求期間載入機密。 HTTP 要求內的高頻率存取可能會超過 Key Vault 交易限制。 將應用程式設定儲存在 應用程式設定中。
調整至適合的環境
使用 Azure 服務的效能層 （SKU），以符合每個環境的需求，但不會超出這些需求。 若要適當調整環境大小，請執行下列動作：
估算成本。 使用 Azure 定價計算機 來預估每個環境的成本。
優化生產環境。 生產環境需要符合生產所需的 SLA、功能和規模的 SKU。 持續監控資源使用情況並調整 SKU 以符合實際效能需求。
優化預生產環境。生產前 環境應該使用成本較低的資源，並利用 Azure 方案等折扣來 進行開發/測試定價。 在這些環境中，停用不需要的服務。 此外，請確定 生產前環境與生產環境足夠相似 ，以避免引入風險。 保持這種平衡，以確保測試保持有效，而不會產生不必要的成本。
使用 IaC 來定義 SKU。 實作 IaC，以根據環境動態選取和部署正確的 SKU。 這種方法增強了一致性並簡化了管理。
例如，參考實作具有選擇性參數，可指定要部署的 SKU。 環境參數會指定 Terraform 範本應該部署開發 SKU：
azd env set APP_ENVIRONMENT prod
實施自動擴展
自動調整有助於確保 Web 應用程式保持彈性、回應能力，並能夠有效率地處理動態工作負載。 若要實作自動調整，請遵循下列建議：
自動化橫向擴充。 使用 Azure 自動調整 ，在生產環境中自動進行水平調整。 設定自動擴展規則，以根據關鍵效能指標橫向擴展，以便您的應用程式可以處理不同的負載。
改進擴展觸發器。 如果您不熟悉應用程式的擴展需求，請使用 CPU 使用率作為初始擴展觸發器。 調整您的擴展觸發器，以包含其他指標，例如 RAM、網路輸送量和磁碟輸入/輸出 （I/O）。 目標是匹配 Web 應用程式的行為以獲得更好的效能。
提供橫向擴充緩衝區。 設定擴展閾值，以在達到最大容量之前啟動擴展。 例如，將調整設定為在 85% CPU 使用率時進行，而不是等到達到 100%。 這種主動方法有助於保持效能並避免潛在的瓶頸。
自動化資源部署
使用自動化跨所有環境部署和更新 Azure 資源和程式代碼。 請遵循這些建議：
使用 IaC。 使用持續整合和持續傳遞 （CI/CD） 管線來部署 IaC 。 Azure 為每個 Azure 資源提供預先建置 的 Bicep 範本、Azure Resource Manager 範本 （ARM 範本） JSON 和 Terraform 範本 。
使用 CI/CD 管線。 使用 CI/CD 管線將程式碼從原始檔控制部署到各種環境，例如測試、預備和生產環境。 如果您使用 Azure DevOps，請使用 Azure Pipelines。 針對 GitHub 專案使用 GitHub Actions。
整合單元測試。 在部署至 App Service 之前，先排定執行和驗證管線內所有單元測試的優先順序。 結合程式碼品質和覆蓋率工具，如 SonarQube，以實現全面的測試覆蓋率。
採用模擬框架。 對於涉及外部端點的測試，請使用模擬框架。 這些架構可讓您建立模擬端點。 它們消除了配置真實外部端點的需要，並確保跨環境的統一測試條件。
執行安全性掃描。 使用靜態應用程式安全測試 （SAST） 來尋找原始程式碼中的安全漏洞和編碼錯誤。 進行軟體組合分析 （SCA） 以檢查非 Microsoft 程式庫和元件是否有安全性風險。 將這些分析的工具整合至 GitHub 和 Azure DevOps。
設定監控
實作應用程式和平台監控，以增強 Web 應用程式的卓越營運和效能效率。 若要實作監控，請遵循下列建議：
收集應用程式遙測。 使用 Application Insights 中的 自動化檢測 來收集應用程式的 遙測，例如請求吞吐量、平均請求持續時間、錯誤和相依性監控。 您不需要變更任何程式碼即可使用此遙測。 Spring Boot 會在 Application Insights 中註冊數個核心計量，例如 Java 虛擬機器 （JVM）、CPU 和 Tomcat。 Application Insights 會自動從 Log4j 和 Logback 等記錄架構收集。
參考實作會在
app_settings應用程式服務的設定中透過 Terraform 啟用 Application Insights：app_settings = { APPLICATIONINSIGHTS_CONNECTION_STRING = var.app_insights_connection_string ApplicationInsightsAgent_EXTENSION_VERSION = "~3" ... }如需詳細資訊，請參閱下列文章：
建立自訂應用程式指標。 實現基於程式碼的儀器化，藉由新增 Application Insights SDK 並使用其 API，以便擷取 自訂應用程式遙測。
監控平台。 啟用所有支援服務的診斷。 將診斷傳送至與應用程式日誌相同的目的地，以進行相互關聯。 Azure 服務會自動建立平臺記錄，但只有在您啟用診斷時才會儲存它們。 為支援診斷的每個服務啟用診斷設定。
參考實作會使用 Terraform 在支援的服務上啟用 Azure 診斷。 下列 Terraform 程式碼會設定應用程式服務的診斷設定：
# 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 } }
部署參考實作
參考實作會引導您完成 Contoso Fiber 將內部部署 Java 應用程式模擬移轉至 Azure。 它也會強調初始採用階段所需的變更。
下列架構代表 Contoso Fiber 的可靠 Web 應用程式模式實作的最終狀態，以 其目標為基礎。
下載此架構的 Visio 檔案。