Five API Gateway Technology Selections, yyds

This article intends to discuss gateways around seven points, namely the basic concepts of gateways, gateway design ideas, gateway design priorities, traffic gateways, business gateways, and comparisons of common gateways. Friends who are familiar with the basic concepts can check the parts they are interested in according to the catalog.

What is a Gateway

Gateway, many places refer to gateway as door, which is fine, but we need to distinguish the difference between gateway and bridge.

A bridge works at the data link layer, storing and forwarding data frames between different or same types of LANs, and performing protocol conversion at the link layer when necessary. It can connect two or more networks and transmit information packets between them.

Gateway is a broad concept and does not refer to a specific type of product. Anything that connects two different networks can be called a gateway. A bridge generally only forwards information, while a gateway may perform packaging.

Gateway Popular Understanding

According to the characteristics of the gateway, for example:

If you want to go to the boss of a group (this is just an example), everyone knows that the boss is not available to everyone, and he is afraid of bad people. Then you go to the office building where the boss is, if it is the group headquarters, the door of the building acts as a gateway. There are usually gatekeepers at the gate. What do the gatekeepers do?

First of all, anyone who wants to see the boss must enter through this door (unified entrance). This door is equivalent to isolating the office from the outside world, mainly to protect the safety inside and normal work. After arriving at this door, the guard will definitely ask you to show relevant documents (authentication check), which means to judge whether your request to see the boss is reasonable. If it is unreasonable, it will be directly rejected, and you will be asked to go home and wait for news. If after authentication, it is found that you are looking for the boss just to talk to him about the business of the two-dollar store, the guard will tell you that there is no need to find the boss, you just need to go to the group investment department (dynamic routing, routing requests to different back-end clusters). At this time, you will be packaged, such as issuing you a visit certificate, and then telling you how to go, etc.

Take a look, aren't these the three functions of the gateway? The ultimate goal is to reduce your coupling with the group. Specifically, on the computer, it is to reduce the coupling between the client and the server. If there is no gateway, it means that all requests will directly call the resources on the server. This means that the coupling is too strong. If there is a problem with the server, the client will directly report an error. For example, if the boss changes his job, if there is no gateway and you go directly to the original place to look for him, you will definitely be told that the boss is not there.

Why do we need a gateway?

When using a monolithic application architecture, the client (web or mobile) obtains data by making a REST call to the backend application. The load balancer routes the request to one of N identical application instances. The application then queries various database tables and returns the response to the client. Under the microservice architecture, the monolithic application is divided into multiple microservices. If all microservices are directly exposed to the outside world, various security issues are bound to arise, and there is also serious internal and external coupling. Follow the official account: "Code Ape Technology Column", reply with the keyword: "1111" to obtain Alibaba's internal tuning manual

• The client can send requests directly to each microservice. The main problems are as follows:
• There is a mismatch between client requirements and the fine-grained APIs exposed by each microservice.
• Some services use protocols that are not web-friendly, such as Thrift binary RPC or AMQP messaging protocol.

Microservices are difficult to refactor. If you merge two services, or split a service into two or more services, this type of refactoring is very difficult.

Exposing each service on the server side directly to the client call is bound to cause various problems. At the same time, each service on the server side has poor scalability and scalability. The API gateway is a basic component in the microservice architecture, located below the access layer and above the business service layer. The functions mentioned above are suitable for implementation in the API gateway.

Gateway and server cluster

Back to our server, the following figure introduces the role of the Gateway. It can be seen that the architecture under the Gateway mode can be as detailed as configuring a Gateway for each service instance, or as coarse as configuring one for a group of services, or even as coarse as configuring an access Gateway for the entire architecture. As a result, the complexity of the entire system architecture will become simple and controllable.

