转载

Spring Cloud实战小贴士：Zuul统一异常处理（三）【Dalston版】

读者是否还记得我们之前分析了Spring Cloud Zuul自带的核心过滤器有哪些呢？我们先根据下图回忆一下：

这次主要将 SendErrorFilter 过滤器的类型从 POST 改为了 ERROR ，所以核心过滤器变成了如下图的结构：

Spring Cloud实战小贴士：Zuul统一异常处理（三）【Dalston版】

处理逻辑的变化

既然过滤器类型发生了变化，那么请求的处理生命周期就会有所变化。在变化之前，各阶段过滤器的流转如下图所示：

Spring Cloud实战小贴士：Zuul统一异常处理（三）【Dalston版】

针对异常情况，在图中我们标出了不同的颜色。从pre和route阶段抛出的异常将会进入error阶段，再进入到post阶段进行返回。由于SendErrorFilter需要判断请求上下文中是否包含 error.status_code 属性：有的话就用SendErrorFilter处理错误结果；没有的话就用SendResponseFilter返回正常结果，但是 error.status_code 属性默认是在各个阶段过滤器中自己put进去的，这就导致，各个阶段过滤器抛出异常之后，是没有办法返回错误结果的。因此，我们扩展了一个ErrorFilter来捕获异常，然后手工的设置 error.status_code 属性，让SendErrorFilter能正常运作。

通过上面你的改造，从pre和route阶段的异常都能处理了，但是post阶段抛出异常后，是不会再进入post阶段的，这使得ErrorFilter设置了设置 error.status_code 属性之后，也没有过滤器去组织返回结果，所以我们通过继承SendErrorFilter在error阶段增加了一个返回错误信息的过滤器。

而这次在Dalston版本中，做了很巧妙的变动：就是上文所述的对SendErrorFilter过滤器类型的变更，这一变动使得所有阶段的异常都会被SendErrorFilter处理，直接解决的上面的第二个问题。当然只是做个变动还是不够的，为了区分SendErrorFilter和SendResponseFitler分别处理出现异常和未出现异常的情况，修改原来根据 error.status_code 属性判断的逻辑，而是改为根据请求上下文中是否包含Throwable来作为基本依据，而这个对象是在过滤器出现异常之后，Zuul往请求上下文中置入的，所以可以更为准确的判断当前请求处理是否出现了异常，而不再需要我们之前扩展的ErrorFilter了。

public class SendErrorFilterextends ZuulFilter{	
	@Override
	public boolean shouldFilter(){
		RequestContext ctx = RequestContext.getCurrentContext();
		return ctx.containsKey("error.status_code")
				&& !ctx.getBoolean(SEND_ERROR_FILTER_RAN, false);
	}
	...
}

public class SendResponseFilterextends ZuulFilter{
	@Override
	public boolean shouldFilter(){
		RequestContext context = RequestContext.getCurrentContext();
		return context.getThrowable() == null
			&& (!context.getZuulResponseHeaders().isEmpty()
				|| context.getResponseDataStream() != null
				|| context.getResponseBody() != null);
	}
	...
}

所以，最后修改之后，整个处理逻辑变为如下图所示的流程：

Spring Cloud实战小贴士：Zuul统一异常处理（三）【Dalston版】