一些架構師、云工程師和 DevOps 人員經常說，“微服務是小單體。” 這源于處理大量服務的復雜性，尤其是管理和配置它們的網絡規(guī)則和安全方面。

當客戶端向分布在分布式系統(tǒng)中的多個集群和云中的微服務發(fā)出請求時，跟蹤每個請求以確保安全和正確的路由規(guī)則變得乏味。理想情況下，后端服務不應該這樣做，因為它們應該單獨提供業(yè)務邏輯。這就是 API 網關（所有請求的單一入口點）的用武之地。讓我們看看什么是 API 網關以及它提供的功能和優(yōu)勢。

什么是 API 網關？

API 網關是客戶端和微服務之間的服務器（或 L7 代理），充當所有客戶端進入系統(tǒng)的集中入口點。它是一個反向代理，接受客戶端 API 調用并將它們轉發(fā)到適當?shù)奈⒎眨▍⒁娤聢D A）。

通過為每個客戶端提供 API，API 網關封裝了底層系統(tǒng)的復雜性，讓客戶端與其對話，而不是調用特定的服務。他們還在流量到達服務之前執(zhí)行安全檢查（身份驗證和授權），從而讓服務專注于其核心功能。

圖 A – 微服務架構的 API 網關實現(xiàn)概念圖

微服務對 API 網關的需求

直接的客戶端到微服務通信模式帶來的挑戰(zhàn)導致了 API 網關的流行。讓我們來看看其中的一些。

服務發(fā)現(xiàn)和流量路由問題

對于客戶端到微服務的直接連接，客戶端必須知道服務實例的特定端點。但是由于服務的動態(tài)（去）縮放，跟蹤端點增加了客戶端的復雜性。此外，如果客戶端與服務耦合，則擴展將成為一個問題，因為它需要在客戶端更改配置。此外，當客戶端直接調用服務時，很難配置基于某些屬性的路由流量，例如地理（geo-routing）。

安全問題

為直接的客戶端到服務通信公開暴露服務端點會引起安全問題。它增加了入侵者的攻擊面，并使后端服務容易受到威脅，例如數(shù)據包嗅探、中間人攻擊等。此外，直接的客戶端到微服務給服務增加了驗證和授權 API 調用的負擔而不是讓他們專注于交付業(yè)務邏輯。

影響互操作性的多種協(xié)議

微服務架構提供的靈活性讓開發(fā)人員可以使用他們選擇的語言（Python、Java、Go）構建服務。同樣，他們可以使用不同的 API 類型（例如 REST、gRPC 等）來實現(xiàn)這些服務。在客戶端到微服務的直接通信模式中，客戶端需要理解并使用不同的協(xié)議進行通信。這增加了額外的復雜性，因為客戶端應用程序將需要更多代碼和邏輯。

往返引起的延遲

考慮來自亞馬遜網站的產品頁面。產品定價、數(shù)量和評論等一些屬性將在后端部署為不同的服務。如果客戶端直接調用服務，它將不得不為每個服務（產品價格、評論、數(shù)量等）發(fā)出單獨的請求以檢索所需的信息，因為沒有緩存來自上游服務的響應的機制。這些調用增加了建立多個連接的開銷，并且這些網絡請求引起的往返增加了延遲和次優(yōu)的用戶體驗。
API 網關的架構在某種程度上減輕了直接客戶端到微服務連接所帶來的挑戰(zhàn)，并提供了多種功能。

API 網關流量

API 網關是一個 L7 代理，它從通常由客戶端請求的前端微服務中抽象出流量管理。API 網關可以讀取和理解 HTTP 消息（參見下圖），因此它們可以應用過濾器或對流量采取行動。

HTTP消息結構

請求在 API 網關處流經多個步驟。下圖（圖 B）表示位于 Kubernetes 集群邊緣的 API 網關以及請求流經的階段。

圖 B – 通過 API 網關的傳入 gRPC 請求的流量

