編輯

共用方式為


在微服務中使用 API 閘道

Azure 應用程式閘道
Azure API 管理

在微服務架構中,用戶端可能會與多個前端服務互動。 鑒於此事實,用戶端如何知道要呼叫哪些端點? 引進新服務或重構現有服務時,會發生什麼事? 服務如何處理 SSL 終止、驗證和其他考慮? API 閘道 可協助解決這些挑戰。

Diagram of an API gateway

下載此架構的 Visio 檔案

什麼是 API 閘道?

API 閘道位於用戶端和服務之間。 它會作為反向 Proxy,將要求從用戶端路由傳送到服務。 它也會執行各種跨領域工作,例如驗證、SSL 終止和速率限制。 如果您未部署閘道,用戶端就必須將要求直接傳送給前端服務。 不過,將服務直接公開給用戶端有一些潛在問題:

  • 這可能會導致複雜的用戶端程式代碼。 用戶端必須追蹤多個端點,並以復原的方式處理失敗。
  • 它會建立用戶端與後端之間的結合。 用戶端必須知道個別服務如何分解。 這使得維護用戶端更難,也更難重構服務。
  • 單一作業可能需要呼叫多個服務。 這會造成用戶端和伺服器之間的多個網路來回行程,導致顯著延遲。
  • 每個公開服務都必須處理驗證、SSL 和用戶端速率限制等疑慮。
  • 服務必須公開用戶端友好的通訊協定,例如 HTTP 或 WebSocket。 這會限制通訊協定 的選擇
  • 具有公用端點的服務是潛在的受攻擊面,而且必須強化。

閘道可藉由將用戶端與服務分離來協助解決這些問題。 閘道可以執行數個不同的功能,而且您可能不需要全部。 函式可以分組為下列設計模式:

閘道路由 。 使用閘道作為反向 Proxy,使用第 7 層路由將要求路由傳送至一或多個後端服務。 閘道會為用戶端提供單一端點,並協助將用戶端與服務分離。

閘道匯總 。 使用閘道將多個個別要求匯總成單一要求。 當單一作業需要呼叫多個後端服務時,就會套用此模式。 用戶端會將一個要求傳送至閘道。 閘道會將要求分派至各種後端服務,然後匯總結果,並將其傳回用戶端。 這有助於減少用戶端與後端之間的閒聊。

閘道卸載 。 使用閘道將功能從個別服務卸載到閘道,特別是橫跨考量。 將這些函式合併到一個地方會很有用,而不是讓每個服務負責實作這些函式。 這特別適用于需要特殊技術才能正確實作的功能,例如驗證和授權。

以下是可卸載至閘道的一些功能範例:

  • SSL 終止
  • 驗證
  • IP 允許清單或封鎖清單
  • 用戶端速率限制 (節流)
  • 記錄和監視
  • 回應快取
  • Web 應用程式防火牆
  • GZIP 壓縮
  • 維護靜態內容

選擇閘道技術

以下是在應用程式中實作 API 閘道的一些選項。

  • 反向 Proxy 伺服器 。 Nginx 和 HAProxy 是熱門的反向 Proxy 伺服器,可支援負載平衡、SSL 和第 7 層路由等功能。 它們都是免費的開放原始碼產品,具有提供其他功能和支援選項的付費版本。 Nginx 和 HAProxy 都是具有豐富功能集和高效能的成熟產品。 您可以使用協力廠商模組來擴充它們,或在 Lua 中撰寫自訂腳本。 Nginx 也支援 JavaScript 型腳本模組,稱為 NGINX JavaScript 。 此課程模組已正式命名為 nginScript。

  • 服務網格輸入控制器 。 如果您使用連結器或 Istio 之類的服務網格,請考慮該服務網格的輸入控制器所提供的功能。 例如,Istio 輸入控制器支援第 7 層路由、HTTP 重新導向、重試和其他功能。

  • Azure 應用程式閘道 。 應用程式閘道是一項受控負載平衡服務,可執行第 7 層路由和 SSL 終止。 它也提供 Web 應用程式防火牆 (WAF)。

  • Azure Front Door 是 Microsoft 的新式雲端內容傳遞網路 (CDN),可在使用者與您的應用程式在全球靜態和動態 Web 內容之間提供快速、可靠且安全的存取。 Azure Front Door 會使用 Microsoft 的全球邊緣網路提供您的內容,其中包含數百個全球和本機存在點(PoPs),這些點分散在世界各地,與您企業和取用者終端使用者非常接近。

  • Azure API 管理 。 API 管理是將 API 發佈至外部和內部客戶的周全解決方案。 它提供可用於管理公開 API 的功能,包括使用 Microsoft Entra ID 或其他身分識別提供者的速率限制、IP 限制和驗證。 API 管理不會執行任何負載平衡,因此應該與負載平衡器搭配使用,例如應用程式閘道或反向 Proxy。 如需搭配應用程式閘道使用 API 管理 的詳細資訊,請參閱 在內部 VNet 中整合 API 管理 與 應用程式閘道

選擇閘道技術時,請考慮下列事項:

特點。 以上所列的選項都支援第 7 層路由,但對其他功能的支援會有所不同。 視您需要的功能而定,您可能會部署多個閘道。

部署。 Azure 應用程式閘道和API 管理是受控服務。 Nginx 和 HAProxy 通常會在叢集內的容器中執行,但也可以部署到叢集外部的專用 VM。 這會隔離閘道與其余工作負載,但會產生較高的管理額外負荷。

管理。 當服務更新或新增服務時,可能需要更新閘道路由規則。 請考慮如何管理此程式。 類似的考慮適用于管理 SSL 憑證、IP 允許清單,以及設定的其他層面。

將 Nginx 或 HAProxy 部署至 Kubernetes

您可以將 Nginx 或 HAProxy 部署至 Kubernetes 做為 ReplicaSet DaemonSet ,以指定 Nginx 或 HAProxy 容器映射。 使用 ConfigMap 來儲存 Proxy 的組態檔,並將 ConfigMap 掛接為磁片區。 建立 LoadBalancer 類型的服務,以透過 Azure Load Balancer 公開閘道。

替代方法是建立輸入控制器。 輸入控制器是部署負載平衡器或反向 Proxy 伺服器的 Kubernetes 資源。 有數個實作存在,包括 Nginx 和 HAProxy。 稱為輸入的個別資源會定義輸入控制器的設定,例如路由規則和 TLS 憑證。 如此一來,您就不需要管理特定 Proxy 伺服器技術特有的複雜組態檔。

閘道是系統中潛在的瓶頸或單一失敗點,因此請一律部署至少兩個複本以提供高可用性。 視負載而定,您可能需要進一步相應放大複本。

也請考慮在叢集中的一組專用節點上執行閘道。 此方法的優點包括:

  • 隔離性。 所有輸入流量都會移至一組固定的節點,而該節點可以與後端服務隔離。

  • 穩定組態。 如果閘道設定錯誤,整個應用程式可能會變成無法使用。

  • 效能: 基於效能考慮,您可能想要針對閘道使用特定的 VM 組態。

下一步

先前的文章已探討微服務之間的 介面,或微服務與用戶端應用程式之間的介面 。 根據設計,這些介面會將每個服務視為不透明方塊。 特別是微服務不應該公開其管理資料的實作詳細資料。 這會影響資料完整性和資料一致性,如下一篇文章所探索。