1. What is GateWay

In the microservice architecture, a system is split into many microservices. So how to call so many microservices as a client? If there is no gateway, the address of each microservice can only be recorded on the client, and then called separately. This will cause many problems:
- The client requests multiple microservices, which increases the complexity of client code or configuration writing;
- Authentication is complicated, and each microservice has an independent authentication
; The processing in the scene is relatively complicated;

In order to solve the above problems, the concept of gateway is introduced: the so-called API gateway refers to the unified entrance of the system, which provides routing and transfer of internal services, and provides unified services for clients. Some public logic that has nothing to do with the functions of the business itself can be found here Implementation, such as authentication, authentication, monitoring, routing and forwarding, etc.

The current mainstream gateways are:

- Zuul 1.x: Netflix's open source gateway, built on the basis of the Servlet framework, rich in functions, developed with JAVA, easy for secondary development Problem: one thread processes a connection request, this method has serious internal delays and many equipment failures It will cause the increase of surviving connections and increase of threads.

- Zuul 2.x: Zuul2 uses Netty to implement an asynchronous non-blocking programming model. Each CPU core has one thread to process all requests and responses. The life cycle of requests and responses is handled through events and callbacks. This method reduces The number of threads is reduced, so the overhead is small. The performance of 2.x has improved a lot, but the open source time is too late, and SpringCloud can't wait any longer, so it has a GateWay;

- GateWay : The gateway service developed by Spring to replace Zuul, the bottom layer is Netty.

- Nginx+lua: Using nginx's reverse proxy and load balancing can achieve load balancing and high availability for api servers. Lua is a scripting language that can be used to write some simple logic. nginx supports lua scripts. The problem is: it cannot Integrate into the microservice architecture.

- Kong: Developed based on Nginx+Lua, it has high performance and stability, and there are multiple available plug-ins (current limiting, authentication, etc.) that can be used out of the box. Problem: only supports Http protocol; secondary development, free expansion is difficult; provides management API, lacks easier-to-use control and configuration methods.

Spring Cloud Gateway is based on Spring Boot 2.x, Spring WebFlux and Project Reactor. It aims to provide a simple and effective unified API routing management method for microservice architecture. Its goal is to replace Netflix Zuul, which not only provides a unified routing method, but also provides the basic functions of the gateway based on the Filter chain, such as: security, monitoring and current limiting.

Features:
1. Strong performance: 1.6 times that of Zuul;
2. Powerful functions: built-in many practical functions, such as forwarding, monitoring, current limiting, etc.;
3. Elegant design, easy to expand;

Route (Route) is one of the most basic components in gateway, which represents a specific routing information carrier. It mainly defines the following information:
- id: route identifier, different from other routes;
- uri: the destination uri pointed to by the route, that is, the microservice to which the client request is finally forwarded;
- order: used for multiple routes The smaller the value, the higher the sorting, and the higher the matching priority;
- predicate: the function of the assertion is to perform conditional judgment, and only when the assertion returns true, the routing will actually be executed;
- filter: the filter is used to modify request and response information;

Execution process:
1. Gateway Client sends a request to Gateway Server;
2. The request will first be extracted by HttpWebHandlerAdapter and assembled into a gateway context;
3. Then the context of the gateway will be passed to DispatcherHandler, which is responsible for distributing the request to RoutePredicateHandlerMapping;
4. RoutePredicateHandlerMapping is responsible for Find the route, and judge whether the route is available according to the route assertion;
5. If the assertion is successful, the FilteringWebHandler will create a filter chain and call it;
6. The request will pass through the PreFilter--microservice--PostFilter method once, and finally return a response;

2. GateWay workflow

The client makes a request to the Gateway, and if the Gateway Handler Mapping determines that the request matches a route, it sends it to the Gateway Web Handler handler. This handler runs the request through a request-specific Filter chain. The reason filters are separated by dotted lines is that filters can run logic before (pre) and after (post) sending proxy requests. Executes all pre filter logic and then proxied requests. After the proxy request is made, the "post" filter logic is run.

Filter function:
- Filter in the pre type filter can be used for parameter validation, authority validation, flow monitoring, log output, protocol conversion, etc.; -
Filter in the post type filter can be used for response content, response header modification, log output, flow monitoring, etc.;
these two types of filters serve a very important purpose.

