適用於 Java 的新式 Web 應用程式模式

Azure App Service

Azure Front Door

Azure Cache for Redis

本文說明如何實作新式 Web 應用程式模式。新式 Web 應用程式模式會定義如何在雲端中將 Web 應用程式現代化，並引進服務導向架構。新式 Web 應用程式模式提供規範架構、程式代碼和組態指引，以符合 Azure 妥善架構架構的原則，並以 Reliable Web 應用程式模式為基礎建置。

為什麼要使用新式 Web 應用程式模式？

新式 Web 應用程式模式可協助優化 Web 應用程式的高需求區域。它提供詳細的指引來分離這些區域，以獨立調整成本優化。此方法可讓您將專用資源配置給重要元件，以提高整體效能。分離可分離的服務可以藉由防止應用程式中某個部分的變慢影響他人，並獨立啟用個別應用程式元件的版本控制，以改善可靠性。

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

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

架構指引：瞭解如何將 Web 應用程式元件模組化，並選取適當的平臺即服務（PaaS）解決方案。
程序代碼指引：實作四種設計模式來優化分離元件：Strangler Fig、佇列型負載撫平、競爭取用者和健康情況端點監視模式。
設定指引：設定分離元件的驗證、授權、自動調整和容器化。

提示

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

架構指導

新式 Web 應用程式模式是以可靠的 Web 應用程式模式為基礎。它需要一些額外的架構元件才能實作。您需要消息佇列、容器平臺、記憶體服務和容器登錄（請參閱圖 1）。

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

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

圖 2.具有第二個區域和中樞和輪輻網路拓撲的新式Web應用程式模式架構。

分離架構

若要實作新式 Web 應用程式模式，您需要將現有的 Web 應用程式架構分離。將架構分離牽涉到將整合型應用程式分解成較小的獨立服務，每個服務都負責特定特性或功能。此程式需要評估目前的 Web 應用程式、修改架構，最後將 Web 應用程式程式代碼擷取至容器平臺。目標是要有系統地識別和擷取受益於分離的應用程式服務。若要分離您的架構，請遵循下列建議：

識別服務界限 套用網域驅動設計原則，以識別整合型應用程式內的限定內容。每個限定內容都代表邏輯界限，而且可以是個別服務的候選專案。代表不同商務功能且相依性較少的服務是分離的良好候選專案。
評估服務優點。 專注於受益於獨立調整的服務。例如，LOB 應用程式中的電子郵件服務提供者之類的外部相依性可能需要與失敗隔離更多。請考慮經常進行更新或變更的服務。分離這些服務可讓獨立部署，並降低影響應用程式其他部分的風險。
評估技術可行性。 檢查目前的架構，以識別可能影響分離程序的技術條件約束和相依性。規劃如何跨服務管理及共享數據。分離的服務應該管理自己的數據，並將跨服務界限的直接數據庫存取降到最低。
部署 Azure 服務。 選取並部署您需要的 Azure 服務，以支援您想要擷取的 Web 應用程式服務。使用下列選取正確的 Azure 服務一節來取得指引。
分離 Web 應用程式服務。 為新擷取的 Web 應用程式服務定義清楚的介面和 API，以與系統的其他部分互動。設計數據管理策略，讓每個服務都能管理自己的數據，同時確保一致性和完整性。如需在此擷取程式期間使用的特定實作策略和設計模式，請參閱程式代碼指引一節。
針對分離的服務使用獨立記憶體。 每個分離的服務都應該有自己的數據存放區，以簡化版本設定和部署。例如，參考實作會分隔電子郵件服務與 Web 應用程式，並不需要服務存取資料庫。相反地，服務會透過 Azure 服務匯流排訊息將電子郵件傳遞狀態傳回 Web 應用程式，而 Web 應用程式會將附註儲存至其資料庫。
為每個分離的服務實作個別的部署管線。 個別的部署管線可讓每個服務以自己的步調更新。如果公司內的不同小組或組織擁有不同的服務，則擁有個別的部署管線可讓每個小組控制自己的部署。使用 Jenkins、GitHub Actions 或 Azure Pipelines 等持續整合和持續傳遞（CI/CD）工具來設定這些管線。
修訂安全性控制。 請確定您的安全性控制已更新，以考慮新的架構，包括防火牆規則和訪問控制。

