Summary of API Gateway Selection Analysis

This article is going to talk about gateways around seven points, namely the basic concepts of gateways, gateway design ideas, gateway design key points, traffic gateways, business gateways, and comparison of common gateways. Friends who are familiar with basic concepts can view the parts they are interested in according to the catalog .

1. What is a gateway

Gateway, in many places, the gateway is like a door, there is no problem, but the difference between a gateway and a bridge needs to be distinguished:

• The bridge  works at the data link layer, stores and forwards data frames between different or the same type of LANs, and performs protocol conversion on the link layer when necessary. Two or more networks can be connected between which packets of information are transmitted.

• A gateway  is a big concept and does not specifically refer to a type of product. As long as it connects two different networks, it can be called a gateway. Generally, a bridge only forwards information, and a gateway may perform packaging.

Common understanding of gateway

According to the characteristics of the gateway, for example:

If you want to go to the boss of the group (here is just an example), everyone knows that the boss is not easy to meet with anyone, and he is also afraid of bad people, then you go to the office building where the boss is located, if it is the headquarters of the group, the door of the building It acts as a gateway. The gate generally has a gatekeeper. What will the gatekeeper do?

First of all, everyone 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. It is mainly to protect the safety and normal work inside. After coming to this door, the guard will definitely let you Presenting relevant documents (authentication inspection) means judging whether your request to see the boss is reasonable. If it is unreasonable, it will be rejected directly, and you will be asked to go home and wait for news. Talk about the business of the two-dollar store, the doorman will tell you that you don’t need to find the boss, you can just go to the investment department of the group (dynamic routing, routing requests to different back-end clusters), and some packaging will be done for you at this time , such as issuing you a visit card, and then telling you how to go, and so on.

You see, the role of the gateway is not just these three. The ultimate goal is to reduce the coupling between you and the group. Specifically, it is to reduce the coupling between the client and the server on the computer. If there is no gateway, it means that all requests will directly call the server on the server. Resources, this coupling is too strong, if there is a problem with the server, the client will directly report an error, for example, the boss has changed his job, if there is no gateway, you can go directly to the original place to look for it, and you will definitely be told that the boss is not here.

Why do you need a gateway

When using a monolithic application architecture, the client (web or mobile) fetches data by making a REST call to the backend application. The load balancer routes requests to one of N identical application instances. The application then queries various database tables and returns responses to the client. Under the microservice architecture, a single application is divided into multiple microservices. If all microservices are directly exposed to the outside world, various security problems will inevitably occur, and the internal and external coupling is serious.

Clients can directly send requests to each microservice, and the main problems are as follows:

• There is a mismatch between client requirements and the fine-grained APIs that each microservice exposes.

• Some services use protocols that are not web-friendly. Either Thrift binary RPC, or AMQP messaging protocol.

• Microservices are difficult to refactor. This type of refactoring can be very difficult if two services are merged, or if one service is split into two or more services.

Various services on the server side are directly exposed to client calls, which will inevitably cause various problems. At the same time, the scalability and scalability of each service on the server side are poor. The API gateway is a basic component in the microservice architecture, which is located under the access layer and above the business service layer. These functions as mentioned above are suitable for implementation in the API gateway.

Gateway and server cluster

Going back to our server, the following figure introduces the role of the Gateway (Gateway). It can be seen that the architecture under the Gateway mode can be as fine as configuring a Gateway for each service instance, or as coarse as configuring a Gateway for a group of services, or even It can be as thick as configuring an access Gateway for the entire architecture. As a result, the complexity of the entire system architecture becomes simple and controllable.

This picture 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 is used to access each subsystem Gateway (business gateway). It can be seen that the service granularity 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.

2. Gateway Design Ideas

A gateway needs to have the following capabilities:

1. Request Routing

The gateway must have the function of request routing. In this way, it is also a very convenient thing for the caller. Because the caller does not need to know the addresses of other services that they need to use, all of them are handed over to the Gateway for processing.

2. Service registration

In order to be able to proxy the services behind and route requests to the correct location, the gateway should have a service registration function, that is, the back-end service instance can register and unregister the address it provides. Generally speaking, registration means registering some API interfaces. For example, for an HTTP Restful request, you can register the URI, method, and HTTP header of the corresponding API. In this way, 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 a load balancing strategy on each peer service instance. The simpler one is direct Round-Robin polling, the more complicated one can be set up for distribution, and the more complicated one can also achieve session sticking.

