Zuul comes with a DebugFilter. At first, the author didn't understand the use of this DebugFilter. It's easy to understand from the name. It's used for debugging, but you can see that its source code has almost no logic, so it just set s two values. The code is as follows.
@Override
public Object run() {
RequestContext ctx = RequestContext.getCurrentContext();
ctx.setDebugRouting(true);
ctx.setDebugRequest(true);
return null;
}
If you want this filter to execute, you have to study its shouldFilter() method. The code is as follows.
@Override
public boolean shouldFilter() {
HttpServletRequest request = RequestContext.getCurrentContext().getRequest();
if ("true".equals(request.getParameter(DEBUG_PARAMETER.get()))) {
return true;
}
return ROUTING_DEBUG.get();
}
The filter can be turned on as long as either of the two conditions is met.
The first condition is that the request parameter can be opened with "a parameter = true". The parameter name is obtained through the following code, as shown below.
private static final DynamicStringProperty DEBUG_PARAMETER = DynamicPropertyFactory.getInstance()
.getStringProperty(ZuulConstants.ZUUL_DEBUG_PARAMETER, "debug");
DynamicStringProperty is an API provided by Netflix's configuration management framework Archaius, which can obtain the configuration from the configuration center. Since Netflix does not have an open-source server of Archaius, the default value used here is debug. If you want to obtain this value dynamically, you can use Ctrip's open-source Apollo to connect with Archaius, which will be explained later in the tutorial.
You can add "debug=true" after the request address to enable this filter. The parameter name debug can also be overwritten in the configuration file, using zuul debug. Parameter is specified. Otherwise, it is obtained from Archaius. If there is no connection with Archaius, it is the default value of debug.
The code of the second condition is shown below.
private static final DynamicBooleanProperty ROUTING_DEBUG = DynamicPropertyFactory
.getInstance().getBooleanProperty(ZuulConstants.ZUUL_DEBUG_REQUEST, false);
It is by configuring zuul debug. Request. You can configure "zuul.debug.request=true" in the configuration file to turn on the DebugFilter filter.
After the DebugFilter filter is turned on, it has no effect. In the run method, only the values of DebugRouting and DebugRequest are set to true, so continue to look at the source code and find that there is such a piece of code in many places, such as com netflix. zuul. FilterProcessor. In runfilters (string), the code is as follows.
if (RequestContext.getCurrentContext().debugRouting()) {
Debug.addRoutingDebug("Invoking {" + sType + "} type filters");
}
When debugrouting is true, some Debug information will be added to the RequestContext. Now I understand why debugrouting and DebugRequest should be set to true in DebugFilter.
There are still some doubts after this step. Generally, if we Debug information, it must be output in the log. The log level is Debug, but the Debug information is only accumulated and stored in the RequestContext, which is not displayed to the user.
At org springframework. cloud. netflix. zuul. filters. post. SendResponseFilter. We see hope in the code addresponseheaders(). The specific code is as follows.
private void addResponseHeaders() {
RequestContext context = RequestContext.getCurrentContext();
HttpServletResponse servletResponse = context.getResponse();
if (this.zuulProperties.isIncludeDebugHeader()) {
@SuppressWarnings("unchecked")
List<String> rd = (List<String>) context.get(ROUTING_DEBUG_KEY);
if (rd != null) {
StringBuilder debugHeader = new StringBuilder();
for (String it : rd) {
debugHeader.append("[[[" + it + "]]]");
}
servletResponse.addHeader(X_ZUUL_DEBUG_HEADER, debugHeader.toString());
}
}
}
The core code is this zuulProperties. Isincludedebugheader(), the debugging information in the RequestContext will be output as the response header only if this condition is met. Add the following configuration in the configuration file:
zuul.include-debug-header=true
Finally, you can see the debugging content in the response header of the request, as shown in Figure 1.
