圖片

服務(wù)網(wǎng)關(guān)為客戶與服務(wù)系統(tǒng)之間的交互提供了統(tǒng)一的接口，也是管理請(qǐng)求和響應(yīng)的中心點(diǎn)，選擇一個(gè)適合的服務(wù)網(wǎng)關(guān)，可以有效地簡(jiǎn)化開(kāi)發(fā)并提高系統(tǒng)的運(yùn)維與管理效率。

服務(wù)網(wǎng)關(guān) = 路由轉(zhuǎn)發(fā) + 過(guò)濾器

1、路由轉(zhuǎn)發(fā)：接收一切外界請(qǐng)求，轉(zhuǎn)發(fā)到后端的微服務(wù)上去；

2、過(guò)濾器：在服務(wù)網(wǎng)關(guān)中可以完成一系列的橫切功能，例如權(quán)限校驗(yàn)、限流以及監(jiān)控等，這些都可以通過(guò)過(guò)濾器完成（其實(shí)路由轉(zhuǎn)發(fā)也是通過(guò)過(guò)濾器實(shí)現(xiàn)的）。

上述所說(shuō)的橫切功能（以權(quán)限校驗(yàn)為例）可以寫(xiě)在三個(gè)位置：

每個(gè)服務(wù)自己實(shí)現(xiàn)一遍

寫(xiě)到一個(gè)公共的服務(wù)中，然后其他所有服務(wù)都依賴這個(gè)服務(wù)

寫(xiě)到服務(wù)網(wǎng)關(guān)的前置過(guò)濾器中，所有請(qǐng)求過(guò)來(lái)進(jìn)行權(quán)限校驗(yàn)

第一種，缺點(diǎn)太明顯，基本不用；第二種，相較于第一點(diǎn)好很多，代碼開(kāi)發(fā)不會(huì)冗余，但是有兩個(gè)缺點(diǎn)：

• 由于每個(gè)服務(wù)引入了這個(gè)公共服務(wù)，那么相當(dāng)于在每個(gè)服務(wù)中都引入了相同的權(quán)限校驗(yàn)的代碼，使得每個(gè)服務(wù)的jar包大小無(wú)故增加了一些，尤其是對(duì)于使用docker鏡像進(jìn)行部署的場(chǎng)景，jar越小越好；
• 由于每個(gè)服務(wù)都引入了這個(gè)公共服務(wù)，那么我們后續(xù)升級(jí)這個(gè)服務(wù)可能就比較困難，而且公共服務(wù)的功能越多，升級(jí)就越難，而且假設(shè)我們改變了公共服務(wù)中的權(quán)限校驗(yàn)的方式，想讓所有的服務(wù)都去使用新的權(quán)限校驗(yàn)方式，我們就需要將之前所有的服務(wù)都重新引包，編譯部署。

而服務(wù)網(wǎng)關(guān)恰好可以解決這樣的問(wèn)題：

• 將權(quán)限校驗(yàn)的邏輯寫(xiě)在網(wǎng)關(guān)的過(guò)濾器中，后端服務(wù)不需要關(guān)注權(quán)限校驗(yàn)的代碼，所以服務(wù)的jar包中也不會(huì)引入權(quán)限校驗(yàn)的邏輯，不會(huì)增加jar包大??；
• 如果想修改權(quán)限校驗(yàn)的邏輯，只需要修改網(wǎng)關(guān)中的權(quán)限校驗(yàn)過(guò)濾器即可，而不需要升級(jí)所有已存在的微服務(wù)。

所以，需要服務(wù)網(wǎng)關(guān)！??！

三、服務(wù)網(wǎng)關(guān)技術(shù)選型

圖片

引入服務(wù)網(wǎng)關(guān)后的微服務(wù)架構(gòu)如上，總體包含三部分：服務(wù)網(wǎng)關(guān)、open-service和service。

1、總體流程

• 服務(wù)網(wǎng)關(guān)、open-service和service啟動(dòng)時(shí)注冊(cè)到注冊(cè)中心上去；
• 用戶請(qǐng)求時(shí)直接請(qǐng)求網(wǎng)關(guān)，網(wǎng)關(guān)做智能路由轉(zhuǎn)發(fā)（包括服務(wù)發(fā)現(xiàn)，負(fù)載均衡）到open-service，這其中包含權(quán)限校驗(yàn)、監(jiān)控、限流等操作
• open-service聚合內(nèi)部service響應(yīng)，返回給網(wǎng)關(guān)，網(wǎng)關(guān)再返回給用戶

