第一章微服務網(wǎng)關(guān)

甘甘灰 2018-08-03

展開全文

一、什么是服務網(wǎng)關(guān)

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

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

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

二、為什么需要服務網(wǎng)關(guān)
上述所說的橫切功能（以權(quán)限校驗為例）可以寫在三個位置：

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

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

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

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

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

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

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

1、總體流程：

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

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

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

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

智能路由：接收外部一切請求，并轉(zhuǎn)發(fā)到后端的對外服務open-service上去；
- 注意：我們只轉(zhuǎn)發(fā)外部請求，服務之間的請求不走網(wǎng)關(guān)，這就表示全鏈路追蹤、內(nèi)部服務API監(jiān)控、內(nèi)部服務之間調(diào)用的容錯、智能路由不能在網(wǎng)關(guān)完成；當然，也可以將所有的服務調(diào)用都走網(wǎng)關(guān)，那么幾乎所有的功能都可以集成到網(wǎng)關(guān)中，但是這樣的話，網(wǎng)關(guān)的壓力會很大，不堪重負。
權(quán)限校驗：只校驗用戶向open-service服務的請求，不校驗服務內(nèi)部的請求。服務內(nèi)部的請求有必要校驗嗎？
API監(jiān)控：只監(jiān)控經(jīng)過網(wǎng)關(guān)的請求，以及網(wǎng)關(guān)本身的一些性能指標（例如，gc等）；
限流：與監(jiān)控配合，進行限流操作；
API日志統(tǒng)一收集：類似于一個aspect切面，記錄接口的進入和出去時的相關(guān)日志
。。。后續(xù)補充

上述功能是網(wǎng)關(guān)的基本功能，網(wǎng)關(guān)還可以實現(xiàn)以下功能：

A|B測試：A|B測試時一塊比較大的東西，包含后臺實驗配置、數(shù)據(jù)埋點（看轉(zhuǎn)化率）以及分流引擎，在服務網(wǎng)關(guān)中，可以實現(xiàn)分流引擎，但是實際上分流引擎會調(diào)用內(nèi)部服務，所以如果是按照上圖的架構(gòu)，分流引擎最好做在open-service中，不要做在服務網(wǎng)關(guān)中。
。。。后續(xù)補充

4、技術(shù)選型

筆者準備自建一個輕量級的服務網(wǎng)關(guān)，技術(shù)選型如下：

開發(fā)語言：java + groovy，groovy的好處是網(wǎng)關(guān)服務不需要重啟就可以動態(tài)的添加filter來實現(xiàn)一些功能；
微服務基礎(chǔ)框架：springboot；
網(wǎng)關(guān)基礎(chǔ)組件：netflix zuul；
服務注冊中心：consul；
權(quán)限校驗：jwt；
API監(jiān)控：prometheus + grafana；
API統(tǒng)一日志收集：logback + ELK；
壓力測試：Jmeter；
。。。后續(xù)補充

在后續(xù)的介紹中，會逐漸介紹各個知識點，并完成一個輕量級的服務網(wǎng)關(guān)！?。?/p>