This diagram shows a multi-layer Gateway architecture, in which there is a general Gateway that accesses all traffic (traffic gateway) and distributes it to different subsystems, and a second-level Gateway that is used as the access gateway for each subsystem (business gateway). As you can see, the granularity of the services managed by the gateway can be coarse or fine. Through the gateway, we can organize the distributed architecture into a star architecture, and the network routes and distributes service requests. Let's talk about what functions a good gateway should have, that is, the gateway design pattern.

Gateway Design Ideas

A gateway needs to have the following functions:

1. Request routing

The gateway must have the function of request routing. This is very convenient for the caller, because the caller does not need to know the addresses of other services it needs to use, and all of them are handled by the Gateway.

2. Service Registration

In order to proxy the services behind and route the requests to the correct location, the gateway should have a service registration function, that is, the backend service instance can register and unregister the address where it provides services. Generally speaking, registration means registering some API interfaces. For example, HTTP Restful requests can register the URI, method, and HTTP header of the corresponding API. In this way, the Gateway can decide which backend service to route to based on the information in the received request.

3. Load Balancing

Because a gateway can receive multiple service instances, the gateway also needs to implement load balancing strategies on each peer service instance. The simplest one is direct Round-Robin polling, the more complex one can set weights for distribution, and the more complex one can also achieve session adhesion.

4. Elastic design

The gateway can also implement asynchrony, retry, idempotence, flow control, circuit breaking, monitoring, etc. in elastic design. In this way, like Service Mesh, application services can only care about their own business logic (or data plane) instead of control logic (control plane).

5. Security

SSL encryption and certificate management, Session verification, authorization, data validation, and prevention of malicious attacks on the request source. The closer the error handling is to the front, the better, so the gateway can be a full-site access component to protect the backend services. Of course, the gateway can also do more interesting things, such as: grayscale release, API aggregation, API orchestration.

Grayscale release

The gateway can completely guide instances of different versions of the same service and collect relevant data, which is of great significance to improving software quality and even product trial and error.

API Aggregation

Using a gateway, you can aggregate multiple individual requests into one request. In the architecture of a microservice system, because the service becomes smaller, an obvious problem is that the client may need to make multiple requests to get all the data. In this way, frequent communication between the client and the backend will have a very adverse effect on the performance and scale of the application. Therefore, we can let the gateway help the client request multiple backend services (concurrent requests are possible in some scenarios), and then assemble the response results of the backend services and send them back to the client (of course, this process can also be made asynchronous, but this requires the cooperation of the client).

API Orchestration

Similarly, in the microservices architecture, to complete a complete business process, we need to call a series of APIs, just like a workflow, which can be completely orchestrated through a web page. We may define and orchestrate different APIs through a DSL, or we can connect different APIs in a way like AWS Lambda service.

Gateway Design Key Points

The gateway design focuses on three aspects: high performance, high availability, and high scalability:

1. High performance

In terms of technical design, the gateway should not and cannot become a performance bottleneck. For high performance, it is best to use high-performance programming languages, such as C, C++, Go, and Java. The gateway's requests to the backend and services to the frontend must use asynchronous non-blocking I/O to ensure that backend delays do not cause performance problems in the application. For C and C++, you can refer to the asynchronous IO model of epoll under Linux and I/O Completion Port under Windows, and the NIO framework of Netty and Spring Reactor under Java.

2. High Availability

Because all traffic or calls go through the gateway, the gateway must be a highly available technical component, and its stability is directly related to the stability of all services. If the gateway is not designed, it will become a single point of failure. Therefore, a good gateway must at least do the following.

• Clustering. For a gateway to become a cluster, it is best if it can form a cluster by itself and synchronize cluster data by itself, without relying on a third-party system to synchronize data.
• Service-oriented. The gateway also needs to be able to modify the configuration without interruption. One way is to do it like Nginx reload configuration, which can provide uninterrupted service. The other is best to be service-oriented. In other words, it must have its own Admin API to modify its configuration at runtime.
• Persistence. For example, restarting is like restarting gracefully like Nginx. There is a main process that is responsible for request distribution. When we need to restart, new requests are assigned to the new process, and the old process exits after processing the request being processed.