4. Elastic design

The gateway can also implement asynchronous, retry, idempotent, flow control, fuse, monitoring, etc. in elastic design. In this way, like Service Mesh, application services can only care about their own business logic (or things on the data plane) rather than control logic (control plane).

5. Safety aspects

SSL encryption and certificate management, Session verification, authorization, data verification, and prevention of malicious attacks on request sources. The earlier the error handling is, the better. Therefore, the gateway can be a whole-site access component to protect the back-end services. Of course, the gateway can also do more and more interesting things, such as grayscale publishing, API aggregation, and API orchestration.

• Gray release

  The gateway can completely divert instances of different versions of the same service, and can also collect relevant data. This is very positive for the improvement of software quality and even product trial and error.

• API aggregation

  Gateways allow multiple individual requests to be aggregated into one request. In the architecture of the microservice system, because the service becomes smaller, an obvious problem is that the client may need multiple requests to get all the data. As a result, frequent communication between the client and the backend can have a very detrimental effect on the performance and scale of the application. Therefore, we can let the gateway help the client request multiple back-end services (in some scenarios, concurrent requests can be made), and then assemble the response results of the back-end services and send them back to the client (of course, this process can also be done asynchronously, but this requires the cooperation of the client).

• API orchestration

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

  ---

3. Key points of gateway design

There are three main points of gateway design, high performance, high availability, and high expansion:

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 the servicing of requests to the frontend, must use asynchronous non-blocking I/O to ensure that backend latency does not cause performance problems in the application. C and C++ can refer to the asynchronous IO model of epoll under Linux and I/O Completion Port of Windows, and the NIO framework of Netty and Spring Reactor under Java.

2. High availability

Because all traffic or calls pass through the gateway, the gateway must become a highly available technical component, and its stability is directly related to the stability of all services. A gateway, if not designed, becomes 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 to form a cluster by itself and synchronize cluster data by itself without relying on a third-party system to synchronize data.

• Servitization  . The gateway also needs to be able to modify the configuration without interruption. One is to achieve non-stop service like the Nginx reload configuration, and the other is to achieve service-oriented. In other words, you must have your own Admin API to modify your configuration at runtime.

• Persistence  . For example, restarting is to restart gracefully like Nginx. There is a main process that oversees the distribution of requests. When we need to restart, the new request is assigned to the new process, and the old process exits after processing the request being processed.

3. High expansion

Because the gateway needs to undertake all business traffic and requests, there must be more or less business logic. And we all know that 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 scalable and capable of secondary development. Of course, secondary development through Module like Nginx is certainly possible.

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

• Services are loosely coupled and protocols are tightly coupled. In terms of business design, the gateway should not form service coupling with subsequent services, nor should it have business logic. The gateway should be a component on the network application layer, and should not process the body of the communication protocol, but should only parse and process the communication protocol header. Also, the gateway should have no dependencies on third-party services other than service discovery.

• Application monitoring, providing analytics data. The monitoring of application performance needs to be considered on the gateway. In addition to the high-availability statistics of the corresponding back-end services, it is also necessary to use the Tracing ID to implement distributed link tracking, and to count the throughput and response time of each API within a certain period of time. and return codes in order to initiate the corresponding strategy in the elastic design.

• Protect backend services with elastic design. Elastic designs such as fuse, current limit, retry, and timeout must be implemented on the gateway. If one or more service calls take too long, it is acceptable to time out and return a portion of the data, or return a cache of data from the last successful request in the gateway. You can consider such a design.

• DevOps. Because the gateway component is so critical, something like DevOps is needed to minimize the probability of its failure. The software needs to be well tested, including functional and performance testing, as well as soak testing. A series of management and control tools for automated operation and maintenance are also required.

4. Gateway design considerations

1. Instead of building the aggregation backend service functionality into the code in the gateway, consider placing the aggregation service outside the gateway core code. Plugin can be used, or it can be placed behind the gateway to form a Serverless service.

2. The gateway should be close to the back-end service, and use the same intranet as the back-end service, which can ensure low latency of gateway and back-end service calls, and can reduce many problems on the network. One more thing to say here, the static content processed by the gateway should be close to the user (should be placed on the CDN), while the gateway and the dynamic service at this time should be close to the back-end service.

