在雲端原生系統中，前端用戶端（行動、Web 和桌面應用程式）需要通道才能與獨立的後端微服務互動。
有哪些選項？
為了保持簡單，前端用戶端可以直接與後端微服務 通訊 ，如圖 4-2 所示。
圖 4-2。 直接客戶與服務溝通
透過這種方法，每個微服務都有一個可供前端用戶端存取的公用端點。 在生產環境中，您會在微服務前面放置負載平衡器，並按比例路由傳送流量。
雖然簡單實作，但直接用戶端通訊僅適用於簡單的微服務應用程式。 此模式緊密結合前端用戶端到核心後端服務，為許多問題打開大門，包括：
- 用戶端容易遭受後端服務重構的影響。
- 核心後端服務直接暴露時，攻擊面更廣。
- 跨每個微服務重複的跨界切面關注點。
- 過於複雜的用戶端程式代碼 - 客戶端必須追蹤多個端點，並以復原的方式處理失敗。
相反地，廣泛接受的雲端設計模式是實作前端應用程式和後端服務之間的 API 閘道服務 。 圖 4-3 顯示模式。
圖 4-3。 API 閘道模式
在上圖中，請注意 API 閘道服務如何抽象化後端核心微服務。 實現為 Web API，它充當反向代理，將傳入流量路由到內部微服務。
閘道會隔離客戶端與內部服務分割和重構。 如果您變更後端服務，您可以在閘道中容納它，而不會中斷用戶端。 這也是您針對跨領域問題的第一道防線，例如身分識別、快取、韌性、計量和節流。 許多跨領域考慮可以從後端核心服務卸除至閘道，以簡化後端服務。
請務必小心讓 API 閘道保持簡單且快速。 一般而言，商業規則會保留在閘道外。 複雜的閘道可能會成為瓶頸，最終甚至會變成一個單一結構。 較大的系統通常會公開依用戶端類型（行動裝置、Web、桌面）或後端功能分割的多個 API 閘道。 Backend for Frontends 模式提供實作多個閘道的指引。 圖 4-4 顯示模式。
圖 4-4。 前端模式的後端
請注意，在上圖中，傳入流量如何傳送至特定 API 閘道 - 根據客戶端類型：Web、行動裝置或傳統型應用程式。 這種方法很合理，因為每個裝置的功能在尺寸、效能和顯示限制上都有很大的差異。 行動應用程式通常公開的功能比瀏覽器或傳統型應用程式少。 每個閘道都可以優化，以符合對應裝置的功能。
簡單閘道
若要開始，您可以建置自己的 API 閘道服務。 快速搜尋 GitHub 將提供許多範例。
針對簡單的 .NET 雲端原生應用程式，您可能會考慮 Ocelot 閘道。 開放原始碼並針對 .NET 微服務建立，它是輕量型、快速、可調整的。 如同任何 API 閘道，其主要功能是將連入 HTTP 要求轉送至下游服務。 此外，它也支援在 .NET 中間件管線中可設定的各種功能。
YARP （另一個反向代理） 是由微軟產品團隊領導的開放原始碼反向代理。 以 NuGet 套件的形式下載，YARP 會以中間件的形式插入 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 顯示架構。
圖 4-5。 應用程式閘道輸入控制器
Kubernetes 包含支援 HTTP （層級 7） 負載平衡的內建功能，稱為 輸入。 Ingress 定義了一組規則，用於將 AKS 中的微服務容器對外部公開。 在上一個映像中，輸入控制器會解譯為叢集設定的輸入規則，並自動設定 Azure 應用程式閘道。 根據這些規則，應用程式閘道會將流量導引並傳送至在 AKS 中執行的微服務。 輸入控制器會接聽輸入規則的變更，並對 Azure 應用程式閘道進行適當的變更。
Azure API 管理
針對中等到大規模的雲端原生系統，您可以考慮 Azure API 管理。 它是雲端式服務，不僅可解決 API 閘道需求，還能提供功能完整的開發人員和系統管理體驗。 API 管理如圖 4-6 所示。
圖 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 管理可跨 四個不同的層級使用：
- 開發人員
- 基本
- 標準
- 高級版
開發人員層適用於非生產工作負載和評估。 其他層級則提供更進階的電源、功能和更高的服務等級協定（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 事件和長輪詢。 開發人員著重於將訊息傳送至連線用戶端的所有或特定子集。
圖 4-7 顯示一組 HTTP 用戶端，連線到已啟用 Azure SignalR 的雲端原生應用程式。
圖 4-7。 Azure SignalR（Azure 即時通訊服務）
Azure SignalR Service 的另一個優點是實作無伺服器雲端原生服務。 或許您的程式代碼會根據需要，透過 Azure Functions 的觸發事件來執行。 此案例可能很棘手，因為您的程式代碼不會維護與客戶端的長時間連線。 Azure SignalR 服務可以處理這種情況，因為服務已經為您管理連線。
Azure SignalR Service 會與其他 Azure 服務緊密整合，例如 Azure SQL Database、服務總線或 Redis 快取，為雲端原生應用程式開啟許多可能性。