3. High scalability

Because the gateway needs to handle all business traffic and requests, there must be more or less business logic. As we all know, business logic is changeable and uncertain. For example, it is necessary to add some business-related things to the gateway. Therefore, a good Gateway also needs to be extensible and capable of secondary development. Of course, secondary development through Modules like Nginx is possible.

In addition, in terms of operation and maintenance, the gateway should have the following design principles.

• Loosely coupled services, tightly coupled protocols. In terms of business design, the gateway should not form service coupling with the services behind it, nor should it have business logic. The gateway should be a component on the network application layer and should not process the communication protocol body, but only parse and process the communication protocol header. In addition, except for service discovery, the gateway should not have dependencies on third-party services.
• Application monitoring and providing analytical data. The gateway needs to consider application performance monitoring. In addition to the high availability statistics of the corresponding backend services, it is also necessary to use Tracing ID to implement distributed link tracking and count the throughput, response time and return code of each API within a certain period of time in order to activate the corresponding strategy in the elastic design.
• Use elastic design to protect backend services. The gateway must implement elastic designs such as circuit breakers, current limiting, retries, and timeouts. If one or more service calls take too long, you can accept the timeout and return part of the data, or return the data of the last successful request cached in the gateway. You can consider such a design.
• DevOps. Because the gateway component is so critical, DevOps is needed to minimize the probability of failure. The software needs to be well tested, including functional and performance testing, as well as immersion testing. A series of automated operation and maintenance management tools are also required.

Gateway Design Considerations

• Do not build the function of aggregating backend services into the code of the gateway. Instead, consider placing the aggregation service outside the core code of the gateway. You can use a plugin or place it behind the gateway to form a Serverless service. Follow the official account: "Code Ape Technology Column" and reply with the keyword: "1111" to obtain Alibaba's internal tuning manual
• The gateway should be close to the backend service and use the same intranet as the backend service. This ensures low latency between the gateway and the backend service and reduces many network issues. Here, the static content processed by the gateway should be close to the user (it should be placed on the CDN), while the gateway and the dynamic service should be close to the backend service.
• The gateway also needs to expand its capacity, so it needs to form a cluster to share the traffic brought by the front end. This can be achieved either through DNS polling, or through CDN to schedule traffic, or through a lower-level load balancing device with higher performance.
• For service discovery, you can make a short-term cache so that you don’t need to check the location of the relevant service for each request. Of course, if your system is not complex, you can consider integrating the service discovery function directly into the gateway.
• Consider a bulkhead design approach for your gateways. Use different gateways to serve different backend services, or use different gateways to serve different frontend clients.

In addition, because the gateway is a bridge between user requests and backend services, some security issues need to be considered. The details are as follows:

• Encrypt data. You can put SSL-related certificates on the gateway, and let the gateway do unified SSL transmission management.
• Verify the user's request. Some basic user verification can be done on the gateway, such as whether the user is logged in, whether the token in the user's request is legal, etc. However, we need to weigh whether the gateway needs to verify the user's input. Because in this way, the gateway needs to change from only caring about the protocol header to caring about the protocol body. On the one hand, the things in the protocol body are not as standard as the protocol header, and on the other hand, parsing the protocol body takes a lot of running time, which reduces the performance of the gateway. In this regard, I would like to say that it depends on the specific needs. On the one hand, if the protocol body is standard, then it can be done; on the other hand, for the performance problems caused by parsing the protocol, corresponding isolation needs to be done.
• Detect abnormal access. The gateway needs to detect some abnormal access, for example, the number of requests exceeds a certain value in a relatively short period of time; for example, the 4xx request error rate of the same client is too high... For such access requests, the gateway needs to block such requests on the one hand, and issue warnings on the other hand, which may be some major security issues, such as being attacked by hackers.

Traffic Gateway