2、引入網(wǎng)關(guān)的注意點(diǎn)

• 增加了網(wǎng)關(guān)，多了一層轉(zhuǎn)發(fā)（原本用戶請(qǐng)求直接訪問(wèn)open-service即可），性能會(huì)下降一些（但是下降不大，通常，網(wǎng)關(guān)機(jī)器性能會(huì)很好，而且網(wǎng)關(guān)與open-service的訪問(wèn)通常是內(nèi)網(wǎng)訪問(wèn)，速度很快）；
• 網(wǎng)關(guān)的單點(diǎn)問(wèn)題：在整個(gè)網(wǎng)絡(luò)調(diào)用過(guò)程中，一定會(huì)有一個(gè)單點(diǎn)，可能是網(wǎng)關(guān)、nginx、dns服務(wù)器等。防止網(wǎng)關(guān)單點(diǎn)，可以在網(wǎng)關(guān)層前邊再掛一臺(tái)nginx，nginx的性能極高，基本不會(huì)掛，這樣之后，網(wǎng)關(guān)服務(wù)就可以不斷的添加機(jī)器。但是這樣一個(gè)請(qǐng)求就轉(zhuǎn)發(fā)了兩次，所以最好的方式是網(wǎng)關(guān)單點(diǎn)服務(wù)部署在一臺(tái)牛逼的機(jī)器上（通過(guò)壓測(cè)來(lái)估算機(jī)器的配置），而且nginx與zuul的性能比較，根據(jù)國(guó)外的一個(gè)哥們兒做的實(shí)驗(yàn)來(lái)看，其實(shí)相差不大，zuul是netflix開(kāi)源的一個(gè)用來(lái)做網(wǎng)關(guān)的開(kāi)源框架；
• 網(wǎng)關(guān)要盡量輕。

3、網(wǎng)關(guān)基本功能

服務(wù)網(wǎng)關(guān)作為客戶端和服務(wù)端的中間橋梁，為微服務(wù)系統(tǒng)提供統(tǒng)一的管理機(jī)制：除了基礎(chǔ)的請(qǐng)求分發(fā)、API 管理和條件路由等功能，還包括身份驗(yàn)證、監(jiān)控報(bào)警、調(diào)用鏈追蹤、負(fù)載均衡、限流隔離和熔斷降級(jí)。 

• 身份認(rèn)證：下圖表示的是微服務(wù)聯(lián)合 服務(wù)網(wǎng)關(guān)如何進(jìn)行身份認(rèn)證的，由圖可見(jiàn)所有請(qǐng)求都通過(guò)網(wǎng)關(guān)，從而有效地隱藏了微服務(wù)。

圖片

• 監(jiān)控報(bào)警/調(diào)用鏈追蹤：API 作為客戶端和服務(wù)端的中間橋梁，是微服務(wù)監(jiān)控的最好載體，服務(wù)網(wǎng)關(guān)監(jiān)控功能的主要職責(zé)是及時(shí)發(fā)現(xiàn)網(wǎng)關(guān)以及后端服務(wù)器的連接異常，在 API 的監(jiān)控平臺(tái)上面用戶可以隨時(shí)查看日志信息，監(jiān)控信息，調(diào)用鏈等等，并且主機(jī)發(fā)生的任何異常都會(huì)自動(dòng)報(bào)警到控制臺(tái)。有些網(wǎng)關(guān)甚至可以做到給客戶端和服務(wù)端雙向報(bào)警。

圖片

• 限流隔離/熔斷降級(jí)：隨著互聯(lián)網(wǎng)業(yè)務(wù)規(guī)模的增加，系統(tǒng)的并發(fā)度增高，多個(gè)服務(wù)之間相互調(diào)用鏈路，一條核心鏈路往往可能調(diào)用十個(gè)服務(wù)。如果在鏈路中，某個(gè)服務(wù)的 rt（響應(yīng)時(shí)間）急劇上升，上游服務(wù)不斷請(qǐng)求，造成惡性循環(huán)，上游等待結(jié)果線程數(shù)越多，使得更上游服務(wù)阻塞最終整條鏈路無(wú)法使用，從而導(dǎo)致服務(wù)雪崩，所以對(duì)入口流量進(jìn)行整治管理是很有必要的。
  下圖表示微服務(wù)系統(tǒng)是如何結(jié)合 服務(wù)網(wǎng)關(guān)進(jìn)行限流隔離和熔斷降級(jí)的。

圖片

4、主流網(wǎng)關(guān)對(duì)比