资讯专栏INFORMATION COLUMN

漫谈Exception与Result

张利勇 / 3482人阅读

摘要:分析性能的影响但是需要注意时间单位,只是微秒而已,毫秒的千分之一秒的百万分之一。在这种情况下,优化毫秒的性能隐患无异于捡了芝麻丢了西瓜。

同步自:https://sulin.me/2019/T2ZXZB....

在分布式系统开发中,我们经常需要将各种各样的状态码、错误信息传递给最外层的调用方,这个调用方通常是http/api接口,错误信息比如登录失效参数错误等等。

最外层接口暴露的数据通常是类似于{code, msg, data}这样的json格式,这一点没有任何争议。

但是分布式系统的节点之间RPC调用、节点内部方法调用中,通常会用ServiceExceptionResult的方式进行错误信息的传递,这两种方式有什么区别以及孰优孰劣呢?本文侧重于开发效率系统性能探讨这个问题。

Result介绍

这是一种比较常见的错误信息传递方式,某些大厂甚至直接将它们设为技术规范,强制各个团队采用这种方式。常见的Result模板如下:

@Data
public class Result {
    private int code; // 也可以是String等
    private String msg;
    private T data;
}

在系统开发中的应用通常是这样的:

Result userModelResult = userService.query(userId);
if (!userModelResult.isSuccess() || userModelResult.getData != null) {
    return Result.fail(userModelResult); // 透传错误
}
UserModel userModel = userModelResult.getData();
if (userModel.getStatus() != UserStatusEnum.NORMAL) {
    return Result.fail("user unavaliable"); // 用户不可用
}
// ... 正常使用UserModel

在比较复杂的分布式微服务环境中,类似的代码非常之多,每个依赖服务的调用都伴随着一段类似的容错逻辑。

这种模式比较类似Golang语言中的错误码处理,这也是Golang比较被人诟病的地方,即每一步都得进行错误判断。

更残酷的现实是,尽管有了Result封装,但是仍然会有后端系统的Exception透传过来。在我接触过的实际应用中,这种突破Result封装的异常透传绝非个例,我自己负责的系统在调用更后端的国内最强交易系统时,就曾接到过最内部交易中心TC的业务异常,排查问题时追踪的团队就有不止5个。

ServiceException介绍

顾名思义,这个方式就是使用异常中断将正常逻辑与异常逻辑进行拆分。

在系统开发中,大部分错误都需要直接中断服务,直接将错误反馈给用户,正因为如此,我们在使用Result时,经常需要写类似if(result.isFail()){return…}这样的代码。而使用ServiceException,我们就可以省略掉绝大部分类似的代码。

通常ServiceException可以这样定义:

@Getter
public class ServiceException extends RuntimeException {
    private final int code;
    private final String msg;
    public ApiException() {
        this(-1, null);
    }
    public ApiException(Code code) {
        this(code, null);
    }
    public ApiException(Code code, String msg) {
        super(msg);
        this.code = code;
        this.msg = msg;
    }
}

系统内部组件在遇到数据缺失越权访问登录失效账户锁定等异常情况时,直接抛出ServiceException中断逻辑,然后由最外层的FilterAspect捕捉异常,提取其中的codemsg返回给用户。

实际使用的代码逻辑类似这样:

UserModel userModel = userService.query(userId); // userID不存在、不可用等隐藏在异常中
// ... 使用userModel

这种方式明显优雅、精简了许多,对于开发效率的提高以及后期维护都有帮助。

但是在坊间有许多流言声称,使用异常中断会影响性能,甚至有人通过简单的性能测试推出异常中断的性能耗时比返回Result快几百倍云云。

性能测试

针对性能问题,我也进行了一个简单的测试,具体测试代码参见:

https://github.com/sisyphsu/b...

这里使用JMH进行性能测试,说到benchmark,真的是羡慕golang语言自带的test库,实在是太方便了。

测试内部的业务逻辑非常简单,只是调用一次System.currentTimeMillis()并返回long时间戳。

性能测试中分别使用Result返回值以及抛出Exception,针对抛出异常的性能测试,又增加的不同深度的调用栈测试,这是因为Java在抛出异常时,需要分析当前Thread的栈,而调用栈越深,所造成的性能损耗就越大。具体栈深度取值为1、10、100:

Test.test                  avgt    5  0.027 ± 0.001  us/op
Test.testException         avgt    5  1.060 ± 0.045  us/op
Test.testDeep10Exception   avgt    5  1.826 ± 0.122  us/op
Test.testDeep100Exception  avgt    5  9.802 ± 0.411  us/op

乍一看,异常栈深度为100的性能损耗确实是普通方法调用的360倍,有的人也确实是基于这种理由得出Java异常中断性能损耗严重的结论。

分析性能的影响

但是需要注意时间单位,只是微秒而已,毫秒的千分之一、秒的百万分之一。

假设某个微服务单CPU吞吐量为1000QPS,而其中有10%是非法请求,那么异常中断的性能损耗也只是万分之一而已,对于服务耗时的影响也只是0.001毫秒而已。