選取正確的 Azure 服務

如需架構中的每個 Azure 服務，請參閱架構完善的架構中的相關 Azure 服務指南。針對新式 Web 應用程式模式，您需要傳訊系統來支援異步傳訊、支援容器化的應用程式平臺，以及容器映射存放庫。

選擇消息佇列。 消息佇列是服務導向架構的重要部分。它會分離訊息傳送者和接收者，以啟用異步傳訊。使用選擇 Azure 傳訊服務的指引，挑選支援您設計需求的 Azure 傳訊系統。 Azure 有三個傳訊服務：Azure 事件方格、Azure 事件中樞和服務匯流排。從服務匯流排開始作為預設選項，如果服務匯流排不符合您的需求，請使用其他兩個選項。

服務	使用案例
服務匯流排	選擇服務匯流排，以取得企業應用程式中高價值訊息可靠、已排序且可能的交易式傳遞。
Event Grid	當您需要有效率地處理大量離散事件時，請選擇 [事件方格]。事件方格可調整為事件驅動應用程式，其中許多小型獨立事件（例如資源狀態變更）必須在低延遲、發佈-訂閱模型中路由傳送給訂閱者。
事件中樞	選擇事件中樞來擷取大量、高輸送量的數據擷取，例如遙測、記錄或即時分析。事件中樞已針對需要持續內嵌和處理大量數據的串流案例進行優化。

實作容器服務。 針對您想要容器化的應用程式部分，您需要支援容器的應用程式平臺。使用選擇 Azure 容器服務指引來協助您做出決策。 Azure 有三個主要容器服務：Azure Container Apps、Azure Kubernetes Service （AKS）和 Azure App 服務。從 Container Apps 作為預設選項開始，如果 Container Apps 不符合您的需求，請使用其他兩個選項。

服務	使用案例
容器應用程式	如果您需要自動調整和管理事件驅動應用程式中容器的無伺服器平臺，請選擇 [容器應用程式]。
AKS	如果您需要對 Kubernetes 設定和進階功能進行詳細控制，以調整、網路和安全性，請選擇 AKS。
適用於容器的 Web Apps	選擇 App Service 上適用於容器的 Web 應用程式，以取得最簡單的 PaaS 體驗。

實作容器存放庫。 使用任何容器型計算服務時，必須有存放庫來儲存容器映像。您可以使用公用容器登錄，例如 Docker Hub 或 Azure Container Registry 之類的受控登錄。使用 Azure 指引中的容器登錄簡介，協助您做出決策。

程序代碼指引

若要成功分離並擷取獨立服務，您必須使用下列設計模式來更新 Web 應用程式程式代碼：Strangler Fig 模式、佇列型負載撫平模式、競爭取用者模式、健康情況端點監視模式和重試模式。

圖 3.設計模式的角色。

Strangler Fig 模式：Strangler Fig 模式會以累加方式將功能從整合型應用程式移轉至分離服務。在主要 Web 應用程式中實作此模式，藉由根據端點引導流量，逐漸將功能移轉至獨立服務。
佇列型負載撫平模式：佇列型負載撫平模式會使用佇列作為緩衝區來管理產生者和取用者之間的訊息流程。在分離服務的產生者部分實作此模式，以異步方式使用佇列管理訊息流程。
競爭取用者模式：競爭取用者模式可讓分離服務的多個實例獨立讀取相同的消息佇列，並競爭處理訊息。在分離服務中實作此模式，以將工作分散到多個實例。
健康情況端點監視模式：健康情況端點監視模式會公開端點，以監視 Web 應用程式不同部分的狀態和健康情況。 （4a） 在主要 Web 應用程式中實作此模式。 （4b） 也在分離服務中加以實作，以追蹤端點的健康情況。
重試模式：重試模式會重試間歇性失敗的作業來處理暫時性失敗。 （5a） 在主要 Web 應用程式中對其他 Azure 服務的所有輸出呼叫上實作此模式，例如對消息佇列和私人端點的呼叫。 （5b） 在分離服務中也實作此模式，以處理私人端點呼叫中的暫時性失敗。