The traffic gateway, as the name implies, is a gateway that controls the traffic entering the cluster. There is a lot of work to be done in this step. For a service cluster, there are bound to be many illegal or invalid requests. At this time, the requests must be rejected to reduce the traffic pressure of the cluster.

The architecture model shown in the figure above is the traffic gateway, which is a global policy gateway that is completely unrelated to specific backend business applications and services. Traffic gateways usually only focus on global API management policies, such as global traffic monitoring, logging, global current limiting, blacklist and whitelist control, and load balancing of access requests to business systems, which is somewhat similar to a firewall. Kong is a typical traffic gateway.

Below is the architecture diagram of kong, from the official website: https://konghq.com

It should be added here that the business gateway is usually deployed after the traffic gateway and before the business system, and is closer to the business system than the traffic gateway. Usually the API network refers to the business gateway. Sometimes we also blur the traffic gateway and the business gateway, letting one gateway take on all the work, so there is no strict boundary between the two.

Business Gateway

When a monolithic application is split into many microservice applications, some problems arise. Some functions that are not strongly related to the business, such as permission control, log output, data encryption, circuit breakers, etc., are required by each microservice application, so there are a lot of duplicate code implementations. In addition, due to system iterations and personnel changes, the implementation details of these functions in each microservice are quite different, resulting in higher maintenance costs. On the other hand, interface management, which was very easy to do in the original monolithic application, no longer has a centralized management place after the service is split, and it is impossible to count which interfaces already exist, what the interface definitions are, and what the operating status is.

The gateway is to solve the above problems. As the core infrastructure in the microservice system, it generally needs to have functions such as interface management, protocol adaptation, circuit breaker and current limiting, and security protection. Various open source gateway products (such as Zuul) provide excellent and highly scalable architectures, which can easily implement some of the functions we need, such as authentication, log monitoring, circuit breaker and current limiting, etc.

The business gateway corresponds to the traffic gateway. The business gateway is closer to our business, that is, it deals with the server application layer. Therefore, many things that need to be considered in the application layer can rely on the business gateway, such as thread model, protocol adaptation, circuit breaker and current limiting, service orchestration, etc. Let's take a look at the business gateway architecture:

From this diagram, we can see the main responsibilities and tasks of the business gateway. Currently, there are three relatively mature API gateway framework products for business gateways: Zuul1, Zuul2 and SpringCloud Gateway, which will be compared later.

Comparison of common gateways

Since we are comparing, we should first have a macro understanding of various gateways, and then select some commonly used or widely used ones for detailed understanding.

Currently, the common open source gateways are roughly classified into the following categories according to language:

• Nginx+lua: OpenResty, Kong, Orange, Abtesting gateway, etc.
• Java: Zuul/Zuul2, Spring Cloud Gateway, Kaazing KWG, gravitee, Dromara soul, etc.
• Go: Janus, fangzi, Grpc-gateway
• Dotnet: Ocelot
• NodeJS: Express Gateway, Micro Gateway

According to the number of uses, maturity, etc., there are five mainstream ones:

• OpenResty
• Kong
• Zuul, Zuul2
• Spring Cloud Gateway

1. OpenResty

OpenResty is a traffic gateway. Based on the previous introduction to the traffic gateway, you can know the responsibilities of the traffic gateway.

OpenResty is a high-performance Web platform based on Nginx and Lua. It integrates a large number of sophisticated Lua libraries, third-party modules, and most dependencies. It is used to easily build dynamic Web applications, Web services, and dynamic gateways that can handle ultra-high concurrency and high scalability. Follow the official account: "CodeApe Technology Column", reply with the keyword: "1111" to obtain Alibaba's internal tuning manual

By combining many well-designed Nginx modules, OpenResty effectively transforms the Nginx server into a powerful Web application server. Based on it, developers can use the Lua programming language to script the Nginx core and various existing Nginx C modules to build extremely high-performance Web applications that can handle more than 10,000 concurrent requests.

