微服務(wù)五種開源API網(wǎng)關(guān)實(shí)現(xiàn)組件對(duì)比-創(chuàng)新互聯(lián)

微服務(wù)架構(gòu)是當(dāng)下比較流行的一種架構(gòu)風(fēng)格，它是一種以業(yè)務(wù)功能組織的服務(wù)集合，可以持續(xù)交付、快速部署、更好的可擴(kuò)展性和容錯(cuò)能力，而且還使組織更容易去嘗試新技術(shù)棧。微服務(wù)具有幾個(gè)關(guān)鍵特征：

成都創(chuàng)新互聯(lián)公司是網(wǎng)站建設(shè)專家,致力于互聯(lián)網(wǎng)品牌建設(shè)與網(wǎng)絡(luò)營(yíng)銷，專業(yè)領(lǐng)域包括成都網(wǎng)站制作、成都做網(wǎng)站、電商網(wǎng)站制作開發(fā)、小程序定制開發(fā)、微信營(yíng)銷、系統(tǒng)平臺(tái)開發(fā)，與其他網(wǎng)站設(shè)計(jì)及系統(tǒng)開發(fā)公司不同，我們的整合解決方案結(jié)合了恒基網(wǎng)絡(luò)品牌建設(shè)經(jīng)驗(yàn)和互聯(lián)網(wǎng)整合營(yíng)銷的理念，并將策略和執(zhí)行緊密結(jié)合，且不斷評(píng)估并優(yōu)化我們的方案，為客戶提供全方位的互聯(lián)網(wǎng)品牌整合方案！

• 高度可維護(hù)和可測(cè)試性
• 與其他服務(wù)松散耦合
• 且可獨(dú)立部署
• 能夠由一個(gè)小團(tuán)隊(duì)開發(fā)

現(xiàn)在很多公司企業(yè)想將自己的單體應(yīng)用架構(gòu)遷移到微服務(wù)架構(gòu)，在這個(gè)問題上，Martin Fowler提出了3個(gè)前提，而Phil Calcado對(duì)其進(jìn)行了擴(kuò)展如下：

• 快速配置計(jì)算資源
• 基本監(jiān)控
• 快速部署
• 易于配置存儲(chǔ)
• 易于訪問網(wǎng)關(guān)
• 認(rèn)證、授權(quán)
• 標(biāo)準(zhǔn)化的 RPC

今天我們主要講講易于訪問的網(wǎng)關(guān)，也就是 API 網(wǎng)關(guān)。

為什么需要 API 網(wǎng)關(guān)

假設(shè)我們要使用微服務(wù)架構(gòu)構(gòu)建一個(gè)電商平臺(tái)，以下可能是一些潛在的服務(wù)：

• 購物車服務(wù)
• 訂單服務(wù)
• 商品服務(wù)
• 評(píng)論服務(wù)
• 庫存服務(wù)

等等，客戶端應(yīng)該怎么訪問這些服務(wù)呢？原來單體應(yīng)用的情況我們都知道，都在一個(gè)服務(wù)器上部署，直接訪問IP+端口+服務(wù)前綴即可，現(xiàn)在微服務(wù)架構(gòu)下，每個(gè)服務(wù)都可以獨(dú)立部署，并且是由不同的開發(fā)團(tuán)隊(duì)開發(fā)的，難道我們要這樣訪問嗎？

理論上每個(gè)服務(wù)都有端點(diǎn)可以訪問，但是客戶端就需要記錄所有服務(wù)的端點(diǎn)，發(fā)起5次請(qǐng)求，現(xiàn)在還是5個(gè)服務(wù)，如果之后擴(kuò)展多了呢？對(duì)客戶端來說就是一個(gè)災(zāi)難，隨之帶來的就是安全性問題、擴(kuò)展性問題等，所以這種客戶端直接與每個(gè)服務(wù)交互是不可取的，通常，更好的方式是使用 API 網(wǎng)關(guān)。

API 網(wǎng)關(guān)是客戶端訪問服務(wù)的統(tǒng)一入口，API 網(wǎng)關(guān)封裝了后端服務(wù)，還提供了一些更高級(jí)的功能，例如：身份驗(yàn)證、監(jiān)控、負(fù)載均衡、緩存、多協(xié)議支持、限流、熔斷等等，API 網(wǎng)關(guān)還可以針對(duì)不同的客戶端定制不同粒度的 API，上面例子中修改架構(gòu)后如下：

API 網(wǎng)關(guān)的優(yōu)缺點(diǎn)

API 網(wǎng)關(guān)的好處是顯而易見的，封裝了應(yīng)用程序的內(nèi)部結(jié)構(gòu)，為不同客戶端提供不同粒度的 API，同時(shí)網(wǎng)關(guān)自身也提供了一些高級(jí)功能，也減少了客戶端與應(yīng)用程序之間的往返次數(shù)，使客戶端代碼更優(yōu)雅。

同時(shí)使用網(wǎng)關(guān)也存在一些缺點(diǎn)，增加了一個(gè)新的組件，增加了整個(gè)應(yīng)用架構(gòu)的復(fù)雜度，一個(gè)通俗的道理，你做的越多你犯錯(cuò)的風(fēng)險(xiǎn)也越高，網(wǎng)關(guān)不可用很可能導(dǎo)致整個(gè)應(yīng)用架構(gòu)崩潰，當(dāng)然現(xiàn)在有各種各樣的方案，能防止網(wǎng)關(guān)崩潰，它也可能存在瓶頸風(fēng)險(xiǎn)。

