https://mp.weixin.qq.com/s?__biz=MjM5MDE0Mjc4MA==&mid=2651008077&idx=4&sn=c1fc508cb24e8f3585d2bf301df76253&chksm=bdbed41e8ac95d080b4db14b009aa3e48dc34469e6317c60c5731b089c766b4d151c8c93e2c4&scene=27#wechat_redirect

在今年 5 月中，Netflix 終于開源了它的支持異步調用模式的 Zuul 網關 2.0 版本，真可謂千呼萬喚始出來。從 Netflix 的官方博文 [附錄 1] 中，我們獲得的信息也比較令人振奮：

The Cloud Gateway team at Netflix runs and operates more than 80 clusters of Zuul 2, sending traffic to about 100 (and growing) backend service clusters which amounts to more than 1 million requests per second.

Netflix 部署了超過 80+ 的 Zuul2 云網關集群，流量經過 Zuul2 集群被路由到后端超過 100+ 的微服務，且每秒鐘經過 Zuul2 集群的請求超過 100 萬。

Zuul2 看起來很強大，支持異步高并發 (Zuul1 僅支持同步) 特性看起來很亮眼，那么我們是否就應該拋棄 Zuul1，開始擁抱 Zuul2 呢？作為架構師，我們不能盲目追時髦，技術的選擇必須基于實踐和理性的分析，基于我之前對 Zuul1 的一線落地實戰經驗，也基于我近期對 Zuul2 的一些調研，我會在本文中對 Zuul1 和 Zuul2 做一個比較客觀的編程模型和優劣分析，同時給出我的個人建議。

Zuul 1.0 編程模型和優劣

Zuul1 設計比較簡單，代碼不多也比較容易讀懂，它本質上就是一個同步 Servlet，采用多線程阻塞模型，如上圖所示 [圖片來自附錄 4]。

同步 Servlet 使用 thread per connection 方式處理請求。簡單講，每來一個請求，Servlet 容器要為該請求分配一個線程專門負責處理這個請求，直到響應返回客戶端這個線程才會被釋放返回容器線程池。如果后臺服務調用比較耗時，那么這個線程就會被阻塞，阻塞期間線程資源被占用，不能干其它事情。我們知道 Servlet 容器線程池的大小是有限制的，當前端請求量大，而后臺慢服務比較多時，很容易耗盡容器線程池內的線程，造成容器無法接受新的請求，Netflix 為此還專門研發了 Hystrix[附錄 2] 熔斷組件來解決慢服務耗盡資源問題。

注意在上圖 Netflix 給出的場景中，它的后臺服務調用也是啟動另外一個 IO 線程來處理的，但是本質上還是阻塞模式，后臺 IO 線程在處理的時候，前臺容器線程仍然是阻塞的。

同步阻塞模式有利有弊，分析如下圖：

?優勢

同步阻塞模式的編程模型比較簡單，整個請求 ->處理 ->響應的流程 (call flow) 都是在一個線程中處理的，這樣開發調試比較方便易于理解，比如出了問題跟蹤調試比較方便。另外，線程局部變量 (ThreadLocal) 機制在同步多線程模式下可以工作，有些監控產品，例如 CAT 調用鏈依賴于 ThreadLocal，在同步多線程模式下，CAT 埋點比較方便，調用鏈關系的展示也比較直觀。

?不足

我們知道線程本身需要消耗 CPU 和內存資源，且多線程之間切換是有開銷的 (所謂的上下文切換 Context Switch 開銷)，線程越多，這種上下文切換的開銷就越大，同步阻塞模式一般會啟動很多的線程，必然引入線程切換開銷。另外，同步阻塞模式下，容器線程池的數量一般是固定的，造成對連接數有一定限制，當后臺服務慢，容器線程池易被耗盡，一旦耗盡容器會拒絕新的請求，這個時候容器線程其實并不忙，只是被后臺服務調用 IO 阻塞，但是干不了其它事情。

總體上，同步阻塞模式比較適用于計算密集型 (CPU bound) 應用場景。對于 IO 密集型場景 (IO bound)，同步阻塞模式會白白消耗很多線程資源，它們都在等待 IO 的阻塞狀態，沒有做實質性工作。

我在極客時間「微服務架構和實踐 160 講」第三模塊「微服務網關 Zuul 架構和實踐」，對 Zuul 進行了十分詳細的講解，戳此了解詳情

Zuul 2.0 編程模型和優劣

Zuul2 的設計相對比較復雜，代碼也不太容易讀懂，它采用了 Netty 實現異步非阻塞編程模型，如上圖所示 [圖片來自附錄 4]。

一般異步模式的本質都是使用隊列 Queue(或稱總線 Bus)，在上圖中，你可以簡單理解為前端有一個隊列專門負責處理用戶請求，后端有個隊列專門負責處理后臺服務調用，中間有個事件環線程 (Event Loop Thread)，它同時監聽前后兩個隊列上的事件，有事件就觸發回調函數處理事件。這種模式下需要的線程比較少，基本上每個 CPU 核上只需要一個事件環處理線程，前端的連接數可以很多，連接來了只需要進隊列，不需要啟動線程，事件環線程由事件觸發，沒有多線程阻塞問題。

異步非阻塞模式也是有利有弊，分析如下圖：

?優勢

異步非阻塞模式啟動的線程很少，基本上一個 CPU core 上只需啟一個事件環處理線程，它使用的線程資源就很少，上下文切換 (Context Switch) 開銷也少。非阻塞模式可以接受的連接數大大增加，可以簡單理解為請求來了只需要進隊列，這個隊列的容量可以設得很大，只要不超時，隊列中的請求都會被依次處理。

