Spring Cloud实战小贴士:Zuul统一异常处理(三)

企业动态
首先,我们可以来看看默认情况下,过滤器中抛出异常Spring Cloud Zuul会发生什么现象。我们创建一个pre类型的过滤器,并在该过滤器的run方法实现中抛出一个异常。比如下面的实现,在run方法中调用的doSomething方法将抛出RuntimeException异常。

本篇作为《Spring Cloud微服务实战》一书关于Spring Cloud Zuul网关在Dalston版本对异常处理的补充。没有看过本书的读书也不要紧,可以先阅读我之前的两篇博文:《Spring Cloud实战小贴士:Zuul统一异常处理(一)》《Spring Cloud实战小贴士:Zuul统一异常处理(二)》,这两篇文章都详细介绍和分析了Spring Cloud Zuul在过滤器设计中对异常处理的不足。同时,在这两篇文章中,也针对不足之处做了相应的解决方案。不过,这些方案都是基于Brixton版本所做的,在***的Dalston版本中,Spring Cloud Zuul做了一些优化,所以我们不再需要做这些扩展就已经能够正确的处理异常信息了。那么,在Dalston版中,Spring Cloud Zuul中做了怎么样的修改以达到之前我们自己扩展的效果呢?

过滤器类型的变更

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

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

处理逻辑的变化

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

针对异常情况,在图中我们标出了不同的颜色。从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了。

  1. public class SendErrorFilter extends ZuulFilter {    
  2.     @Override 
  3.     public boolean shouldFilter() { 
  4.         RequestContext ctx = RequestContext.getCurrentContext(); 
  5.         return ctx.containsKey("error.status_code"
  6.                 && !ctx.getBoolean(SEND_ERROR_FILTER_RAN, false); 
  7.     } 
  8.     ... 
  9. public class SendResponseFilter extends ZuulFilter { 
  10.     @Override 
  11.     public boolean shouldFilter() { 
  12.         RequestContext context = RequestContext.getCurrentContext(); 
  13.         return context.getThrowable() == null 
  14.             && (!context.getZuulResponseHeaders().isEmpty() 
  15.                 || context.getResponseDataStream() != null 
  16.                 || context.getResponseBody() != null); 
  17.     } 
  18.     ... 

所以,***修改之后,整个处理逻辑变为如下图所示的流程:

【本文为51CTO专栏作者“翟永超”的原创稿件,转载请通过51CTO联系作者获取授权】

戳这里,看该作者更多好文

责任编辑:武晓燕 来源: 51CTO专栏
相关推荐

2017-05-18 14:14:25

过滤器Spring ClouZuul

2017-05-19 15:13:05

过滤器Spring ClouZuul

2017-05-02 23:05:44

HTTPZuulCookie

2017-10-20 14:55:06

Spring ClouZuul加载

2017-10-18 16:00:14

SpringCloudZuul路径

2017-08-10 16:14:07

FeignRPC模式

2017-09-26 16:17:39

Ribboneager-load模式

2021-04-30 07:34:01

Spring BootController项目

2023-11-28 14:32:04

2021-06-29 19:26:29

缓存Spring CachSpring

2024-08-09 08:25:32

Spring流程注解

2017-04-12 14:43:01

Spring ClouZuul过滤器

2024-08-05 10:03:53

2017-05-04 22:30:17

Zuul过滤器微服务

2019-08-22 14:02:00

Spring BootRestful APIJava

2021-04-20 10:15:34

Spring ClouZuul架构

2024-10-28 08:32:22

统一接口响应SpringBoot响应框架

2017-04-13 11:06:28

SpringCloud随机端口

2022-05-30 08:03:06

后端参数校验异常处理

2020-05-26 13:48:05

后端框架异常
点赞
收藏

51CTO技术栈公众号