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

在前几天发布的《Spring Cloud实战小贴士:Zuul统一异常处理(一)》一文中,我们详细说明了当Zuul的过滤器中抛出异常时会发生客户端没有返回任何内容的问题以及针对这个问题的两种解决方案:一种是通过在各个阶段的过滤器中增加try-catch块,实现过滤器内部的异常处理;另一种是利用error类型过滤器的生命周期特性,集中地处理preroutepost阶段抛出的异常信息。通常情况下,我们可以将这两种手段同时使用,其中第一种是对开发人员的基本要求;而第二种是对第一种处理方式的补充,以防止一些意外情况的发生。这样的异常处理机制看似已经完美,但是如果在多一些应用实践或源码分析之后,我们会发现依然存在一些不足。

不足之处

下面,我们不妨跟着源码来看看,到底上面的方案还有哪些不足之处需要我们注意和进一步优化的。先来看看外部请求到达API网关服务之后,各个阶段的过滤器是如何进行调度的:

try {
preRoute();
} catch (ZuulException e) {
error(e);
postRoute();
return;
}
try {
route();
} catch (ZuulException e) {
error(e);
postRoute();
return;
}
try {
postRoute();
} catch (ZuulException e) {
error(e);
return;
}

上面代码源自com.netflix.zuul.http.ZuulServletservice方法实现,它定义了Zuul处理外部请求过程时,各个类型过滤器的执行逻辑。从代码中我们可以看到三个try-catch块,它们依次分别代表了preroutepost三个阶段的过滤器调用,在catch的异常处理中我们可以看到它们都会被error类型的过滤器进行处理(之前使用error过滤器来定义统一的异常处理也正是利用了这个特性);error类型的过滤器处理完毕之后,除了来自post阶段的异常之外,都会再被post过滤器进行处理。而对于从post过滤器中抛出异常的情况,在经过了error过滤器处理之后,就没有其他类型的过滤器来接手了,这就是使用之前所述方案存在不足之处的根源。

问题分析与进一步优化

回想一下之前实现的两种异常处理方法,其中非常核心的一点,这两种处理方法都在异常处理时候往请求上下文中添加了一系列的error.*参数,而这些参数真正起作用的地方是在post阶段的SendErrorFilter,在该过滤器中会使用这些参数来组织内容返回给客户端。而对于post阶段抛出异常的情况下,由error过滤器处理之后并不会在调用post阶段的请求,自然这些error.*参数也就不会被SendErrorFilter消费输出。所以,如果我们在自定义post过滤器的时候,没有正确的处理异常,就依然有可能出现日志中没有异常并且请求响应内容为空的问题。我们可以通过修改之前ThrowExceptionFilterfilterType修改为post来验证这个问题的存在,注意去掉try-catch块的处理,让它能够抛出异常。

解决上述问题的方法有很多种,比如最直接的我们可以在实现error过滤器的时候,直接来组织结果返回就能实现效果,但是这样的缺点也很明显,对于错误信息组织和返回的代码实现就会存在多份,这样非常不易于我们日后的代码维护工作。所以为了保持对异常返回处理逻辑的一致,我们还是希望将post过滤器抛出的异常能够交给SendErrorFilter来处理。

在前文中,我们已经实现了一个ErrorFilter来捕获preroutepost过滤器抛出的异常,并组织error.*参数保存到请求的上下文中。由于我们的目标是沿用SendErrorFilter,这些error.*参数依然对我们有用,所以我们可以继续沿用该过滤器,让它在post过滤器抛出异常的时候,继续组织error.*参数,只是这里我们已经无法将这些error.*参数再传递给SendErrorFitler过滤器来处理了。所以,我们需要在ErrorFilter过滤器之后再定义一个error类型的过滤器,让它来实现SendErrorFilter的功能,但是这个error过滤器并不需要处理所有出现异常的情况,它仅对post过滤器抛出的异常才有效。根据上面的思路,我们完全可以创建一个继承自SendErrorFilter的过滤器,就能复用它的run方法,然后重写它的类型、顺序以及执行条件,实现对原有逻辑的复用,具体实现如下:

@Component
public class ErrorExtFilter extends SendErrorFilter {

@Override
public String filterType() {
return "error";
}

@Override
public int filterOrder() {
return 30; // 大于ErrorFilter的值
}

@Override
public boolean shouldFilter() {
// TODO 判断:仅处理来自post过滤器引起的异常
return true;
}

}

到这里,我们在过滤器调度上的实现思路已经很清晰了,但是又有一个问题出现在我们面前:怎么判断引起异常的过滤器是来自什么阶段呢?(shouldFilter方法该如何实现)对于这个问题,我们第一反应会寄希望于请求上下文RequestContext对象,可是在查阅文档和源码后发现其中并没有存储异常来源的内容,所以我们不得不扩展原来的过滤器处理逻辑,当有异常抛出的时候,记录下抛出异常的过滤器,这样我们就可以在ErrorExtFilter过滤器的shouldFilter方法中获取并以此判断异常是否来自post阶段的过滤器了。

为了扩展过滤器的处理逻辑,为请求上下文增加一些自定义属性,我们需要深入了解一下Zuul过滤器的核心处理器:com.netflix.zuul.FilterProcessor。该类中定义了下面过滤器调用和处理相关的核心方法:

  • getInstance():该方法用来获取当前处理器的实例
  • setProcessor(FilterProcessor processor):该方法用来设置处理器实例,可以使用此方法来设置自定义的处理器
  • processZuulFilter(ZuulFilter filter):该方法定义了用来执行filter的具体逻辑,包括对请求上下文的设置,判断是否应该执行,执行时一些异常处理等
  • getFiltersByType(String filterType):该方法用来根据传入的filterType获取API网关中对应类型的过滤器,并根据这些过滤器的filterOrder从小到大排序,组织成一个列表返回
  • runFilters(String sType):该方法会根据传入的filterType来调用getFiltersByType(String filterType)获取排序后的过滤器列表,然后轮询这些过滤器,并调用processZuulFilter(ZuulFilter filter)来依次执行它们
  • preRoute():调用runFilters("pre")来执行所有pre类型的过滤器
  • route():调用runFilters("route")来执行所有route类型的过滤器
  • postRoute():调用runFilters("post")来执行所有post类型的过滤器
  • error():调用runFilters("error")来执行所有error类型的过滤器

根据我们之前的设计,我们可以直接通过扩展processZuulFilter(ZuulFilter filter)方法,当过滤器执行抛出异常的时候,我们捕获它,并往请求上下中记录一些信息。比如下面的具体实现:

public class DidiFilterProcessor extends FilterProcessor {

@Override
public Object processZuulFilter(ZuulFilter filter) throws ZuulException {
try {
return super.processZuulFilter(filter);
} catch (ZuulException e) {
RequestContext ctx = RequestContext.getCurrentContext();
ctx.set("failed.filter", filter);
throw e;
}
}

}

在上面代码的实现中,我们创建了一个FilterProcessor的子类,并重写了processZuulFilter(ZuulFilter filter),虽然主逻辑依然使用了父类的实现,但是在最外层,我们为其增加了异常捕获,并在异常处理中为请求上下文添加了failed.filter属性,以存储抛出异常的过滤器实例。在实现了这个扩展之后,我们也就可以完善之前ErrorExtFilter中的shouldFilter()方法,通过从请求上下文中获取该信息作出正确的判断,具体实现如下:

@Component
public class ErrorExtFilter extends SendErrorFilter {

@Override
public String filterType() {
return "error";
}

@Override
public int filterOrder() {
return 30; // 大于ErrorFilter的值
}

@Override
public boolean shouldFilter() {
// 判断:仅处理来自post过滤器引起的异常
RequestContext ctx = RequestContext.getCurrentContext();
ZuulFilter failedFilter = (ZuulFilter) ctx.get("failed.filter");
if(failedFilter != null && failedFilter.filterType().equals("post")) {
return true;
}
return false;
}

}

到这里,我们的优化任务还没有完成,因为扩展的过滤器处理类并还没有生效。最后,我们需要在应用主类中,通过调用FilterProcessor.setProcessor(new DidiFilterProcessor());方法来启用自定义的核心处理器以完成我们的优化目标。

本文节选自《Spring Cloud微服务实战》并稍做加工,转载请注明出处


相关阅读

  • 《Spring Cloud实战小贴士:Zuul统一异常处理(一)》
  • 《Spring Cloud源码分析(四)Zuul:核心过滤器》
  • 《Spring Cloud实战小贴士:Zuul处理Cookie和重定向》
  • 《Spring Cloud构建微服务架构(五)服务网关》

money.jpg

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/477481.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

论文浅尝 | Explainable Link Prediction in Knowledge Hypergraphs

笔记整理:陈子睿,天津大学硕士论文链接:https://dl.acm.org/doi/10.1145/3511808.3557316动机知识超图链接预测已被认为是各种知识使能下游应用的关键问题。然而,大多数现有方法主要以黑盒方式执行链接预测,它们学习实…

吴恩达入驻知乎,涨粉秒过万!知乎首答:如何系统学习机器学习

文 | 卖萌酱大家好,我是卖萌酱。昨天在知乎timeline上刷到一个问题:虽然卖萌酱已经不需要系统学习机器学习了,但无意间发现最高赞的id竟然叫“吴恩达”??好家伙,看了看回答日期,是4月8号。戳进去…

学术会议|第六届知识图谱论坛CNCC-知识图谱赋能大数据大算力

CNCC2022将于12月8日至10日在贵州省贵阳市国际生态会议中心举办,今年CNCC技术论坛数量达到122个,内容涵盖了“计算行业、人工智能、云计算、教育、安全”等30个方向。本文特别介绍将于12月9日举行的【第六届知识图谱论坛-知识图谱赋能大数据大算力】。报…

LeetCode 第 18 场双周赛(188/587,前32%)

文章目录1. 比赛结果2. 题目LeetCode 1331. 数组序号转换 easyLeetCode 1328. 破坏回文串 mediumLeetCode 1329. 将矩阵按对角线排序 mediumLeetCode 1330. 翻转子数组得到最大的数组值 hard1. 比赛结果 做出来了1, 2, 3题,第4题提交超时 2. 题目 LeetCode 1331.…

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

在上一篇《Spring Cloud源码分析(四)Zuul:核心过滤器》一文中,我们详细介绍了Spring Cloud Zuul中自己实现的一些核心过滤器,以及这些过滤器在请求生命周期中的不同作用。我们会发现在这些核心过滤器中并没有实现error…

ACL’22 | 为大模型定制的数据增强方法FlipDA,屠榜六大NLU 数据集

本文转载自公众号“夕小瑶的卖萌屋”,专业带逛互联网算法圈的神操作 -----》我是传送门 关注后,回复以下口令: 回复【789】 :领取深度学习全栈手册(含NLP、CV海量综述、必刷论文解读) 回复【入群】&#xf…

技术动态 | 面向可解释性的知识图谱推理研究

导读:本次演讲的主题是面向可解释性的知识图谱推理研究,报告分为以下 5 个部分:研究背景前沿进展研究动机近期研究研究展望分享嘉宾|万国佳 武汉大学 计算机学院 博士后编辑整理|xiaomei出品平台|DataFunTa…

LeetCode 1332. 删除回文子序列

1. 题目 给你一个字符串 s,它仅由字母 ‘a’ 和 ‘b’ 组成。每一次删除操作都可以从 s 中删除一个回文 子序列。 返回删除给定字符串中所有字符(字符串为空)的最小删除次数。 「子序列」定义:如果一个字符串可以通过删除原字符…

Spring Cloud源码分析(四)Zuul:核心过滤器

通过之前发布的《Spring Cloud构建微服务架构(五)服务网关》一文,相信大家对于Spring Cloud Zuul已经有了一个基础的认识。通过前文的介绍,我们对于Zuul的第一印象通常是这样的:它包含了对请求的路由和过滤两个功能&am…