?不足

異步模式讓編程模型變得復雜。一方面 Zuul2 本身的代碼要比 Zuul1 復雜很多，Zuul1 的代碼比較容易看懂，Zuul2 的代碼看起來就比較費勁。另一方面異步模型沒有一個明確清晰的請求 ->處理 ->響應執行流程 (call flow)，它的流程是通過事件觸發的，請求處理的流程隨時可能被切換斷開，內部實現要通過一些關聯 id 機制才能把整個執行流再串聯起來，這就給開發調試運維引入了很多復雜性，比如你在 IDE 里頭調試異步請求流就非常困難。另外 ThreadLocal 機制在這種異步模式下就不能簡單工作，因為只有一個事件環線程，不是每個請求一個線程，也就沒有線程局部的概念，所以對于 CAT 這種依賴于 ThreadLocal 才能工作的監控工具，調用鏈埋點就不好搞 (實際可以工作但需要進行特殊處理)。

總體上，異步非阻塞模式比較適用于 IO 密集型 (IO bound) 場景，這種場景下系統大部分時間在處理 IO，CPU 計算比較輕，少量事件環線程就能處理。

Zuul1 和 Zuul2 的性能比對

Netflix 本身對網關使用異步非阻塞模式這件事情是非常謹慎的，它們進行了嚴格的性能測試，下面是 Netflix 給出的一些性能數據，來自 Zuul2 網關核心研發成員 Arthur Gonigberg 的 ppt(Zuul's Journey to Non-Blocking)[附錄 3]：

Netflix 給出了一個比較模糊的數據，大致 Zuul2 的性能比 Zuul1 好 20% 左右，這里的性能主要指每節點每秒處理的請求數。為什么說模糊呢？因為這個數據受實際測試環境，流量場景模式等眾多因素影響，你很難復現這個測試數據。即便這個 20% 的性能提升是確實的，其實這個性能提升也并不大，和異步引入的復雜性相比，這 20% 的提升是否值得是個問題。Netflix 本身在其博文 [附錄 4] 和 ppt[附錄 3] 中也是有點含糊其詞，甚至自身都有一些疑問的。

While we did not see a significant efficiency benefit in migrating to async and non-blocking, we did achieve the goals of connection scaling.

比較明確的是，Zuul2 在連接數方面表現要好于 Zuul1，也就是說 Zuul2 能接受更多的連接數。

Zuul 2.0 架構和額外特性

上圖是 Zuul2 的架構，和 Zuul1 沒有本質區別，兩點變化：

前端用 Netty Server 代替 Servlet，目的是支持前端異步。后端用 Netty Client 代替 Http Client，目的是支持后端異步。

過濾器換了一下名字，用 Inbound Filters 代替 Pre-routing Filters，用 Endpoint Filter 代替 Routing Filter，用 Outbound Filters 代替 Post-routing Filters。

上圖是 Zuul2 的一些功能亮點，我個人認為除了對 HTTP/2 的支持算是一個亮點，其它都是在安全、彈性和運維層面的一些優化，不能算新功能。其中像 Request Passport，Status Categories，Request Attempts 這些所謂的新功能，其實是為了減輕異步帶來的復雜性，方便開發人員調試異步請求而專門開發的。

? 建議??

基于上述分析，我的建議是在生產環境中繼續使用 Zuul1，原因如下：

Zuul1 同步編程模型簡單，門檻低，開發運維方便，容易調試定位問題。Zuul2 門檻高，調試不方便。

Zuul1 監控埋點容易，比如和調用鏈監控工具 CAT 集成，如果你用 Zuul2 的話，CAT 不好埋點是個問題。

Zuul1 已經開源超過 6 年，穩定成熟，坑已經被踩平。Zuul2 剛開源很新，實際落地案例不多，難說有 bug 需要踩坑。

大部分公司達不到 Netflix 那個量級，Netflix 是要應對每日千億級流量，它們才挖空心思搞異步，一般公司億級可能都不到，Zuul1 綽綽有余。

Zuul1 可以集成 Hystrix 熔斷組件，可以部分解決后臺服務慢阻塞網關線程的問題。

Zuul1 可以使用 Servlet 3.0 規范支持的 AsyncServlet 進行優化，可以實現前端異步，支持更多的連接數，達到和 Zuul2 一樣的效果，但是不用引入太多異步復雜性。在《微服務架構實戰 160 講》視頻課程中，有我關于講解 Zuul1 如何使用 AsyncServlet 優化連接數的內容

對于 Zuul2，我的建議是持謹慎觀望的態度，可以在測試環境小規模實驗驗證，但是暫不上到生產環境。

? 結論??

同步異步各有利弊，同步多線程編程模型簡單，但會有線程開銷和阻塞問題，異步非阻塞模式線程少并發高，但是編程模型變得復雜。

架構師做技術選型需要嚴謹務實，具備批判性思維 (Critical Thinking)，即使是對于一線大公司推出的開源產品，也要批判性看待，不可盲目追新。

個人建議生產環境繼續使用 Zuul1，同步阻塞模式的一些不足，可以使用熔斷組件 Hystrix 和 AsyncServlet 等技術進行優化。

轉載于:https://www.cnblogs.com/davidwang456/articles/10338253.html

總結

以上是生活随笔為你收集整理的Zuul1.0和2.0我们该如何选择？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。