Zuul1與Spring Cloud Gateway的區(qū)別及說明
Zuul1簡介
Zuul1是Netflix在2013年開源的網(wǎng)關(guān)組件,大規(guī)模的應(yīng)用在Netflix的生產(chǎn)環(huán)境中,經(jīng)受了實踐考驗。它可以與Eureka、Ribbon、Hystrix等組件配合使用,實現(xiàn)路由轉(zhuǎn)發(fā)、負(fù)載均衡、熔斷等功能。Zuul1的核心是一系列過濾器,過濾器簡單易于擴(kuò)展,已經(jīng)有一些三方庫如spring-cloud-zuul-ratelimit等提供了過濾器支持。
Zuul1基于Servlet構(gòu)建,使用的是阻塞的IO,引入了線程池來處理請求。每個請求都需要獨立的線程來處理,從線程池中取出一個工作線程執(zhí)行,下游微服務(wù)返回響應(yīng)之前這個工作線程一直是阻塞的。
Spring Cloud Gateway簡介
Spring Cloud Gateway 是Spring Cloud的一個全新的API網(wǎng)關(guān)項目,目的是為了替換掉Zuul1。Gateway可以與Spring Cloud Discovery Client(如Eureka)、Ribbon、Hystrix等組件配合使用,實現(xiàn)路由轉(zhuǎn)發(fā)、負(fù)載均衡、熔斷等功能,并且Gateway還內(nèi)置了限流過濾器,實現(xiàn)了限流的功能。
Gateway基于Spring 5、Spring boot 2和Reactor構(gòu)建,使用Netty作為運(yùn)行時環(huán)境,比較完美的支持異步非阻塞編程。Netty使用非阻塞的IO,線程處理模型建立在主從Reactors多線程模型上。其中Boss Group輪詢到新連接后與Client建立連接,生成NioSocketChannel,將channel綁定到Worker;Worker Group輪詢并處理Read、Write事件。
產(chǎn)品對比
下邊以表格形式對Zuul1和Gateway作簡單對比:
| 對比項 | Zuul1.x | Gateway |
|---|---|---|
| 實現(xiàn) | 基于Servlet2.x構(gòu)建,使用阻塞的API | 基于Spring 5、Project Reactor、Spring Boot 2,使用非阻塞式的API |
| 長連接 | 不支持 | 支持 |
| 不適用場景 | 后端服務(wù)響應(yīng)慢或者高并發(fā)場景下,因為線程數(shù)量是固定(有限)的,線程容易被耗盡,導(dǎo)致新請求被拒絕。 | 中小流量的項目,使用Zuul1.x更合適。 |
| 限流 | 無 | 內(nèi)置限流過濾器 |
| 上手難度 | 同步編程,上手簡單 | 門檻較高,上手難度中等 |
| Spring Cloud集成 | 是 | 是 |
| Sentinel集成 | 是 | 是 |
| 技術(shù)棧沉淀 | Zuul1開源近七年,經(jīng)受考驗,穩(wěn)定成熟。 | 未見實際落地案例 |
| Github used by | 1007 repositories | 102 repositories |
| Github issues | 88 Open / 2736 Closed | 135 Open / 850 Closed |
注:Github used by和Github issues統(tǒng)計時間截止2019/8/26。
性能對比
低并發(fā)場景
不同的tps,同樣的請求時間(50s),對兩種網(wǎng)關(guān)產(chǎn)品進(jìn)行壓力測試,結(jié)果如下:
| tps | 測試樣本Zuul1/Gateway,單位個 | 平均響應(yīng)時間Zuul1/Gateway, 單位毫秒 | 99%響應(yīng)時間小于Zuul1/Gateway,單位毫秒 | 錯誤比例Zuul1/Gateway |
|---|---|---|---|---|
| 20tps | 20977 / 20580 | 11 / 14 | 16 / 40 | 0% / 0% |
| 50tps | 42685 / 50586 | 18 / 12 | 66 / 22 | 0% / 0% |
并發(fā)較低的場景下,兩種網(wǎng)關(guān)的表現(xiàn)差不多
高并發(fā)場景
配置同樣的線程數(shù)(2000),同樣的請求時間(5分鐘),后端服務(wù)在不同的響應(yīng)時間(休眠時間),對兩種網(wǎng)關(guān)產(chǎn)品進(jìn)行壓力測試,結(jié)果如下:
| 休眠時間 | 測試樣本Zuul1/Gateway,單位個 | 平均響應(yīng)時間Zuul1/Gateway, 單位毫秒 | 99%響應(yīng)時間小于Zuul1/Gateway,單位毫秒 | 錯誤次數(shù)Zuul1/Gateway,單位個 | 錯誤比例Zuul1/Gateway |
|---|---|---|---|---|---|
| 休眠100ms | 294134 / 1059321 | 2026 / 546 | 6136 / 1774 | 104 / 0 | 0.04% / 0% |
| 休眠300ms | 101194 / 399909 | 5595 / 1489 | 15056 / 1690 | 1114 / 0 | 1.10% / 0% |
| 休眠600ms | 51732 / 201262 | 11768 / 2975 | 27217 / 3203 | 2476 / 0 | 4.79% / 0% |
| 休眠1000ms | 31896 / 120956 | 19359 / 4914 | 46259 / 5115 | 3598 / 0 | 11.28% / 0% |
Zuul網(wǎng)關(guān)的tomcat最大線程數(shù)為400,hystrix超時時間為100000。
Gateway在高并發(fā)和后端服務(wù)響應(yīng)慢的場景下比Zuul1的表現(xiàn)要好。
官方性能對比
Spring Cloud Gateway的開發(fā)者提供了benchmark項目用來對比Gateway和Zuul1的性能,官方提供的性能對比結(jié)果如下:
| 網(wǎng)關(guān) | Avg Req/sec/Thread | Avg Latency |
|---|---|---|
| Spring Cloud Gateway | 3.24k | 6.61ms |
| Zuul1 | 2.09k | 12.56ms |
| none | 11.77k | 2.09ms |
測試工具為wrk,測試時間30秒,線程數(shù)為10,連接數(shù)為200。
從官方的對比結(jié)果來看,Gateway的RPS是Zuul1的1.55倍,平均延遲是Zuul1的一半。
總結(jié)
Zuul1的開源時間很早,Netflix、Riot、攜程、拍拍貸等公司都已經(jīng)在生產(chǎn)環(huán)境中使用,自身經(jīng)受了實踐考驗,是生產(chǎn)級的API網(wǎng)關(guān)產(chǎn)品。
Gateway在2019年離開Spring Cloud孵化器,應(yīng)用于生產(chǎn)的案例少,穩(wěn)定性有待考證。
從性能方面比較,兩種產(chǎn)品在流量小的場景下性能表現(xiàn)差不多;并發(fā)高的場景下Gateway性能要好很多。從開發(fā)方面比較,Zuul1編程模型簡單,易于擴(kuò)展;Gateway編程模型稍難,代碼閱讀難度要比Zuul高不少,擴(kuò)展也稍復(fù)雜一些。
以上為個人經(jīng)驗,希望能給大家一個參考,也希望大家多多支持腳本之家。
相關(guān)文章
鴻蒙HarmonyOS App開發(fā)造輪子之自定義圓形圖片組件的實例代碼
這篇文章主要介紹了鴻蒙HarmonyOS App開發(fā)造輪子之自定義圓形圖片組件,本文給大家介紹的非常詳細(xì),對大家的學(xué)習(xí)或工作具有一定的參考借鑒價值,需要的朋友可以參考下2021-01-01
Java實現(xiàn)限定時間CountDownLatch并行場景
本文將結(jié)合實例代碼,介紹Java實現(xiàn)限定時間CountDownLatch并行場景,文中通過示例代碼介紹的非常詳細(xì),需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2021-07-07
springBoot+webMagic實現(xiàn)網(wǎng)站爬蟲的實例代碼
這篇文章主要介紹了springBoot+webMagic實現(xiàn)網(wǎng)站爬蟲的實例代碼,文中通過示例代碼介紹的非常詳細(xì),對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值,需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2020-05-05