每個設計模式都提供符合良好架構架構一或多個支柱的優點（請參閱下表）。

設計模式	實作位置	可靠性（RE）	成本優化（CO）	卓越營運（OE）	效能效率（PE）	支持架構完善的架構原則
Strangler Fig 圖樣	主要 Web 應用程式	✔	✔	✔		RE：08 CO：07 CO：08 OE：06 OE：11
基於佇列的負載調節模式	分離服務的產生者	✔	✔		✔	RE：06 RE：07 CO：12 PE：05
競爭取用者模式	分離服務	✔	✔		✔	RE：05 RE：07 CO：05 CO：07 PE：05 PE：07
健全狀況端點監視模式	主要 Web 應用程式與分離服務	✔		✔	✔	RE：07 RE：10 OE：07 PE：05
重試模式	主要 Web 應用程式與分離服務	✔				RE：07

實作 Strangler Fig 模式

使用 Strangler fig 模式，逐漸將功能從整合型程式代碼基底移轉至新的獨立服務。從現有的整合型程式代碼基底擷取新的服務，並緩慢地將Web應用程式的重要部分現代化。若要實作 Strangler Fig 模式，請遵循下列建議：

設定路由層。 在整合型 Web 應用程式程式代碼基底中，實作路由層，以根據端點導向流量。視需要使用自定義路由邏輯來處理特定商務規則來引導流量。例如，如果您的整合型應用程式中有 /users 端點，且您已將該功能移至分離的服務，路由層會將所有要求 /users 導向至新的服務。
管理功能推出。實作功能旗標和分段推出，以逐漸推出分離的服務。現有的整合型應用程式路由應該控制分離服務收到的要求數目。從一小部分的要求開始，並隨著時間增加使用量，因為您對它的穩定性和效能充滿信心。

例如，參考實作會將電子郵件傳遞功能擷取到獨立服務中，這可以逐漸引入，以處理大部分的要求，以傳送包含 Contoso 支援指南的電子郵件。隨著新服務證明其可靠性和效能，它最終可以從整合型接管整個電子郵件責任集，完成轉換。
使用外觀服務（如有必要）。 當單一要求需要與多個服務互動，或想要從客戶端隱藏基礎系統的複雜性時，外觀服務就很有用。不過，如果分離服務沒有任何公開的 API，則可能不需要外觀服務。

在整合型 Web 應用程式程式代碼基底中，實作外觀服務，將要求路由傳送至適當的後端（整合型或微服務）。在新的分離服務中，確保新的服務可以在透過外觀存取時獨立處理要求。

實作佇列型負載撫平模式

在分離服務的產生者部分實作佇列型負載撫平模式，以異步方式處理不需要立即回應的工作。此模式使用佇列來管理工作負載散發，藉此增強整體系統回應性和延展性。它可讓分離的服務以一致的速率處理要求。若要有效地實作此模式，請遵循下列建議：

使用非封鎖消息佇列。 請確定將訊息傳送至佇列的進程不會在等候分離服務處理佇列中的訊息時封鎖其他進程。如果進程需要分離服務作業的結果，請實作替代方式來處理等候佇列作業完成時的情況。例如，在 Spring Boot 中，您可以使用 StreamBridge 類別以異步方式將訊息發佈至佇列，而不封鎖呼叫線程（請參閱範例程式碼）：