3. The gateway also needs capacity expansion, so it needs to become a cluster to share the traffic brought by the front end. This is achieved either through DNS polling, or through CDN for traffic scheduling, or through lower-level load balancing devices with higher performance.

4. For service discovery, you can make a short-term cache, so that you don't need to check the location of the relevant service every time you request it. Of course, if your system is not complicated, you can consider integrating the service discovery function directly into the gateway.

5. Consider the bulkhead design approach for gateways. Use different gateways to serve different back-end services, or use different gateways to serve different front-end customers.

   
    

   

In addition, because the gateway is a bridging device for user requests and back-end services, some security issues need to be considered. details as follows:

1. Encrypt data  . SSL-related certificates can be placed on the gateway, and the gateway will perform unified SSL transmission management.

2. Validate the user's request  . Some basic user verification can be done on the gateway, such as whether the user has logged in, whether the token in the user 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. On the other hand, parsing the protocol body takes a lot of running time, thereby reducing the performance of the gateway. In this regard, what I want to say is that depending on the specific requirements, 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 the parsing protocol, corresponding isolation needs to be done.

3. Detect abnormal access  . The gateway needs to detect some abnormal accesses, for example, the number of requests exceeds a certain value in a relatively short period of time; for example, the error rate of 4xx requests from the same client is too high... For such access requests, the gateway should take such Requesting to be blocked, on the other hand, needs to be warned, which may be some relatively serious security issues, such as being hacked.

5. Traffic Gateway

Traffic gateway, as the name implies, is a gateway that controls 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. flow pressure.

Defining a policy gateway that is global and has nothing to do with specific back-end business applications and services is the architectural model shown in the figure above—traffic gateway. Traffic gateways usually only focus on global Api management strategies, such as global traffic monitoring, logging, global traffic limiting, black and white list control, load balancing from access requests to business systems, etc., which are somewhat similar to firewalls. Kong is a typical traffic gateway.

The following is the architecture diagram of kong, from the official website:

What needs to be added here is that the business gateway is generally deployed after the traffic gateway and before the business system, and is closer to the business system than the traffic gateway. Generally, the API network refers to the service gateway. Sometimes we also blur traffic gateways and business gateways, and let one gateway do all the work, so there is no strict boundary between the two.

6. Business Gateway

When a single application is split into many microservice applications, it also brings some problems. Some functions that are not strongly related to the business, such as permission control, log output, data encryption, fuse current limit, etc., are required by every microservice application, so there are a lot of repeated code implementations. Moreover, due to the iteration of the system and the replacement of personnel, there are large differences in the implementation details of these functions in each microservice, resulting in higher maintenance costs. On the other hand, interface management, which was very easy to do under the original single application, has no place for centralized management after the service is split, and it is impossible to count which interfaces exist, what is the definition of the interface, and what is the running status.

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, fuse current limit, security protection, etc. Various open source gateway products (such as zuul) provide excellent and highly scalable architectures, It is very convenient to realize some of the functions we need, such as authentication, log monitoring, circuit breaking and current limiting, etc.

Corresponding to the traffic gateway is the business gateway, which is closer to our business, that is, dealing with the server application layer, so many things that need to be considered by the application layer can rely on the business gateway, such as threading model, protocol adaptation, Circuit breaking and current limiting, service orchestration, etc. Let's take a look at the business gateway architecture:

Picture from: Landing practice of business gateway

From this figure, we can see the main responsibilities of the business gateway and what it does. At present, there are three relatively mature API gateway framework products for the business gateway: Zuul1, Zuul2 and SpringCloud Gateway , which will be compared later.

7. Comparison of Common Gateways

Now that we are comparing, let’s first have a macroscopic understanding of various gateways, and then choose some commonly used or widely used ones for detailed understanding.

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

• Nginx+lua ：OpenResty、Kong、Orange、Abtesting gateway 等

• Java ：Zuul/Zuul2、Spring Cloud Gateway、Kaazing KWG、gravitee、Dromara soul 等

• Go ：Janus、fagongzi、Grpc-gateway

• Dotnet ：Ocelot

• NodeJS ：Express Gateway、Micro Gateway

