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