private final StreamBridge streamBridge;

public SupportGuideQueueSender(StreamBridge streamBridge) {
    this.streamBridge = streamBridge;
}

// Asynchronously publish a message without blocking the calling thread
@Override
public void send(String to, String guideUrl, Long requestId) {
    EmailRequest emailRequest = EmailRequest.newBuilder()
            .setRequestId(requestId)
            .setEmailAddress(to)
            .setUrlToManual(guideUrl)
            .build();

    log.info("EmailRequest: {}", emailRequest);

    var message = emailRequest.toByteArray();
    streamBridge.send(EMAIL_REQUEST_QUEUE, message);

    log.info("Message sent to the queue");
}

這個 Java 範例會使用 StreamBridge 異步傳送訊息。此方法可確保主要應用程式保持回應，而且可以同時處理其他工作，而分離的服務則會以可管理的速度處理佇列要求。

實作訊息重試和移除。 實作機制，以重試無法成功處理的佇列訊息處理。如果失敗持續發生，則應該從佇列中移除這些訊息。例如，服務匯流排具有內建的重試和寄不出的信件佇列功能。
設定等冪訊息處理。 處理來自佇列訊息的邏輯必須是等冪的，才能處理訊息可能多次處理的情況。在 Spring Boot 中，您可以使用 @StreamListener 或 @KafkaListener 搭配唯一訊息識別碼，以防止重複處理。或者，您可以使用 Spring Cloud Stream 組織商務程式以運作方式運作，其中 consume 方法是以重複執行時產生相同結果的方式定義。如需管理訊息取用方式行為的進一步設定清單，請參閱具有服務匯流排的 Spring Cloud Stream。
管理體驗的變更。 異步處理可能會導致工作未立即完成。用戶應該在工作仍在處理時知道，以設定正確的預期並避免混淆。使用視覺提示或訊息來指出工作正在進行中。提供使用者在工作完成時接收通知的選項，例如電子郵件或推播通知。

實作競爭取用者模式

在分離服務中實作競爭取用者模式，以管理來自消息佇列的連入工作。此模式牽涉到將工作分散到多個分離服務實例。這些服務會處理來自佇列的訊息、增強負載平衡，以及提升系統處理同時要求的容量。競爭取用者模式在下列情況下有效：

訊息處理的順序並不重要。
佇列不會受到格式不正確的訊息影響。
處理作業具有等冪性，這表示可以多次套用，而不需變更初始應用程式以外的結果。

若要實作競爭取用者模式，請遵循下列建議：

處理並行訊息。 從佇列接收訊息時，請設定並行以符合系統設計的方式，確保系統可預測地進行調整。負載測試結果可協助您決定要處理的適當並行訊息數目，而且您可以從其中一個開始測量系統執行方式。
停用預先擷取。 停用預先擷取訊息，讓取用者在準備好時只擷取訊息。
使用可靠的訊息處理模式。 使用可靠的處理模式，例如 PeekLock（或其對等專案），自動重試處理失敗的訊息。此模式可增強刪除優先方法的可靠性。如果某個背景工作角色無法處理訊息，則即使訊息已處理多次，另一個背景工作角色也必須能夠處理該訊息，而不會發生錯誤。
實作錯誤處理。 將格式不正確或無法處理的訊息路由傳送至個別的寄不出的信件佇列。此設計可防止重複處理。例如，您可以在訊息處理期間攔截例外狀況，並將有問題的訊息移至不同的佇列。針對服務匯流排，訊息會在指定的傳遞嘗試次數或應用程式明確拒絕之後，移至寄不出的佇列。
處理順序錯誤的訊息。 設計取用者來處理依序抵達的訊息。多個平行取用者表示它們可能會依序處理訊息。
根據佇列長度進行調整。 從佇列取用訊息的服務應該根據佇列長度自動調整。調整型自動調整可讓您有效率地處理傳入訊息的尖峰。
使用訊息回復佇列。 如果系統需要訊息後置處理的通知，請設定專用的回復或回應佇列。此設定會將操作傳訊與通知程式分開。
使用無狀態服務。 請考慮使用無狀態服務來處理來自佇列的要求。它可讓您輕鬆調整資源，並有效率地使用資源。
設定記錄。 在訊息處理工作流程中整合記錄和特定例外狀況處理。專注於擷取串行化錯誤，並將這些有問題的訊息導向死信機制。這些記錄提供寶貴的深入解析以進行疑難解答。

