1. What is springcloud gateway?
Spring Cloud Gateway aims to provide a simple, effective, and unified API routing management method for microservice architecture.
As a gateway in the Spring Cloud ecosystem, Spring Cloud Gateway not only provides a unified routing method, but also provides basic gateway functions, such as security, monitoring / buying points, and current limiting, based on the Filter chain.
Spring Cloud Gateway depends on Spring Boot and Spring WebFlux and runs on Netty. It cannot work in a traditional servlet container, nor can it be built into a war package.
There are several core concepts in Spring Cloud Gateway that we need to understand:
1）Route
Route is the basic element of the gateway, which is composed of ID, target URI, assertion, and filter. When the request reaches the gateway, Gateway Handler Mapping performs route matching through the assertion. When the assertion is true, the route is matched.
2）Predicate
Predicate is a function provided in Java 8. The input type is Spring Framework ServerWebExchange. It allows developers to match requests from HTTP, such as request headers or request parameters. Simply put, it is the matching condition.
3）Filter
Filter is a filter in Gateway, and can perform some business processing before and after the request is issued.
How Spring Cloud Gateway works
The client of Gateway sends a request back to Spring Cloud Gateway. The request is first extracted by HttpWebHandlerAdapter and assembled into the context of the gateway, and then the context of the gateway is passed to the DispatcherHandler. DispatcherHandler is the dispatch processor for all requests. DispatcherHandler is mainly responsible for dispatching the processor corresponding to the request, such as dispatching the request to the corresponding RoutePredicateHandlerMapping (route assertion processor mapper). The route assertion processing mapper is mainly used to find the route and return the corresponding FilteringWebHandler after finding the route. FilteringWebHandler is mainly responsible for assembling the Filter linked list and calling Filter to perform a series of Filter processing, and then transfers the request to the corresponding proxy service processing on the back end. After processing, the Response is returned to the Gateway client.
In the Filter chain, the reason for dividing the Filter by the dotted line is that the filter can be processed before forwarding the request or after receiving the return result of the proxy service. After all Pre-type filters are executed, the request will be forwarded to the proxied service for processing. After the proxy service completes all requests, the Post-type filter will be executed.
Excerpt from the blog "Redefined Spring Cloud combat".
SpringCloud Gateway features
SpringCloud official, introduced the characteristics of SpringCloud Gateway as follows:
(1) Based on Spring Framework 5, Project Reactor and Spring Boot 2.0
(2) Integrated Hystrix circuit breaker
（3）集成 Spring Cloud DiscoveryClient
(4) Predicates and Filters act on specific routes, easy to write Predicates and Filters
(5) With some advanced functions of 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 is still in the underlying communication framework.
Briefly explain the three terms above:
( . 1 ) the Filter (filter) :
Similar to Zuul's filter in concept, you can use it 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.
(2) Route :
The basic component 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 will be accessed.
( 3 ) Predicate (assertion) :
This is a Java 8 Predicate that can be used to match anything from HTTP requests, such as headers or parameters. The input type of the assertion is a ServerWebExchange.
SpringCloud Gateway and architecture
Spring ushered in Webflux in the second half of 2017. The emergence of Webflux filled Spring's gap in reactive programming. Webflux's reactive programming is not only a change in programming style, but also provides a response to a series of well-known frameworks. Development kits, such as Netty, Redis, etc.
The Reactor-netty responsive programming component in Webflux used by SpringCloud Gateway uses the Netty communication framework at the bottom.
- IO model of SpringCloud Zuul
The Zuul version integrated in Springcloud uses a Tomcat container and uses the traditional Servlet IO processing model.
As you know, servlets are managed by the servlet container for lifecycle. When the container starts, construct a servlet object and call servlet init () to initialize; when the container is closed, call servlet destory () to destroy the servlet; when the container is running, accept the request and assign a thread to each request (generally get idle threads from the thread pool) Then call service ().
Disadvantages: servlet is a simple network IO model, when the request enters the servlet container, the servlet container will bind a thread for it, this model is applicable in the scenario of low concurrency, but once the concurrency rises, the number of threads It will rise, and the cost of thread resources is expensive (online text switching, large memory consumption) seriously affects the processing time of the request. In some simple business scenarios, you do not want to assign a thread to each request. Only one or a few threads are required to handle extremely concurrent requests. In this business scenario, the servlet model has no advantage.
Therefore, Springcloud Zuul is a blocking processing model based on servlet, that is, spring implements a servlet (DispatcherServlet) that processes all request requests, and the servlet blocks processing. So Springcloud Zuul cannot get rid of the shortcomings of the servlet model. Although Zuul 2.0 started, Netty was used, and there are mature cases of large-scale Zuul 2.0 cluster deployment, however, the Springcloud official has no plan to integrate and change the version.
1.3.2 Webflux model
Webflux mode replaces the old Servlet threading model. A small number of threads are used to process request and response io operations. These threads are called Loop threads, and the business is handed over to the responsive programming framework. The responsive programming is very flexible. Users can submit the operations blocked in the business to the responsive framework Operations performed in the work thread without blocking can still be processed in the Loop thread, greatly improving the utilization rate of the Loop thread. Official structure drawing:
Although Webflux can be compatible with multiple low-level communication frameworks, under normal circumstances, the bottom layer still uses Netty. After all, Netty is the highest performance communication framework recognized by the industry. The Webflux Loop thread happens to be the Reactor thread of the famous Reactor mode IO processing model. If you use the high-performance communication framework Netty, this is Netty's EventLoop thread.
Knowledge about the Reactor threading model and the Netty communication framework is an important and necessary internal skill for Java programmers. For the principle, please refer to the book "Netty, Zookeeper, Redis High Concurrency in Action" edited by Nion, here Do not repeat too much.
The processing flow of Spring Cloud Gateway
The client makes a request to Spring Cloud Gateway. Then find the route that matches the request in the Gateway Handler Mapping and send it to the Gateway Web Handler. Handler then sends the request to our actual service through the specified filter chain to execute the business logic, and then returns. The dotted line between the filters is because the filter may execute business logic before ("pre") or after ("post") the proxy request is sent.
Spring Cloud Gateway routing configuration
Basic URI a routing configuration method
spring:
application:
name: cloud-gateway
cloud:
gateway:
discovery:
locator:
enabled: true
#Turn on the function of dynamically creating routes from the registration center, using microservice names for routing
routes: -id: payment_routh #payment_route #Routing ID, There is no fixed rule but the requirement is unique. It is recommended to cooperate with the service name
uri: http: // localhost: 8001 #The routing address of the service after matching
predicates:
-Path = / payment / get / ** # Assert that the path matches the route
Code-based routing configuration
/** * 编程式路由 * @author L * */ @Configuration public class GateWayConfig { @Bean public RouteLocator customRouteLocator(RouteLocatorBuilder routeLocatorBuilder) { RouteLocatorBuilder.Builder routes = routeLocatorBuilder.routes(); routes.route("path_route_atguigu", r -> r.path("/guonei") .uri("http://news.baidu.com/guonei")).build(); return routes.build(); } }
Routing configuration method combined with registration center
The schema protocol part of uri is a customized lb: type, which means that the service is subscribed from the microservice registration center (such as Eureka) and the service is routed.
A typical example is as follows:
spring:
application:
name: cloud-gateway
cloud:
gateway:
discovery:
locator:
enabled: true
#Turn on the function of dynamically creating routes from the registration center, using microservice names for routing
routes: -id: payment_routh #payment_route #Routing ID, There is no fixed rule, but the requirement is unique. It is recommended to cooperate with the service name
#uri: http: // localhost: 8001 #The routing address of the service after matching
uri: lb: // cloud-payment-service #The routing address of the service after matching
predicates:
-Path = / payment / get / ** # Assertion, routing with matching path
The routing configuration method combined with the registration center has a very small difference from the routing configuration of a single URI, only that the scheme protocol of the URI is different. The schema protocol of a single URI address is generally http or https protocol.
Detailed explanation: SpringCloud Gateway matching rules
The function of Spring Cloud Gateway is very powerful, we can see from the design of Predicates only. In the front, we only used Predicates for simple condition matching. In fact, Spring Cloud Gataway helps us to build a lot of Predicates function.
Spring Cloud Gateway uses Spring WebFlux's HandlerMapping as the underlying support to match forwarding routes. Spring Cloud Gateway has many built-in Predicates factories. These Predicates factories are matched by different HTTP request parameters. Multiple Predicates factories can be used in combination.
Introduction to Predicate
Predicate comes from Java 8 and is a function introduced in Java 8. Predicate accepts an input parameter and returns a boolean result. This interface contains multiple default methods to group Predicate into other complex logic (such as: AND, OR, NOT). It can be used for interface request parameter verification and judging whether there is a change in new or old data that needs to be updated.
In Spring Cloud Gateway, Spring uses the characteristics of Predicate to implement various routing matching rules. There are different conditions such as headers and request parameters to match the corresponding routes as conditions. There is a picture on the Internet summarizing the implementation of several Predicate built in Spring Cloud.
[
Frankly speaking, Predicate is to implement a set of matching rules to facilitate the request to find the corresponding Route for processing. Next, we take over the use of several built-in Predicate in Spring Cloud GateWay.
By request parameter matching, the request parameter is in the above picture, just change the attribute
spring: cloud: gateway: routes: - id: method_route uri: http://www.google.com predicates: - Method=GET
GatewayFilter Factory Introduction
Route filters can modify the input and output of HTTP requests in some ways. For some special scenarios, Spring Cloud Gateway has built-in GatewayFilter Factories with many different functions.
The following will explain these GatewayFilter Factories one by one through examples.
1. AddRequestHeader GatewayFilter Factory
AddRequestHeader GatewayFilter Factory can increase the request header by configuring the name and value
spring:
application:
name: cloud-gateway
cloud:
gateway:
discovery:
locator:
enabled: true
#Turn on the function of dynamically creating routes from the registration center, using microservice names for routing
routes: -id: payment_routh #payment_route #Routing ID, There is no fixed rule, but the requirement is unique. It is recommended to cooperate with the service name
#uri: http: // localhost: 8001 #The routing address of the service after matching
uri: lb: // cloud-payment-service #The routing address of the service after matching
predicates:
-Path = / payment / get / ** # Assertion, route matching routing
filters:
-AddRequestHeader = foo, aaa
-AddRequestParameter = foo, bbbccc
-name: Hystrix # Hystrix Filter name, set to default
args: # Hystrix configuration parameter
name: fallbackcmd # HystrixCommand name
fallbackUri: forward: / fallbackA # fallback pair of uri
2. HttpServletRequest.getHeader ("foo"); get the corresponding value in the multi-service microservice
Custom filter : need to implement GlobalFilter, Ordered interface
@Component
@Slf4j
public class MyLogGateWayFilter implements GlobalFilter,Ordered
{
@Override
public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain)
{
log.info("***********come in MyLogGateWayFilter: "+new Date());
String uname = exchange.getRequest().getQueryParams().getFirst("uname");
if(uname == null)
{
log.info("*******用户名为null");
exchange.getResponse().setStatusCode(HttpStatus.NOT_ACCEPTABLE);
return exchange.getResponse().setComplete();
}
return chain.filter(exchange);
}
@Override
public int getOrder()
{
return 0;
}
}
Fuse degradation
Why should fuse degradation be achieved?
In a distributed system, the gateway serves as the entrance to traffic, so a large number of requests enter the gateway and initiate calls to other services. Inevitably, other services will have call failures (timeouts, exceptions). When they fail, the requests cannot be accumulated in the gateway It needs to fail quickly and return to the client. If you want to achieve this requirement, you must do fuse and downgrade operations on the gateway.
Why does the request fail on the gateway need to be quickly returned to the client?
Because when a client request fails, this request will always accumulate on the gateway. Of course there is only one such request, and the gateway must be no problem (if a request can cause the entire system to be paralyzed, then the system can be taken down) However, excessive accumulation on the gateway will cause tremendous pressure on the gateway and the entire service, and even the entire service will fail. Therefore, some services and pages must be strategically downgraded to alleviate the pressure on server resources to ensure the normal operation of the core business, and at the same time maintain the correct correspondence between customers and most customers, so they need to request on the gateway Failure needs to be quickly returned to the client.
File configuration:
spring:
application:
name: cloud-gateway
cloud:
gateway:
discovery:
locator:
enabled: true
#Turn on the function of dynamically creating routes from the registration center, using microservice names for routing
routes: -id: payment_routh #payment_route #Routing ID, There is no fixed rule, but the requirement is unique. It is recommended to cooperate with the service name
#uri: http: // localhost: 8001 #The routing address of the service after matching
uri: lb: // cloud-payment-service #The routing address of the service after matching
predicates:
-Path = / payment / get / ** # Assertion, route matching routing
filters:
-AddRequestHeader = foo, yinjihuan
args: # Hystrix configuration parameters
-AddRequestParameter = foo, yinjihuanAddRequestParameter
: Hystrix # Hystrix Filter name, set to the default
name: fallbackcmd # HystrixCommand name
fallbackUri: forward: / fallbackA # fallback pair uri
# Hystrix configuration
hystrix:
fallbackcmd:
execution:
isolation:
thread:
timeoutInMilliseconds: 1000 # Hystrix's fallbackcmd time
Fused fallbackA
@RestController
public class FallbackController {
@GetMapping ("/ fallbackA")
public CommonResult fallbackA () {
return new CommonResult (100, "service temporarily unavailable");
}
}
Filter Hystrix, the function is to fuse downgrade through Hystrix
When the upstream request enters the Hystrix fuse downgrade mechanism, it will call the downgrade address configured by fallbackUri. It should be noted that the timeout period of Hystrix's commandKey also needs to be set separately