在性能测试中,业务耗时只是获取系统时间,大概耗时为25ns。正因为如此才显得异常中断的性能损耗达到恐怖的“几百倍”,但是如果业务耗时从25ns变为25us25ms呢?

再谈性能瓶颈

我们在分析系统性能时,一定要搞清楚它的数量级以及性能瓶颈,切记陷入性能优化的困境。

举个粗糙例子,在常规服务中,利用了索引的DB操作在1~10毫秒之间,访问分布式Cache的耗时在3~30毫秒之间,微服务RPC的网络性能损耗在3~10毫秒之间,客户端与服务器之间的网络耗时在5~300毫秒之间,如此之类等等。在这种情况下,优化0.001毫秒的性能隐患无异于捡了芝麻丢了西瓜。

我曾经写过类似TCP的底层网络协议,在那种高频场景中,算法优化带来0.1微秒的性能优化就意味着每秒钟吞吐量几成甚至几倍的提升,但是在分布式调用的低频场景中,这种性能用处没有任何用处。

另外一个例子,几年前我和同事在讨论DB数据表设计时,因为订单状态使用什么长度的int而争执的面红脖子粗,现在想想,订单状态上优化的1个字节,长年累月下来也只是节省不到1MB的磁盘空间而已,有什么用呢?

RPC中的异常中断

对于使用Dubbo、HSF这种远程调用框架而言,使用异常中断进行错误信息传递,需要注意一点就是,异常类型需要设计为通用的,即各个微服务都引用的基础类型。

在某厂的技术规范中有说到:

1) 使用抛异常返回方式,调用方如果没有捕获到就会产生运行时错误。

2) 如果不加栈信息,只是new自定义异常,加入自己的理解的error message,对于调用端解决问题的帮助不会太多。如果加了栈信息,在频繁调用出错的情况下,数据序列化和传输的性能损耗也是问题。

我对这种技术规范相当的不以为然。

首先业务异常本来就需要调用方透传给最外层,诸如数据不存在登录失效用户锁定这种异常,中间的调用方捕获了也往往没有什么用。

其次又是鬼扯性能损耗,这种低频的数据序列化和内网传输会有什么样的性能损耗呢?栈信息透传给调用方也有益于故障排查,我曾经接到过TC的异常栈信息,根据栈中的package直接就绕过三四层找到了底层出错的地方,可以说是节省了大量的时间。

结论

在分布式微服务中,采用异常中断可以大幅精简业务代码,对于性能的影响也微乎其微。

辅助以@NotNull@Nullable等注解,可以让分布式开发如风一般的快速便捷。在复杂的服务网络中,业务异常也可以方便开发人员精确地定位错误,避免大家顺着调用链一层一层地追踪故障点的尴尬情景。

文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/73640.html

相关文章

  • 漫谈js-原型

    摘要:原型链只看构造函数的原型对象和实例化出来的对象。既然构造函数本身是函数,那么和直接调用有什么区别答案揭晓只有通过调用构造函数才会走第二步,也就是原型的委托操作。 原型 相信js开发者都知道原型,原型链,但是很多人晕晕乎乎对此不知甚解。下面分享一下我的个人心得。 学习中的困惑 构造函数,原型,实例对象之间的关系是什么? 原型链是怎么继承的? 既然构造函数本身是函数,那么new和直接调用...

    shuibo 评论0 收藏0
  • 漫谈promise使用场景

    摘要:能帮我们解决什么痛点实现异步执行,在未出现前,我们通常是使用嵌套的回调函数来解决的。那么,接下来我们看一下使用的实例可以传入两个参数表示两个状态的回调函数,第一个是,必选参数第二个是,可选参数的方便之处。 深入理解promise 对于现在的前端同学来说你不同promise你都不好意思出门了。对于前端同学来说promise已经成为了我们的必备技能。 那么,下面我们就来说一说promise...

    刘德刚 评论0 收藏0
  • [前端漫谈_2] 从 Dva 的 Effect 到 Generator + Promise 实现异步

    摘要:你能学到什么如何使用实现异步编程异步编程的原理解析前言结合上一篇文章,我们来聊聊基础原理说到异步编程,你想到的是和,但那也只是的语法糖而已。表示一个异步操作的最终状态完成或失败,以及其返回的值。至此实现异步操作的控制。 你能学到什么 如何使用 Generator + Promise 实现异步编程 异步编程的原理解析 前言 结合 上一篇文章 ,我们来聊聊 Generator 基础原理...

    pekonchan 评论0 收藏0
  • [前端漫谈_1] 从 for of 聊到 Generator

    摘要:数据的层级意味着迭代数据结构并提取它的数据。对于技术人而言技是单兵作战能力,术则是运用能力的方法。在前端娱乐圈,我想成为一名出色的人民艺术家。 聊聊 for of 说起 for of 相信每个写过 JavaScript 的人都用过 for of ,平时我们用它做什么呢?大多数情况应该就是遍历数组了,当然,更多时候,我们也会用 map() 或者 filer() 来遍历一个数组。 但是就...

    miqt 评论0 收藏0

发表评论

0条评论

最新活动
阅读需要支付1元查看
<