OpenResty was originally developed to follow the trend of OpenAPI, so Open means "open" and Resty means REST style. Although later on, any form of web service or traditional web application can also be implemented based on ngx_openresty.

That is to say, Nginx is no longer a simple static web page server, nor is it a simple reverse proxy. The second generation of openresty is committed to expanding nginx into a full-featured web application server through a series of nginx modules.

ngx_openresty is a user-driven project. Later, many domestic users also participated in it. Judging from the distribution of clicks on openresty.org, the number of clicks from China and abroad is basically the same.

ngx_openresty currently has two major application goals:

• General purpose web application server. Under this goal, existing web application technologies can be considered more or less similar to OpenResty, such as Nodejs, PHP, etc. The performance of ngx_openresty (including memory usage and CPU efficiency) is one of its biggest selling points.
• Nginx script extension programming is used to build flexible Web application gateways and Web application firewalls. Somewhat similar is NetScaler. Its advantage lies in the great flexibility brought by Lua programming.

2. Kong

Kong is developed based on OpenResty and is also a traffic layer gateway. It is a cloud-native, fast, scalable, and distributed API gateway. It inherits the high performance and scalability of OpenResty. Kong can be easily expanded horizontally by simply adding machine nodes. At the same time, the functions are plug-in-based, and its capabilities can be expanded through plug-ins. It can run on any infrastructure. It has the following features:

• Provides a variety of authentication layers to protect APIs.
• Inbound and outbound traffic can be controlled.
• Provides visual traffic inspection, monitoring and analysis APIs.
• Able to convert requests and responses in a timely manner.
• Providing log solutions
• Serverless functions can be called through the API.
• What Problems Kong Solve

When we decide to transform the application into microservices, the question of how the application client interacts with the microservices also arises. After all, the increase in the number of services will directly lead to increased difficulty in deployment authorization, load balancing, communication management, analysis, and change.

In the face of the above problems, API GATEWAY is a good solution. The access restriction, security, traffic control, analysis and monitoring, logging, request forwarding, synthesis and protocol conversion functions it provides can free developers to focus on the specific logic code instead of spending time thinking about how to solve the problem of linking applications with other microservices.

Image from Kong official website:

You can see the problems that Kong solves. It focuses on global API management strategies, global traffic monitoring, logging, global current limiting, blacklist and whitelist control, and load balancing from access requests to business systems.

Advantages and performance of Kong

Among the many API GATEWAY frameworks, Mashape's open source high-performance and high-availability API gateway and API service management layer - KONG (based on NGINX+Lua) is particularly outstanding. It can extend existing functions through plug-ins. These plug-ins (written in lua) are executed during the life cycle of the API request response cycle. At the same time, KONG itself provides basic functions including HTTP basic authentication, key authentication, CORS, TCP, UDP, file logging, API request current limiting, request forwarding and NGINX monitoring. Currently, Kong manages more than 15,000 APIs in Mashape and provides billions of requests per month for 200,000 developers.

Kong Architecture

Kong provides a number of services, which requires us to talk about its internal architecture:

First of all, the bottom layer is based on Nginx, which is a high-performance basic layer, a good load balancing and reverse proxy. Then, the Lua script library is added on this basis to form OpenResty, which intercepts requests and responds to the life cycle. Scripts can be written through Lua, so the plug-ins are relatively rich.

For some of Kong's plugin libraries and how to configure them, please refer to Jianshu: Open Source API Gateway System (Kong Tutorial) Getting Started to Mastery: https://www.jianshu.com/p/a68e45bcadb6

3. Zuul 1.0

Zuul is the front door for all requests from devices and web sites to the Netflix streaming application backend. As an edge service application, Zuul is built to support dynamic routing, monitoring, resiliency, and security. It can also route requests to multiple Amazon auto-scaling groups as needed.

Zuul uses a range of different types of filters to allow us to quickly and flexibly apply functionality to our services.

Filters

Filters are the core functionality of Zuul. They are responsible for the business logic of the application and can perform a variety of tasks.

