1. 程式人生 > >為什麼微服務一定要有閘道器?

為什麼微服務一定要有閘道器?

作者:趙計剛

來自:cnblogs.com/java-zhao/p/6716059.html

一、什麼是服務閘道器

服務閘道器 = 路由轉發 + 過濾器

1、路由轉發:接收一切外界請求,轉發到後端的微服務上去;

2、過濾器:在服務閘道器中可以完成一系列的橫切功能,例如許可權校驗、限流以及監控等,這些都可以通過過濾器完成(其實路由轉發也是通過過濾器實現的)。

二、為什麼需要服務閘道器


上述所說的橫切功能(以許可權校驗為例)可以寫在三個位置:

  1. 每個服務自己實現一遍

  2. 寫到一個公共的服務中,然後其他所有服務都依賴這個服務

  3. 寫到服務閘道器的前置過濾器中,所有請求過來進行許可權校驗

第一種,缺點太明顯,基本不用;


第二種,相較於第一點好很多,程式碼開發不會冗餘,但是有兩個缺點:

由於每個服務引入了這個公共服務,那麼相當於在每個服務中都引入了相同的許可權校驗的程式碼,使得每個服務的jar包大小無故增加了一些,尤其是對於使用docker映象進行部署的場景,jar越小越好;

由於每個服務都引入了這個公共服務,那麼我們後續升級這個服務可能就比較困難,而且公共服務的功能越多,升級就越難,而且假設我們改變了公共服務中的許可權校驗的方式,想讓所有的服務都去使用新的許可權校驗方式,我們就需要將之前所有的服務都重新引包,編譯部署。

而服務閘道器恰好可以解決這樣的問題:

將許可權校驗的邏輯寫在閘道器的過濾器中,後端服務不需要關注許可權校驗的程式碼,所以服務的jar包中也不會引入許可權校驗的邏輯,不會增加jar包大小;

如果想修改許可權校驗的邏輯,只需要修改閘道器中的許可權校驗過濾器即可,而不需要升級所有已存在的微服務。

所以,需要服務閘道器!!!

三、服務閘道器技術選型

引入服務閘道器後的微服務架構如上,總體包含三部分:服務閘道器、open-service和service。

1、總體流程:

服務閘道器、open-service和service啟動時註冊到註冊中心上去;

使用者請求時直接請求閘道器,閘道器做智慧路由轉發(包括服務發現,負載均衡)到open-service,這其中包含許可權校驗、監控、限流等操作open-service聚合內部service響應,返回給閘道器,閘道器再返回給使用者

2、引入閘道器的注意點

增加了閘道器,多了一層轉發(原本使用者請求直接訪問open-service即可),效能會下降一些(但是下降不大,通常,閘道器機器效能會很好,而且閘道器與open-service的訪問通常是內網訪問,速度很快);

閘道器的單點問題:在整個網路呼叫過程中,一定會有一個單點,可能是閘道器、nginx、dns伺服器等。防止閘道器單點,可以在閘道器層前邊再掛一臺nginx,nginx的效能極高,基本不會掛,這樣之後,閘道器服務就可以不斷的新增機器。但是這樣一個請求就轉發了兩次,所以最好的方式是閘道器單點服務部署在一臺牛逼的機器上(通過壓測來估算機器的配置),而且nginx與zuul的效能比較,根據國外的一個哥們兒做的實驗來看,其實相差不大,zuul是netflix開源的一個用來做閘道器的開源框架;

閘道器要儘量輕。

3、服務閘道器基本功能

智慧路由:接收外部一切請求,並轉發到後端的對外服務open-service上去;

注意:我們只轉發外部請求,服務之間的請求不走閘道器,這就表示全鏈路追蹤、內部服務API監控、內部服務之間呼叫的容錯、智慧路由不能在閘道器完成;當然,也可以將所有的服務呼叫都走閘道器,那麼幾乎所有的功能都可以整合到閘道器中,但是這樣的話,閘道器的壓力會很大,不堪重負。

許可權校驗:只校驗使用者向open-service服務的請求,不校驗服務內部的請求。服務內部的請求有必要校驗嗎?

API監控:只監控經過閘道器的請求,以及閘道器本身的一些效能指標(例如,gc等);

限流:與監控配合,進行限流操作;

API日誌統一收集:類似於一個aspect切面,記錄介面的進入和出去時的相關日誌。

上述功能是閘道器的基本功能,閘道器還可以實現以下功能:

A|B測試:A|B測試時一塊比較大的東西,包含後臺實驗配置、資料埋點(看轉化率)以及分流引擎,在服務閘道器中,可以實現分流引擎,但是實際上分流引擎會呼叫內部服務,所以如果是按照上圖的架構,分流引擎最好做在open-service中,不要做在服務閘道器中。

4、技術選型

技術選型參考如下:

開發語言:java + groovy,groovy的好處是閘道器服務不需要重啟就可以動態的新增filter來實現一些功能;

微服務基礎框架:springboot;

閘道器基礎元件:netflix zuul;

服務註冊中心:consul;

許可權校驗:jwt;

API監控:prometheus + grafana;

API統一日誌收集:logback + ELK;

壓力測試:Jmeter;