Shulou(Shulou.com)06/03 Report--

This article mainly introduces "summing up Spring Cloud Gateway-related knowledge points". In daily operation, I believe many people have doubts about summarizing Spring Cloud Gateway-related knowledge points. The editor consulted all kinds of materials and sorted out simple and easy-to-use operation methods. I hope it will be helpful for you to answer the doubts about "summing up Spring Cloud Gateway-related knowledge points". Next, please follow the editor to study!

What is Spring Cloud Gateway?

SpringCloud Gateway is a new project of SpringCloud, which is a gateway based on Spring 5.0, Spring Boot 2.0 and Project Reactor technologies. It aims to provide a simple and effective unified API route management method for micro-service architecture.

In order to improve the performance of the gateway, SpringCloud Gateway is implemented based on the WebFlux framework, while the bottom layer of the WebFlux framework uses the high-performance Reactor mode communication framework Netty.

Spring Cloud Gateway aims to provide a simple and efficient way to send API and provide them with crosscutting concerns such as security, monitoring / metrics, and resilience.

Core concepts of Spring Cloud Gateway

Route (routing): this is the basic building block of the gateway. It 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 destination URI is accessed.

Predicate (assertion): this is a Java 8 Predicate. The input type is a ServerWebExchange. We can use it to match anything from the HTTP request, such as headers or parameters.

Filter (filter): this is an instance of org.springframework.cloud.gateway.filter.GatewayFilter that we can use to intercept and modify requests and reprocess the response above.

Spring Cloud Gateway characteristics

Built on Spring Framework 5, Project Reactor and Spring Boot 2.0

Ability to match routes on any request attribute

Predicates (predicate) and filters (filter) are route specific

Integrated with Hystrix circuit breaker

Integrated with Spring Cloud DiscoveryClient

Easy to write predicates and filters

Request rate limit

Path rewriting

The workflow of Spring Cloud Gateway

The client sends a request to the Gateway.

The route matching the request is then found in Gateway Handler Mapping and sent to Gateway Web Handler.

Handler then sends the request to our actual service to execute the business logic through the specified filter chain, and finally returns the request result.

Filters are separated by dotted lines because the filter may perform business logic before or after sending the proxy request.

Filter can do parameter verification, permission verification, traffic monitoring, log output, protocol conversion and so on before the request. After the request, you can modify the response content, response header, log output, traffic monitoring, and so on.

Interpretation of Spring Cloud Gateway routing configuration based on Spring Cloud Gateway Core knowledge

1. Based on URI routing configuration

Server: port: 8080 spring: application: name: api-gateway cloud: gateway: routes:-id: url-api-gateway uri: https://www.baidu.com predicates:-Path=/toBaidu

The meanings of each configuration field are as follows:

Id: our custom routing ID, which remains unique

Uri: destination service address

Predicates: routing condition. Predicate accepts an input parameter and returns a Boolean result. This interface contains a variety of default methods to combine Predicate into other complex logic (such as and, or, not).

The above configuration means that a URI proxy rule with id as url-api-gateway is configured, and the routing rule is: when the address http://localhost:8080/toBaidu is accessed, it will be routed to the upstream address https://www.baidu.com.

two。 Code-based routing configuration

Package com.superhero;import com.bstek.ureport.console.UReportServlet;import org.springframework.boot.SpringApplication;import org.springframework.boot.autoconfigure.SpringBootApplication;import org.springframework.boot.autoconfigure.jdbc.DataSourceAutoConfiguration;import org.springframework.boot.web.servlet.ServletRegistrationBean;import org.springframework.context.annotation.Bean;import org.springframework.context.annotation.ImportResource;import javax.servlet.Servlet / * launcher * @ author superhero * / @ SpringBootApplication (exclude = {DataSourceAutoConfiguration.class}) @ ImportResource ("classpath:context.xml") public class SuperHeroApplication {public static void main (String [] args) {/ / System.setProperty ("spring.devtools.restart.enabled", "false"); SpringApplication.run (SuperHeroApplication.class, args) } @ Bean public RouteLocator customRouteLocator (RouteLocatorBuilder builder) {return builder.routes () .route ("url-api-gateway", r-> r.path ("/ toBaidu") .uri ("https://www.baidu.com")) .build ();}})

First of all, we annotate the configuration information of the relevant routes just added in the configuration file, then restart the service, visit the link: http://localhost:8080/ toBaidu, and you can see the same page as above, which proves that our test is successful.

In the above two examples, uri points to the home page of my Baidu. In actual project use, you can point uri to the address of the project that provides services, and unify the output API.

The above two routing forwarding examples are the easiest to use of Spring Cloud Gateway. More advanced features and core knowledge are available. I will explain them step by step.

How to realize cross-domain access to Spring Cloud Gateway

What is cross-domain will not be explained here, here we mainly implement Spring Cloud Gateway cross-domain access.

Spring Cloud Gateway is also designed for cross-domain access, and the following configurations can be used to solve cross-domain access problems.

When the service is started, the cross-domain configuration information is stored in the corsConfigurations map of GlobalCorsProperties. Key is / * * and value is the object of CorsConfiguration. The above configuration indicates that Get requests from https://docs.spring.io are allowed to access this gateway, and that the server allows the field Content-Type in the request header.

Detailed explanation of Spring Cloud Gateway filter

Spring Cloud Gateway has only two filter lifecycles: "pre" and "post".

Pre: called before the request is routed. You can use this filter to authenticate, select the requested micro-service in the cluster, and record debugging information.

Post: executed after routing to the server. This filter can be used to add HTTP Header, statistics and metrics to the response, send the response from the microservice to the client, and so on.

