微服務(wù)架構(gòu)中API網(wǎng)關(guān)介紹
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ù)(參見下圖 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ù)通信公開暴露服務(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)提供的靈活性讓開發(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è)連接的開銷,并且這些網(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 消息(參見下圖),因此它們可以應(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使用)和行為,從而提高可見性、安全性并減少停機(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è)施,不被公開。這使得攻擊者很難試圖關(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)有助于開發(fā)人員為應(yīng)用程序編寫更少的代碼,從而促進(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)。
三大開源API網(wǎng)關(guān)工具
在評(píng)估API網(wǎng)關(guān)工具時(shí),組織可以尋找開源工具、云服務(wù)提供商或企業(yè)版。如果開源是您的首要任務(wù),我們根據(jù)易用性、靈活性和可擴(kuò)展性等因素列出了排名前三的開源API網(wǎng)關(guān)工具。
1.TykAPI網(wǎng)關(guān)
Tyk提供了一個(gè)完全開源的網(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、客戶端證書等的 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 的一些開源功能包括:
- 端到端自動(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 的開源版本提供以下功能:
- 一個(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)部溝通的可見性。
- 無(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。
- 上一篇
量子計(jì)算現(xiàn)狀:當(dāng)前所處的位置和未來(lái)發(fā)展走向
量子計(jì)算用例蘊(yùn)藏的巨大潛力讓許多行業(yè)人士感到興奮,然而就像5G一樣,這一期望可能會(huì)受挫,因?yàn)檫@些用例缺乏規(guī)?;占暗臈l件和標(biāo)準(zhǔn)。
- 下一篇
光技術(shù)創(chuàng)新推動(dòng)了云基礎(chǔ)設(shè)施的性能、容量和彈性
網(wǎng)絡(luò)的復(fù)雜性正在穩(wěn)步增加。在云計(jì)算技術(shù)沒(méi)有出現(xiàn)之前,只有數(shù)據(jù)中心托管應(yīng)用程序,這些應(yīng)用程序驅(qū)動(dòng)著互聯(lián)網(wǎng)的OTT數(shù)字服務(wù)。而如今迅速演變?yōu)椴渴鸪笠?guī)模云提計(jì)算供商提供的公共云服務(wù),創(chuàng)建混合和多云生態(tài)系統(tǒng)。
相關(guān)資訊
- 企業(yè)是否準(zhǔn)備好保護(hù)其云計(jì)算操作
- 分布式系統(tǒng):拆分與協(xié)同的平衡
- 阿里云全面降價(jià),釋放了什么信號(hào)?
- 人工智能的非結(jié)構(gòu)化數(shù)據(jù)管理
- 人工智能改變科學(xué)的四種方式
- 看到雙重安全問(wèn)題
- 關(guān)于AI驅(qū)動(dòng)的網(wǎng)絡(luò)攻擊,您應(yīng)該了解
- 區(qū)塊鏈和物聯(lián)網(wǎng)推動(dòng)市場(chǎng)增長(zhǎng)的六
- 區(qū)塊鏈如何將價(jià)值從信息互聯(lián)網(wǎng)傳
- 物聯(lián)網(wǎng)在能源轉(zhuǎn)型中的作用