在微服務架構中，用戶端可能會與多個前端服務互動。 鑒於此事實，用戶端如何知道要呼叫哪些端點？ 引進新服務或重構現有服務時，會發生什麼事？ 服務如何處理 SSL 終止、相互 TLS、驗證和其他考慮？ API 閘道 有助於解決這些挑戰。
下載此架構的 Visio 檔案。
什麼是 API 閘道？
API 閘道提供集中式進入點，以管理用戶端與應用程式服務之間的互動。 它會做為反向 Proxy，並將用戶端要求路由傳送至適當的服務。 它也可以執行各種跨領域工作，例如驗證、SSL 終止、相互 TLS 和速率限制。
為什麼要使用 API 閘道？
API 閘道可簡化通訊、增強客戶端互動，並集中管理一般服務等級責任。 其會作為媒介，並防止將應用程式服務直接暴露給用戶端。 如果沒有 API 閘道，客戶端必須直接與個別應用程式服務通訊，這可能會帶來下列挑戰：
複雜用戶端程式代碼：可能會導致複雜的用戶端程序代碼。 客戶端必須追蹤多個端點，並有彈性地處理失敗。
緊密結合：它會在用戶端與後端之間建立結合。 客戶端必須了解個別服務的分解、使服務維護和重構複雜化。
增加延遲：單一作業可能需要呼叫多個服務。 結果可能是客戶端與伺服器之間的多個網路來回行程，因而增加顯著的延遲。
重複處理考慮：每個公開服務都必須處理驗證、SSL 和用戶端速率限制等疑慮。
通訊協定限制：服務必須公開用戶端友好的通訊協定，例如 HTTP 或 WebSocket。 此暴露 通訊協定 選項的限制。
展開攻擊面：公用端點會增加潛在的受攻擊面，而且需要強化。
如何使用 API 閘道
API 閘道可以使用特定的設計模式，根據應用程式的需求量身打造。 這些設計模式可解決主要功能，例如路由、要求匯總和跨領域考慮：
閘道路由。 您可以使用 API 閘道作為反向 Proxy，將用戶端要求路由傳送至不同的應用程式服務。 API 閘道會使用第 7 層路由，並提供單一端點供用戶端使用。 當您想要將用戶端與應用程式服務分離時，請使用 API 閘道路由。
閘道匯總。 您可以使用 API 閘道，將多個用戶端要求匯總成單一要求。 當單一作業需要呼叫多個應用程式服務時，請使用此模式。 在 API 匯總中，用戶端會將一個要求傳送至 API 閘道。 然後，API 閘道會將要求路由傳送至作業所需的各種服務。 最後，API 閘道會匯總結果，並將其傳回用戶端。 匯總可協助減少用戶端與應用程式服務之間的閒聊。
閘道卸除。 您可以使用 API 閘道來提供跨領域功能，因此個別服務不需要提供此功能。 將跨領域功能合併到一個位置，而不是讓每個服務負責，這非常有用。 以下是您可以卸除至 API 閘道的功能範例：
- SSL 終止
- 相互 TLS
- 認證
- IP 允許清單或封鎖清單
- 用戶端速率限制 （節流）
- 記錄和監視
- 回應快取
- Web 應用程式防火牆
- GZIP 壓縮
- 維護靜態內容
API 閘道選項
以下是在應用程式中實作 API 閘道的一些選項。
反向 Proxy 伺服器。 Nginx 和HAProxy是開放原始碼反向 Proxy 供應專案。 它們支援負載平衡、SSL 終止和第 7 層路由等功能。 他們有免費版本和付費版本，可提供額外的功能和支持選項。 這些產品已成熟，具有豐富的功能集、高效能和可擴充性。
服務網格輸入控制器。 如果您使用服務網格，請評估該服務網格特有的輸入控制器功能。 檢查 Istio 和 Open Service Mesh 等 AKS 支援的附加元件。 尋找第三方開放原始碼專案，例如Linkerd或 Consul Connect。 例如，Istio 輸入控制器支援第 7 層路由、HTTP 重新導向、重試和其他功能。
Azure 應用程式閘道。 應用程式閘道是受控負載平衡服務。 它提供執行第 7 層路由、SSL 終止，以及 Web 應用程式防火牆 （WAF）。
Azure Front Door。 Azure Front Door 是內容傳遞網路 （CDN）。 它會使用全域和本機存在點來提供快速、可靠且安全地存取您應用程式的靜態和動態Web內容。
Azure API 管理。 API 管理是一種受控解決方案，可將 API 發佈至外部和內部客戶。 它提供功能來管理公開的 API，包括使用Microsoft Entra ID 或其他身分識別提供者的速率限制、IP 限制和驗證。 API 管理不會執行任何負載平衡，因此您應該將其與負載平衡器搭配使用，例如 Azure 應用程式網關或反向 Proxy。 如需詳細資訊，請參閱使用 Azure 應用程式閘道 API 管理。
選擇 API 閘道技術
選取 API 閘道時，請考慮下列因素：
支援所有需求。 選擇支援所需功能的 API 閘道。 所有先前 API 閘道選項 都支援第 7 層路由。 但是，他們對其他功能的支援，例如驗證、速率限制和 SSL 終止，可能會有所不同。 評估單一閘道是否符合您的需求，或是否需要多個閘道。
偏好內建供應專案。 只要符合您的安全性和控制需求，請使用平臺所提供的內建 API 閘道和輸入解決方案，例如 Azure Container Apps 和 AKS。 只有在內建選項缺乏必要的彈性時，才使用自定義網關。 自定義解決方案需要治理模型，例如 GitOps，才能有效地管理其生命週期。
選擇正確的部署模型。 使用 Azure 應用程式閘道和 Azure API 管理等受控服務，降低作業負荷。 如果您使用一般用途的反向 Proxy 或負載平衡器，請以符合架構的方式部署它們。 您可以將一般用途 API 閘道部署至專用虛擬機，或在其輸入控制器供應專案中的 AKS 叢集內。 若要隔離 API 閘道與工作負載，您可以在叢集外部部署它們，但此部署會增加管理複雜性。
管理變更。 當您更新服務或新增服務時，您可能需要更新閘道路由規則。 實作程式或工作流程，以在新增或修改服務、SSL 憑證、IP 允許清單和安全性設定時管理路由規則。 使用基礎結構即程式代碼和自動化工具來簡化 API 閘道管理。
後續步驟
先前的文章探索了 微服務與微服務與用戶端應用程式之間 介面。 這些介面會將每個服務視為獨立的不透明單位。 微服務架構的重要原則是服務絕對不應該公開其管理數據的內部詳細數據。 這種方法對於維護數據完整性和一致性具有重大影響，這是下一篇文章的主題。