【性能測試】三大網關:Spring Cloud Gateway, Zuul, Edge Service 性能對比

本文對幾種流行的
API
網關以關鍵指標
RPS
為依據,利用
wrk
做了性能測評并且給出結論。本文所有使用的軟件、命令、以及代碼均在文中注明,讀者可以很方便地在自己的環境中做出相同的測試。另外性能測試的數據在不同的運行環境中差別較大,但是總體上來說各項數據會成比例變化,本文的測試過程和結論可以較準確地反應出各
API
網關之間的性能差
異。

背景知識介紹

1

API網關

網上有很多關于
API
網關的博客說得很清楚,比如
 

使用 API Gateway

https://www.jianshu.com/p/52c2fd448f24)
 API
網關提供以下的一些功能

  • API
    最核心的用途是提供系統的唯一入口,類似于設計模式中的

    門面模式

    ,可以在網關層處理所有的非業務功

  • 封裝系統內部架構,為每個客戶端提供定制
    API

  • 還可以提供一些別的功能,如身份驗證、監控、負載均衡緩存、請求分片與管理、靜態響應處理等

Netflix Zuul

【性能測試】三大網關:Spring Cloud Gateway, Zuul, Edge Service 性能對比

相比較 Spring Cloud Gateway、ServiceComb EdgeService 而言,早在
2013
年之前 Zuul 就已經存在Github項目,在
2013
年進入大眾市場并廣受歡迎。先發劣勢導致當年的
Zuul
還是基于阻塞
io
開發的,在今天看來,性能實在是一般,但是先發優勢又讓
Zuul
在網關界一直有一席之地

2016
年前后基于
NIO

Zuul2
開始開發,一直到
2018
年才發布,彼時,市場上類似產品層出不窮,
Zuul
已經失去了它的先發優勢,
Spring Cloud
甚至到現在都沒有對
Zuul2
提供支持,
Spring Cloud Gateway
等產品的出現和
Zuul2
的頻繁跳票,便秘式發布也讓
Zuul
走下神壇,逐漸淪落為性能一般,需要被替換的代名詞

Spring Cloud Gateway

【性能測試】三大網關:Spring Cloud Gateway, Zuul, Edge Service 性能對比

Gateway
建立在
Spring Framework 5

Project Reactor

Spring Boot 2
上,使用非阻塞
API
。由于它與 
Spring 
緊密集成,對于開發者而言,成為了一個整合方便、使用方便、高性能的產品

其實
Spring Cloud
最開始是整合
Zuul
作為網關解決方案的,但是隨著時間的推移,
AIO
的局限性不斷暴露,據傳
Spring
在等待高性能
Zuul
的過程中逐漸失去了耐心,直接導致
Spring Cloud
自己開發了
Spring Cloud Gateway
網關。而這一產品也確實經受住了時間的考驗,成為了業界最佳的網關選擇之一。回首往事看
Spring
等待
Zuul2
的過程,可以說是塞翁失馬,焉知禍福了

ServiceComb EdgeService

【性能測試】三大網關:Spring Cloud Gateway, Zuul, Edge Service 性能對比

相比以上的兩個網關,
EdgeService
知名度顯得小很多。但其實
EdgeService
來自于開源項目
apache/servicecomb-java-chassis

ServiceComb 是

2017

11
月由華為公司
捐獻給
Apache
并啟動孵化,并于2018 年
10

24
日被
Apache
宣布畢業成為
Apache
頂級項目,這也是業界首個在
 Apache
孵化并畢業成為微服務頂級項目

由于自帶微服務場景的基因,所以
EdgeService
天生適用于微服務場景,這一點在后文的配置部分可以很明顯地感受的到

性能測試

1

環境準備

  • 硬件環境:三臺機器,分別運行服務端程序,網關程序和壓測程

    • CPU: 4vCPU Intel(R) Xeon(R) CPU E5-2680 v4 @ 2.40GHz

    • 內存:
      8GB

  • 軟件環境:

    • wrk

