??? 微服務(wù)架構(gòu)在項(xiàng)目中的應(yīng)用越來(lái)越多，我們知道在微服務(wù)架構(gòu)風(fēng)格中，一個(gè)大應(yīng)用被拆分成為了多個(gè)小的服務(wù)系統(tǒng)提供出來(lái)，這些小的系統(tǒng)他們可以自成體系，也就是說(shuō)這些小系統(tǒng)可以擁有自己的數(shù)據(jù)庫(kù)，框架甚至語(yǔ)言等，這些小系統(tǒng)通常以提供 Rest Api 風(fēng)格的接口來(lái)被 H5, Android, IOS 以及第三方應(yīng)用程序調(diào)用。
但是在UI上進(jìn)行展示的時(shí)候，我們通常需要在一個(gè)界面上展示很多數(shù)據(jù)，這些數(shù)據(jù)可能來(lái)自于不同的微服務(wù)中，舉個(gè)例子。
??? 在一個(gè)電商系統(tǒng)中，查看一個(gè)商品詳情頁(yè)，這個(gè)商品詳情頁(yè)包含商品的標(biāo)題，價(jià)格，庫(kù)存，評(píng)論等，這些數(shù)據(jù)對(duì)于后端來(lái)說(shuō)可能是位于不同的微服務(wù)系統(tǒng)之中，可能我后臺(tái)的系統(tǒng)是這樣來(lái)拆分我的服務(wù)的：

??? 產(chǎn)品服務(wù) - 負(fù)責(zé)提供商品的標(biāo)題，描述，規(guī)格等。
??? 價(jià)格服務(wù) - 負(fù)責(zé)對(duì)產(chǎn)品進(jìn)行定價(jià)，價(jià)格策略計(jì)算，促銷(xiāo)價(jià)等。
??? 庫(kù)存服務(wù) - 負(fù)責(zé)產(chǎn)品庫(kù)存。
??? 評(píng)價(jià)服務(wù) - 負(fù)責(zé)用戶(hù)對(duì)商品的評(píng)論，回復(fù)等。

現(xiàn)在，商品詳情頁(yè)需要從這些微服務(wù)中拉取相應(yīng)的信息，問(wèn)題來(lái)了？
問(wèn)題由于我們使用的服務(wù)系統(tǒng)架構(gòu)，所以沒(méi)辦法像傳統(tǒng)單體應(yīng)用一樣依靠數(shù)據(jù)庫(kù)的 join 查詢(xún)來(lái)得到最終結(jié)果，那么如何才能訪(fǎng)問(wèn)各個(gè)服務(wù)呢？
按照微服務(wù)設(shè)計(jì)的指導(dǎo)原則，我們的微服務(wù)可能存在下面的問(wèn)題：

??? 服務(wù)使用了多種協(xié)議，因?yàn)椴煌膮f(xié)議有不同的應(yīng)場(chǎng)景用，比如可能同時(shí)使用 HTTP, AMQP, gRPC 等。
??? 服務(wù)的劃分可能隨著時(shí)間而變化。
??? 服務(wù)的實(shí)例或者Host+端口可能會(huì)動(dòng)態(tài)的變化。

那么，對(duì)于前端的UI需求也可能會(huì)有以下幾種：

??? 粗粒度的API，而微服務(wù)通常提供的細(xì)粒度的API，對(duì)于UI來(lái)說(shuō)如果要調(diào)用細(xì)粒度的api可能需要調(diào)用很多次，這是個(gè)不小的問(wèn)題。
??? 不同的客戶(hù)端設(shè)備可能需要不同的數(shù)據(jù)。Web,H5,APP
??? 不同設(shè)備的網(wǎng)絡(luò)性能，對(duì)于多個(gè)api來(lái)說(shuō)，這個(gè)訪(fǎng)問(wèn)需要轉(zhuǎn)移的服務(wù)端會(huì)快得多

