Filter API gateway function is implemented Zuul most core member, each HTTP request will enter Zuul through a series of filters to give request response processing chain and returned to the client.
Spring Cloud Zuul implemented in the filter must contain four basic characteristics: type of filtering, execution order, the execution condition, the specific operation, these four interface and ZuulFilter IZuulFilter operation is an abstract class (ZuulFilter implements IZuulFilter) and defined four abstract methods:
String filterType();
int filterOrder();
boolean shouldFilter();
Object run();
For their meanings and functions are summarized as follows:
filterType: This function returns a string requires to represent the type of the filter, and the various stages of this type is defined in the HTTP request process. In Zuul default filter is defined four different types of life cycle, as follows:
pre: it can be called before the request is routed.
routing: routing request time is called.
post: is called after the routing and error filters.
error: is called when an error occurred while processing the request.
filterOrder: the filter is defined by the value of int execution order, the smaller the value the higher the priority.
shouldFilter: returns a boolean determining whether the filter is to be performed. We can specify the effective range of the filter by this method.
run: the specified logical filter. In this function, we can implement custom filtering logic to determine whether to intercept the current request, is not subjected to a subsequent route or after the route request return result, the processing result do some processing.
Core filter
In Spring Cloud Zuul, in order to make the API gateway components can be more convenient to get up and running, it requests all stages of the life cycle of the default HTTP filter to achieve a core group, they will be automatically loaded when the API Gateway service starts and enabled. We can see and understand them in the source code, they are defined under org.springframework.cloud.netflix.zuul.filters package spring-cloud-netflix-core module.
pre filter
ServletDetectionFilter: its execution order of -3, the first filter is executed. The filter will always be performed, is mainly used to detect the current request is made by a process running DispatcherServlet Spring, or by a process running through ZuulServlet. Its detection result will be stored in a Boolean parameter isDispatcherServletRequest context of the current request, so that the subsequent filter, we can RequestUtils.isDispatcherServletRequest () and RequestUtils.isZuulServletRequest () method for determining which performs different processing to achieve . In general, the transmitted external request to the API gateway process will be DispatcherServlet Spring, in addition to the request by / zuul / access path bypasses DispatcherServlet, ZuulServlet is processed, is mainly used to deal with the case of large files uploaded. In addition, the access path ZuulServlet / zuul /, we can be modified by zuul.servletPath parameters.
Servlet30WrapperFilter: -2 its execution sequence is executed the second filter. The current implementation will take effect for all requests, mainly to the original packaging to Servlet30RequestWrapper HttpServletRequest object.
FormBodyWrapperFilter: -1 order of its execution, execution of the third filter. The filter commencement request only two types, the first type is the Content-Type is application / x-www-form-urlencoded request, the second is Content-Type of multipart / form-data and is processed by the Spring DispatcherServlet request (ServletDetectionFilter uses the processing result). The principal purpose of the filter is to meet the requirements of the request into a packaging FormBodyRequestWrapper objects.
DebugFilter: 1 order of its execution, execution of the fourth filter. The filter may perform operations to determine whether a filter in accordance with the configuration parameters and zuul.debug.request debug request parameters. And its specific operation contents sucked current request context and debugRequest debugRouting parameter set to true. Since the life cycle with a different request, have access to these two values, so we can use these two values in each subsequent filter to define debug information, so that when there is a problem online environment, You can activate the debug information through the request parameters to help analyze the problem. Further, the request for debug parameter parameters, we can also be customized by zuul.debug.parameter.
PreDecorationFilter: 5 its execution order, the last stage is a filter pre executed. The filter determines whether the current request is present and the serviceId forward.to context parameters, if none exists, it performs the specific operation of the filter (if one is present, it indicates that the current request have been processed, because this information is to load two routing information based on the current request comes in). And its operation content is specific for the current request to do some preprocessing, such as: routing rules match, set the basic information of the request and the matching results and some routing information provided in the request context and the like, the subsequent information will be filtered an important basis for processing, we can RequestContext.getCurrentContext () to access this information. Furthermore, we can also find some logic in this implementation of HTTP head request process, which contains some header fields familiar, such as: X-Forwarded-Host, X-Forwarded-Port. Further, the recording heads of these fields is controlled by zuul.addProxyHeaders parameter, and this parameter defaults to true, so when the default request Zuul will jump to request an increase in X-Forwarded- * header field, comprising: X -Forwarded-Host, X-Forwarded-Port, X-Forwarded-For, X-Forwarded-Prefix, X-Forwarded-Proto. We may also be provided by adding zuul.addProxyHeaders = false closing operation of these header fields.
route filter
RibbonRoutingFilter: its execution order of 10, is a first filter stage route performed. The filter serviceId request parameter exists only for processing the request context, i.e. the configuration takes effect only on request by routing rules serviceId. And execution logic core of the filter is oriented routing service, it initiates a request to the service instance by using and MAMMALIA, Ribbon, and return the service request result instance.
SimpleHostRoutingFilter: its execution order of 100, the second stage is executed route filters. The request routeHost filter parameter exists only for processing the request context, i.e., by effect only on request url configure routing rules. And execution logic of the filter is initiated to a physical address directly routeHost request parameter from the source, we can know that the request is achieved through direct httpclient package, without the use of packaging Hystrix command, and so such requests no thread spacer and protection circuit breaker.
SendForwardFilter: its execution order of 500, the third stage is executed route filters. The request forward.to filter parameter exists only for processing the request context, i.e. for local processing jumps forward configure routing rules.
post filter
LocationRewriteFilter: It's execution order is 900, at the time of redirection, in charge of the header is rewritten URL Zuul, otherwise, the browser will redirect to the URL Web application instead of Zuul URL.
SendResponseFilter: its execution order of 1000, a post filter stage last executed. The filter checks whether the request context contains relevant header information in response to a request, response, or data stream response body, comprising only one of them will be executed when the processing logic. And the processing logic is the use of the filter context request response message needs to be sent back in response to tissue content client.
error filter
SendErrorFilter: Its execution sequence is 0, the first stage is a post filter performed. The filter parameters include only error.status_code (error codes provided by the filter before execution) in the context of the request has not been executed and the time filter treated. And specific logic of the filter is to use requests the error message context to be organized into a forward Gateway API request / error error error response generating endpoints.