例如，參考實作會在 Container Apps 中執行的無狀態服務上使用競爭取用者模式來處理來自服務匯流排佇列的電子郵件傳遞要求。

處理器會記錄訊息處理詳細數據，協助進行疑難解答和監視。它會擷取還原串行化錯誤，並提供偵錯程式時所需的深入解析。服務會在容器層級進行調整，允許根據佇列長度有效率地處理訊息尖峰（請參閱下列程序代碼）。

@Configuration
public class EmailProcessor {

    private static final Logger log = LoggerFactory.getLogger(EmailProcessor.class);

    @Bean
    Function<byte[], byte[]> consume() {
        return message -> {

            log.info("New message received");

            try {
                EmailRequest emailRequest = EmailRequest.parseFrom(message);
                log.info("EmailRequest: {}", emailRequest);

                EmailResponse emailResponse = EmailResponse.newBuilder()
                        .setEmailAddress(emailRequest.getEmailAddress())
                        .setUrlToManual(emailRequest.getUrlToManual())
                        .setRequestId(emailRequest.getRequestId())
                        .setMessage("Email sent to " + emailRequest.getEmailAddress() + " with URL to manual " + emailRequest.getUrlToManual())
                        .setStatus(Status.SUCCESS)
                        .build();

                return emailResponse.toByteArray();

            } catch (InvalidProtocolBufferException e) {
                throw new RuntimeException("Error parsing email request message", e);
            }
        };
    }
}

實作健全狀況端點監視模式

在主要應用程式程式代碼和分離的服務程式代碼中實作健全狀況端點監視模式，以追蹤應用程式端點的健康情況。 AKS 或 Container Apps 等協調器可以輪詢這些端點，以確認服務健康情況並重新啟動狀況不良的實例。 Spring Boot 提供 Spring Boot 執行器健康情況檢查的內建支援，可公開資料庫、訊息代理程式和記憶體系統等密鑰相依性的健全狀況檢查端點。若要實作健全狀況端點監視模式，請遵循下列建議：

實作健康情況檢查。 使用 Spring Boot 執行器提供健康情況檢查端點。 Spring Boot 執行器會公開端點 /actuator/health ，其中包含內建的健康情況指標和各種相依性的自定義檢查。若要啟用健康情況端點，請在 spring-boot-starter-actuator 或 pom.xml build.gradle 檔案中新增相依性。
```

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
```
在中 application.properties 設定健康情況端點，如參考實作所示： txt management.endpoints.web.exposure.include=metrics,health,info,retry,retryevents

驗證相依性。 Spring Boot 執行器包含各種相依性的健康情況指標，例如資料庫、訊息代理程式（RabbitMQ 或 Kafka），以及記憶體服務。若要驗證 Azure 服務的可用性，例如 Azure Blob 儲存體或服務匯流排，請使用 Azure Spring Apps 或 Micrometer 整合等社群外掛程式，以提供這些服務的健康情況指標。如果需要自定義檢查，您可以藉由建立自定義豆來實作它們 HealthIndicator 。

import org.springframework.boot.actuate.health.Health;
import org.springframework.boot.actuate.health.HealthIndicator;
import org.springframework.stereotype.Component;