• Type: usually defines at which stage the filter is applied
• Async: Defines whether the filter is synchronous or asynchronous
• Execution Order: Execution Order
• Criteria: The conditions for filter execution
• Action: The action that the filter performs if the condition is met.

Zuul provides a framework for dynamically reading, compiling, and running these filters. Filters do not communicate directly with each other, but share state through the RequestContext unique to each request.

Here are some filters for Zuul:

Incoming

Incoming filters are executed before the request is proxied to the origin. This is usually where most of the business logic is executed. For example: authentication, dynamic routing, rate limiting, DDoS protection, metrics.

Endpoint

Endpoint filters are responsible for processing requests based on the execution of incoming filters. Zuul has a built-in filter (ProxyEndpoint) for proxying requests to backend servers, so the typical use of these filters is for static endpoints. For example: health check responses, static error responses, 404 responses.

Outgoing

Outgoing filters perform processing actions after receiving a response from the backend. Typically, they are more used to shape the response and add metrics than for any heavy lifting. For example: storing statistics, adding/stripping standard headers, sending events to a real-time stream, gziping responses.

Filter Type

The following are the standard filter types that correspond to the typical life cycle of a request:

• PRE: Executed before routing to Origin
• ROUTING: Executed during routing to Origin
• POST: Executed after the request is routed to Origin
• ERROR: Executed when an error occurs

These filters help us perform the following functions:

• Authentication and security: Identify the authentication requirements of each resource and reject requests that do not meet them
• Monitoring: Tracking meaningful data and statistics at the edge to give us an accurate view of production
• Dynamic routing: Dynamically route requests to different backend clusters
• Stress testing: gradually increase the traffic to the cluster to evaluate performance
• Throttling: Allocate capacity for each request type and drop requests that exceed the limit
• Static response processing: build some responses directly at the edge instead of forwarding them to an internal cluster

Zuul 1.0 request lifecycle

Netflix announced the architectural transformation of Zuul, the universal API gateway. Zuul originally used a synchronous blocking architecture, but after the transformation, it was called Zuul2, which uses an asynchronous non-blocking architecture. The main difference between Zuul2 and Zuul1 in terms of architecture is that Zuul2 runs on an asynchronous non-blocking framework, such as Netty. Zuul1 relies on multithreading to support throughput growth, while the Netty framework used by Zuul 2 relies on event loops and callback functions.

4. Zuul 2.0

Zuul 2.0 architecture diagram

The above figure shows the architecture of Zuul2, which is essentially the same as Zuul1, with two changes:

• The front-end uses Netty Server instead of Servlet to support front-end asynchrony. The back-end uses Netty Client instead of Http Client to support back-end asynchrony.
• The filters have been renamed, with Inbound Filters replacing Pre-routing Filters, Endpoint Filter replacing Routing Filter, and Outbound Filters replacing Post-routing Filters.

Inbound Filters: Executed before routing to Origin, can be used for authentication, routing and decoration requests

Endpoint Filters: can be used to return a static response, otherwise the built-in ProxyEndpoint filter routes the request to the Origin

Outbound Filters: Executed after getting the response from Origin, can be used for metrics, decorating user responses or adding custom headers

There are two types of filters: sync and async. Because Zuul runs on an event loop, never block in a filter. If you must block, do so in an asynchronous filter and run it on a separate thread pool, otherwise use a synchronous filter.

As mentioned above, Zuul2 began to adopt an asynchronous model

The advantage is that the asynchronous non-blocking mode starts very few threads. Basically, only one event loop processing thread needs to be started on a CPU core, which uses very few thread resources and has less context switching overhead. The number of connections that can be accepted in the non-blocking mode is greatly increased. It can be simply understood that when a request comes, it only needs to enter the queue. The capacity of this queue can be set very large. As long as it does not time out, the requests in the queue will be processed in sequence.

