前端用戶端通訊

  • 發行項

提示

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

下載 PDF

Cloud Native .NET apps for Azure eBook cover thumbnail.

在雲端原生系統中，前端用戶端 (行動、Web 和桌面應用程式) 需要通訊通道才能與獨立的後端微服務互動。

請問有哪些選項？

為了簡單起見，前端用戶端可以與後端微服務「直接通訊」，如圖 4-2 所示。

Direct client to service communication

圖 4-2. 直接用戶端對服務通訊

透過這項方法，每個微服務都會有可供前端用戶端存取的公用端點。 在生產環境中，您會在微服務之前放置負載平衡器，並依比例路由傳送流量。

雖然可簡易實作，但直接用戶端通訊僅適用於單純的微服務應用程式。 此模式會讓前端用戶端與核心後端服務緊密結合，且可能出現許多問題，包括：

  • 用戶端易受後端服務重構影響。
  • 因直接公開核心後端服務，而具有更廣泛的受攻擊面。
  • 重複為每個微服務進行跨領域考量。
  • 過於複雜的用戶端程式碼；用戶端必須追蹤多個端點，並以復原方式處理失敗。

相反地，其中一項廣泛接受的雲端設計模式，是在前端應用程式和後端服務之間實作 API 閘道服務。 圖 4-3 會顯示該模式。

API Gateway Pattern

圖 4-3： API 閘道模式

在上圖中，請注意 API 閘道服務如何將後端核心微服務抽象化。 其可實作為 Web API，並作為「反向 Proxy」將連入流量路由傳送至內部微服務。

閘道會將用戶端隔離於內部服務分割和重構。 如果您變更後端服務，則可以在閘道中配合變更，而無須中斷用戶端。 這也是跨領域考量的第一道防線，例如身分識別、快取、復原、計量和節流。 您可以將許多跨領域考量的負載從後端核心服務缷載至閘道，以簡化後端服務。

請務必小心讓 API 閘道保持簡單快速。 一般而言，商務邏輯會保留在閘道之外。 複雜的閘道會有成為瓶頸的風險，並最終成為臃腫的龐然大物。 較大的系統通常會公開依用戶端類型 (行動裝置、Web、桌面) 或後端功能區隔的多個 API 閘道。 前端的後端模式為實作多個閘道提供了方向。 圖 4-4 會顯示該模式。

Backend for Frontend Pattern

圖 4-4： 前端的後端模式

請注意上圖中根據用戶端類型 (Web、行動或傳統型應用程式) 將連入流量傳送至特定 API 閘道的方式。 因為每個裝置的功能在外形規格、效能和顯示限制之間明顯不同，所以這種方法很合理。 行動應用程式所公開的功能，通常比瀏覽器或傳統型應用程式較少。 每個閘道都可以最佳化，以符合對應裝置的功能。

簡單閘道

若要開始，您可以建置自己的 API 閘道服務。 快速搜尋 GitHub 會提供許多範例。

針對簡單的 .NET 雲端原生應用程式，您可以考慮 Ocelot 閘道。 其為開放原始碼，並針對 .NET 微服務建立，且輕量、快速、可調整。 如同任意 API 閘道，其主要功能是將傳入的 HTTP 要求轉接至下游服務。 此外，其支援可在 .NET 中介軟體管線中設定的各種功能。

YARP (另一個反向 Proxy) 是由 Microsoft 產品小組所引領的另一個開放原始碼反向 Proxy。 YARP 可下載為 NuGet 套件，會以中介軟體的形式插入 ASP.NET 架構，且可高度自訂。 您會發現 YARP 已妥善記載各種使用範例。

針對企業雲端原生應用程式，有數個受控 Azure 服務可協助您展開工作。

Azure 應用程式閘道

針對簡單的閘道需求，您可以考慮 Azure 應用程式閘道。 其可作為 Azure PaaS 服務使用，並包含基本的閘道功能，例如 URL 路由、SSL 終止和 Web 應用程式防火牆。 此服務支援第 7 層負載平衡功能。 透過第 7 層，您可以根據 HTTP 訊息的實際內容來路由傳送要求，而不只是路由傳送低階 TCP 網路封包。

在本書中，我們會推廣 Kubernetes 中的主控雲端原生系統。 Kubernetes 是一種容器協調器，會將整個容器化工作負載的部署、縮放和作業考量事項自動化。 Azure 應用程式閘道可以設定為 Azure Kubernetes Service 叢集的 API 閘道。

應用程式閘道輸入控制器可讓 Azure 應用程式閘道直接使用 Azure Kubernetes Service。 圖 4.5 會顯示該架構。

Application Gateway Ingress Controller

圖 4-5： 應用程式閘道輸入控制器

Kubernetes 包含稱為輸入 (英文) 的內建功能，可支援 HTTP (第 7 層) 負載平衡。 輸入會定義一組規則，以說明如何向外部公開 AKS 內的微服務執行個體。 在上圖中，輸入控制器會解譯為針對叢集所設定的輸入規則，並自動設定 Azure 應用程式閘道。 根據這些規則，應用程式閘道會將流量路由至 AKS 內執行的微服務。 輸入控制器會接聽輸入規則的變更，並對 Azure 應用程式閘道進行適當的變更。

Azure API 管理

針對中型到大型的雲端原生系統，您可以考慮使用 Azure API 管理。 其為雲端式服務，不僅可解決您的 API 閘道需求，還提供功能完整的開發人員和系統管理體驗。 API 管理如圖 4-6 所示。

Azure API Management

圖 4-6： Azure API 管理