@Component
public class CustomAzureServiceBusHealthIndicator implements HealthIndicator {
    @Override
    public Health health() {
        // Implement your health check logic here (e.g., ping Service Bus)
        boolean isServiceBusHealthy = checkServiceBusHealth();
        return isServiceBusHealthy ? Health.up().build() : Health.down().build();
    }

    private boolean checkServiceBusHealth() {
        // Implement health check logic (pinging or connecting to the service)
        return true; // Placeholder, implement actual logic
    }
}

設定 Azure 資源。 設定 Azure 資源以使用應用程式的健康情況檢查 URL 來確認即時性和整備程度。例如，您可以使用 Terraform 來使用健康狀態檢查 URL 來確認部署至容器應用程式之應用程式的活躍度和整備程度。如需詳細資訊，請參閱容器應用程式中的健康情況探查。

實作重試模式

重試模式可讓應用程式從暫時性錯誤復原。重試模式是 Reliable Web 應用程式模式的核心，因此您的 Web 應用程式應該已經使用重試模式。將重試模式套用至您從 Web 應用程式擷取的分離服務所發出的訊息系統和要求。若要實作重試模式，請遵循下列建議：

設定重試選項。 與消息佇列整合時，請務必使用適當的重試設定來設定負責與佇列互動的用戶端。指定參數，例如重試次數上限、重試之間的延遲，以及最大延遲。
使用指數輪詢。 針對重試嘗試實作指數輪詢策略。這表示以指數方式增加每次重試之間的時間，這有助於在高失敗率期間減少系統上的負載。
使用 SDK 重試功能。 對於具有特殊 SDK 的服務，例如服務匯流排或 Blob 記憶體，請使用內建的重試機制。內建的重試機制已針對服務的一般使用案例進行優化，而且可以更有效率地處理重試，且部分所需的設定較少。
採用 HTTP 用戶端的標準復原連結庫。 針對 HTTP 用戶端，您可以使用 Resilience4* 搭配 Spring 的 RestTemplate 或 WebClient 來處理 HTTP 通訊中的重試。 Spring 的 RestTemplate 可以包裝 Resilience4j 的重試邏輯，以有效處理暫時性 HTTP 錯誤。
處理訊息鎖定。 針對訊息型系統，實作支援在不遺失數據的情況下重試的訊息處理策略，例如使用可用的「查看鎖定」模式。請確定失敗的訊息會有效重試，並在重複失敗後移至寄不出的信件佇列。

設定指引

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

組態	可靠性（RE）	安全性（SE）	成本優化（CO）	卓越營運（OE）	效能效率（PE）	支持架構完善的架構原則
設定驗證和授權		✔		✔		SE：05 OE：10
實作獨立的自動調整	✔		✔		✔	RE：06 CO：12 PE：05
容器化服務部署			✔		✔	CO：13 PE：09 PE：03

設定驗證和授權

若要在新增至 Web 應用程式的任何新 Azure 服務（工作負載身分識別）上設定驗證和授權，請遵循下列建議：

針對每個新服務使用受控識別。 每個獨立服務都應該有自己的身分識別，並使用受控識別進行服務對服務驗證。受控識別不需要管理程式碼中的認證，並降低認證外泄的風險。它可協助您避免將敏感性資訊，例如連接字串放在程式代碼或組態檔中。
將最低許可權授與每個新服務。 僅將必要許可權指派給每個新的服務身分識別。例如，如果身分識別只需要推送至容器登錄，請勿授與提取許可權。請定期檢閱這些許可權，並視需要進行調整。針對不同的角色使用不同的身分識別，例如部署和應用程式。如果一個身分識別遭到入侵，這會限制潛在的損害。
採用基礎結構即程式代碼（IaC）。 使用 Bicep 或類似的 IaC 工具，例如 Terraform 來定義和管理您的雲端資源。 IaC 可確保在部署中一致地套用安全性設定，並可讓您對基礎結構設定進行版本控制。

若要設定使用者（使用者身分識別）的驗證和授權，請遵循下列建議：