Three core points of GateWay

- Route (routing)
routing is the basic module for building a gateway. It consists of ID, target URI, including a series of assertions and filters. If the assertion is true, the route will be matched;

- Predicate (assertion)
refers to java.util.function.Predicate of Java8. Developers can match all content in HTTP requests (such as request headers or request parameters), and the request will be routed if it matches the assertion;

- Filter (filter)
refers to the instance of GateWayFilter in the Spring framework. Using a filter, the request can be modified before or after the request is routed;

The three core points are connected:
when a user sends a request to GateWay, GateWay will locate the real service node through some matching conditions, and perform some fine-grained control before and after the forwarding process. Among them, Predicate is our matching condition, and Filter can be understood as an interceptor. With these two points and the target URI, a specific route can be realized.

3. GateWay builds the foundation

Now that you have understood the overall basic concept of GateWay, let's build a GateWay module: cloudaliba-gateway-9999

Although the name is cloudaliba, in fact GateWay belongs to SpringCloud and has nothing to do with Alibaba, but it can be integrated with SpringCloud Alibaba. Therefore, when introducing related dependencies, we must pay attention to the compatibility relationship with the SpringBoot version:

I use the 2.7.x version of SpringBoot here, so the version of spring-cloud-dependencies introduced by the parent project should be 2021.0.x. It is recommended that this version be consistent with the version of SpringCloud Alibaba. I use 2021.0.4.0 for SpringCloud Alibaba here, so the final spring-cloud-dependencies use version 2021.0.4.

Introduce GateWay and Nacos-related dependencies in the 9999 subproject, and GateWay also needs to be registered in Nacos:

Configure the yml file of the 9999 project:

Write a Controller in the 9001 project, matching the path in the GateWay configuration file:

Start 9001 and 9999, access 9999, and verify whether GateWay forwarding is successful:

Both are also successfully registered in Nacos:

GateWay's basic route configuration method is done through the yml configuration file, but in fact GateWay also provides another configuration method. It is configured through code, that is, injecting a RouteLocator through @Bean.

Create a new GateWayConfig. In fact, the configuration here corresponds to the corresponding content configured in yml:

Write a Controller in the 9001 project, matching the path in GateWay Config:

Start 9001 and 9999, access 9999, and verify whether GateWay forwarding is successful:

4. GateWay load balancing

automatic load balancing

First look at the yml configuration of 9999. In fact, some configuration information here does not need to be written:

Start 9001 and 9999 again, visit 9999, and verify whether GateWay forwarding is successful:

It can be seen that even if some attributes are annotated in yml, it still does not affect the use of GateWay functions. So what do the commented out properties mean?

Keep the Controllers of 9001 and 9002 the same, and register them in Nacos, and the service names of the two are the same:

discovery.locator.enabled: true
Whether to combine with the service discovery component and forward it to a specific service instance through serviceID (service name). The default is false, and when it is true, the function of automatically creating routes based on serviceID through the service center is enabled.

In other words, GateWay will automatically read the services in the current Nacos. Currently, there are two services 9001 and 9002 in Nacos. After reading these two services, GateWay will automatically perform load balancing among services with the same name.

Open discovery.locator.enabled in the 9999 configuration file , and delete the routes:

Since load balancing is to be achieved, it is natural to introduce the spring-cloud-starter-loadbalancer dependency in 9999

To restart the 9999 gateway service, you need to write the corresponding service name on the URL when requesting the gateway:

Manual load balancing

In the above yml configuration, the target service name will be exposed when the service is forwarded, and it is too flexible, so it can be solved by manual configuration. Just use the routes configuration:

Restart the 9999 gateway service, and you don’t need to write the corresponding service name on the URL when requesting the gateway:

In fact, after the routes configuration is enabled, discovery.locator.enabled no longer works.

The use of each Predicate can be understood as forwarding when the conditions are met. The relationship between each Predicate is &&, that is to say, no matter how many assertion rules are written, all conditions must be met before forwarding.

