API 閘道器的10個最常見用例

1. API 資源路由。
2. API 基於內容的路由。
3. API 地理路由。
4. API 聚合器。
5. API 集中式身份驗證。
6. API 格式轉換。
7. API 可觀察性。
8. API 快取。
9. API 故障處理。
10. API 版本控制。

API 主導的架構
首先，讓我們再次修改這 3 個術語，例如：API Gateway、API-Led architecture和API-Led Connectivity。

API Gateway是透過在客戶端和伺服器之間新增一個層而形成的模式，該層充當將請求從客戶端轉發到伺服器的單個入口點。它允許所有客戶端透過單個 API 閘道器層訪問他們想要訪問的服務。

API-led是一種架構方法，它將 API 置於應用程式之間的通訊及其需要訪問的業務功能的核心，以便在所有數字渠道中始終如一地提供無縫功能。
API 主導的連線性是指使用可重用和精心設計的 API 來連結資料和應用程式的技術，這反過來又基於API 主導的架構。它是一種架構方法，著眼於重用 API 的最佳方式，以促進您的創新並在市場中快速移動。在最基本的層面上，API 主導的架構應該解決以下問題：

• 保護 API 免受未經授權的訪問和重大安全威脅。
• 確保消費應用程式總能找到正確的 API 端點。
• 限制和/或限制對 API 的呼叫次數以確保持續可用性。
• 支援 API 設計、測試、持續整合、生命週期管理、監控和操作等功能，僅舉幾例。
• 錯誤處理和防止錯誤在堆疊中傳播。
• 透過豐富的分析和洞察力實時監控 API。
• 一種實現可擴充套件和靈活業務功能的方法，例如，支援微服務架構。

API資源路由
列表中的第一個是API 資源路由方法，它使用 API 閘道器根據唯一資源識別符號 (URI) 路由傳入呼叫。將 API 閘道器實現為所有服務的單一入口點意味著 API 使用者只需瞭解一個 URL 域。透過這種方式，API 閘道器負責將流量路由到相應的服務端點，並執行任何應用的策略，如下圖所示。
它降低了 API 消費者端的複雜性，因為客戶端應用程式不需要使用來自多個 HTTP 端點的功能，以防系統中有許多服務。此外，無需為每個服務單獨實現所有橫切關注點，例如身份驗證/授權、節流和速率限制。大多數 API 閘道器（如Apache APISIX）已經具備這些核心功能。

API 基於內容的路由
類似地，API 基於內容的路由機制也使用 API 閘道器根據請求的內容（例如，基於 HTTP 標頭或訊息體）而不只是 URI 來路由呼叫。
以應用資料庫分片以跨多個資料庫例項分佈負載為例。當儲存的記錄總數很大並且單個例項難以管理負載時，通常會應用此技術。相反，記錄分佈在多個資料庫例項中。然後，您實現多個服務，每個唯一資料儲存一個，並採用 API 閘道器作為所有服務的唯一入口點。然後，您可以配置 API 閘道器，以根據從 HTTP 標頭或負載中獲取的鍵將呼叫路由到相應的服務。

API 地理路由
API 地理路由解決方案根據 API 呼叫的來源將 API 呼叫路由到最近的 API 閘道器。為了防止延遲問題和其他可能因距離而出現的不可預見的問題（例如，來自亞洲的消費應用程式呼叫位於北美的 API），API 閘道器和其他服務基礎設施已部署在全球多個地區作為需要。例如，為每個區域中的每個 API 閘道器使用不同的子域，並讓消費應用程式根據應用程式邏輯確定最近的閘道器。然後，API 閘道器提供內部負載平衡，以確保傳入請求分佈在服務的可用例項中。

API 聚合器
此技術對多個服務執行操作（例如，查詢），並透過一次HTTP request/response呼叫將結果返回給客戶端服務。API 聚合器不是讓客戶端應用程式多次呼叫多個 API，而是使用 API 閘道器代表伺服器端的消費者執行此操作。
例如，考慮一個移動應用程式，它多次呼叫不同的 API 以顯示單個螢幕的資料。在這種情況下，它會增加客戶端程式碼的複雜性、網路資源的過度利用，甚至會因為應用程式更容易受到延遲問題的影響而導致使用者體驗不佳。API Gateway 可以接受所有所需資訊作為輸入，請求身份驗證和驗證，瞭解與其互動的所有 API 的所有資料結構，並且能夠轉換響應負載，以便將它們作為統一負載傳送回移動應用程式消費者所需要的。

API集中認證
在此設計中，API 閘道器充當集中式身份驗證閘道器。作為身份驗證器，API Gateway 在 - 例如，不記名令牌中查詢訪問憑據HTTP header，並實施業務邏輯，使用 IDP、身份提供程式（例如Okta、Cognito、Azure Active Directory或Ory Hydra）驗證這些憑據，通常使用OpenID Connect (OIDC) 是一種基於OAuth 2.0的身份驗證協議，用於檢查他們是否有權訪問。