將最低許可權授與使用者。 就像使用服務一樣，請確定用戶只獲得執行其工作所需的許可權。定期檢閱並調整這些許可權。
定期進行安全性稽核。 定期檢閱和稽核您的安全性設定。尋找任何設定錯誤或不必要的許可權，並立即加以修正。

參考實作會使用 IaC 將受控識別指派給每個身分識別新增服務和特定角色。它會定義容器登錄推送和提取的角色，以定義部署的角色和許可權存取權（請參閱下列程序代碼）。

resource "azurerm_role_assignment" "container_app_acr_pull" {
  principal_id         = var.aca_identity_principal_id
  role_definition_name = "AcrPull"
  scope                = azurerm_container_registry.acr.id
}

resource "azurerm_user_assigned_identity" "container_registry_user_assigned_identity" {
  name                = "ContainerRegistryUserAssignedIdentity"
  resource_group_name = var.resource_group
  location            = var.location
}

resource "azurerm_role_assignment" "container_registry_user_assigned_identity_acr_pull" {
  scope                = azurerm_container_registry.acr.id
  role_definition_name = "AcrPull"
  principal_id         = azurerm_user_assigned_identity.container_registry_user_assigned_identity.principal_id
}


# For demo purposes, allow current user access to the container registry
# Note: when running as a service principal, this is also needed
resource "azurerm_role_assignment" "acr_contributor_user_role_assignement" {
  scope                = azurerm_container_registry.acr.id
  role_definition_name = "Contributor"
  principal_id         = data.azuread_client_config.current.object_id
}

設定獨立的自動調整

新式 Web 應用程式模式會開始分解整合型架構，並引進服務分離。當您分離 Web 應用程式架構時，您可以獨立調整分離的服務。調整 Azure 服務以支援獨立的 Web 應用程式服務，而不是整個 Web 應用程式，將調整成本優化，同時符合需求。若要自動調整容器，請遵循下列建議：

使用無狀態服務。 請確定您的服務是無狀態的。如果您的 Web 應用程式包含行程內工作階段狀態，請將它外部化為 Redis 之類的分散式快取，或 SQL Server 之類的資料庫。
設定自動調整規則。 使用自動調整組態，為您的服務提供最符合成本效益的控制。針對容器化服務，事件型調整，例如 Kubernetes 事件驅動自動調整程式（KEDA）通常提供細微的控制，讓您根據事件計量進行調整。容器應用程式和 AKS 支援 KEDA。對於不支援 KEDA 的服務，例如 App Service，請使用平臺本身所提供的自動調整功能。這些功能通常包括根據計量型規則或 HTTP 流量進行調整。
設定最小復本。 若要防止冷啟動，請設定自動調整設定，以維持至少一個複本。冷啟動是當您從停止狀態初始化服務時，通常會建立延遲的回應。如果將成本降至最低是優先順序，而且您可以容忍冷啟動延遲，請在設定自動調整時，將復本計數下限設定為 0。
設定冷卻期間。 套用適當的冷卻期間，以在調整事件之間引入延遲。目標是防止暫時負載尖峰觸發的過度調整活動。
設定佇列型調整。 如果您的應用程式使用訊息佇列，例如服務匯流排，請設定自動調整設定，以根據具有要求訊息的佇列長度進行調整。縮放程式的目標是針對佇列中每個 N 訊息維護一個服務複本（四捨五入）。

