一、前言
Zuul 網關是具體核心業務服務的看門神，相比具體實現業務的系統服務來說它是一個邊緣服務，主要提供動態路由，監控，彈性，安全性等功能。在分佈式的微服務系統中，系統被拆爲了多套系統，通過zuul網關來對用戶的請求進行路由，轉發到具體的後臺服務系統中。
本 Chat 主要內容如下：
- 服務網關演化歷程。
- Zuul 1.0 服務架構與源碼剖析。
- Zuul 2.0 服務架構新特性。
二、服務網關演化歷程
網關是具體核心業務服務的看門神，相比具體實現業務的系統服務來說它是一個邊緣服務，主要提供動態路由，監控，彈性，安全性等功能，下面我們從單體應用到多體應用的演化過程來講解網關的演化歷程。
一般業務系統發展歷程都是基本相似的，從單體應用到多應用，從本地調用到遠程調用。對應單體應用架構模式（如下圖1），由於只需一個應用，所有業務模塊的功能都打包爲了一個 War 包進行部署，這樣可以減少機器資源和部署的繁瑣。
image.png
圖1 單體應用
在單體應用中，網關模塊是和應用部署到同一個jvm進程裏面的，當外部移動設備或者web站點訪問單體應用的功能時候，請求是先被應用的網關模塊攔截的，網關模塊對請求進行鑑權、限流等動作後在把具體的請求轉發到當前應用對應的模塊進行處理。
隨着業務的發展，網站的流量會越來越大，在單體應用中簡單的通過加機器的方式可以帶來的承受流量衝擊的能力也越來越低，這時候就會考慮根據業務將單體應用拆成若干個功能獨立的應用，單體應用拆爲多個應用後，由於不同的應用開發對應的功能，所以多應用開發之間可以獨立開發而不用去理解對方的業務，另外不同的應用模塊只承受對應業務流量的壓力，不會對其他應用模塊造成影響，這時候多體的分佈式系統就出現了，如下圖2。
image.png
圖2 多體應用
如上圖在多體應用中業務模塊A和B單獨起了個應用，每個應用裏面有自己的網關模塊，如果業務模塊多了，那麼每個應用都有自己的網關模塊，這樣複用性不好，所以可以考慮把網關模塊提起出來，單獨作爲一個應用來做服務路由，如下圖3：
image.png
如上圖當移動設備發起請求時候是具體發送到網關應用的，經過鑑權後請求會被轉發到具體的後端服務應用上，對應前端移動設備來說他們不在乎也不知道後端服務器應用是一個還是多個，他們只能感知到網關應用的存在。
Zuul是Netflix開源的一個網關組件，在Netflix內部系統中Zuul被用來作爲內部系統的門面，如下圖是Zuul在Netflix內部使用的一個架構圖：
image.png
如上圖最上層的移動設備或者網站首先通過aws負載均衡器把請求路由到zuul網關上，zuul網關則負責把請求路由到具體的後端service上。
Zuul開源地址 https://github.com/Netflix/zuul
三、Zuul 1.0 服務架構與源碼剖析
3.1 Zuul 1.0 服務架構概述
Zuul網關的核心是一系列的過濾器，這些過濾器可以對請求或者響應結果做一系列過濾，Zuul 提供了一個框架可以支持動態加載，編譯，運行這些過濾器，這些過濾器是使用責任鏈方式順序對請求或者響應結果進行處理的，這些過濾器直接不會直接進行通信，但是通過責任鏈傳遞的RequestContext參數可以共享一些東西。
雖然Zuul 支持任何可以在jvm上跑的語言，但是目前zuul的過濾器只能使用Groovy腳本來編寫。編寫好的過濾器腳本一般放在zuul服務器的固定目錄，zuul服務器會開啓一個線程定時去輪詢被修改或者新增的過濾器，然後動態進行編譯，加載到內存，然後等後續有請求進來，新增或者修改後的過濾器就會生效了。
在zuul中過濾器分爲四種：
-
PRE Filters(前置過濾器) ：當請求會路由轉發到具體後端服務器前執行的過濾器，比如鑑權過濾器，日誌過濾器，還有路由選擇過濾器
-
ROUTING Filters （路由過濾器）：該過濾器作用是把請求具體轉發到後端服務器上，一般是通過Apache HttpClient 或者 Netflix Ribbon把請求發送到具體的後端服務器上
-
POST Filters（後置過濾器）：當把請求路由到具體後端服務器後執行的過濾器；場景有添加標準http 響應頭，收集一些統計數據（比如請求耗時等），寫入請求結果到請求方等。
-
ERROR Filters（錯誤過濾器）：當上面任何一個類型過濾器執行出錯時候執行該過濾器
如下圖爲zuul1.0的工作原理：
image.png
如上圖，當zuul接受到請求後，首先會由前置過濾器進行處理，然後在由路由過濾器具體把請求轉發到後端應用，然後在執行後置過濾器把執行結果寫會到請求方，當上面任何一個類型過濾器執行出錯時候執行該過濾器。
3.2 Zuul 1.0 源碼分析
本節作者使用zuul的版本：
<dependency>
<groupId>com.netflix.zuul</groupId>
<artifactId>zuul-core</artifactId>
<version>1.0.28</version>
</dependency>
3.2.1 核心處理流程-ZuulServlet類
...
3.2.2 動態裝載過濾器-FilterFileManager類
....
總結：zuul1.0時候當zuul接受到一個請求後會同步執行前置過濾器、路由過濾器、後置過濾器，等執行完畢後在同步把結果返回爲調用方，調用方在整個過程中是阻塞的。其實SpringBoot集成的zuul就是自己實現了個前置過濾器做選擇路由，然後自己實現了個路由過濾器根據前置過濾器選擇的路由具體做路由轉發。
四、Zuul 2.0 服務架構新特性
4.1 新特性
Netty作爲高性能異步網絡通訊框架，在dubbo，rocketmq,sofa等知名開源框架中都有使用，如下圖zuul2.0使用netty server作爲網關監聽服務器監聽客戶端發來的請求，然後把請求轉發到前置過濾器（inbound filters）進行處理，處理完畢後在把請求使用netty client代理到具體的後端服務器進行處理，處理完畢後在把結果交給後者過濾器（outbound filters）進行處理，然後把處理結果通過nettyServer寫回客戶端。
image.png
...
總: 在zuul1.0時候客戶端發起的請求後需要同步等待zuul網關返回，zuul網關這邊對每個請求會分派一個線程來進行處理，這會導致併發請求數量有限。而zuul2.0使用netty作爲異步通訊，可以大大加大併發請求量。
五、最後
- 微服務核心組件 Zuul 網關原理剖析全集單擊我
- rocketmq環境搭建單擊我
- 想系統學dubbo的單擊我
- Java併發想學併發的童鞋可以 單擊我
- spring事務
本地事務諮詢可以單擊我
分佈式事務諮詢可以單擊我
Spring事務配置解惑單擊我
作者：阿里加多
鏈接：https://www.jianshu.com/p/d1e61f9fc13a
來源：簡書
著作權歸作者所有。商業轉載請聯繫作者獲得授權，非商業轉載請註明出處。