采用 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.

你可以使用 API 網關來實現 API 版本管理。版本管理可以是請求頭，查詢參數或路徑。

APISIX 的網關

如果你需要令 API 服務可伸縮，就需要使用 API 網關。Apache APISIX 提供了必要的功能，可以實現健壯的入口，它的好處是顯而易見的。它遵循 API 主導的架構，并且有可能改變客戶端與托管服務交互的方式。

本文經作者許可，從 Apache APISIX 博客改編并轉載。