The concept of filter is not expanded here. In short, in order to make some logic in the routing process, Gateway provides filters for developers to use
The Spring Cloud Gateway} filter is divided into gateway filter and GlobalFilter according to the scope of action. The differences between the two are as follows:
- Gateway filter: it needs to pass spring cloud. routes. Filters are configured under specific routes and only work on the current route or through spring cloud. Default filters are configured globally and act on all routes
- GlobalFilter (Global filter): it does not need to be configured in the configuration file and acts on all routes. Finally, it is packaged into a filter recognizable by GatewayFilterChain through the GatewayFilterAdapter. It is the core filter that converts the URI of the requested service and route into the request address of the real service. It does not need to be loaded during system initialization and acts on each route
Gateway filter
Gateway filter is used to intercept and chain process Web requests, which can crosscut application independent requirements, such as security, access timeout setting, etc. Modify the incoming HTTP request or outgoing HTTP response. Spring Cloud Gateway includes many built-in gateway filter factories. There are 22 filters in total, including Header filter, Path class filter, Hystrix filter, rewrite request URL Filter, Parameter Status code and other types of filters. According to the purpose of the filter factory, it can be divided into: Header, Parameter, Path, Body, Status, Session, Redirect, Retry, ratelimit and Hystrix
-
Path filter
URL rewriting can be realized. Rewriting the URL can hide the actual path, improve security, be used for user memory and typing, and be easy to be included by search engines. The implementation method is as follows:
- Using RewritePathGatewayFilterFactory
The RewritePath gateway filter factory adopts path regular expression parameters and replacement parameters, and uses Java regular expression to flexibly rewrite the request path
Here is an example of rewriting a path:
server: port: 8082 spring: application: name: service-gateway-server cloud: gateway: #Routing rules routes: - id: service-provider-gateway #Route ID, unique uri: lb://Service provider gateway # LB: / / obtain the service request address from the registry according to the service name predicates: # Assertion (judgment condition) - Path=/provider/**, /api-gateway/** # For the request matching the corresponding URI, append the matching request after the target URI # - Query=token #Match the request with token in the request parameter #- Query=token,abc. #The matching request parameter must contain a token, and the value of the token satisfies the regular abc #- Method=GET #Match GET mode # Matching requests after 20:20:20, February 2, 2020, Shanghai time # - After=2020-02-02T20:20:20.000+08:00[Asia/Shanghai] #- RemoteAddr=192.168.10.1/0 #0 indicates the subnet mask # A request whose matching request header contains X-Request-Id and matches the regular expression \ d + # - Header=X-Request-Id, \d+ filters: # Rewrite / API gateway / provider/getProductsById/1 to / provider/getProductsById/1 - RewritePath=/api-gateway(?<segment>/?.*),$\{segment}
For the convenience of demonstration, the route is also configured in the old way. The rule in the assertion is that the path with the URL conforming to / provider / * *, / API gateway / * * will be routed, while the goods and services do not have the resources of API gateway / path. Direct access will definitely report an error. We erase the path of / API gateway / by rewriting the path
Test after restarting the service, http://localhost:8082/api-gateway/provider/getProductsById/1 Accessing this path returns the correct result
- Using PrefixPathGatewayFilterFactory
Use PrefixPath to add a specified prefix to each matching URI
server: port: 8082 spring: application: name: service-gateway-server cloud: gateway: #Routing rules routes: - id: service-provider-gateway #Route ID, unique uri: lb://Service provider gateway # LB: / / obtain the service request address from the registry according to the service name predicates: # Assertion (judgment condition) - Path=/** # For the request matching the corresponding URI, append the matching request after the target URI # - Query=token #Match the request with token in the request parameter #- Query=token,abc. #The matching request parameter must contain a token, and the value of the token satisfies the regular abc #- Method=GET #Match GET mode # Matching requests after 20:20:20, February 2, 2020, Shanghai time # - After=2020-02-02T20:20:20.000+08:00[Asia/Shanghai] #- RemoteAddr=192.168.10.1/0 #0 indicates the subnet mask # A request whose matching request header contains X-Request-Id and matches the regular expression \ d + # - Header=X-Request-Id, \d+ filters: # Rewrite / API gateway / provider/getProductsById/1 to / provider/getProductsById/1 #- RewritePath=/api-gateway(?<segment>/?.*),$\{segment} # Rewrite getProductsById/1 to / provider/getProductsById/1 - PrefixPath=/provider
In order to facilitate the test, I changed the assertion that all paths comply with and access http://localhost:8082/getProductsById/1 Can return normally