以上，就是我們構(gòu)建微服務(wù)的過(guò)程中可能會(huì)遇到的問(wèn)題。那么如何解決呢？
這種情況下， API 網(wǎng)關(guān)（API Gataway）誕生了。
API 網(wǎng)關(guān)API網(wǎng)關(guān)是一個(gè)服務(wù)器，是系統(tǒng)的唯一入口。從面向?qū)ο笤O(shè)計(jì)的角度看，它與外觀模式類(lèi)似。API網(wǎng)關(guān)封裝了系統(tǒng)內(nèi)部架構(gòu)，為每個(gè)客戶(hù)端提供一個(gè)定制的API。它可能還具有其它職責(zé)，如身份驗(yàn)證、監(jiān)控、負(fù)載均衡、緩存、請(qǐng)求分片與管理、靜態(tài)響應(yīng)處理。
API網(wǎng)關(guān)方式的核心要點(diǎn)是，所有的客戶(hù)端和消費(fèi)端都通過(guò)統(tǒng)一的網(wǎng)關(guān)接入微服務(wù)，在網(wǎng)關(guān)層處理所有的非業(yè)務(wù)功能。通常，網(wǎng)關(guān)也是提供REST/HTTP的訪(fǎng)問(wèn)API。服務(wù)端通過(guò)API-GW注冊(cè)和管理服務(wù)。
API網(wǎng)關(guān)網(wǎng)關(guān)的價(jià)值：

??? 網(wǎng)關(guān)層對(duì)外部和內(nèi)部進(jìn)行了隔離，保障了后臺(tái)服務(wù)的安全性。
??? 對(duì)外訪(fǎng)問(wèn)控制由網(wǎng)絡(luò)層面轉(zhuǎn)換成了運(yùn)維層面，減少變更的流程和錯(cuò)誤成本
??? 減少客戶(hù)端與服務(wù)的耦合，服務(wù)可以獨(dú)立發(fā)展。通過(guò)網(wǎng)關(guān)層來(lái)做映射。
??? 通過(guò)網(wǎng)關(guān)層聚合，減少外部訪(fǎng)問(wèn)的頻次，提升訪(fǎng)問(wèn)效率。
??? 節(jié)約后端服務(wù)開(kāi)發(fā)成本，減少上線(xiàn)風(fēng)險(xiǎn)。
??? 為服務(wù)熔斷，灰度發(fā)布，線(xiàn)上測(cè)試提供簡(jiǎn)單方案。

微服務(wù)API網(wǎng)關(guān)框架

單節(jié)點(diǎn)場(chǎng)景

?

多節(jié)點(diǎn)場(chǎng)景

?

網(wǎng)關(guān)作用

統(tǒng)一入口

安全：黑名單、權(quán)限身份認(rèn)證

限流：實(shí)現(xiàn)微服務(wù)訪(fǎng)問(wèn)流量計(jì)算，基于流量計(jì)算分析進(jìn)行限流，可以定義多種限流規(guī)則。

緩存：數(shù)據(jù)緩存

日志：日志記錄

監(jiān)控：記錄請(qǐng)求響應(yīng)數(shù)據(jù)，api耗時(shí)分析，性能監(jiān)控

重試：異常重試

熔斷： 降級(jí)

?

現(xiàn)有框架

Tyk：Tyk是一個(gè)開(kāi)放源碼的API網(wǎng)關(guān)，它是快速、可擴(kuò)展和現(xiàn)代的。Tyk提供了一個(gè)API管理平臺(tái)，其中包括API網(wǎng)關(guān)、API分析、開(kāi)發(fā)人員門(mén)戶(hù)和API管理面板。Trk 是一個(gè)基于Go實(shí)現(xiàn)的網(wǎng)關(guān)服務(wù)。

Kong：Kong是一個(gè)可擴(kuò)展的開(kāi)放源碼API Layer(也稱(chēng)為API網(wǎng)關(guān)或API中間件)。Kong 在任何RESTful API的前面運(yùn)行，通過(guò)插件擴(kuò)展，它提供了超越核心平臺(tái)的額外功能和服務(wù)。

Orange：和Kong類(lèi)似也是基于OpenResty的一個(gè)API網(wǎng)關(guān)程序，是由國(guó)人開(kāi)發(fā)的。

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

apiaxle: Nodejs 實(shí)現(xiàn)的一個(gè) API 網(wǎng)關(guān)。

api-umbrella: Ruby 實(shí)現(xiàn)的一個(gè) API 網(wǎng)關(guān)。

?

網(wǎng)關(guān)技術(shù)選項(xiàng)

轉(zhuǎn)載于:https://www.cnblogs.com/reblue520/p/11428888.html

總結(jié)

以上是生活随笔為你收集整理的openresty开发系列1--网关API架构及选型的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。