例如，參考實作會使用服務匯流排 KEDA 縮放程式，根據服務匯流排佇列的長度自動調整容器應用程式。名為service-bus-queue-length-rule的縮放規則會根據指定服務匯流排佇列中的訊息計數來調整服務複本的數目。參數 messageCount 設定為 10，這表示調整器會針對佇列中每 10 則訊息新增一個複本。最大複本（max_replicas）會設定為 10，而且除非覆寫，否則最小復本會隱含為 0，這可讓服務在佇列中沒有任何訊息時相應減少為零。服務匯流排佇列的連接字串會安全地儲存為名為 azure-servicebus-connection-string的 Azure 中的秘密，用來向服務匯流排驗證縮放程式。

    max_replicas = 10
    min_replicas = 1

    custom_scale_rule {
      name             = "service-bus-queue-length-rule"
      custom_rule_type = "azure-servicebus"
      metadata = {
        messageCount = 10
        namespace    = var.servicebus_namespace
        queueName    = var.email_request_queue_name
      }
      authentication {
        secret_name       = "azure-servicebus-connection-string"
        trigger_parameter = "connection"
      }
    }

容器化服務部署

容器化表示應用程式運作的所有相依性都會封裝在可可靠地部署到各種主機的輕量型映像中。若要容器化部署，請遵循下列建議：

識別網域界限。 從識別整合型應用程式內的網域界限開始。這有助於判斷您可以擷取至個別服務的應用程式部分。
建立 Docker 映像。 為 Java 服務建立 Docker 映射時，請使用官方 OpenJDK 基底映射。這些映射只包含 Java 執行所需的最小套件集，可將套件大小和受攻擊介面區降到最低。
使用多階段 Dockerfiles。 使用多階段 Dockerfiles 來分隔建置時間資產與運行時間容器映像。這有助於保持生產映像的小型且安全。您也可以使用預先設定的組建伺服器，並將 jar 檔案複製到容器映像。
以非根使用者身分執行。 以非根使用者身分執行 Java 容器（透過使用者名稱或 UID，$APP_UID）來符合最低許可權原則。它會限制遭入侵容器的潛在影響。
接聽埠 8080。 以非根使用者身分執行時，請將您的應用程式設定為接聽埠 8080。這是非根使用者的共同慣例。
封裝相依性。 確定應用程式要運作的所有相依性都會封裝在 Docker 容器映射中。封裝可讓應用程式可靠地部署到各種主機。
選擇正確的基底映像。 您選擇的基底映像取決於您的部署環境。例如，如果您要部署至 Container Apps，則需要使用 Linux Docker 映射。

參考實作示範用於容器化 Java 應用程式的 Docker 建置程式。此 Dockerfile 會使用具有 OpenJDK 基底映射的單一階段組建，mcr.microsoft.com/openjdk/jdk:17-ubuntu以提供必要的 Java 運行時間環境。

Dockerfile 包含下列步驟：

磁碟區宣告：已定義暫存磁碟區（/tmp），允許將暫存盤儲存區與容器的主要文件系統分開。
複製成品：應用程式的 JAR 檔案（email-processor.jar）會複製到容器中，以及 Application Insights 代理程式（applicationinsights-agent.jar）進行監視。
設定進入點：容器會設定為使用在運行時間期間監視應用程式， java -javaagent 以啟用ApplicationInsights代理程式來執行應用程式。

此 Dockerfile 僅藉由包含運行時間相依性來維持映射的精簡，適用於支援 Linux 型容器的 Container Apps 等部署環境。

# Use OpenJDK 17 base image on Ubuntu as the foundation
FROM mcr.microsoft.com/openjdk/jdk:17-ubuntu

# Define a volume to allow temporary files to be stored separately from the container's main file system
VOLUME /tmp

# Copy the packaged JAR file into the container
COPY target/email-processor.jar app.jar

# Copy the Application Insights agent for monitoring
COPY target/agent/applicationinsights-agent.jar applicationinsights-agent.jar

# Set the entry point to run the application with the Application Insights agent
ENTRYPOINT ["java", "-javaagent:applicationinsights-agent.jar", "-jar", "/app.jar"]

部署參考實作

部署適用於 Java 的新式 Web 應用程式模式參考實作。存放庫中有開發和生產部署的指示。部署之後，您可以模擬並觀察設計模式。

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

適用於 Java 參考實作的新式 Web 應用程式模式

共用方式為