• 請求驗證： 首先，API 網關通過檢查請求方法、標頭和正文來驗證傳入請求，以確保它符合預定義的規(guī)則。此外，根據網關的允許列表和拒絕列表將請求列入白名單或黑名單，以執(zhí)行嚴格的訪問控制。
• 認證授權（AuthN/Z）： 網關通過驗證憑據，如API密鑰（認證），對經過驗證的請求進行認證和授權，然后實施授權策略，如RBAC（基于角色的訪問控制）。API 網關還可以使用 IdP（身份提供者）的幫助進行詳盡的 authN/Z 檢查，例如多因素身份驗證 (MFA)。
• 服務發(fā)現(xiàn)： API 網關使用服務發(fā)現(xiàn)組件為授權請求定位適當?shù)暮蠖朔铡Ｋㄟ^查詢服務注冊表或使用動態(tài) DNS 來實現(xiàn)。
• 協(xié)議轉換： API 網關可以在必要時在客戶端和微服務之間轉換協(xié)議。在上圖中，客戶端發(fā)送一個 gRPC 請求，該請求被轉換為 REST 以供“購物車”服務理解。此外，網關在將響應返回給客戶端之前將響應轉換為面向公眾的協(xié)議（此處為 REST 到 gRPC 格式）。
• 動態(tài)路由： 一旦找到后端服務并根據需要轉換請求協(xié)議，API 網關就會將請求路由到適當?shù)姆諏嵗蜇撦d均衡器。網關通常在其配置中定義了路由規(guī)則。

API 網關完成上述步驟后，會將服務的響應返回給客戶端。但是，請注意，概述的步驟可能會有所不同，具體取決于網關的配置方式和其他功能的實現(xiàn)。

API網關功能

除了上面提到的關鍵功能外，API 網關還提供許多功能。

• 高級流量路由： API 網關可以管理和控制 API 流量在服務之間的分配方式。它們可以執(zhí)行負載平衡和流量拆分，并充當反向代理和正向代理。API 網關還實現(xiàn)了漸進式交付，例如藍綠部署。
• 速率限制： API 網關可以根據 IP 地址或 HTTP 標頭限制請求。它有助于服務避免請求過載并防止惡意攻擊，例如拒絕服務 (DoS)。速率限制還有助于 API 提供商實施不同的貨幣化策略（例如，分層定價模型）。
  
• 錯誤處理： API網關可以對因服務器內部錯誤、認證失敗、無效輸入等導致API請求失敗的錯誤響應進行處理和標準化。可以為使用網關的客戶端自定義錯誤的HTTP狀態(tài)碼和錯誤信息，幫助客戶端正確理解和處理/調試。
• 斷路器： API 網關可以實現(xiàn)斷路器模式，幫助后端服務避免因請求失敗而過載。熔斷模式將停止向失敗的服務轉發(fā)請求并返回適當?shù)腻e誤代碼。它有助于防止錯誤級聯(lián)到健康的上游服務，并使 API 基礎設施具有彈性。
• 可觀察性： API 網關為操作可觀察性提供日志記錄、監(jiān)控和分析。它有助于了解 API 基礎設施的性能（API 使用）和行為，從而提高可見性、安全性并減少停機時間。
• 緩存： API 網關可以緩存和服務先前對客戶端請求的響應。如果啟用了 API 緩存，網關將根據緩存的響應檢查請求并轉發(fā)請求（如果存在），從而無需每次都向后端服務發(fā)出新的相同請求。這將顯著降低服務負載和響應延遲，并改善 API 性能和用戶體驗。
  
• SSL 終止： API 網關可以執(zhí)行 SSL 終止，這涉及代表后端服務解密來自客戶端的傳入 SSL 連接。卸載 SSL 終止以及 authN/Z 等其他安全功能將使服務專注于其主要職責。

API 網關提供的所有這些功能為管理分布式服務系統(tǒng)帶來了巨大的好處。

API 網關的好處

API 網關實施可幫助組織獲得以下好處等。

改進的應用程序安全性

作為 API 管理的集中點，網關隱藏了服務和底層基礎設施，不被公開。這使得攻擊者很難試圖關閉應用程序，特別是通過用請求壓倒服務（DoS 攻擊）。由于網關在到達后端之前處理每個請求，因此它們可以對此類攻擊應用速率限制。其他安全功能，如請求驗證、authN/Z、斷路和策略實施，再加上日志記錄和監(jiān)控，使 API 網關有助于應用程序的整體安全性。

增強處理和擴展微服務的靈活性

API 網關將外部客戶端與內部微服務分離。這為 DevOps 和基礎架構工程師提供了高度的靈活性，可以更改后端服務，而無需更新客戶端應用程序中的配置。客戶端仍然可以通過網關發(fā)出請求并獲得響應，而無需了解后端發(fā)生的變化。許多重要的功能，例如 authN/Z 和負載平衡，將由網關負責。將這些責任卸載到網關有助于開發(fā)人員為應用程序編寫更少的代碼，從而促進創(chuàng)新并實現(xiàn)快速發(fā)布。

API 提供商更好的貨幣化

