API網(wǎng)關(guān)簡(jiǎn)化了對(duì)分布在多個(gè)Kubernetes集群和云中的微服務(wù)的管理。繼續(xù)閱讀以了解其架構(gòu)、功能和優(yōu)勢(shì)。

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

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

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

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

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

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

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

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

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

對(duì)于客戶端到微服務(wù)的直接連接，客戶端必須知道服務(wù)實(shí)例的特定端點(diǎn)。但是由于服務(wù)的動(dòng)態(tài)（去）縮放，跟蹤端點(diǎn)增加了客戶端的復(fù)雜性。此外，如果客戶端與服務(wù)耦合，則擴(kuò)展將成為一個(gè)問(wèn)題，因?yàn)樗枰诳蛻舳烁呐渲谩４送?，?dāng)客戶端直接調(diào)用服務(wù)時(shí)，很難配置基于某些屬性的路由流量，例如地理（geo-routing）。

安全問(wèn)題

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

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

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

往返引起的延遲

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

增強(qiáng)處理和擴(kuò)展微服務(wù)的靈活性

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

API提供商更好的貨幣化

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

改進(jìn)的用戶體驗(yàn) (UX)

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

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

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

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

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

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

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

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

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

KongAPIGateway 的一些開(kāi)源功能包括：

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

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

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

KrakenD 的開(kāi)源版本提供以下功能：

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

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

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

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

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

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