若要開始，API 管理會公開閘道伺服器，依可設定的規則和原則，允許對後端服務的受控制存取。 這些服務可位於 Azure 雲端、內部部署資料中心或其他公用雲端中。 API 金鑰和 JWT 權杖會決定誰可以執行何種動作。 且會記錄所有流量以供分析之用。

對於開發人員，API 管理會提供開發人員入口網站，可讓您存取服務、文件和叫用服務的範例程式碼。 開發人員可以使用 Swagger/Open API 來檢查服務端點並分析其使用量。 此服務可跨主要開發平台運作：如 .NET、JAVA、Golang 等等。

發行者入口網站會公開管理儀表板，可讓系統管理員公開 API 並管理其行為。 您可以授與服務存取權、監視服務健康狀態，以及收集服務遙測。 系統管理員會將「原則」套用至每個端點以影響行為。 原則是針對每個服務呼叫而循序執行的預先建置陳述式。 會針對輸入呼叫、輸出呼叫設定原則，或在發生錯誤時叫用。 您可以在不同的服務範圍上套用原則，以便在合併原則時啟用決定性排序。 產品會隨附大量預先建置的原則。

下列是原則如何影響雲端原生服務行為的範例：

  • 限制服務存取。
  • 施行驗證。
  • 視需要節流來自單一來源的呼叫。
  • 啟用快取功能。
  • 封鎖來自特定 IP 位址的呼叫。
  • 控制服務的流程。
  • 將要求從 SOAP 轉換為 REST，或在不同的資料格式之間轉換，例如從 XML 轉換為 JSON。

Azure API 管理可以公開裝載於雲端或資料中心任何位置的後端服務。 其會針對您可能在雲端原生系統中公開的舊版服務，同時支援 REST 和 SOAP API。 即使是其他 Azure 服務，也可以透過 API 管理公開。 您可以將受控 API 放在 Azure 備份服務之上，例如 Azure 服務匯流排或 Azure Logic Apps。 Azure API 管理不包含內建的負載平衡支援，且應該與負載平衡服務搭配使用。

Azure API 管理可跨四個不同的層級使用：

  • 開發人員
  • 基本
  • Standard
  • Premium

開發人員層級適用於非生產工作負載和評估。 其他層級則會漸進性地提供更強大的性能、功能和更高的服務等級協定 (SLA)。 進階層級提供 Azure 虛擬網路和多重區域支援。 所有階層每小時都有固定價格。

Azure 雲端也為 Azure API 管理提供無伺服器層級 (英文)。 該服務稱為「消費定價層」，是針對無伺服器運算模型所設計的 API 管理版本。 不同於先前顯示的「預先配置」定價層，消費層級提供立即佈建和依行為付費定價。

其會針對下列使用案例啟用 API 閘道功能：

  • 使用無伺服器技術實作的微服務，例如 Azure Functions 和 Azure Logic Apps。
  • Azure 備份服務資源，例如服務匯流排佇列和主題、Azure 儲存體等等。
  • 流量偶爾飆高，但大部分時間會維持低量的微服務。

消費層級使用與前一層級相同的基礎服務 API 管理元件，但會根據動態配置的資源來採用完全不同的架構。 其與無伺服器運算模型完全一致：

  • 沒有要管理的基礎結構。
  • 沒有閒置容量。
  • 高可用性。
  • 自動擴充。
  • 成本依實際使用量而定。

新的消費層級是雲端原生系統的絕佳選擇，可公開無伺服器資源作為 API。

即時通訊

即時或推送通訊是前端應用程式的另一個選項，可透過 HTTP 與後端雲端原生系統通訊。 財務報價程式、線上教育、遊戲和作業進度更新等應用程式需要來自後端的即時回應。 使用一般 HTTP 通訊時，用戶端無法知道何時有新的資料可用。 用戶端必須持續「輪詢」或傳送要求給伺服器。 透過「即時」通訊，伺服器可以隨時將新資料推送至用戶端。

即時系統的特徵通常為高頻率資料流程和大量並行用戶端連線。 手動實作即時連線可能很快就會變得十分複雜，且需要龐大的基礎結構方可確保可擴縮性及針對連線用戶端的可靠傳訊。 您可能需要自行管理 Azure Redis 快取的執行個體，以及針對用戶端親和性使用黏性工作階段設定的一組負載平衡器。

Azure SignalR Service 是完全受控的 Azure 服務，可簡化雲端原生應用程式的即時通訊。 您可以忽略技術性的實作詳細資料 (例如容量佈建、縮放和持續性連線)。 99.9% 的服務等級協定會為您處理這些項目。 您應專注於應用程式功能，而非基礎結構管道。

啟用之後，雲端式 HTTP 服務可以將內容更新直接推送至已連線的用戶端，包括瀏覽器、行動和桌面應用程式。 用戶端會更新，而不需要輪詢伺服器。 Azure SignalR 會忽略可建立即時連線的傳輸技術，包括 WebSocket、Server-Side Events 和長期輪詢。 開發人員應著重於將訊息傳送至已連線用戶端的所有或特定子集。

圖 4-7 顯示一組 HTTP 用戶端，連線至已啟用 Azure SignalR 的雲端原生應用程式。

Azure SignalR

圖 4-7. Azure SignalR

Azure SignalR Service 的另一個優點是會實作無伺服器雲端原生服務。 或許您的程式碼會使用 Azure Functions 觸發程序來隨選執行。 因為您的程式碼不需要長時間維持用戶端連線，所以這種情況可能會有些棘手。 Azure SignalR Service 可以處理這種情況，因為服務已經為您管理連線了。

Azure SignalR Service 會與其他 Azure 服務緊密整合，例如 Azure SQL Database、服務匯流排或 Redis 快取，為您的雲端原生應用程式開啟許多可能性。

上一個下一個