There are two kinds of filter for Spring Cloud gateway: GatewayFilter and Globalfilter.

GlobalFilter will be applied to all routes, while Gatewayfilter will be applied to a single route or a packet route.

Using Gatewayfilter, you can modify the request or response of the requested http, or make some special restrictions based on the request or response.

More often, we can use Gatewayfilter to do some specific routing configuration.

Gateway filter GatewayFilter

GatewayFilter gateway filter is used to intercept and chain process web requests, and can achieve crosscutting requirements that have nothing to do with the application, such as security, access timeout settings and so on.

Let's take a look at GatewayFilter's class diagram first.

As you can see from the class diagram, GatewayFilter has four implementation classes, and we introduce that two of the important ones is OrderedGatewayFilter, which is an ordered gateway filter. There is also a GatewayFilterAdapter, which is an adapter class and is an inner class in the web processor (FilteringWebHandler).

The GatewayFilter source code is as follows

/ * Gateway route filter, * Contract for interception-style, chained processing of Web requests that may * be used to implement cross-cutting, application-agnostic requirements such * as security, timeouts, and others. Specific to a Gateway * * Copied from WebFilter * * @ author Rossen Stoyanchev * @ since 5.0* / public interface GatewayFilter extends ShortcutConfigurable {String NAME_KEY = "name"; String VALUE_KEY = "value"; / * * filter execution method * Process the Web request and (optionally) delegate to the next * {@ code WebFilter} through the given {@ link GatewayFilterChain}. * @ param exchange the current server exchange * @ param chain provides a way to delegate to the next filter * @ return {@ code Mono} to indicate when request processing is complete * / Mono filter (ServerWebExchange exchange, GatewayFilterChain chain);}

In the gateway filter interface GatewayFilter source code, there is one and only one method filter, which executes the current filter and determines whether the filter list continues to be executed in this method.

Orderly gateway filter OrderedGatewayFilter

