將 eShopOnContainers 對應至 Azure 服務

提示

此內容摘錄自《建構適用於 Azure 的雲端原生 .NET 應用程式》電子書，您可以在 .NET Docs 找到此電子書，或免費下載可離線閱讀的 PDF。

下載 PDF

雖然並非必要，但 Azure 很適合支援 eShopOnContainers，因為專案已建置為雲端原生應用程式。 應用程式是使用 .NET 所建置，因此它可以根據 Docker 主機在 Linux 或 Windows 容器上執行。 應用程式是由多個自發微服務所組成，每個微服務都有自己的資料。 不同的微服務展示不同的方法，範圍從簡單的 CRUD 作業到更複雜的 DDD 和 CQRS 模式。 微服務會透過 HTTP 與用戶端通訊，以及透過訊息型通訊與彼此通訊。 應用程式也支援用戶端的多個平台，因為它採用 HTTP 作為標準通訊協定，並包含在 Android、iOS 和 Windows 平台上執行的 ASP.NET Core 和 Xamarin 行動裝置應用程式。

應用程式架構會顯示在圖 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 資料庫。 Basket 微服務會利用 Redis 快取來保存。 Locations 微服務預期針對其資料使用 MongoDB API。 Azure 支援所有這些資料格式。

針對 SQL Server 資料庫支援，Azure 具有適用於單一資料庫到高度可調整 SQL Database 彈性集區之所有專案的產品。 可以設定個別微服務，快速且輕鬆地與其本身的個別 SQL Server 資料庫通訊。 這些資料庫可以視需要調整，根據需求支援每個個別的微服務。

eShopOnContainers 應用程式會在要求之間儲存使用者目前的購物籃。 這個層面是由將資料儲存在 Redis 快取中的 Basket 微服務所管理。 在開發階段中，此快取可以部署在容器中，而生產環境中則可利用 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 章中深入瞭解雲端原生復原功能。

上一個下一個