本 Chat 主要內容如下：
網關是具體核心業務服務的看門神，相比具體實現業務的系統服務來說它是壹個邊緣服務，主要提供動態路由，監控，彈性，安全性等功能，下面我們從單體應用到多體應用的演化過程來講解網關的演化歷程。
壹般業務系統發展歷程都是基本相似的，從單體應用到多應用，從本地調用到遠程調用。對應單體應用架構模式（如下圖1），由於只需壹個應用，所有業務模塊的功能都打包為了壹個 War 包進行部署，這樣可以減少機器資源和部署的繁瑣。
圖1 單體應用
在單體應用中，網關模塊是和應用部署到同壹個jvm進程裏面的，當外部移動設備或者web站點訪問單體應用的功能時候，請求是先被應用的網關模塊攔截的，網關模塊對請求進行鑒權、限流等動作後在把具體的請求轉發到當前應用對應的模塊進行處理。
隨著業務的發展，網站的流量會越來越大，在單體應用中簡單的通過加機器的方式可以帶來的承受流量沖擊的能力也越來越低，這時候就會考慮根據業務將單體應用拆成若幹個功能獨立的應用，單體應用拆為多個應用後，由於不同的應用開發對應的功能，所以多應用開發之間可以獨立開發而不用去理解對方的業務，另外不同的應用模塊只承受對應業務流量的壓力，不會對其他應用模塊造成影響，這時候多體的分布式系統就出現了，如下圖2。
圖2 多體應用
如上圖在多體應用中業務模塊A和B單獨起了個應用，每個應用裏面有自己的網關模塊，如果業務模塊多了，那麽每個應用都有自己的網關模塊，這樣復用性不好，所以可以考慮把網關模塊提起出來，單獨作為壹個應用來做服務路由，如下圖3：
如上圖當移動設備發起請求時候是具體發送到網關應用的，經過鑒權後請求會被轉發到具體的後端服務應用上，對應前端移動設備來說他們不在乎也不知道後端服務器應用是壹個還是多個，他們只能感知到網關應用的存在。
Zuul是Netflix開源的壹個網關組件，在Netflix內部系統中Zuul被用來作為內部系統的門面，如下圖是Zuul在Netflix內部使用的壹個架構圖：
如上圖最上層的移動設備或者網站首先通過aws負載均衡器把請求路由到zuul網關上，zuul網關則負責把請求路由到具體的後端service上。
Zuul開源地址 /Netflix/zuul
Zuul網關的核心是壹系列的過濾器，這些過濾器可以對請求或者響應結果做壹系列過濾，Zuul 提供了壹個框架可以支持動態加載，編譯，運行這些過濾器，這些過濾器是使用責任鏈方式順序對請求或者響應結果進行處理的，這些過濾器直接不會直接進行通信，但是通過責任鏈傳遞的RequestContext參數可以***享壹些東西。
雖然Zuul 支持任何可以在jvm上跑的語言，但是目前zuul的過濾器只能使用Groovy腳本來編寫。編寫好的過濾器腳本壹般放在zuul服務器的固定目錄，zuul服務器會開啟壹個線程定時去輪詢被修改或者新增的過濾器，然後動態進行編譯，加載到內存，然後等後續有請求進來，新增或者修改後的過濾器就會生效了。
在zuul中過濾器分為四種：
如下圖為zuul1.0的工作原理：
如上圖，當zuul接受到請求後，首先會由前置過濾器進行處理，然後在由路由過濾器具體把請求轉發到後端應用，然後在執行後置過濾器把執行結果寫會到請求方，當上面任何壹個類型過濾器執行出錯時候執行該過濾器。
本節作者使用zuul的版本：
...
....
總結：zuul1.0時候當zuul接受到壹個請求後會同步執行前置過濾器、路由過濾器、後置過濾器，等執行完畢後在同步把結果返回為調用方，調用方在整個過程中是阻塞的。其實SpringBoot集成的zuul就是自己實現了個前置過濾器做選擇路由，然後自己實現了個路由過濾器根據前置過濾器選擇的路由具體做路由轉發。
Netty作為高性能異步網絡通訊框架，在dubbo，rocketmq,sofa等知名開源框架中都有使用，如下圖zuul2.0使用netty server作為網關監聽服務器監聽客戶端發來的請求，然後把請求轉發到前置過濾器（inbound filters）進行處理，處理完畢後在把請求使用netty client代理到具體的後端服務器進行處理，處理完畢後在把結果交給後者過濾器（outbound filters）進行處理，然後把處理結果通過nettyServer寫回客戶端。
...
總: 在zuul1.0時候客戶端發起的請求後需要同步等待zuul網關返回，zuul網關這邊對每個請求會分派壹個線程來進行處理，這會導致並發請求數量有限。而zuul2.0使用netty作為異步通訊，可以大大加大並發請求量。