在微服務架構中，用戶端可能會與多個前端服務互動。 鑒於此事實，用戶端如何知道要呼叫哪些端點？ 引進新服務或重構現有服務時，會發生什麼事？ 服務如何處理 SSL 終止、驗證和其他考慮？ API 閘道 可協助解決這些挑戰。
什麼是 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 組態。
下一步
先前的文章已探討微服務之間的 介面，或微服務與用戶端應用程式之間的介面 。 根據設計，這些介面會將每個服務視為不透明方塊。 特別是微服務不應該公開其管理資料的實作詳細資料。 這會影響資料完整性和資料一致性，如下一篇文章所探索。