A, API Gateway
Under the micro-service shelf, easy to form a network of relationships between service calls, network call this inconvenience relationship management and maintenance, API gateway is required under this scenario. As the entrance back-end services, API gateway is particularly important in the micro-service architecture, in the external system provides API entry requirements, API Gateway should have the routing forwarding, load balancing, current-limiting fuse, access control, trajectory tracking and real-time monitoring and other functions.
Currently, Spring Cloud lot of micro ecological services are based constructs. Spring Cloud Eco provides us with two API gateway products, which are open source Netflix Zuul1 and Spring to develop their own Spring Cloud Gateway (below referred to as the Gateway). Spring Cloud version is the dividing line to Finchley, Finchley before release Zuul1 use as an API gateway, after more recommended Gateway.
Although Netflix has been open sourced Zuul2 in May 2018, but has launched a Spring Cloud Gateway, and that there is no integrated plan Zuul2 on github. So from Spring Cloud development trend, Gateway instead of Zuul is inevitable.
About 1.1 Zuul1
Zuul1 is open source Netflix in 2013 gateway components, large-scale application in the production environment Netflix, has stood the test of practice. It can be used in conjunction with Eureka, Ribbon, Hystrix and other components, to achieve routing forwarding, load balancing, fuse and other functions. Zuul1 core is a series of filters, filter simple easy to expand, there are already some libraries such as the Tripartite spring-cloud-zuul-ratelimitprovide a filter support.
Zuul1 Servlet-based construct, using blocking IO, the introduction of the thread pool to handle the request. Each request requires a separate thread to handle, remove a worker threads from the thread pool, the downstream micro-services before returning a response to the worker thread has been blocked.
1.2 Spring Cloud Gateway Profile
Spring Cloud Spring Cloud Gateway is a new API Gateway project, the purpose is to replace Zuul1. Gateway may Spring Cloud Discovery Client (such as Eureka), Ribbon, Hystrix other components used in conjunction with forwarding for routing, load balancing, and other functions of the fuse, and also built-in flow restrictor Gateway filter implements the current limiting function.
Gateway-based Spring 5, Spring boot 2 and Reactor building, Netty use as a runtime environment, more perfect support non-blocking asynchronous programming. Netty use non-blocking IO, threading model is based on a master-slave Reactors multi-threading model. Wherein Boss Group poll to establish a connection with the new connection Client generates NioSocketChannel, bind to the channel Worker; Worker Group polling process and Read, Write event.
Second, comparison
2.0 Product Comparison
Below in tabular form Zuul1 Gateway and make a simple comparison:
| Comparison items | Zuul1.x | Gateway |
|---|---|---|
| achieve | Servlet2.x build, use blocking based API. | Based Spring 5, Project Reactor, Spring Boot 2, using non-blocking API. |
| Long connection | not support | stand by |
| NA scene | In response to the slow back-end service or high concurrency scenarios, since the number of threads is fixed (limited), the thread is easily depleted, resulting in a new request is denied. | Small flow of the project, using Zuul1.x more appropriate. |
| Limiting | no | Built-in flow restrictor filter |
| Difficult to get started | Synchronous programming, easy to get started | Higher threshold, moderate difficult to get started |
| Spring Cloud Integration | Yes | Yes |
| Sentinel Integration | Yes | Yes |
| Technology stack precipitation | Zuul1 revenue of nearly seven years, tested, stable and mature. | |
| Github used by | 1007 repositories | 102 repositories |
| Github issues | 88 Open / 2736 Closed | 135 Open / 850 Closed |
注：Github used by和Github issues统计时间截止2019/8/26。
2.1 性能对比
2.1.1 低并发场景
不同的tps，同样的请求时间（50s），对两种网关产品进行压力测试，结果如下：
| tps | 测试样本Zuul1/Gateway，单位个 | 平均响应时间Zuul1/Gateway, 单位毫秒 | 99%响应时间小于Zuul1/Gateway，单位毫秒 | 错误比例Zuul1/Gateway |
|---|---|---|---|---|
| 20tps | 20977 / 20580 | 11 / 14 | 16 / 40 | 0% / 0% |
| 50tps | 42685 / 50586 | 18 / 12 | 66 / 22 | 0% / 0% |
并发较低的场景下，两种网关的表现差不多
2.1.2 高并发场景
配置同样的线程数（2000），同样的请求时间（5分钟），后端服务在不同的响应时间（休眠时间），对两种网关产品进行压力测试，结果如下：
| 休眠时间 | 测试样本Zuul1/Gateway，单位个 | 平均响应时间Zuul1/Gateway, 单位毫秒 | 99%响应时间小于Zuul1/Gateway，单位毫秒 | 错误次数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网关的tomcat最大线程数为400，hystrix超时时间为100000。
Gateway在高并发和后端服务响应慢的场景下比Zuul1的表现要好。
2.1.3 官方性能对比
Spring Cloud Gateway developers to provide a benchmark program used to compare the performance of the Gateway and Zuul1, performance comparison of official results are as follows:
| Gateway | Avg Req/sec/Thread | Avg Latency |
|---|---|---|
| Spring Cloud Gateway | 3.24k | 6.61ms |
| Zuul1 | 2.09k | 12.56ms |
| none | 11.77k | 2.09ms |
WRK test tool, test time of 30 seconds, the number of threads 10, 200 connections.
From the official point of view of comparison results, Gateway of RPS is 1.55 times Zuul1 average delay of half Zuul1.
Third, the summary
Zuul1 open source very early, Netflix, Riot, Ctrip, pat loans and other companies have used in a production environment itself has stood the test of practice, is a production-level API gateway products.
Spring Cloud Gateway leave the incubator in 2019, little used in the production of cases, the stability to be verified.
Comparison of the performance, the two products at low flow performance of similar scenes; Gateway performance is much better under high concurrency scenarios. Comparison of the development, Zuul1 programming model is simple, easy to expand; Gateway programming model is slightly difficult to read the code more difficult than many high Zuul, also extended a little more complicated.
Attachment: a text to understand Netty model architecture