2

工程文件

本文涉及到的所有代碼可從
 

https://github.com/AngLi2/api-gateway-benchmark

 
獲得(歡迎各位同好
 star
關注我啊):
 

【性能測試】三大網關:Spring Cloud Gateway, Zuul, Edge Service 性能對比


其中

  • origin
    :為本次性能測試的被調用服務文件,測試中在

      192.168.0.5:8080
     

    端口

  • zuul

    zuul
    網關程序,將請求分發到
    origin
    ,測試中在

      192.168.0.152:8081
     

    端口啟

    • 使用的
      spring-cloud-starter-zuul
      版本為
      1.4.7.RELEASE
      ,對應的
      Zuul
      版本為
      1.3.1

  • gateway:

    gateway
    網關程序,將請求分發到
    origin
    ,測試中在

      192.168.0.152:8082
     

    端口啟

    • 使用的
      spring-cloud-starter-gateway
      版本為
      2.1.2.RELEASE

  • edgeservice:

    edgeservice
    網關程序,將請求分發到
    origin
    ,測試中在

      192.168.0.152:8083
     

    端口啟

    • 使用的
      org.apache.servicecomb:edge-core
      版本為
      1.2.0.B006

3

關鍵配置

這里展示了多種不同的配置方法,所起到的作用都是一樣的,不影響網關的使用和性
能。

Netflix Zuul

通過
application.properties
進行配置

