使用開源 API 網關實現可伸縮 API

採用 Apache APISIX 的 API 主導架構。

API 網關是一個單一節點，提供對 API 調用入口。網關聚合了所請求的服務，並相應傳回合適的響應信息。為了令你的 API 網關有效地工作，設計一個可靠、高效且簡潔地 API 至關重要。本文介紹一種設計風格，但只要你理解其中的重點內容，它就能解決你的相關問題。

由 API 主導的方法

API 主導的方法是將 API 置於應用程序和它們需要訪問的業務能力之間的通信核心，從而在所有數字通道上一致地交付無縫功能。API 主導的連接是指使用一種可重用、且設計得當的 API 來連接數據和應用程序的方法。

API 主導的架構

API 主導的架構是一種架構方法，它著眼於實現重用 API 的最佳方式。它能解決以下問題：

保護 API，使外界無法在未授權情況下訪問 API
確保應用程序能找到正確的 API 端點
限制對 API 的請求次數，從而確保持續的可用性
支持持續集成、測試、生命周期管理、監控、運維等等
防止錯誤在棧間傳播
對 API 的實時監測和分析
實現可伸縮和靈活的業務能力（例如支持微服務架構）

API 資源路由

實現一個 API 網關，把它作為與所有服務通信的單一入口點，意味著使用者只需要知道 URL 就能使用 API。將請求路由到相應的服務端點，並執行相應的功能是 API 網關的職責。

Image depicting the API routing traffic.

由於客戶端應用程序不需要從多個 HTTP 端點調用功能，這個辦法就減少了 API 使用者的操作複雜度。對每個服務來說，也不需實現一個單獨的層級去實現認證、授權、節流和速度限制。大多數API 網關，如開源的 Apache APISIX，已經包含了這些核心功能。

API 基於內容的路由

基於內容的路由機制也使用 API 網關根據請求的內容進行路由調用。例如，一個請求可能是基於 HTTP 請求的頭部內容或消息體被路由，而不只基於它的目標 URI。

考慮這樣一個場景：為了將負載在多個資料庫實例間均分，需要對資料庫進行分區。當記錄總數較大，單個資料庫實例難以管理負載時，常常會用這個辦法。

還有一個更好的辦法，就是把記錄在多個資料庫實例間分散開來。然後你實現多個服務，每個不同的資料庫都有一個服務，把一個 API 網關作為訪問所有服務的唯一入口。然後，你可以配置你的 API 網關，根據從 HTTP 頭或有效載荷中獲得的密鑰，將調用路由到相應的服務。

Image of the API gateway exposing a single customer.

在上面的圖表中，一個 API 網關向多個客戶服務暴露一個單一的 /customers 資源，每個服務都有對應的不同資料庫。

API 地理路由

API 地理路由解決方案根據 API 調用的來源將其路由到最近的 API 網關。為了防止地理距離導致的延遲問題（例如一個位於亞洲的客戶端調用了位於北美地區的 API），你可以在多個地區部署 API 網關。對於一個 API 網關，你可以在每個區域使用不同的子域名，讓應用程序基於業務邏輯選擇最近的網關。因此 API 網關就提供了內部負載均衡，確保進入的請求分布於可用的實例之間。

Image of a DNS traffic management system.

通常使用 DNS 流量管理服務和 API 網關，針對該區域的負載均衡器解析子域名，定位到距離最近的網關。

API 聚合器

這項技術對多個服務執行操作（例如查詢），並向客戶端服務以單個 HTTP 響應的形式返回結果。API 聚合器使用 API 網關在伺服器端代表使用者來執行這項工作，而非讓客戶端程序多次調用 API。

假定你有一款移動端 APP，對不同的 API 發起多次調用。這增加了客戶端代碼的複雜性，導致網路資源的過度使用，而且由於延遲性，用戶體驗也不好。網關可以接收所有需要的信息，可以要求認證和驗證，並理解來自每個 API 的數據結構。它也可以傳遞響應的有效載荷，因此它們也會作為一個用戶需要的統一負載傳回移動端。

