爲何微服務必定要有網關？

1、什麼是服務網關

服務網關 = 路由轉發 + 過濾器

一、路由轉發：接收一切外界請求，轉發到後端的微服務上去；

二、過濾器：在服務網關中能夠完成一系列的橫切功能，例如權限校驗、限流以及監控等，這些均可以經過過濾器完成（其實路由轉發也是經過過濾器實現的）。

2、爲何須要服務網關

上述所說的橫切功能（以權限校驗爲例）能夠寫在三個位置：

每一個服務本身實現一遍

寫到一個公共的服務中，而後其餘全部服務都依賴這個服務

寫到服務網關的前置過濾器中，全部請求過來進行權限校驗

第一種，缺點太明顯，基本不用；

第二種，相較於第一點好不少，代碼開發不會冗餘，可是有兩個缺點：

因爲每一個服務引入了這個公共服務，那麼至關於在每一個服務中都引入了相同的權限校驗的代碼，使得每一個服務的jar包大小無端增長了一些，尤爲是對於使用docker鏡像進行部署的場景，jar越小越好；

因爲每一個服務都引入了這個公共服務，那麼咱們後續升級這個服務可能就比較困難，並且公共服務的功能越多，升級就越難，並且假設咱們改變了公共服務中的權限校驗的方式，想讓全部的服務都去使用新的權限校驗方式，咱們就須要將以前全部的服務都從新引包，編譯部署。

而服務網關剛好能夠解決這樣的問題：

將權限校驗的邏輯寫在網關的過濾器中，後端服務不須要關注權限校驗的代碼，因此服務的jar包中也不會引入權限校驗的邏輯，不會增長jar包大小；

若是想修改權限校驗的邏輯，只須要修改網關中的權限校驗過濾器便可，而不須要升級全部已存在的微服務。

因此，須要服務網關！！！

3、服務網關技術選型

引入服務網關後的微服務架構如上，整體包含三部分：服務網關、open-service和service。

一、整體流程：

服務網關、open-service和service啓動時註冊到註冊中心上去；

用戶請求時直接請求網關，網關作智能路由轉發（包括服務發現，負載均衡）到open-service，這其中包含權限校驗、監控、限流等操做open-service聚合內部service響應，返回給網關，網關再返回給用戶

二、引入網關的注意點

增長了網關，多了一層轉發（本來用戶請求直接訪問open-service便可），性能會降低一些（可是降低不大，一般，網關機器性能會很好，並且網關與open-service的訪問一般是內網訪問，速度很快）；

網關的單點問題：在整個網絡調用過程當中，必定會有一個單點，多是網關、nginx、dns服務器等。防止網關單點，能夠在網關層前邊再掛一臺nginx，nginx的性能極高，基本不會掛，這樣以後，網關服務就能夠不斷的添加機器。可是這樣一個請求就轉發了兩次，因此最好的方式是網關單點服務部署在一臺牛逼的機器上（經過壓測來估算機器的配置），並且nginx與zuul的性能比較，根據國外的一個哥們兒作的實驗來看，其實相差不大，zuul是netflix開源的一個用來作網關的開源框架；

網關要儘可能輕。

三、服務網關基本功能

智能路由：接收外部一切請求，並轉發到後端的對外服務open-service上去；

注意：咱們只轉發外部請求，服務之間的請求不走網關，這就表示全鏈路追蹤、內部服務API監控、內部服務之間調用的容錯、智能路由不能在網關完成；固然，也能夠將全部的服務調用都走網關，那麼幾乎全部的功能均可以集成到網關中，可是這樣的話，網關的壓力會很大，不堪重負。

權限校驗：只校驗用戶向open-service服務的請求，不校驗服務內部的請求。服務內部的請求有必要校驗嗎？

API監控：只監控通過網關的請求，以及網關自己的一些性能指標（例如，gc等）；

限流：與監控配合，進行限流操做；

API日誌統一收集：相似於一個aspect切面，記錄接口的進入和出去時的相關日誌。

上述功能是網關的基本功能，網關還能夠實現如下功能：

A|B測試：A|B測試時一塊比較大的東西，包含後臺實驗配置、數據埋點（看轉化率）以及分流引擎，在服務網關中，能夠實現分流引擎，可是實際上分流引擎會調用內部服務，因此若是是按照上圖的架構，分流引擎最好作在open-service中，不要作在服務網關中。

四、技術選型

技術選型參考以下：

開發語言：java + groovy，groovy的好處是網關服務不須要重啓就能夠動態的添加filter來實現一些功能；

微服務基礎框架：springboot；

網關基礎組件：netflix zuul；

服務註冊中心：consul；

權限校驗：jwt；

API監控：prometheus + grafana；

API統一日誌收集：logback + ELK；

壓力測試：Jmeter；