雖然並非必要，但 Azure 非常適合支援 eShopOnContainers，因為專案已建置為雲端原生應用程式。 應用程式是以 .NET 建置，因此它可以在Linux或 Windows 容器上執行，視 Docker 主機而定。 應用程式是由多個自主微服務所組成，每個微服務都有自己的數據。 不同的微服務會展示不同的方法，範圍從簡單的 CRUD 作業到更複雜的 DDD 和 CQRS 模式。 微服務會透過 HTTP 與用戶端通訊，以及透過訊息型通訊彼此通訊。 應用程式也支援用戶端的多個平臺，因為它採用 HTTP 作為標準通訊協定，並包含在 Android、iOS 和 Windows 平臺上執行的 ASP.NET Core 和 Xamarin 行動應用程式。 （Xamarin 自 2024 年 5 月起不受支援。
應用程式架構如圖 2-5 所示。 左側是用戶端應用程式，分為行動裝置、傳統 Web 和 Web 單頁應用程式 （SPA） 類別。 右側是構成系統的伺服器端元件，每個元件都可以裝載在 Docker 容器和 Kubernetes 叢集中。 傳統 Web 應用程式是由以黃色顯示的 ASP.NET Core MVC 應用程式所提供。 此應用程式和行動和 Web SPA 應用程式會透過一或多個 API 閘道與個別微服務通訊。 API 閘道會遵循「前端的後端」（BFF）模式，這表示每個閘道都是設計來支援指定的前端用戶端。 個別微服務會列在 API 閘道右側，並同時包含商業規則和某種持續性存放區。 不同的服務會使用 SQL Server 資料庫、Redis 快取實例和 MongoDB/CosmosDB 存放區。 最右邊是系統的事件總線，用於微服務之間的通訊。
圖 2-5。 eShopOnContainers 架構。
此架構的伺服器端元件都會輕鬆地對應至 Azure 服務。
容器編排和容器叢集
應用程式的容器裝載服務，從 ASP.NET Core MVC 應用程式到個別目錄和訂購微服務，都可以在 Azure Kubernetes Service （AKS） 中裝載和管理。 應用程式可以在 Docker 和 Kubernetes 上本機執行，然後可以將相同的容器部署至裝載於 AKS 中的預備和生產環境。 此過程可以自動化，我們將在下一節看到。
AKS 提供個別容器叢集的管理服務。 應用程式會針對 AKS 叢集中的每個微服務部署個別的容器，如上圖所示。 此方法可讓每個個別服務根據其資源需求獨立調整。 每個微服務也可以獨立部署，在理想情況下，這類部署應該會產生零系統停機時間。
API 閘道
eShopOnContainers 應用程式有多個前端用戶端和多個不同的後端服務。 用戶端應用程式與支援用戶端應用程式的微服務之間沒有一對一的對應。 在這類案例中，撰寫用戶端軟體以安全的方式與各種後端服務進行介面時，可能會有很大的複雜性。 每個客戶端都需要自行解決這個複雜性，導致重複及需要更新的地方增多，特別是當服務改變或新政策實施時。
Azure API 管理 （APIM） 可協助組織以一致且可管理的方式發佈 API。 APIM 包含三個元件：API 閘道和系統管理入口網站（Azure 入口網站），以及開發人員入口網站。
API 閘道會接受 API 呼叫，並將其路由傳送至適當的後端 API。 它也可以提供額外的服務，例如實時驗證 API 金鑰或 JWT 令牌和 API 轉換，而不需修改程式碼（例如，以容納預期較舊介面的用戶端）。
Azure 入口網站可讓您定義 API 架構，並將不同的 API 封裝到產品中。 您也可以設定使用者存取、檢視報表，以及設定配額或轉換的原則。
開發人員入口網站可作為開發人員的主要資源。 它為開發人員提供 API 檔、互動式測試主控台，以及報告自己的使用方式。 開發人員也會使用入口網站來建立和管理自己的帳戶，包括訂用帳戶和 API 金鑰支援。
使用APIM，應用程式可以公開數個不同的服務群組，每個服務都提供特定前端用戶端的後端。 建議針對複雜案例使用APIM。 針對更簡單的需求，可以使用輕量型 API 閘道 Ocelot。 eShopOnContainers 應用程式之所以使用 Ocelot，是因為其簡單性，而且可以部署至與應用程式本身相同的應用程式環境。 深入瞭解 eShopOnContainers、APIM 和 Ocelot。
如果您的應用程式使用 AKS，另一個選項是將 Azure 閘道輸入控制器部署為 AKS 叢集中的 Pod。 這種方法可讓您的叢集與 Azure 應用程式閘道整合，讓閘道能夠對 AKS Pod 的流量進行負載平衡。 深入瞭解 AKS 的 Azure 閘道輸入控制器。
資料
eShopOnContainers 所使用的各種後端服務有不同的記憶體需求。 數個微服務使用 SQL Server 資料庫。 購物籃微服務會利用 Redis 快取來實現資料持久性。 Locations 微服務需要 MongoDB API 作為其數據。 Azure 支援所有這些數據格式。
針對 SQL Server 資料庫支援，Azure 具有從單一資料庫到高度可調整 SQL Database 彈性集區的所有產品。 您可以設定個別微服務，以快速且輕鬆地與自己的個別 SQL Server 資料庫通訊。 您可以視需要調整這些資料庫，根據其需求支援每個個別的微服務。
eShopOnContainers 應用程式會將使用者目前的購物籃儲存在要求之間。 這一部分是由籃子的微服務管理，它將數據儲存在 Redis 快取中。 在開發階段，此快取可以部署在容器中；在生產環境中，可以利用 Azure Cache for Redis。 Azure Cache for Redis 是完全受控的服務，可提供高效能和可靠性，而不需要自行部署和管理 Redis 實例或容器。
Locations 微服務會使用 MongoDB NoSQL 資料庫進行持續性。 在開發期間，資料庫可以部署在自己的容器中，而在生產環境中，服務可以利用 適用於 MongoDB 的 Azure Cosmos DB API。 Azure Cosmos DB 的優點之一是能夠運用多個不同的通訊協定，包括 SQL API 和常見的 NoSQL API，包括 MongoDB、Cassandra、Gremlin 和 Azure 數據表記憶體。 Azure Cosmos DB 提供全管理且全域分布的資料庫即服務，能夠彈性調整以滿足使用該資料庫的服務需求。
第 5 章將更詳細地說明雲端原生應用程式中的分散式數據。
事件總線
應用程式會使用事件來傳達不同服務之間的變更。 這項功能可以使用各種方式來實現，而 eShopOnContainers 應用程式在本機使用 RabbitMQ。 在 Azure 中裝載時，應用程式會利用 Azure 服務總線 進行傳訊。 Azure 服務總線是完全受控的整合訊息代理程式，可讓應用程式和服務以分離、可靠、異步的方式彼此通訊。 Azure 服務總線支持單一佇列，以及提供不同 主題 以支援發佈-訂閱模式。 eShopOnContainers 應用程式會利用 Azure 服務總線的主題，支援將訊息從一個微服務散發至任何其他需要回應指定訊息的微服務。
彈性
部署至生產環境之後，eShopOnContainers 應用程式將能夠利用數個可用的 Azure 服務來改善其復原能力。 應用程式會發佈健康情況檢查，其可與 Application Insights 整合，以根據應用程式的可用性提供報告和警示。 Azure 資源也提供診斷記錄，可用來識別和更正 Bug 和效能問題。 資源記錄提供有關應用程式使用不同 Azure 資源時機和方式的詳細資訊。 您將在 第 6 章中深入了解雲端原生復原功能。
