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

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

什么是 API 網(wǎng)關(guān)？

API 網(wǎng)關(guān)是客戶端和微服務(wù)之間的服務(wù)器（或 L7 代理），充當(dāng)所有客戶端進入系統(tǒng)的集中入口點。它是一個反向代理，接受客戶端 API 調(diào)用并將它們轉(zhuǎn)發(fā)到適當(dāng)?shù)奈⒎?wù)（參見下圖 A）。

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

圖 A – 微服務(wù)架構(gòu)的 API 網(wǎng)關(guān)實現(xiàn)概念圖

微服務(wù)對 API 網(wǎng)關(guān)的需求

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

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

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

安全問題

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

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

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

往返引起的延遲

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

API 網(wǎng)關(guān)流量

API 網(wǎng)關(guān)是一個 L7 代理，它從通常由客戶端請求的前端微服務(wù)中抽象出流量管理。API 網(wǎng)關(guān)可以讀取和理解 HTTP 消息（參見下圖），因此它們可以應(yīng)用過濾器或?qū)α髁坎扇⌒袆印?/p>

HTTP消息結(jié)構(gòu)

請求在 API 網(wǎng)關(guān)處流經(jīng)多個步驟。下圖（圖 B）表示位于 Kubernetes 集群邊緣的 API 網(wǎng)關(guān)以及請求流經(jīng)的階段。

圖 B – 通過 API 網(wǎng)關(guān)的傳入 gRPC 請求的流量

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

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

API網(wǎng)關(guān)功能

除了上面提到的關(guān)鍵功能外，API 網(wǎng)關(guān)還提供許多功能。

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

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

API 網(wǎng)關(guān)的好處

API 網(wǎng)關(guān)實施可幫助組織獲得以下好處等。

改進的應(yīng)用程序安全性

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

增強處理和擴展微服務(wù)的靈活性

API 網(wǎng)關(guān)將外部客戶端與內(nèi)部微服務(wù)分離。這為 DevOps 和基礎(chǔ)架構(gòu)工程師提供了高度的靈活性，可以更改后端服務(wù)，而無需更新客戶端應(yīng)用程序中的配置?？蛻舳巳匀豢梢酝ㄟ^網(wǎng)關(guān)發(fā)出請求并獲得響應(yīng)，而無需了解后端發(fā)生的變化。許多重要的功能，例如 authN/Z 和負載平衡，將由網(wǎng)關(guān)負責(zé)。將這些責(zé)任卸載到網(wǎng)關(guān)有助于開發(fā)人員為應(yīng)用程序編寫更少的代碼，從而促進創(chuàng)新并實現(xiàn)快速發(fā)布。

API 提供商更好的貨幣化

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

改進的用戶體驗 (UX)

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

三大開源 API 網(wǎng)關(guān)工具

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

1.Tyk API網(wǎng)關(guān)

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

以下是 Tyk API 網(wǎng)關(guān)的一些功能：

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

2.Kong API網(wǎng)關(guān)

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

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

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

3. KrakenD API網(wǎng)關(guān)

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

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

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

API 網(wǎng)關(guān)是銀彈嗎？

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

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

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

此外，還有不同的場景可以使用您現(xiàn)有的 API 網(wǎng)關(guān)基礎(chǔ)設(shè)施來實施 Istio。