Predicate types:
1. After : Match requests that occur after the specified date and time;
2. Before : Match requests that occur before the specified date;
3. Between : You need to specify two date parameters, set a time interval, and match this time 4. Cookie : Two parameters need to be specified, namely name and regexp (regular expression), and Key and Value can also be understood to match a cookie with a given name and whose value matches the regular expression
; 5 , Header : Two parameters header and regexp (regular expression) are required, which can also be understood as Key and Value, matching the information carried by the request; 6, Host: matching whether the current request comes from the set host; 7, Method : you can set a or multiple parameters, matching HTTP requests, such as GET, POST; 8. Path : Match requests under the specified path, which can be separated by multiple commas; 9. Query : One or more parameters need to be specified, one must be a parameter and one Optional regular expression, whether the matching request contains the first parameter, if there are two parameters, whether the value of the first parameter in the matching request conforms to the regular expression; 10 , RemoteAddr

: Match the specified IP or IP segment, and forward if it meets the conditions;
11. Weight : It needs two parameters group and weight (int), which realizes the routing weight function, and selects the route in the same group according to the routing weight;

After

Matching requests that occur after the specified time can correspond to early online services. To demonstrate this assertion rule, you need to know what the current time is, for example:
my current time is:
2022-11-16T23:08:39.184751300+08:00[Asia/Shanghai]
then I want to set it to 2022-11-17 If you can access it, you need to set the time to:
2022-11-17T00:00:00.000000000+08:00[Asia/Shanghai]

After restarting 9999, if you go to visit again, you will find that the request will report an error before the set time:

Two parameters need to be specified, namely name and regexp (regular expression), and Key and Value can also be understood. Matches a cookie with the given name whose value matches the regular expression. A simple understanding is that the routing rules will match by obtaining the cookie name value and the regular expression. If it matches, the routing will be executed, and if it does not match, it will not be executed.

Set the matching rules for cookies:

Use Postman to add a cookie that meets the rules when requesting:

Then the result of the request is normal:

But if using a non-compliant cookie:

The result of the request will directly report an error:

Two parameters header and regexp (regular expression), which can also be understood as Key and Value, are required to match the information carried by the request. In fact, it is the information carried in the request header. The case given by the official website is X-Request-Id, so use this as an experiment.

Set Header assertion rules:

Use Postman to add a Header that conforms to the rules when requesting, then the result of the request is normal:

Use Postman to add a Header that does not conform to the rules when requesting, then the result of the request will directly report an error:

Host

Matches whether the current request comes from the set host.

Set Host assertion rules:

Use Postman to add a host that meets the rules when requesting, then the result of the request is normal:

Use Postman to add a host that does not conform to the rules when requesting, then the result of the request will directly report an error:

Method

One or more parameters can be set to match HTTP requests, such as GET, POST, etc.

Set Host assertion rules:

Use Postman to add a method that meets the rules when requesting, then the result of the request is normal:

Use Postman to add a method that does not conform to the rules when requesting, then the result of the request will directly report an error:

Query

One or more parameters need to be specified, a required parameter and an optional regular expression. Whether the first parameter is included in the matching request. If there are two parameters, whether the value of the first parameter in the matching request matches the regular expression.

Set Query assertion rules:

Use Postman to add a Query that conforms to the rules when requesting, then the result of the request is normal:

Use Postman to add a Query that does not conform to the rules when requesting, then the result of the request will directly report an error:

Weight

Two parameters group and weight (int) are required to implement the route weight function, and select routes in the same group according to the route weight.

Set the Weight assertion rule:

This route forwards about 80% of traffic to weighthigh.org and about 20% to weightlow.org.

5. GateWay filter

Route filters allow to modify incoming HTTP requests or outgoing HTTP responses in some way. Route filters are scoped to specific routes, and Spring Cloud Gateway includes a number of built-in GatewayFilter factories.

GateWay has many built-in filters:
1. There are two types of filter life cycles built in GateWay: pre (before business logic), post (after business logic)
; GlobalFilter (global);
3. There are 32 single filters and 9 global filters;

In fact, these filters that come with GateWay are basically rarely used. Take StripPrefix as an example: StripPrefix has a parameter: parts. The parts parameter indicates the number of parts in the path to strip from the request before sending it downstream.

Add a context-path configuration to the 9001 service:

Then when requesting the interface of 9001, you need to bring /nacos-provider in the URL:

Then, according to the original routes configured in 9999, the interface in 9001 cannot be accessed. At this time, a filter must be used to solve the problem: