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

本文深入解析Dalston版SpringCloudZuul的异常处理优化,重点介绍SendErrorFilter过滤器类型的变更及处理逻辑改进,使得异常信息在不同阶段得到有效处理。

本篇作为《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了。

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

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

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

推荐阅读


money.jpg
AI 代码审查Review工具 是一个旨在自动化代码审查流程的工具。它通过集成本控制系统(如 GitHub 和 GitLab)的 Webhook,利用大型语言模型(LLM)对代码变更进行分析,并将审查意见反馈到相应的 Pull Request 或 Merge Request 中。此外,它还支持将审查结果通知到企业微信等通讯工具。 一个基于 LLM 的自动化代码审查助手。通过 GitHub/GitLab Webhook 监听 PR/MR 变更,调用 AI 分析代码,并将审查意见自动评论到 PR/MR,同时支持多种通知渠道。 主要功能 多平台支持: 集成 GitHub 和 GitLab Webhook,监听 Pull Request / Merge Request 事件。 智能审查模式: 详细审查 (/github_webhook, /gitlab_webhook): AI 对每个变更文件进行分析,旨在找出具体问题。审查意见会以结构化的形式(例如,定位到特定代码行、问题分类、严重程度、分析和建议)逐条评论到 PR/MR。AI 模型会输出 JSON 格式的分析结果,系统再将其转换为多条独立的评论。 通用审查 (/github_webhook_general, /gitlab_webhook_general): AI 对每个变更文件进行整体性分析,并为每个文件生成一个 Markdown 格式的总结性评论。 自动化流程: 自动将 AI 审查意见(详细模式下为多条,通用模式下为每个文件一条)发布到 PR/MR。 在所有文件审查完毕后,自动在 PR/MR 中发布一条总结性评论。 即便 AI 未发现任何值得报告的问题,也会发布相应的友好提示和总结评论。 异步处理审查任务,快速响应 Webhook。 通过 Redis 防止对同一 Commit 的重复审查。 灵活配置: 通过环境变量设置基
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值