使用 API Gateway 進行集中式身份驗證可以解決許多問題並帶來一些好處，因為它完全減輕了應用程式的使用者管理負擔，並且透過快速響應從客戶端應用程式收到的身份驗證請求來提高效能。

例如，Apache APISIX提供了多種外掛來啟用不同的 API 閘道器身份驗證方法。我們檢視了這篇博文中最常用的一些使用Apache APISIX 外掛的集中式身份驗證。您甚至可以為給定的 API 啟用多種身份驗證方法。

API 格式轉換
這是指能夠透過相同的傳輸將有效負載從一種格式轉換為另一種格式。例如，從基於 HTTPS 的 XML/SOAP 到基於 HTTPS 的 JSON，反之亦然。API 閘道器預設提供支援 REST API 和一些專用 API 閘道器的功能，除了有效負載轉換之外，還支援傳輸轉換，例如從 TCP（物聯網中非常流行的傳輸）上的訊息佇列遙測傳輸 (MQTT) 轉換為HTTPS 上的 JSON。

例如，Apache APISIX 能夠接收 HTTP 請求，然後將其轉碼並轉發給 gRPC 服務，獲取響應，並透過其gRPC Transcode外掛將其以 HTTP 格式返回給客戶端。

API 可觀察性
到目前為止，我們知道 API 閘道器為傳入各種目的地的流量提供了一箇中央控制點，但它也可以作為觀察的中心點，因為它具有了解客戶端和我們之間移動的所有流量的獨特資格。服務網路。始終可以檢測 API 閘道器，以便收集可觀察性資料（結構化日誌、指標和跟蹤），以便使用專門的監控工具。
例如，Apache APISIX 提供了預構建的聯結器（外掛），您可以輕鬆地將其與外部監控工具整合。您可以利用這些聯結器從 API 閘道器獲取日誌資料，以進一步獲取有用的指標並全面瞭解使用情況，您可以管理環境中 API 的效能和安全性。

API 快取
API 快取是另一個級別的快取，通常在 API 閘道器中實現。它可以減少對端點的呼叫次數，還可以透過快取來自上游的響應來改善對 API 的請求延遲。如果 API Gateway 快取具有所請求資源的新副本，它會使用該副本直接滿足請求，而不是向端點發出請求。如果未找到快取的資料，則請求將傳輸到預期的上游服務（後端服務）。

API 故障處理
API 服務因多種原因而失敗，例如網路問題、連線（無法開啟與 SQL Server 資料庫等資料來源的連線）、API 效能問題或無法對依賴項進行身份驗證。在這種情況下，我們的 API 服務應該有足夠的彈性來處理可預測的故障。此外，我們希望確保我們擁有的任何彈性機制，例如錯誤處理程式碼、斷路器、健康檢查、重試、回退、冗餘例項等。現代 API 閘道器支援上述所有錯誤處理功能，包括自動重試和超時。

API Gateway 充當協調器，可以使用此狀態報告來決定如何管理流量、將負載平衡到健康節點、由於一些級聯故障而快速失敗，或者只是在它發現出現問題時提醒您。API Gateway 還確保路由和其他網路級元件成功協同工作，以將請求傳遞到 API 程式。它可以幫助您在早期階段檢測並更輕鬆地解決正在執行的應用程式的問題。或者 API 閘道器級別的故障注入機制可用於測試應用程式或微服務 API 對各種形式的故障的彈性，以建立對生產環境的信心。

API 版本控制
這指的是能夠定義和執行 API 的多個併發版本。這一點尤其重要，因為 API 會隨著時間的推移而發展，並且能夠管理 API 的併發版本將使 API 使用者能夠逐步切換到 API 的較新版本，因此舊版本可以被棄用並最終退役。這一點很重要，因為 API 就像任何其他軟體應用程式一樣，應該能夠發展以支援新功能或僅僅響應錯誤修復。

您可以使用 API 閘道器來實現基於 API 版本控制（標頭、查詢引數或路徑）。逐步發展您的 RESTful API，一篇循序漸進的方法部落格文章解釋瞭如何透過在 API Gateway 中配置兩條路由來實現版本控制，一個是版本控制的，另一個是非版本控制的，透過啟用Apache APISIX 的代理重寫外掛在它們之間切換。

概括
在整篇文章中，我們描述了 API Gateway 在設計 API-Led 架構中的一些用例，例如 API 如何處理身份驗證、轉換、聚合、快取、可觀察性，如何應用 API 閘道器以路由訪問多個後端端點等。但是，人們可能會想到許多其他用例。