预训练再次跨界!百度提出ERNIE-GeoL,地理位置-语言联合预训练!

源 | 百度NLP本文介绍『文心大模型』的一项最新工作:“地理位置-语言”预训练模型ERNIE-GeoL。论文链接:https://arxiv.org/abs/2203.09127实践中的观察近年来,预训练模型在自然语言处理、视觉等多个领域都取得了显著效果。基于预训练模型&am…

LeetCode 1333. 餐厅过滤器(Lambda排序)

1. 题目 给你一个餐馆信息数组 restaurants,其中 restaurants[i] [idi, ratingi, veganFriendlyi, pricei, distancei]。你必须使用以下三个过滤器来过滤这些餐馆信息。 其中素食者友好过滤器 veganFriendly 的值可以为 true 或者 false,如果为 true …

Spring Cloud实战小贴士:Zuul处理Cookie和重定向

由于我们在之前所有的入门教程中,对于HTTP请求都采用了简单的接口实现。而实际使用过程中,我们的HTTP请求要复杂的多,比如当我们将Spring Cloud Zuul作为API网关接入网站类应用时,往往都会碰到下面这两个非常常见的问题&#xff1…

论文浅尝 | Language Models (Mostly) Know What They Know

笔记整理:程思源、梁孝转,浙江大学在读硕士,研究方向为知识图谱的表示学习,自然语言处理,预训练对于一个语言模型,我们最终希望得到一个“诚实”的人工智能系统,即语言模型需要准确并且忠实地评…

百度AI技术盛宴来了!大咖齐聚解读CV/NLP/跨模态大模型技术!

随着人工智能步入工业大生产阶段,AI大模型正在加速走出实验室,在全球范围内逐步实现产业落地应用的突破。自2020年至今,越来越多的科技巨头和科研机构参与其中。去年12月,百度发布了全球首个知识增强千亿级大模型——鹏城-百度文心…

Spring Cloud实战小贴士:健康检查

今天在博客的交流区收到一条不错的问题,拿出来给大家分享一下。具体问题如下: 因为项目里面用到了redis集群,但并不是用spring boot的配置方式,启动后项目健康检查老是检查redis的时候状态为down,导致注册到eureka后项…

恕我直言,你的模型可能并没看懂 prompt 在说啥

本文转载自公众号“夕小瑶的卖萌屋”,专业带逛互联网算法圈的神操作 -----》我是传送门 关注后,回复以下口令: 回复【789】 :领取深度学习全栈手册(含NLP、CV海量综述、必刷论文解读) 回复【入群】&#xf…

开源开放 | 区域供冷供热系统及空调系统知识图谱

OpenKG地址:http://openkg.cn/dataset/less开放许可协议:CC BY-SA 4.0 (署名相似共享)贡献者:浙江大学(赵阳,李婷婷,章超波)1、背景区域供冷供热系统及空调系统领域涉及知…

LeetCode 1334. 阈值距离内邻居最少的城市(最短路径Dijkstra)

1. 题目 有 n 个城市,按从 0 到 n-1 编号。给你一个边数组 edges,其中 edges[i] [fromi, toi, weighti] 代表 fromi 和 toi 两个城市之间的双向加权边,距离阈值是一个整数 distanceThreshold。 返回能通过某些路径到达其他城市数目最少、且…

五个同事想计算他们的平均工资,但公司不让吐露薪资,如何实现?

源 | Xpecya知乎大家好我是卖萌酱。昨天在知乎上刷到一个很有意思的问题:“五个同事决定计算他们的平均工资,在大家互相不告诉薪水的情况下,如何才能做到这一点?”。确实互联网公司是不让员工讨论薪资的,但通过一些神操…

基于Consul的分布式信号量实现

本文将继续讨论基于Consul的分布式锁实现。信号量是我们在实现并发控制时会经常使用的手段,主要用来限制同时并发线程或进程的数量,比如:Zuul默认情况下就使用信号量来限制每个路由的并发数,以实现不同路由间的资源隔离。 信号量(…