Spring Cloud Most everyone is questioned Gateway performance from the outset, it is because Spring Cloud initially chose to use open source Zuul Netflix a few years ago as a basis for high-performance version of the Zuul 2 After a number of bounced checks, for Spring integration specialists such may be reluctant to continue to wait, Spring Cloud gateway came into being, then the launch of the Spring community to develop their own gateway then? A recent article entitled "Measured | micro transformation services, who are four major tools API gateway optimal performance? "The translation compared NGINX, ZUUL, Spring Cloud Gateway, Linkerd, concluded surprised so many readers, whether Spring Cloud Gateway really so bad? You may wish to learn more through below (reproduced below unsolicited "Spring Cloud Services and Docker micro-combat" author Zhou Bowen, the original address: http: //www.itmuch.com/spring-cloud-sum/performance-zuul- and-gateway-linkerd /).
motivation
Has more than once to see "Spring Cloud Gateway performance worse than Zuul" remarks, and many people others, to ask me, in that case, it has also developed the official Spring Spring Cloud Gateway doing? Is it just to support Zuul 1.x does not support the long connection, Web Socket it?
Therefore write a blog, to correct all erroneous views.
beginning
Online search a bit, say Spring Cloud Gateway performance worse than Zuul remarks from: http:? //Www.servicemesh.cn/ / article / 45
The authors used ab were benchmark, the operation is very standard. From the results, indeed Spring Cloud Gateway Zuul worse than a big slice.
But, let's open the official Issue: Throughput problems when compared with Netflix Zuul and Nginx, which officials replied:
reactor-netty has issues with http 1.0 and hence ab. reactor/reactor-netty#21
May wish to track the reactor / reactor-netty # 21, take a look at what to say:
As discussed recently about the issue raised on https://jira.spring.io/browse/SPR-14964, a very simple
ab-n1-c1http://localhost:8082/items/10on Spring + Reactor Netty based server block forever likely because Reactor Netty does not support HTTP 1.0.
Which said, Reactor Netty does not support HTTP 1.0, and Spring Cloud Gateway relied reactor-netty .
That is - due to the bug reactor-netty using ab pressure measurement results are not accurate!
Correct posture
The official recommended wrk conduct benchmark testing. Not only that, officials also ten (funeral) points (heart) stickers (disease) Heart (mad) created a benchmark project: spring-cloud-gateway-bench , which contrasted:
-
Spring Cloud Gateway
-
Zuul
-
gauche man
The performance of the three.
The idea is very simple: static project is a simple server written in Go; then were used Gateway / Zuul / Linkerd proxy endpoint to the service, and contrast.
Final Results:
| Package | RPS(request per second) |
|---|---|
| Spring Cloud Gateway | Requests/sec: 32213.38 |
| Zuul | Requests/sec: 20800.13 |
| gauche man | Requests/sec: 28050.76 |
From the results can be seen, Spring Cloud Gateway of RPS is 1.6 times Zuul1 of! Better than Linkerd performance!
Outlook
-
Zuul herein, refers to the Zuul 1.x, is a blocking io based on the API Gateway.
-
Spring Cloud Gateway is a promising project, started simple, function is also more powerful.
-
Linkerd is a very promising project, is based on the realization of Scala, currently available only production-level Service Mesh (such as other Istio, Conduit is still not used in the production).
-
Zuul has released Zuul 2.x, based Netty, is non-blocking, support long connection, but Spring Cloud No integration plan.