文章来源: 陈同学|异常处理实践
本文分享自己关于异常处理的理解。
产品是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
上面扯了很多异常效果，下面展示下我们团队的邮件预警效果(数据无实际意义，拼凑而成)：