According to the number of usage, maturity, etc., there are 4 mainstream ones:

• OpenResty

• Kong

• Zuul/Zul2

• Spring Cloud Gateway

1. OpenResty

Related links: official website, station B, Github

OpenResty is a traffic gateway. According to 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, which integrates a large number of excellent Lua libraries, third-party modules and most dependencies. It is used to conveniently build dynamic web applications, web services, and dynamic gateways that can handle ultra-high concurrency and high scalability.

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

OpenResty was first made in line with the trend of OpenAPI, so Open is taken from the meaning of "openness", and Resty is the meaning of REST style. Although any form of web service or traditional web application can be implemented based on ngx_openresty later.

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

ngx_openresty is a user-driven project, and later many domestic users participated. From the distribution of clicks on openresty.org, domestic and foreign clicks are basically the same.

ngx_openresty currently has two application targets:

1. General purpose web application server. Under this goal, the existing web application technologies can be regarded as more or less similar to OpenResty, such as Nodejs, PHP and so on. The performance of ngx_openresty (including memory usage and CPU efficiency) is one of the biggest selling points.

2. Nginx script extension programming for building flexible web application gateways and web application firewalls. Somewhat similar is NetScaler. Its strength lies in the enormous flexibility that Lua programming brings.

2. Kong

Related links: official website, Github

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 easy scalability of OpenResty. Kong can easily expand horizontally by simply adding machine nodes. At the same time, the function is plug-in, and its capabilities can be extended through plug-ins. And it works on any infrastructure. Has the following properties:

• Provides a variety of authentication layers to protect the API.

• Ingress and egress traffic can be regulated.

• Provides visual traffic inspection, monitoring and analysis APIs.

• Able to convert requests and responses in a timely manner.

• Provide log solutions

• Serverless functions can be called through the api.

What problem does 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 increase the difficulty of deployment authorization, load balancing, communication management, analysis and changes. .

Faced with the above problems, API GATEWAY is a good solution. It provides access restriction, security, flow control, analysis and monitoring, logging, request forwarding, synthesis and protocol conversion functions, which can liberate developers to concentrate on specific Logical code, instead of spending time thinking about how to solve the problem of linking applications and other microservices.

Picture from Kong official website:

You can see the problems Kong solves. Focus on global Api management strategies, global traffic monitoring, logging, global traffic limiting, black and white list control, load balancing from access requests to business systems, etc.

Advantages and performance of Kong

Among 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 prominent. It can extend existing functions through plug-ins. These plug-ins (written in lua) Executed during the lifecycle 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 logs, API request flow limiting, request forwarding, and NGINX monitoring. Currently, Kong manages more than 15,000 APIs in Mashape, supporting 200,000 developers with billions of requests per month.

Kong Architecture

Kong provides a series of services, so we have to talk about the internal architecture:

First of all, the bottom layer is based on Nginx, Nginx is a high-performance base layer, a good load balancing, reverse proxy, and then add Lua script library on this basis, forming OpenResty, intercepting requests, responding to the life cycle, you can pass Lua Write scripts, so the plug-ins are relatively rich.

For some plug-in libraries of Kong and how to configure them, you can refer to the short book: Open Source API Gateway System (Kong Tutorial) from entry to proficiency

3. Zuul1.0

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

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

filter

Filters are the core functionality of Zuul. They are responsible for the business logic of the application and can perform various 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 : 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 each request-specific RequestContext.

Here are some of Zuul's filters:

Incoming

The Incoming filter is executed before the request is proxied to Origin. This is usually where most of the business logic is performed. 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 a typical use of these filters is for static endpoints. For example: health check response, static error response, 404 response.

Outgoing

Outgoing filters perform processing actions after receiving responses from the backend. Typically, they are used more for forming responses and adding metrics than for any heavy lifting. For example: storing statistics, adding/stripping standard headers, sending events to live streams, gziping responses.

filter type

The following are standard filter types that correspond to a typical lifecycle of a request:

• PRE: execute 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 needs of each resource and reject requests that do not meet them

• Monitoring  : Track 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 test  : Gradually increase the traffic of the cluster to evaluate the performance

• Rate limiting  : Allocate capacity for each request type and drop requests exceeding the limit

