异常处理实践

文章来源: 陈同学|异常处理实践

本文分享自己关于异常处理的理解。

产品是2B业务，且用户量小，因此以下思考均基于这个前提。

为什么需要异常处理机制？

良好的异常处理机制带来许多好处，例如：

• 及时发现问题，别让用户找上门时我方还一头雾水

• 辅助开发人员准确定位问题

• 统计分析

  …...

异常机制要达到什么效果？

异常信息受众有两类：人和机器.

• 人：用户、运营、开发人员等
• 机器：根据状态码程序进行处理

针对受众，各方的需求可能有：

• 用户：给用户看得懂的反馈，例如：密码错误
• 运营：根据信息能判断 哪个用户、在什么时候、做什么操作时、发生了什么问题
• 开发人员：根据信息能判断用户环境(用户、Token等)、请求信息(请求方式、数据格式、请求的数据、URL、请求时间)、异常信息(stacktrace、异常状态码、异常消息)、日志信息(报错时的关键ID、单据等)、服务信息(哪个服务、哪个实例、在哪台机器)等

如何进行异常预警？

异常预警要根据团队及业务情况来，初创团队简单处理，有余力再好好整。

• 简单处理：出现异常发个邮件通知即可
• 稳妥处理：由于非工作时间大家不一定看邮件，严重异常除普通预警，还可以进行：短信通知、微信通知、自动语音拨号等措施，做到哪怕人在睡觉，只要通讯正常，也能把人抓起来

有余力可以自建异常处理平台，有一套异常处理流程，有个炫酷且实用的Dashboard。

SpringCloud网关处理异常案例

目前我们使用的异常处理方式，请根据红色序号阅读：

案例

网关异常处理

流程简析：

• 1.用户发起请求，经负载均衡后最后达到网关
• 2.网关路由到具体的服务某实例
• 3.服务实例运行时抛出了异常，服务需在最上层捕获异常并封装好数据返回到网关.

例如：结合@ControllerAdvice + @ExceptionHandler捕获异常，创建一个异常处理starter让各个服务直接引用maven依赖，starter中直接注入异常处理Bean，这样具体服务开发时不用关心异常处理，专注业务即可。同时将异常处理与业务模块解耦，便于后续拓展异常处理。

• 4.服务返回封装好的数据返回到网关
• 5.网关针对异常处理进行处理，为了保证性能，网关仅初步处理异常

e1.解析异常码: 由网关解析异常码的好处是：具体服务只需要用枚举类定义异常状态码，不需要关心异常对应的提示信息。同时也只需要网关连接到缓存(例如:redis)。

e3.纠正HTTP状态码：网关和具体服务之间可以通过任意状态码通讯，但到网关时必须将HTTP状态码调整为HTTP标准状态码

• 6.用户得到可读的反馈信息

为什么用网关处理异常？

出于以下几个考虑，使用了网关来处理异常：

• 若异常交给具体服务处理，那么各个团队在代码中处理异常的方式将 "形色各异"，不好统一管理
• 开发人员应该专注于业务，知道合理的抛出异常即可，具体服务不应该重复做相同的事情
• 异常状态码对应的异常消息应该统一读取，具体的服务不允许直接访问缓存服务器
• 异常处理流程本身较为复杂，例如：持久化、预警等，各个服务不需要做同样的事情

这个思路和AOP的理念有点类似

预警数据Demo

上面扯了很多异常效果，下面展示下我们团队的邮件预警效果(数据无实际意义，拼凑而成)：

exception mail