Image of an API gateway.

API 集中認證

在這種設計中，API 網關就是一個集中式認證網關。作為一個認證者，API 網關在 HTTP 請求頭中查找訪問憑據（例如不記名的令牌）。然後它藉助於身份驗證提供方執行驗證憑據的業務邏輯。

Image of a tree showing API gateway's centralized authentication.

使用 API 網關的集中式身份驗證能解決很多問題。它完全取代了應用程序中的用戶管理模塊，通過對來自客戶端應用程序的身份驗證請求的快速響應來提高性能。Apache APISIX 提供了一系列插件，支持不同的 API 網關認證方法。

Image showing Apache ASPISIS and various plugins.

API 格式轉換

API 格式轉換是通過同一傳輸方式將有效載荷從一種格式轉換為另一種格式的能力。例如，你可以通過 HTTPS 從 XML/SOAP 格式轉換為 JSON 格式，反之亦然。API 網關提供了支持 REST API 的功能，可以有效地進行負載和傳輸的轉換。例如，它可以把消息隊列遙測傳輸（MQTT）轉換為 JSON 格式。

Image depicting APISIX transfers.

Apache APISIX 能夠接收 HTTP 請求，對其進行代碼轉換，然後將其轉發給 gRPC 服務。它通過 gRPC Transcode 插件獲取響應並將其以 HTTP 格式返回給客戶端。

API 的可觀察性

現在，你知道 API 網關為進入各種目的地的流量提供了一個中心控制點。但它也可以是一個中心觀察點，因為就監控客戶端和伺服器端的流量來說，它有獨特的資格。為了收集監測工具所需要的數據（結構化日誌、度量和跟蹤），你可以對 API 網關作出調整。

Apache APISIX 提供了預先構建的連接器，因此你可以跟外部監測工具結合使用。你可以利用這些連接器從你的 API 網關收集日誌數據，進一步獲得有用的指標，並獲取完整可見的服務使用情況。

API 緩存

API 緩存通常在網關內部實現。它可以減少對端點的調用次數，同時通過緩存上游的響應，改進了請求延遲的情況。如果網關緩存對請求資源有一個新副本，它會直接使用這個副本來響應這個請求，而不必對端點發出請求。如果緩存數據不存在，就將請求傳到目標上游服務。

Image depicting how the API gateway cache functions.

API 錯誤處理

由於各種原因，API 服務可能會出錯。在這種情況下，API 服務需要有一定的彈性，來應對可預見的錯誤。你也希望確保彈性機制能正常工作。彈性機制包括錯誤處理代碼、斷路器、健康檢查、回退、冗餘等等。新式的 API 網關支持各種常見錯誤處理功能，包括自動重試和超時設置。

Image depicting some of the many mechanisms that the modern API Gatway can support.

API 網關作為一個協調器，它會根據各方面情況來決定如何管理流量、將負載均衡發送到一個健康的節點，還能快速失敗。當有異常狀況，它也會向你發出警示。API 網關也保證路由和其他網路級組件能協同將請求傳給 API 進程。它能幫助你在早期檢測出問題，並修復問題。網關的錯誤注入機制（類似於 Apache APISIX 使用的那種）可用於測試應用程序或微服務 API 在各種錯誤發生時的彈性。

API 版本管理

版本管理是指定義和運行多個並發的 API 版本的功能。這點也很重要，因為 API 是隨著時間推移不斷改進的。如果能對 API 的並發版本進行管理，那麼 API 使用者就可以較快地切換到新的版本。這也意味著較老的版本可以被廢棄並最終退役。API 也跟其他應用程序類似，無論是開發新功能還是進行錯誤修復，都存在演變的過程。

Image of using the API Gateway to implement API versioning.