使用網(wǎng)關(guān)有利有弊，我個(gè)人而言，利肯定是大于弊的，我們盡可能的將弊端降到最低。

API 網(wǎng)關(guān)一些實(shí)現(xiàn)

使用一個(gè)組件時(shí)，尤其是這種比較流行的架構(gòu)，組件肯定存在開源的，我們不必自己去從零開始去實(shí)現(xiàn)一個(gè)網(wǎng)關(guān)，自己開發(fā)一個(gè)網(wǎng)關(guān)的工作量是相當(dāng)可觀的，現(xiàn)在比較流行的開源 API 網(wǎng)關(guān)如下所示：

Kong

Kong是一個(gè)在 Nginx 中運(yùn)行的Lua應(yīng)用程序，并且可以通過lua-nginx模塊實(shí)現(xiàn)，Kong不是用這個(gè)模塊編譯Nginx，而是與 OpenResty 一起發(fā)布，OpenResty已經(jīng)包含了 lua-nginx-module， OpenResty 不是 Nginx 的分支，而是一組擴(kuò)展其功能的模塊。

它的核心是實(shí)現(xiàn)數(shù)據(jù)庫抽象，路由和插件管理，插件可以存在于單獨(dú)的代碼庫中，并且可以在幾行代碼中注入到請(qǐng)求生命周期的任何位置。

Traefik

Traefik 是一個(gè)現(xiàn)代 HTTP 反向代理和負(fù)載均衡器，可以輕松部署微服務(wù)，Traeffik 可以與您現(xiàn)有的組件（Docker、Swarm，Kubernetes，Marathon，Consul，Etcd，…）集成，并自動(dòng)動(dòng)態(tài)配置。

Ambassador

Ambassador 是一個(gè)開源的微服務(wù) API 網(wǎng)關(guān)，建立在 Envoy 代理之上，為用戶的多個(gè)團(tuán)隊(duì)快速發(fā)布，監(jiān)控和更新提供支持，支持處理 Kubernetes ingress controller 和負(fù)載均衡等功能，可以與 Istio 無縫集成。

Tyk

Tyk是一個(gè)開源的、輕量級(jí)的、快速可伸縮的 API 網(wǎng)關(guān)，支持配額和速度限制，支持認(rèn)證和數(shù)據(jù)分析，支持多用戶多組織，提供全 RESTful API。基于 go 編寫。

Zuul

Zuul 是一種提供動(dòng)態(tài)路由、監(jiān)視、彈性、安全性等功能的邊緣服務(wù)。Zuul 是 Netflix 出品的一個(gè)基于 JVM 路由和服務(wù)端的負(fù)載均衡器。

API 網(wǎng)關(guān)實(shí)現(xiàn)對(duì)比

總結(jié)

由上述對(duì)比表格中可以看出：從開源社區(qū)活躍度來看，無疑是Kong和Traefik較好；從成熟度來看，較好的是Kong、Tyk、Traefik；從性能角度來看，Kong要比其他幾個(gè)領(lǐng)先一些；從架構(gòu)優(yōu)勢(shì)的擴(kuò)展性來看，Kong、Tyk有豐富的插件，Ambassador也有插件但不多，而Zuul是完全需要自研，但Zuul由于與Spring Cloud深度集成，使用度也很高，近年來Istio服務(wù)網(wǎng)格的流行，Ambassador因?yàn)槟軌蚝虸stio無縫集成也是相當(dāng)大的優(yōu)勢(shì)。

具體使用選擇還是需要依據(jù)具體的業(yè)務(wù)場(chǎng)景，我們?cè)趨⒖兼溄又惺占艘恍┬阅軐?duì)比，大家可以做下參考。

參考鏈接

• https://www.bbva.com/en/api-gateways-kong-vs-tyk/ kong vs tyk
• https://stackshare.io/stackups/kong-vs-traefik kong vs traefik
• https://blog.getambassador.io/envoy-vs-nginx-vs-haproxy-why-the-open-source-ambassador-api-gateway-chose-envoy-23826aed79ef envoy vs nginx
• https://engineering.opsgenie.com/comparing-api-gateway-performances-nginx-vs-zuul-vs-spring-cloud-gateway-vs-linkerd-b2cc59c65369 nginx vs zuul

另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)cdcxhl.cn，海內(nèi)外云服務(wù)器15元起步，三天無理由+7*72小時(shí)售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國服務(wù)器、虛擬主機(jī)、免備案服務(wù)器”等云主機(jī)租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡(jiǎn)單易用、服務(wù)可用性高、性價(jià)比高”等特點(diǎn)與優(yōu)勢(shì)，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場(chǎng)景需求。

分享文章：微服務(wù)五種開源API網(wǎng)關(guān)實(shí)現(xiàn)組件對(duì)比-創(chuàng)新互聯(lián)
當(dāng)前地址：http://muchs.cn/article12/djihgc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供域名注冊(cè)、ChatGPT、網(wǎng)站設(shè)計(jì)公司、網(wǎng)站改版、微信小程序、品牌網(wǎng)站建設(shè)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)