/ * sorted gateway route filter, which is used to wrap the real gateway filter. The filter can sort * * @ author Spencer Gibb * / public class OrderedGatewayFilter implements GatewayFilter, Ordered {/ / target filter private final GatewayFilter delegate; / / sort field private final int order; public OrderedGatewayFilter (GatewayFilter delegate, int order) {this.delegate = delegate; this.order = order @ Override public Mono filter (ServerWebExchange exchange, GatewayFilterChain chain) {return this.delegate.filter (exchange, chain);}}

The OrderedGatewayFilter implementation class is the wrapper class for the target filter, and its main purpose is to wrap the target filter into a sortable object type.

Most filters are prioritized, so there are many scenarios where orderly gateway filters are used. While implementing the filter interface, the ordered gateway filter also implements the Ordered interface. Pass the gateway filter and priority that need to be proxied in the constructor to construct an ordered gateway filter.

The implementation of the specific filtering function is implemented in the filter of the proxy, so only the filter of the proxy needs to be called here.

Adapter class GatewayFilterAdapter

/ * the wrapper class of the global filter that wraps the global route as a unified gateway filter * / private static class GatewayFilterAdapter implements GatewayFilter {/ * Global filter * / private final GlobalFilter delegate; public GatewayFilterAdapter (GlobalFilter delegate) {this.delegate = delegate;} @ Override public Mono filter (ServerWebExchange exchange, GatewayFilterChain chain) {return this.delegate.filter (exchange, chain);}}

GatewayFilter is used in the gateway filter chain GatewayFilterChain to filter requests, and the role of GatewayFilterAdapter is to adapt the global filter GlobalFilter to the gateway filter GatewayFilter.

Global filter Globalfilter

What is a global filter? in a simple sentence, a global filter acts on a global route.

The GlobalGilter global filter interface has the same method definition as the GatewayFilter gateway filter interface.

Global filters are a series of special filters that are applied to all routes based on conditions. Gateway filters are finer-grained filters that act on specified routes.

The class diagram of Globalfilter is as follows

We can see from the class diagram that there are eleven implementation classes in GlobalGilter. We introduce GlobalGilter from these eleven implementation classes to give you a detailed description of what GlobalGilter is.

First, let's take a look at the Globalfilter source code.

Public interface GlobalFilter {/ * Process the Web request and (optionally) delegate to the next* {@ code WebFilter} through the given {@ link GatewayFilterChain}. * @ param exchange the current server exchange* @ param chain provides a way to delegate to the next filter* @ return {@ code Mono} to indicate when request processing is complete*/Mono filter (ServerWebExchange exchange, GatewayFilterChain chain);}

We see that the GlobalGilter interface has a filter method, and GlobalGilter has eleven implementation classes that implement filtering by overriding the filter method.

So we can mainly understand the logic of the filter methods overridden by these eleven classes.

Next, we will introduce these eleven implementation classes in turn.

1. ForwardRoutingFilter forwarding route filter

ForwardRoutingFilter looks for URL in the exchange attribute ServerWebExchangeUtils.GATEWAY_ REQUEST_ URL_ ATTR, and if URL is in forwarding mode, that is, forward:/// localendpoint, it will use Spring DispatcherHandler to process the request. The unmodified original URL is saved to the list of GATEWAY_ ORIGINAL_ REQUEST_ URL_ ATTR properties.

Public class ForwardRoutingFilter implements GlobalFilter, Ordered {private static final Log log = LogFactory.getLog (ForwardRoutingFilter.class); private final ObjectProvider dispatcherHandler; public ForwardRoutingFilter (ObjectProvider dispatcherHandler) {this.dispatcherHandler = dispatcherHandler;} @ Override public int getOrder () {return Ordered.LOWEST_PRECEDENCE;} @ Override public Mono filter (ServerWebExchange exchange, GatewayFilterChain chain) {URI requestUrl = exchange.getRequiredAttribute (GATEWAY_REQUEST_URL_ATTR) / / get the request structure of the request URI String scheme = requestUrl.getScheme (); / / if the route has been processed or the URI format is not forward, continue with other filters if (isAlreadyRouted (exchange) |! "forward" .equals (scheme)) {return chain.filter (exchange);} setAlreadyRouted (exchange); / / TODO: translate url? If (log.isTraceEnabled ()) {log.trace ("Forwarding to URI:" + requestUrl);} / / use dispatcherHandler to process return this.dispatcherHandler.getIfAvailable () .handle (exchange);}}

The forwarding route filter is relatively simple to implement, and the constructor passes in the requested distribution processor DispatcherHandler.

When the filter is executed, first get the url prefix of the request address, and then determine whether the request has been routed or whether the prefix of the URL is not forward, then continue to execute the filter chain

Otherwise, set the routing processing status and leave it to DispatcherHandler for processing.

The judgment of whether the request route is processed is as follows:

/ / ServerWebExchangeUtils.javapublic static void setAlreadyRouted (ServerWebExchange exchange) {exchange.getAttributes () .put (GATEWAY_ALREADY_ROUTED_ATTR,true);} public static boolean isAlreadyRouted (ServerWebExchange exchange) {return exchange.getAttributeOrDefault (GATEWAY_ALREADY_ROUTED_ATTR,false);}

Two methods are defined in ServerWebExchangeUtils and are used to modify and query Map in ServerWebExchange

< String， Object>

The getAttributes (), # getAttributes method returns the variable mapping of the attribute requested by the current exchange.

These two methods are defined in ServerWebExchangeUtils and are used to modify and query GATEWAY_ALREADY_ROUTED_ATTR state, respectively.

2. LoadBalancerClientFilter load balancing client filter

Spring: cloud: gateway: routes:-id: myRoute uri: lb://service predicates:-Path=/service/**

LoadBalancerClientFilter looks for URL in the exchange attribute GATEWAY_ REQUEST_ URL_ ATTR, and if URL has a lb prefix, lb:// myservice, it uses LoadBalancerClient to resolve the name to the actual host and port, such as myservice in the example.

The unmodified original URL is saved to the list of GATEWAY_ ORIGINAL_ REQUEST_ URL_ ATTR properties.

The filter also looks at the ServerWebExchangeUtils.GATEWAY_SCHEME_PREFIX_ATTR property to see if it equals lb, and then applies the same rule.

@ Overridepublic Mono filter (ServerWebExchange exchange,GatewayFilterChain chain) {URI url=exchange.getAttribute (GATEWAY_REQUEST_URL_ATTR); String schemePrefix=exchange.getAttribute (GATEWAY_SCHEME_PREFIX_ATTR); if (url==null | | (! "lb" .equals (url.getScheme ()) & &! "lb" .equals (schemePrefix)) {return chain.filter (exchange);} / / keep the original url addOriginalRequestUrl (exchange,url); log.trace ("LoadBalancerClientFilter url before:" + url) / / load balancing to a specific service instance final ServiceInstance instance=choose (exchange); if (instance==null) {throw new NotFoundException ("Unable to find instance for" + url.getHost ());} URI uri=exchange.getRequest () .getURI (); / / if no prefix is provided, the default'

< scheme>

', otherwise use' lb:

< scheme>

'The mechanism. String overrideScheme=null; if (schemePrefixtures invalid null) {overrideScheme=url.getScheme ();} / reassemble the requested url URI requestUrl=loadBalancer.reconstructURI (new DelegatingServiceInstance (instance,overrideScheme), uri) based on the obtained service instance information; / / Routing-related GatewayFilter initiates the request through the GATEWAY_ REQUEST_ URL_ ATTR attribute. Log.trace ("LoadBalancerClientFilter url chosen:" + requestUrl); exchange.getAttributes () .put (GATEWAY_REQUEST_URL_ATTR,requestUrl); return chain.filter (exchange);}

As can be seen from the filter execution method, the implementation steps of the load balancer client filter are as follows:

1. The constructor is passed to the load balancer client, and the Bean can be injected by adding Spring Cloud Netflix Ribbon to the dependency.

2. Get the requested URL and its prefix. If the URL is not empty and the prefix is lb or the prefix of the gateway request is lb, save the original URL, load it to the specific service instance, and reassemble the requested URL according to the obtained service instance information.

3. Finally, add the requested URL to the GATEWAY_ REQUEST_ URL_ ATTR and submit it to the filter chain to continue execution

When assembling the requested address, if loadbalancer does not provide a prefix, the default is used, that is, overrideScheme is null, otherwise lb is used:

3. NettyRoutingFilter and NettyWriteResponseFilter

If the URL in the ServerWebExchangeUtils.GATEWAY_ REQUEST_ URL_ ATTR request attribute has a http or https prefix, the NettyRoutingFilter route filter runs, which uses the Netty HttpClient agent for downstream requests.

The response information is placed in the ServerWebExchangeUtils.CLIENT_ RESPONSE_ ATTR property and passed in the filter chain.

The actual processing of the filter and the implementation of client-side load balancing are similar to ↓.

First, get the URL and prefix of the request to determine whether the prefix is http or https. If the request has been routed or the prefix is invalid, the filter chain will be passed back directly; otherwise, the header will be filtered normally.

Public class NettyRoutingFilter implements GlobalFilter, Ordered {private final HttpClient httpClient; private final ObjectProvider headersFilters; private final HttpClientProperties properties; public NettyRoutingFilter (HttpClient httpClient, ObjectProvider headersFilters, HttpClientProperties properties) {this.httpClient = httpClient; this.headersFilters = headersFilters; this.properties = properties;} @ Override public int getOrder () {return Ordered.LOWEST_PRECEDENCE } @ Override public Mono filter (ServerWebExchange exchange, GatewayFilterChain chain) {URI requestUrl = exchange.getRequiredAttribute (GATEWAY_REQUEST_URL_ATTR); String scheme = requestUrl.getScheme (); if (isAlreadyRouted (exchange) | | (! "http" .equals (scheme) & &! "https" .equals (scheme)) {return chain.filter (exchange);} setAlreadyRouted (exchange); ServerHttpRequest request = exchange.getRequest () Final HttpMethod method = HttpMethod.valueOf (request.getMethod (). ToString ()); final String url = requestUrl.toString (); HttpHeaders filtered = filterRequest (this.headersFilters.getIfAvailable (), exchange); final DefaultHttpHeaders httpHeaders = new DefaultHttpHeaders (); filtered.forEach (httpHeaders::set); String transferEncoding = request.getHeaders (). GetFirst (HttpHeaders.TRANSFER_ENCODING); boolean chunkedTransfer = "chunked" .equals IgnoreCase (transferEncoding) Boolean preserveHost = exchange.getAttributeOrDefault (PRESERVE_HOST_HEADER_ATTRIBUTE, false); Mono responseMono = this.httpClient.request (method, url, req-> {final HttpClientRequest proxyRequest = req.options (NettyPipeline.SendOptions::flushOnEach) .headers (httpHeaders) .chunkedTransfer (chunkedTransfer) .failOnServerError (false) .failOnClientErro r (false) If (preserveHost) {String host = request.getHeaders () .getFirst (HttpHeaders.HOST); proxyRequest.header (HttpHeaders.HOST, host) } if (properties.getResponseTimeout ()! = null) {proxyRequest.context (ctx-> ctx.addHandlerFirst (new ReadTimeoutHandler (properties.getResponseTimeout (). ToMillis (), TimeUnit.MILLISECONDS) } return proxyRequest.sendHeaders () / / I shouldn't need this .send (request.getBody () .map (dataBuffer-> ((NettyDataBuffer) dataBuffer). GetNativeBuffer ());}); return responseMono.doOnNext (res-> {ServerHttpResponse response = exchange.getResponse ()) / / put headers and status so filters can modify the response HttpHeaders headers = new HttpHeaders (); res.responseHeaders () .forEach (entry-> headers.add (entry.getKey (), entry.getValue (); String contentTypeValue = headers.getFirst (HttpHeaders.CONTENT_TYPE); if (StringUtils.hasLength (contentTypeValue)) {exchange.getAttributes () .put (ORIGINAL_RESPONSE_CONTENT_TYPE_ATTR, contentTypeValue) } HttpHeaders filteredResponseHeaders = HttpHeadersFilter.filter (this.headersFilters.getIfAvailable (), headers, exchange, Type.RESPONSE); response.getHeaders () .putAll (filteredResponseHeaders); HttpStatus status = HttpStatus.resolve (res.status (). Code ()); if (status! = null) {response.setStatusCode (status) } else if (response instanceof AbstractServerHttpResponse) {/ / https://jira.spring.io/browse/SPR-16748 ((AbstractServerHttpResponse) response) .setStatusCodeValue (res.status (). Code ());} else {throw new IllegalStateException ("Unable to set status code on response:" + res.status (). Code () + "," + response.getClass ()) } / / Defer committing the response until all route filters have run / / Put client response as ServerWebExchange attribute and write response later NettyWriteResponseFilter exchange.getAttributes () .put (CLIENT_RESPONSE_ATTR, res) ) .onErrorMap (t-> properties.getResponseTimeout ()! = null & & t instanceof ReadTimeoutException, t-> new TimeoutException ("Response took longer than timeout:" + properties.getResponseTimeout ()). Then (chain.filter (exchange));}}

The constructor of the NettyRoutingFilter filter takes three arguments, ↓

HttpClient httpClient: HttpClient implemented based on Netty, through which the back-end Http service is requested.

HeadersFilters of type ObjectProvider headersFilters:ObjectProvider, used for header filtering

Configuration properties of HttpClientProperties properties:Netty HttpClient

4. NettyRoutingFilter # # HttpHeadersFilter header filter API

FilterRequest is used to process the information of the request header. It is the default method defined in the API HttpHeadersFilter. The API has three implementation classes. The request header will pass through these three header filters, and finally return the modified header.

Public interface HttpHeadersFilter {enum Type {REQUEST, RESPONSE} / * Filters a set of HttpHeaders * * @ param input HttpHeaders * @ return filtered HttpHeaders * / HttpHeaders filter (HttpHeaders input, ServerWebExchange exchange); static HttpHeaders filterRequest (List filters, ServerWebExchange exchange) {HttpHeaders headers = exchange.getRequest () .getHeaders () Return filter (filters, headers, exchange, Type.REQUEST);} static HttpHeaders filter (List filters, HttpHeaders input, ServerWebExchange exchange, Type type) {HttpHeaders response = input If (filters! = null) {HttpHeaders reduce = filters.stream () .filter (headersFilter-> headersFilter.supports (type)) .reduce (input, (headers, filter)-> filter.filter (headers, exchange), (httpHeaders HttpHeaders2)-> {httpHeaders.addAll (httpHeaders2) Return httpHeaders;}); return reduce;} return response;} default boolean supports (Type type) {return type.equals (Type.REQUEST);}}

Three implementation classes ↓ of HttpHeadersFilter interface

ForwardedHeadersFilter: add Forwarded header. The header values are protocol type, host and destination address.

XForwardedHeadersFilter: add X-Forwarded- For, X-Forwarded- Host, X-Forwarded- Port and X-Forwarded- Proto headers. When forwarded by the agent, the custom header information is passed downstream.

RemoveHopByHopHeadersFilter: to define the behavior of cached and non-cached proxies, we divide HTTP header fields into two categories: end-to-end header fields that are sent to the final recipient of the request or response, and hop-by-hop header fields that are meaningful for a single transport-level connection and are not cached or forwarded by the proxy.

So the header filter removes the hop-by-hop header field, including the following 8 fields:

Proxy- Authenticate

Proxy- Authorization

TE

Trailer

Transfer- Encoding

Upgrade

Proxy- connection

Content- length

5 、 NettyWriteResponseFilter

NettyWriteResponseFilter is used in pairs with NettyRoutingFilter. There is nothing in the "pre" filtering phase because CLIENT_ RESPONSE_ ATTR is not added until WebHandler is run.

@ Overridepublic Mono filter (ServerWebExchange exchange,GatewayFilterChain chain) {/ / NOTICE: nothing in "pre" filter stage as CLIENT_RESPONSE_ATTR is not added / / until the WebHandler is run return chain.filter (exchange) .then (Mono.defer (()-> {HttpClientResponse clientResponse=exchange.getAttribute (CLIENT_RESPONSE_ATTR); if (clientResponse==null) {return Mono.empty ();} log.trace ("NettyWriteResponseFilter start"); ServerHttpResponse response=exchange.getResponse (); NettyDataBufferFactory factory= (NettyDataBufferFactory) response.bufferFactory () / / TODO: what if it's not netty final Flux body=clientResponse.receive () .retain () / / TODO: needed? .map (factory::wrap); MediaType contentType=null; try {contentType=response.getHeaders () .getContentType ();} catch (Exception e) {log.trace ("invalid media type", e) } return (isStreamingMediaType (contentType)? response.writeAndFlushWith (body.map (Flux::just)): response.writeWith (body));});}

If Netty HttpClientResponse exists in the CLIENT_ RESPONSE_ ATTR request attribute, NettyWriteResponseFilter is applied.

It runs after the other filters are complete and writes the agent response back to the gateway client response.

Pairs of WebClientHttpRoutingFilter and WebClientWriteResponseFilter filters perform the same functions as Nettty-based routing and response filters, but do not require the use of Netty.

6. RouteToRequestUrlFilter routes to the filter of the specified url

If there is a Route object in the ServerWebExchangeUtils.GATEWAY_ ROUTE_ ATTR request property, the RouteToRequestUrlFilter filter is run.

He will create a new URI based on the request URI.

The new URI is in the ServerWebExchangeUtils.GATEWAY_REQUEST_URL_ATTR request property. The filter is assembled into the URL address sent to the proxy service and passed back to the filter forwarded by the route.

@ Overridepublic Mono filter (ServerWebExchange exchange,GatewayFilterChain chain) {Route route=exchange.getAttribute (GATEWAY_ROUTE_ATTR); if (route==null) {return chain.filter (exchange);} log.trace ("RouteToRequestUrlFilter start"); URI uri=exchange.getRequest () .getURI (); boolean encoded=containsEncodedParts (uri); URI routeUri=route.getUri () If (hasAnotherScheme (routeUri)) {/ / this is a special url, save scheme to special attribute / / replace routeUri with schemeSpecificPart exchange.getAttributes (). Put (GATEWAY_SCHEME_PREFIX_ATTR,routeUri.getScheme ()); routeUri=URI.create (routeUri.getSchemeSpecificPart ()) } URI mergedUrl=UriComponentsBuilder.fromUri (uri) / / .uri (routeUri) .scheme (routeUri.getScheme ()) .host (routeUri.getHost ()) .port (routeUri.getPort ()) .build (encoded) .toUri (); exchange.getAttributes () .put (GATEWAY_REQUEST_URL_ATTR,mergedUrl); return chain.filter (exchange);}

1. First, get the Route in the request, and if it is empty, submit the filter chain directly; otherwise, get routeUri and determine whether routeUri is special. If so, you need to process URL, save the prefix to GATEWAY_SCHEME_PREFIX_ATTR, and replace routeUri.

two。 Get the Route in the request. If it is empty, submit it directly to the filter chain

3. Get routeUri and determine whether it is special. If so, you need to process URL, save the prefix to GATEWAY_SCHEME_PREFIX_ATTR, and replace routeUri with schemeSpecificPart.

The requestUrl is then spliced to convert the requested URI into the routeUri defined by the route

4. Finally, submit to the filter chain to continue execution

7 、 WebsocketRoutingFilter

If the URL prefix for the ServerWebExchangeUtils.GATEWAY_REQUEST_URL_ATTR attribute in the request is ws or wss, the Websocket route filter is enabled. It uses Spring WebSocket as the underlying communication component to forward WebSocket requests downstream.

Websocket can achieve load balancing by adding the prefix lb, such as lb:ws://serviceid.

If you use SockJS as a callback for normal http, you should configure normal HTTP routing as well as Websocket routing

Spring: cloud: gateway: routes: # SockJS route-id: websocket_sockjs_route uri: http://localhost:3001 predicates:-Path=/websocket/info/** # Normwal Websocket route-id: websocket_route uri: ws://localhost:3001 predicates:-Path=/websocket/**

When the Websocket route filter processes, it first obtains the requested URL and its prefix to determine whether the condition for enabling the Websocket filter is met

For requests that are not routed and prefixed with ws or wss, the routing status bit is set, and the filtered header is constructed. Finally, the request is forwarded through the agent.

/ / WebsocketRoutingFilter.java@Overridepublic Mono filter (ServerWebExchange exchange,GatewayFilterChain chain) {/ / check whether websocket is upgrade changeSchemeIfIsWebSocketUpgrade (exchange); URI requestUrl=exchange.getRequiredAttribute (GATEWAY_REQUEST_URL_ATTR); String scheme=requestUrl.getScheme (); / / determine whether the websocket enabling condition if (isAlreadyRouted (exchange)) | (! "ws" .equals (scheme) & &! "wss" .equals (scheme)) {return chain.filter (exchange);} setAlreadyRouted (exchange) HttpHeaders headers=exchange.getRequest (). GetHeaders (); HttpHeaders filtered=filterRequest (getHeadersFilters (), exchange); List protocols=headers.get (SEC_WEBSOCKET_PROTOCOL); if (empty slots null) {protocols=headers.get (SEC_WEBSOCKET_PROTOCOL) .stream () .flatMap (header- > Arrays.stream (commaDelimitedListToStringArray (header) .map (String::trim) .map (Collectors.toList ()) } / / forward the request agent to return this.webSocketService.handleRequest (exchange, new ProxyWebSocketHandler (requestUrl,this.webSocketClient,filtered,protocols));}

ProxyWebSocketHandler is the implementation class of WebSocketHandler that handles client-side WebSocket Session. Let's take a look at the implementation of the proxy WebSocket processor:

/ / WebsocketRoutingFilter.javaprivate static class ProxyWebSocketHandler implements WebSocketHandler {private final WebSocketClient client; private final URI url; private final HttpHeaders headers; private final List subProtocols; public ProxyWebSocketHandler (URI url, WebSocketClient client, HttpHeaders headers, List protocols) {this.client = client; this.url = url; this.headers = headers; if (protocols! = null) {this.subProtocols = protocols } else {this.subProtocols = Collections.emptyList ();} @ Override public List getSubProtocols () {return this.subProtocols } @ Override public Mono handle (WebSocketSession session) {/ / pass headers along so custom headers can be sent through return client.execute (url, this.headers) New WebSocketHandler () {@ Override public Mono handle (WebSocketSession proxySession) {/ / Use retain () for Reactor Netty Mono proxySessionSend = proxySession .send (session.receive () .doOnNext (WebSocketMessage::retain)) / / .log ("proxySessionSend", Level.FINE); Mono serverSessionSend = session .send (proxySession.receive () .doOnNext (WebSocketMessage::retain)); / / .log ("sessionSend", Level.FINE); return Mono.zip (proxySessionSend, serverSessionSend) .then () } / * Copy subProtocols so they are available downstream. * @ return * / @ Override public List getSubProtocols () {return ProxyWebSocketHandler.this.subProtocols;}})

The 1.WebSocketClient# execute method connects to the WebSocket service that is proxied at the back end.

two。 After the connection is successful, call back the handle (WebSocketSession session) method of the inner class implemented by WebSocketHandler

The inner class of the 3.WebSocketHandler implementation forwards the message: client = > specific business service = > client; then merges the session information proxySessionSend of the broker service and the session information serverSessionSend of the business service.

8. Other filters

The filter used by AdaptCachedBodyGlobalFilter to cache the request body has a higher priority in the global filter.

The gatewayRoute attribute in the ForwardPathFilter request corresponds to the Route object, and when the URI scheme in Route is in forward mode, this filter is used to set the URI path of the request to the URI path in the Route object.

Practical summary, customize a GlobalFilter to achieve the restrictions on IP addresses. @ Component public class IPCheckFilter implements GlobalFilter, Ordered {@ Override public int getOrder () {return 0;} @ Override public Mono filter (ServerWebExchange exchange, GatewayFilterChain chain) {HttpHeaders headers = exchange.getRequest (). GetHeaders (); InetSocketAddress host = headers.getHost (); / / the IP address here is written to death. In practice, you need to configure String hostName = host.getHostName (). If ("localhost" .equals (hostName)) {ServerHttpResponse response = exchange.getResponse (); byte [] datas = "{\" code\ ": 401,\" message\ ":\" illegal request\ ".getBytes (StandardCharsets.UTF_8); DataBuffer buffer = response.bufferFactory (). Wrap (datas); response.setStatusCode (HttpStatus.UNAUTHORIZED) Response.getHeaders (). Add ("Content-Type", "application/json;charset=UTF-8"); return response.writeWith (Mono.just (buffer));} return chain.filter (exchange);}} Spring Cloud Gateway routing forwarding rules

Before we learn the Spring Cloud Gateway routing forwarding rules, we need to know all the predicates (predicates, assertions) provided within Spring Cloud Gateway.

Predicates is the condition for judging route forwarding. Currently, SpringCloud Gateway supports a variety of methods, as shown in the following figure

The use of each Predicate can be interpreted as: only when this condition is met will it be forwarded. If there are multiple, it will be forwarded when all of them are satisfied.

In fact, when we introduced the routing configuration above, we have already introduced Path matching and forwarding, and then we will introduce several methods that are often used in daily development.

1. By time matching

Predicate supports setting a time that can be forwarded before or after the request is forwarded. For example, we are now set to forward it to my website only on January 1, 2019. If we do not forward it before then, I can configure it like this:

Spring: cloud: gateway: routes:-id: time_route uri: http://ityouknow.com predicates:-After=2018-01-20T06:06:06+08:00 [Asia/Shanghai]

Spring compares time through ZonedDateTime. ZonedDateTime is a class used to represent date and time information with time zone in Java 8. ZonedDateTime supports setting time through time zone. The time zone in China is Asia/Shanghai.

After Route Predicate means that requests after this time are forwarded to the destination address. The above example means that all requests after 06:06:06 on January 20, 2018 are forwarded to the address http://ityouknow.com. + 08:00 means that there is an eight-hour difference between time and UTC time, and the time area is Asia/Shanghai.

After the routing rule is added, the access address http://localhost:8080 is automatically forwarded to http://ityouknow.com.

Before Route Predicate, on the contrary, forwards requests that are requested before a certain time. Let's change the After in the routing rule above to Before, as follows:

Spring: cloud: gateway: routes:-id: after_route uri: http://ityouknow.com predicates:-Before=2018-01-20T06:06:06+08:00 [Asia/Shanghai]

It means that routing can be carried out before this time, stop routing after this time, and restart the project to visit the address http://localhost:8080 again after modification. The page will report that no address was found.

In addition to before or after time, Gateway also supports limiting routing requests to a certain time range, which can be implemented using Between Route Predicate.

Spring: cloud: gateway: routes:-id: after_route uri: http://ityouknow.com predicates:-Between=2018-01-20T06:06:06+08:00 [Asia/Shanghai], 2019-01-20T06:06:06+08:00 [Asia/Shanghai]

This setting means that the route can be matched within this time period, but not beyond this time period. The ability to match routing through time is cool and can be used in time-limited panic buying scenarios.

two。 Match through Cookie

Cookie Route Predicate can receive two parameters, one is Cookie name and the other is regular expression. Routing rules will match by obtaining the corresponding Cookie name value and regular expression. If there is a match, the route will be executed, and if there is no match, it will not be executed.

Spring: cloud: gateway: routes:-id: cookie_route uri: http://ityouknow.com predicates:-Cookie=ityouknow, kee.e

Using the curl test, enter on the command line:

Curl http://localhost:8080-cookie "ityouknow=kee.e"

The page code will be returned. If-cookie "ityouknow=kee.e" is removed, the background will report a 404 error.

3. Match by Header attribute

Header Route Predicate, like Cookie Route Predicate, receives two parameters, an attribute name in header and a regular expression, which is executed if the attribute value matches the regular expression.

Spring: cloud: gateway: routes:-id: header_route uri: http://ityouknow.com predicates:-Header=X-Request-Id,\ d+

Using the curl test, enter on the command line:

Curl http://localhost:8080-H "X-Request-Id:666666"

The page code is returned to prove that the match is successful. Change the parameter-H "X-Request-Id:666666" to-H "X-Request-Id:neo" when executed again and return 404 to prove that there is no match.

4. Match through Host

Host Route Predicate receives a set of parameters, a list of matching domain names, this template is an ant-separated template, with. Number as a delimiter. It uses the host address in the parameter as the matching rule.

Spring: cloud: gateway: routes:-id: host_route uri: http://ityouknow.com predicates:-Host=**.ityouknow.com

Using the curl test, enter on the command line:

Curl http://localhost:8080-H "Host: www.ityouknow.com" curl http://localhost:8080-H "Host: md.ityouknow.com"

After testing, both of the above two host can match to the host_route route, and if the host parameter is removed, a 404 error will be reported.

5. Match by request

It can be routed through different request methods such as POST, GET, PUT, DELETE, and so on.

Spring: cloud: gateway: routes:-id: method_route uri: http://ityouknow.com predicates:-Method=GET

Using the curl test, enter on the command line:

# curl defaults to requesting curl http://localhost:8080 by GET

The test returns the page code to prove that it matches the route, and then we request the test in the form of POST.

# curl defaults to requesting curl-X POST http://localhost:8080 by GET

Return 404 is not found, which proves that there is no matching route.

6. Match by request path

Path Route Predicate receives a parameter that matches the path to determine whether to walk or not.

Spring: cloud: gateway: routes:-id: host_route uri: http://ityouknow.com predicates:-Path=/foo/ {segment}

If the request path meets the requirements, the route will match, for example: / foo/1 or / foo/bar.

Using the curl test, enter on the command line:

Curl http://localhost:8080/foo/1curl http://localhost:8080/foo/xxcurl http://localhost:8080/boo/xx

After testing, the first and second commands can get the return value of the page normally, and the last command reports 404, which proves that the route is matched by the specified route.

7. Match through request parameters

Query Route Predicate supports passing in two parameters, one is the attribute name and the other is the attribute value, which can be a regular expression.

Spring: cloud: gateway: routes:-id: query_route uri: http://ityouknow.com predicates:-Query=smile

In this configuration, the route can be matched as long as the request contains the parameter of the smile attribute.

Using the curl test, enter on the command line:

Curl localhost:8080?smile=x&id=2

After testing, it is found that the route will be matched as long as the request summary has the smile parameter, and it will not match without the smile parameter.

You can also configure the value of Query as a key-value pair, so that the attribute value and regularity will be matched when the request comes over.

Spring: cloud: gateway: routes:-id: query_route uri: http://ityouknow.com predicates:-Query=keep, pu.

This will be matched and routed only if the request contains the keep attribute and the parameter value is a three-digit string that begins with pu.

Using the curl test, enter on the command line:

Curl localhost:8080?keep=pub

The test can return the page code and change the property value of keep to pubx and it will report 404 when it is accessed again, proving that the route needs to match the regular expression to route.

8. Match by requesting an ip address

Predicate also supports routing requests by setting an ip interval number range. RemoteAddr Route Predicate accepts a list of cidr symbol (IPv4 or IPv6) strings (the minimum size is 1), such as 192.168.0.1 Universe 16 (where 192.168.0.1 is the IP address and 16 is the subnet mask).

Spring: cloud: gateway: routes:-id: remoteaddr_route uri: http://ityouknow.com predicates:-RemoteAddr=192.168.1.1/24

You can set this address to the native ip address for testing.

Curl localhost:8080

If the requested remote address is 192.168.1.10, this route will match.

9. Combined use

In order to demonstrate the use of each Predicate above, we do configuration testing individually, but we can actually use various Predicate together.

For example:

Spring: cloud: gateway: routes:-id: host_foo_path_headers_to_httpbin uri: http://ityouknow.com predicates:-Host=**.foo.org-Path=/headers-Method=GET-Header=X-Request-Id,\ d +-Query=foo, ba. -Query=baz-Cookie=chocolate, ch.p-After=2018-01-20T06:06:06+08:00 [Asia/Shanghai]

When all kinds of Predicates exist on the same route at the same time, the request must meet all the conditions at the same time before it can be matched by this route.

When a request satisfies the predicate condition of multiple routes, the request will only be forwarded by the first successfully matched route.

Spring Cloud Gateway fuse mechanism

In the previous Spring Cloud series of articles, in what is Hystrix, the final aspect of Ali technology, it is a pity to fall in front of Hystrix! We have made a detailed introduction to the fuse.

Spring Cloud Gateway can also take advantage of the circuit breaker feature of Hystrix to downgrade the service when the traffic is too large. Similarly, we should first add dependencies to the project.

Org.springframework.cloud spring-cloud-starter-netflix-hystrix

Configuration example

Spring: cloud: gateway: routes:-id: hystrix_route uri: http://example.org filters:-Hystrix=myCommandName

Once configured, gateway uses myCommandName as the name to generate a HystrixCommand object for circuit breaker management. If you want to add the callback after the circuit breaker, you need to add some configuration.

Spring: cloud: gateway: routes:-id: hystrix_route uri: lb://spring-cloud-producer predicates:-Path=/consumingserviceendpoint filters:-name: Hystrix args: name: fallbackcmd fallbackUri: forward:/incaseoffailureusethis

FallbackUri: forward:/incaseoffailureusethis configures the path that will be called when fallback is called. When the fallback that calls Hystrix is called, the request will be forwarded to the URI of / incaseoffailureuset.

Spring Cloud Gateway retry mechanism

First of all, we need to know why we use the retry mechanism. Usually, when we invoke a service, we will inevitably encounter a failure of the service call, such as network fluctuations or some other reason.

At this point we will want to revisit the service, and here we use the retry mechanism.

However, we should not abuse the retry mechanism. For example, if we use the retry mechanism when writing data, we should be extra careful. We must make the interface idempotent to prevent data from being repeatedly written into the library.

And a large number of retry mechanisms will inevitably lead to an increase in the number of requests and increase the pressure on the system, so it is also very important for us to set a reasonable number of retries.

Let's talk about the retry mechanism and use in Spring Cloud Gateway.

Let's take a look at GatewayAutoConfiguration. According to the class name, we know that it is the autoassembly class of Gateway.

The source code is as follows

Configuration@ConditionalOnProperty (name = "spring.cloud.gateway.enabled", matchIfMissing = true) @ EnableConfigurationProperties@AutoConfigureBefore (HttpHandlerAutoConfiguration.class) @ AutoConfigureAfter ({GatewayLoadBalancerClientAutoConfiguration.class, GatewayClassPathWarningAutoConfiguration.class}) @ ConditionalOnClass (DispatcherHandler.class) public class GatewayAutoConfiguration {/ /. @ Bean public RetryGatewayFilterFactory retryGatewayFilterFactory () {return new RetryGatewayFilterFactory ();} /.}

We found that the program enabled RetryGatewayFilterFactory by default. Let's take a look at the source code of RetryGatewayFilterFactory.

Org.springframework.cloud.gateway.filter.factory.RetryGatewayFilterFactory

Public class RetryGatewayFilterFactory extends AbstractGatewayFilterFactory {private static final Log log = LogFactory.getLog (RetryGatewayFilterFactory.class); public RetryGatewayFilterFactory () {super (RetryConfig.class);} @ Override public GatewayFilter apply (RetryConfig retryConfig) {/ / verify that the retry configuration format is correct retryConfig.validate (); Repeat statusCodeRepeat = null If (! retryConfig.getStatuses (). IsEmpty () | |! retryConfig.getSeries () .isEmpty ()) {Predicate repeatPredicate = context-> {ServerWebExchange exchange = context.applicationContext (); / / determine whether the number of retries has reached the configured maximum if (exceedsMaxIterations (exchange, retryConfig)) {return false } / / get the status code of the response HttpStatus statusCode = exchange.getResponse () .getStatusCode (); / / get the request method type HttpMethod httpMethod = exchange.getRequest () .getMethod () / / determine whether the response status code exists in the configuration boolean retryableStatusCode = retryConfig.getStatuses () .contains (statusCode) If (! retryableStatusCode & & statusCode! = null) {/ / null status code might mean a network exception? / / try the series retryableStatusCode = retryConfig.getSeries (). Stream () .anyMatch (series-> statusCode.series (). Equals (series)) } / / determine whether the method is included in the configuration boolean retryableMethod = retryConfig.getMethods () .contains (httpMethod); / / decide whether to retry return retryableMethod & & retryableStatusCode;} StatusCodeRepeat = Repeat.onlyIf (repeatPredicate) .doOnRepeat (context-> reset (context.applicationContext ();} / / TODO: support timeout, backoff, jitter, etc... In Builder Retry exceptionRetry = null; if (! retryConfig.getExceptions (). IsEmpty ()) {Predicate retryContextPredicate = context-> {if (exceedsMaxIterations (context.applicationContext (), retryConfig)) {return false;} / / exception judgment for (Class)

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.