Insufficient, asynchronous mode makes the programming model complicated. On the one hand, the code of Zuul2 itself is much more complicated than Zuul1. The code of Zuul1 is easier to understand, while the code of Zuul2 looks more difficult. On the other hand, the asynchronous model does not have a clear and clear request->processing->response execution process (call flow). Its process is triggered by events, and the request processing process may be switched and disconnected at any time. The internal implementation must use some association id mechanisms to connect the entire execution flow in series, which introduces a lot of complexity to development, debugging and operation and maintenance. For example, it is very difficult to debug asynchronous request flows in the IDE. In addition, the ThreadLocal mechanism cannot work simply in this asynchronous mode, because there is only one event loop thread, not one thread per request, and there is no concept of thread locality. Therefore, for monitoring tools such as CAT that rely on ThreadLocal to work, call chain tracking is not easy to do (it can actually work but requires special processing).

In general, the asynchronous non-blocking mode is more suitable for IO-intensive (IO bound) scenarios. In this scenario, the system spends most of its time processing IO, the CPU calculation is relatively light, and a small number of event ring threads can handle it.

Performance comparison between Zuul and Zuul 2

Netflix gave a rather vague data, roughly Zuul2's performance is about 20% better than Zuul1. The performance here mainly refers to the number of requests processed per node per second. Why is it vague? Because this data is affected by many factors such as the actual test environment and traffic scenario mode, it is difficult to reproduce this test data. Even if this 20% performance improvement is true, it is actually not that big. Compared with the complexity introduced by asynchrony, whether this 20% improvement is worth it is a question. Netflix itself is also a bit vague in its blog post 22 and ppt 11, and even has some doubts itself.

5. Spring Cloud Gateway

SpringCloud Gateway is a new project of Spring Cloud. It is a gateway developed based on technologies such as Spring 5.0, Spring Boot 2.0, and Project Reactor. It aims to provide a simple, effective and unified API routing management method for microservice architecture.

SpringCloud Gateway is a gateway in the Spring Cloud ecosystem. Its goal is to replace Zuul. In Spring Cloud 2.0 and above, the latest high-performance versions of Zuul 2.0 and above are not integrated. The old non-Reactor mode version before Zuul 2.0 is still used. In order to improve the performance of the gateway, SpringCloud Gateway is implemented based on the WebFlux framework, and the underlying WebFlux framework uses the high-performance Reactor mode communication framework Netty.

The goal of Spring Cloud Gateway is not only to provide a unified routing method, but also to provide basic gateway functions based on the Filter chain, such as security, monitoring/indicators, and current limiting.

Spring Cloud Gateway uses the high-performance communication framework Netty at the bottom layer.

SpringCloud Gateway Features

SpringCloud officially introduces the features of SpringCloud Gateway as follows:

(1) Based on Spring Framework 5, Project Reactor and Spring Boot 2.0

(2) Integrate Hystrix circuit breaker

(3) Integrate Spring Cloud DiscoveryClient

(4) Predicates and Filters act on specific routes and are easy to write.

(5) It has some advanced functions of the gateway: dynamic routing, current limiting, and path rewriting

From the above features, there is not much difference from Zuul. The main difference between SpringCloud Gateway and Zuul is in the underlying communication framework.

Let me briefly explain the three terms in the above text:

Filter

Similar in concept to Zuul's filter, it can be used to intercept and modify requests and perform secondary processing on upstream responses. The filter is an instance of the org.springframework.cloud.gateway.filter.GatewayFilter class.

Route

The basic building block of the gateway configuration is similar to the Zuul route configuration module. A Route module is defined by an ID, a target URI, a set of assertions, and a set of filters. If the assertion is true, the route matches and the target URI is accessed.

Predicate:

This is a Java 8 Predicate that can be used to match anything from an HTTP request, such as headers or parameters. The input type of the predicate is a ServerWebExchange.

Comparison of several gateways

The main account friend slot is full, and I have opened a new account. If you have any questions or want to be friends with Chen, you can add me as a friend.