API 貨幣化就是為第三方消費者將 API 產品化。API 網關為公司提供了一種更好的方式來將其 API 貨幣化以產生收入或支付維護 API 的運營成本。網關將客戶端請求連接到計費系統(tǒng)，從而為 API 提供商提供集中計費和計量機制。這有助于公司通過為 API 消費者實施不同的定價模型（例如現(xiàn)收現(xiàn)付、分層和基于單位）來跟蹤 API 使用情況并收取服務費用。

改進的用戶體驗 (UX)

API 網關通過請求底層服務并聚合它們來減輕客戶端發(fā)出過多請求的麻煩。也就是說，對網關的單個請求就足以滿足客戶端應用程序的需求，從而顯著減少延遲。并且在頻繁重復請求的情況下，網關可以及時提供緩存的響應，而無需將請求轉發(fā)給后端。此外，借助監(jiān)控和日志記錄功能，API 網關可以更輕松地跟蹤和排除任何性能問題，這有助于最大限度地減少應用程序停機時間。所有這些都有助于提高應用程序的性能、可靠性和用戶體驗。

三大開源 API 網關工具

在評估 API 網關工具時，組織可以尋找開源工具、云服務提供商或企業(yè)版。如果開源是您的首要任務，我們根據易用性、靈活性和可擴展性等因素列出了排名前三的開源 API 網關工具。

1.Tyk API網關

Tyk提供了一個完全開源的網關，支持多種協(xié)議，如 REST、GraphQL 和 gRPC。除了 Redis 之外，它沒有第三方依賴項，是當今最快的網關之一。

以下是 Tyk API 網關的一些功能：

• 使用任何協(xié)議：REST、SOAP、GraphQL、gRPC 和 TCP。
• 使用 OIDC、JWT、客戶端證書等的 AuthN/Z。
• 使用任何語言（Python、JS、Go）創(chuàng)建可擴展插件。
• Kubernetes 原生聲明式 API 的Tyk 運算符。
• 通過啟用 CORS 允許基于瀏覽器的請求。
• API 版本控制和生命周期管理。
• 帶有分析日志記錄的詳細 API 使用數(shù)據。

2.Kong API網關

Kong API Gateway是一個適用于多云和混合云部署的云原生網關。在其自己的Kubernetes ingress controller的幫助下，網關也是 Kubernetes 原生的。Kong 以其通過模塊和插件的靈活性和可擴展性而聞名。

Kong API Gateway 的一些開源功能包括：

• 端到端自動化，以推動 API 設計和執(zhí)行的 GitOps 流程。
• 用于將 API 部署到 K8s 的 Kubernetes Ingress Controller。
• 基本流量控制插件，例如基本速率限制和輕量級緩存。
• 簡單的數(shù)據轉換
• gRPC 到后端 gRPC 服務的轉換。
• AuthN/Z（HMAC、JWT 密鑰驗證、有限的 0Auth 2.0 和 LDAP、機器人檢測、ACL。）
• 簡單日志記錄（文件日志記錄、HTTP 日志記錄、基本 StatsD、TCP/UDP 日志記錄。）

3. KrakenD API網關

KrakenD是一個高性能的 API 網關，采用無服務器架構構建，可提供真正的線性可擴展性。它有助于在沒有單點故障的情況下進行擴展。KrakenD 在本地、混合或云上運行，并且可以使用插件和嵌入式腳本進行擴展。

KrakenD 的開源版本提供以下功能：

• 一個名為 KrakenD Designer 的可視化工具，用于生成 KrakenD 配置。
• 多格式配置（JSON、YAML、TOML、HCL等）
• 構建自定義 Go 插件并將它們嵌入到一個隨時可用的圖像中。
• 數(shù)據轉換、CDN 的 HTTP 緩存標頭和自動輸出編碼。
• 零信任參數(shù)轉發(fā)，防止點擊劫持、嗅探和跨站腳本。
• JWT 基于聲明的路由和流量鏡像/鏡像。
• 日志記錄、跟蹤和指標（Jaeger、Zipkin、ELK 堆棧儀表板、Prometheus 等）

API 網關是銀彈嗎？

不它不是。與任何其他工具一樣，API 網關也面臨著一系列挑戰(zhàn)。這里有幾個：

• 流量處理僅限于邊緣。
• 無法處理南北交通。
• 缺乏對內部溝通的可見性。
• 無法控制集群內部的網絡。
• 不安全的東西向流量。
• 無法實現(xiàn)漸進式交付（例如金絲雀）。

詳細探索 API 網關的這些挑戰(zhàn)，并理解為什么考慮像 Istio 這樣的服務網格平臺是理想的：API 網關與 Istio 服務網格。

此外，還有不同的場景可以使用您現(xiàn)有的 API 網關基礎設施來實施 Istio。