zuul.routes.demo.path=/*

zuul.routes.demo.url=http://192.168.0.5:8080

Spring Cloud Gateway

通過
Bean
注入的方式進行配置

@Bean

public RouteLocator customRouteLocator(RouteLocatorBuilder builder) {

return builder.routes()

.route(r -> r.path("/checked-out")

.uri("http://192.168.0.5:8080/checked-out")

).build();

}

ServiceComb EdgeService

由于
EdgeService
主要是針對微服務,需要先注冊
REST
服務的
endpoint
、接口契約等信息,所以這里的配置稍顯復雜,如果直接使用微服務和服務中心,會方便很多

1.

 

根據
REST
接口編寫
Java
接口

@Path("/checked-out")

@Api(produces = MediaType.TEXT_PLAIN)

public interface Service {

@GET

String getCheckedOut();

}


2. 

根據
endpoint
調用方法并且注冊

String endpoints="rest://192.168.0.5:8080"; RegistryUtils.getServiceRegistry().registerMicroserviceMappingByEndpoints(

"thirdPartyService",

"0.0.1",

Collections.singletonList(endpoints),

Service.class

);

3. 網關配置文件
(
這里的
loadbalance
只是為了
edgeservice
調用,實際只有一個被調用實例
)
,這里有一個
maxPoolSize
設置成了
20
,這個過程是這樣的

開始沒有進行
maxPoolSize
的設置,結果發現用
 
netstat -apn | grep 192.168.0.5 | grep ESTA | wc -l
 
來看連接數發現只建立了
20
條連接,參考
 

ServiceComb 文檔

(https://docs.servicecomb.io/java-chassis/zh_CN/transports/rest-over-vertx.html)
,可以看出鏈接數為
verticle-count * maxPoolSize
,而
maxPoolSize
的默認值只有
5
,而
verticle-count
的默認值為

  • 如果
    CPU
    數小于
    8
    ,則取
    CPU

  • 如果
    CPU
    數大于等于
    8
    ,則為
    8

因為測試環境
CPU
讀數為
4
,所以總鏈接數只有
4 * 5 = 20
,而
Spring Cloud Gateway
的總鏈接數測試的時候一直在
90
多,所以這里將
maxPoolSize
設置成
20

事實上,即使在
 EdgeService 
的鏈接數為
 20 
的情況下,測試時也比
 Spring Cloud Gateway 
鏈接數
 90 
的表現要好一點,讀者們可以自己嘗試一下

servicecomb:


rest:

address: 127.0.0.1:8083

client:

connection:

maxPoolSize: 20

http:

dispatcher:

edge:

default:

withVersion: false

enabled: true

prefix: rest

prefixSegmentCount: 2

4

測試過程

原先使用大名鼎鼎的
Apache Benchmark
進行壓力測試,結果得出的結論和預期的大相徑庭,基于
rxNetty

Spring Cloud Gateway
居然比
Zuul
表現還差一大截!而且在進行長連接測試時
 Spring Cloud Gateway
直接卡死

其實這個問題在
Github

spring-cloud-gateway

Issues
區早有提及:
 Throughput problems when compared with Netflix Zuul and Nginx
(https://github.com/spring-cloud/spring-cloud-gateway/issues/124)

Issue
被提出是因為有人提出用
Apache Benchmark

Spring Cloud Gateway、Netflix Zuul

Nginx
進行壓測,發現結果如下

【性能測試】三大網關:Spring Cloud Gateway, Zuul, Edge Service 性能對比

通過
Issue
的回復區的

Add support for HTTP 1.0
(https://github.com/reactor/reactor-netty/issues/21)
 
關聯問題,我們可以找到很多關于
rxNetty
不支持
HTTP1.0

Issues
,這里列出來幾個,有興趣的讀者可以點進去看看

  • Add HTTP 1.0 support
    (https://github.com/ReactiveX/RxNetty/issues/575)

  • Buffering of output in Spring Web Reactive with Netty too aggressive
    (https://github.com/spring-projects/spring-framework/issues/19510)

  • Add HTTP 1.0 support on Reactor Netty


    Add HTTP 1.0 support on Reactor Netty

既然得出
Apache Benchmark
并不能很好地測試出網關的性能,轉而使用
wrk
進行測試(
Spring Cloud Gateway
官方使用的性能測試工具也是這個,后面會有提及)。
wrk
默認工作于長連接模式,有效地減少了斷連建連的損耗,可以比較真實地反映出網關的性能

對原始服務進行測試


1.   

運行命令

 wrk -t12 -c100 -d300s http://192.168.0.5:8080/checked-out


2.   

得到結果如下

Running 5m test @ http://192.168.0.5:8080/checked-out

12 threads and 100 connections

Thread Stats Avg Stdev Max +/- Stdev

Latency 2.94ms 1.18ms 56.41ms 81.59%

Req/Sec 2.76k 228.24 3.76k 72.32%

9906220 requests in 5.00m, 1.25GB read

Requests/sec: 33014.70

Transfer/sec: 4.26MB


3.  

根據測試結果,可以得到延時服務的
RPS
和平均延時為

  • RPS

    33014.70
    請求
    /

  • Average Latency: 2.94ms

Netflix Zuul


1.   

運行命令

 wrk -t12 -c100 -d300s http://192.168.0.5:8081/checked-out


2.    

得到結果如下

Running 5m test @ http://192.168.0.152:8081/checked-out

12 threads and 100 connections

Thread Stats Avg Stdev Max +/- Stdev

Latency 12.39ms 21.27ms 1.15s 91.90%

Req/Sec 1.10k 264.62 2.09k 72.43%

3953807 requests in 5.00m, 735.99MB read

Requests/sec: 13175.21

Transfer/sec: 2.45MB


3.   

根據測試結果,可以得到
Netflix Zuul

RPS
和平均延時為

  • RPS

    13175.21
    請求
    /

  • Average Latency: 12.39ms


4.   

在性能測試的過程中使用
top
看一下
CPU
使用情況,發現基本上拉滿:
 

Spring Cloud Gateway


1.   

運行命令

wrk -t12 -c100 -d300s http://192.168.0.152:8082/checked-out


2.    

得到結果如下

Running 5m test @ http://192.168.0.152:8082/checked-out

12 threads and 100 connections

Thread Stats Avg Stdev Max +/- Stdev

Latency 4.95ms 9.96ms 539.29ms 98.96%

Req/Sec 1.82k 222.74 2.39k 91.81%

6507221 requests in 5.00m, 850.19MB read

Requests/sec: 21685.14

Transfer/sec: 2.83MB


3.   

根據測試結果,可以得到
Spring Cloud Gateway

RPS
和平均延時為

  • RPS

    21685.14
    請求
    /

  • Average Latency:4.95ms


4.   

在性能測試的過程中使用
top
看一下
CPU
使用情況,發現基本上拉滿:
 

ServiceComb EdgeService


1.   

運行命令

wrk -t12 -c100 -d300s http://192.168.0.152:8083/rest/thirdPartyService/checked-out


2.   

得到結果如下

Running 5m test @ http://192.168.0.152:8083/rest/thirdPartyService/checked-out

12 threads and 100 connections

Thread Stats Avg Stdev Max +/- Stdev

Latency 3.80ms 4.67ms 300.59ms 97.98%

Req/Sec 2.27k 309.82 3.10k 86.53%

8144028 requests in 5.00m, 1.03GB read

Requests/sec: 27139.19

Transfer/sec: 3.52MB


3.   

提取
RPS
數據,可以得到
EdgeService
的測試
RPS
為:
27139.19



/


4.   

在性能測試的過程中使用
top
看一下
CPU
使用情況,發現基本上拉滿:
 

5

測試結果

對測試的數據進行表格分析對比后,分別給出平均時延、
RPS
和性能損失((原服務的
RPS -
網關的
RPS

/
原服務的
RPS
),表格如下圖所示

【性能測試】三大網關:Spring Cloud Gateway, Zuul, Edge Service 性能對比

從上圖可以看出,在硬件環境完全相同,并且
cpu
消耗基本一致的情況下,以
RPS
為性能指標(以性能損失為性能指標的話,差異更大,這里參考業界做法,以
RPS
為指標),
ServiceComb EdgeService
的性能是
Netflix Zuul
的兩倍多,是
Spring Cloud Gateway

1.25
倍多!這還是在
EdgeService
的鏈接數劣于
Spring Cloud Gateway 20%
左右的情況下的數據,如果將
EdgeService
的鏈接數設置和
Spring Cloud Gateway
一致,性能會相差更大,有興趣的讀者可以自己嘗試一下

Spring Cloud Gateway
的性能比
Zuul
好基本上已經是業界公認的了,實際上,
Spring Cloud Gateway
官方也發布過一個性能測試:
spring-cloud-gateway-bench
(https://github.com/spencergibb/spring-cloud-gateway-bench)
,這里節選數據如下

【性能測試】三大網關:Spring Cloud Gateway, Zuul, Edge Service 性能對比

因為我們的測試機器部署在同一個局域網,所以性能損失均要低于
spring-cloud-gateway-bench
的測試數據,但是從測試結果看來基本一致。網關的性能和其實現方式也有很大的關系

  • Netflix Zuul:
    測試版本為
    1.x
    ,基于阻塞
    io

  • Spring Cloud Gateway:
    前面已經提到過,基于
    RxNetty
    ,異步非阻

  • ServiceComb EdgeService
    :為
    ServiceComb
    的子項目,基于
    vert.x
    ,也是異步非阻

同樣基于異步非阻塞,
EdgeService
的性能明顯優于
Spring Cloud Gateway
,可以看出網關的性能不僅和底層實現有關,和內部實現方式和優化也有很大的關系。其實看
ServiceComb

官方文檔
(https://docs.servicecomb.io/java-chassis/zh_CN)
,可以發現
EdgeService
還支持接入
rest
自動變成
highway
轉調,性能更高。這里因為協議層面不一樣,就不放出來做對比了,對性能有極致要求的可以采用這種模式


2018
年終于難產似的發布了
Zuul 2.x
之后,
Netflix
給出了一個比較模糊的數據,大致
Zuul2
的性能比
Zuul1

20%
左右。然而從測試數據看來就算提升一半也完全打不過
Spring Cloud Gateway
,更不用說
EdgeService
了。看來
Zuul 2.x
并沒有把異步非阻塞的性能發揮出來

競爭是發展的催化劑。在這個網關服務層出不窮的年代,各公司都鉚足力氣打造自己的網關產品,盡量讓自己的產品成為用戶的第一選擇。而廣大開發者也在享受這樣的紅利,使用高性能的網關來開發自己的應用。作為廣大開發者的一員,我們欣然接受這樣良性競爭的出現,并且也樂于嘗試市面上出現的任何新產品,誰也說不準某一個產品以后就會成為優選的代名詞。雖然從現在網關的性能差距看來,后發優勢明顯,但在可預見的將來,各網關遲早會到達性能瓶頸,在性能差距不大并且產品穩定之后,就會有各種差異化特性出現。而等到網關產品進入百舸爭流的時代之后,用戶就可以不再根據性能,而是根據自己的需求選擇適合的網關服務了

參考資料

  • https://github.com/spring-cloud/spring-cloud-gateway/issues

  • https://github.com/reactor/reactor-netty/issues

  • https://github.com/ReactiveX/RxNetty/issues

  • https://github.com/spring-projects/spring-framework/issues

  • https://github.com/spencergibb/spring-cloud-gateway-bench

  • https://docs.servicecomb.io/java-chassis/zh_CN

  • http://www.itmuch.com/spring-cloud-sum/performance-zuul-and-gateway-linkerd/

  • https://blog.csdn.net/j3T9Z7H/article/details/81025180

  • https://www.zhihu.com/question/67498050

  • https://www.jianshu.com/p/52c2fd448f24

  • https://www.w3xue.com/exp/article/20197/48191.html

1

END

【性能測試】三大網關:Spring Cloud Gateway, Zuul, Edge Service 性能對比


●  可能是國內第一篇全面解讀Java現狀及趨勢的文章


●  持續交付的架構成熟度模型


●  Apache ServiceComb Meetup -Shanghai 2019 (PPT Download)

【性能測試】三大網關:Spring Cloud Gateway, Zuul, Edge Service 性能對比

長按二維碼加小助手

有趣的靈魂在等你

用心做開源,不忘初心

點個 在看

少個bug

【性能測試】三大網關:Spring Cloud Gateway, Zuul, Edge Service 性能對比

【性能測試】三大網關:Spring Cloud Gateway, Zuul, Edge Service 性能對比

點擊下方“閱讀原文”查看更多精彩內容?

手机彩票计划软件超稳

原文 

http://mp.weixin.qq.com/s?__biz=MzUxNTEwNTg5Mg==&mid=2247488337&idx=1&sn=7e64722dbc00ec1e72c91ad111b5399b

本站部分文章源于互聯網,本著傳播知識、有益學習和研究的目的進行的轉載,為網友免費提供。如有著作權人或出版方提出異議,本站將立即刪除。如果您對文章轉載有任何疑問請告之我們,以便我們及時糾正。

PS:推薦一個微信公眾號: askHarries 或者qq群:474807195,里面會分享一些資深架構師錄制的視頻錄像:有Spring,MyBatis,Netty源碼分析,高并發、高性能、分布式、微服務架構的原理,JVM性能優化這些成為架構師必備的知識體系。還能領取免費的學習資源,目前受益良多

轉載請注明原文出處:Harries Blog? » 【性能測試】三大網關:Spring Cloud Gateway, Zuul, Edge Service 性能對比

贊 (0)
分享到:更多 ()

評論 1

  • 昵稱 (必填)
  • 郵箱 (必填)
  • 網址
  1. starjack io感謝您分享的信息回復