• Static response processing  : build some responses directly at the edge instead of forwarding them to the internal cluster

Zuul 1.0 request lifecycle

Netflix announced the architectural transformation of Zuul, a general-purpose API gateway. Zuul originally adopted a synchronous blocking architecture. After the transformation, it was called Zuul2 and adopted 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 multi-threading to support throughput growth, while the Netty framework used by Zuul 2 relies on event loops and callback functions.

Zeul2.0

Zuul 2.0 architecture diagram

The picture above shows the architecture of Zuul2, which is no essential difference from Zuul1, with two changes:

1. The front end uses Netty Server instead of Servlet to support front-end asynchrony. The backend uses Netty Client instead of Http Client to support backend asynchrony.

2. The filter changed its name, replaced Pre-routing Filters with Inbound Filters, replaced Routing Filter with Endpoint Filter, and replaced Post-routing Filters with Outbound Filters.

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

Endpoint Filters: Can be used to return static responses, otherwise the built-in ProxyEndpoint filter routes the request to Origin

Outbound Filters: Execute after getting the response from Origin, which can be used to measure, decorate the user's response or add custom headers

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

As mentioned above, Zuul2 began to adopt the asynchronous model

The advantage  is that there are few threads started in asynchronous non-blocking mode. Basically, only one event loop processing thread needs to be started on a CPU core, which uses few thread resources and less context switching (Context Switch) overhead. The number of connections that can be accepted in 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 sequentially.

Insufficient  , the asynchronous mode complicates the programming model. On the one hand, the code of Zuul2 itself is much more complicated than that of Zuul1. The code of Zuul1 is easier to understand, but the code of Zuul2 looks more laborious. On the other hand, the asynchronous model does not have a clear request->processing->response execution flow (call flow). Its flow is triggered by events, and the request processing flow may be switched and disconnected at any time. The internal implementation needs to pass some associations The id mechanism can connect the entire execution flow in series, which introduces a lot of complexity to the development, debugging, and maintenance. For example, it is very difficult for you to debug the asynchronous request flow in the IDE. In addition, the ThreadLocal mechanism cannot simply work in this asynchronous mode, because there is only one event loop thread, not one thread for each request, and there is no concept of thread locality, so for CAT, a monitoring tool that relies on ThreadLocal to work, It is not easy to bury the call chain (actually it can work but needs special handling).

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

Zuul and Zuul 2 performance comparison

Image credit: Zuul's Journey to Non-Blocking

Netflix gave a rather vague data. The performance of Zuul2 is roughly 20% better than Zuul1  . The performance here mainly refers to the number of requests processed per second per node. Why do you say vague? Because this data is affected by many factors such as the actual test environment and traffic scene mode, it is difficult for you to reproduce this test data. Even if this 20% performance improvement is true, in fact, this performance improvement is not large. Compared with the complexity introduced by asynchrony, whether this 20% improvement is worthwhile is a question. Netflix itself is a bit vague in its blog post 22 and ppt11, and even has some doubts of its own.

4. Spring Cloud Gateway

Related links: official website, Chinese official documents

SpringCloud Gateway is a brand new project of Spring Cloud. The project 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 and effective unified API routing management method for microservice architecture.

As a gateway in the Spring Cloud ecosystem, SpringCloud Gateway aims to replace Zuul. In Spring Cloud 2.0 and above, it does not integrate the latest high-performance versions of Zuul 2.0 and above, and still uses the non-Reactor mode before Zuul 2.0. old version of . In order to improve the performance of the gateway, SpringCloud Gateway is implemented based on the WebFlux framework, and the bottom layer of the 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 functions of the gateway based on the Filter chain, such as: security, monitoring/indicators, and current limiting.

The bottom layer of Spring Cloud Gateway uses Netty, a high-performance communication framework.

Spring Cloud 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) Integrated Hystrix circuit breaker

(3) Integrate Spring Cloud Discovery Client

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

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

From the above characteristics, it is not much different from Zuul's characteristics. The main difference between SpringCloud Gateway and Zuul lies in the underlying communication framework.

A brief explanation of the three terms above:

• Filter

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

• Route

  The basic component module of gateway configuration is similar to Zuul's routing 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 asserted input type is a ServerWebExchange.

Comparison of several gateways

Source: https://developer.aliyun.com/article/889271