Day06 错误码

今天是孤尽T31训练营的第六天，总结错误码相关的知识

错误码的功用

系统与系统之间的沟通

系统中没有好的错误码和指定错误异常信息、错误产生原因
调用方不知道发生了什么错误，如何处理

人与人间的沟通

【参考】错误码有利于不同文化背景的开发者进行交流与代码协作。
说明：英文单词形式的错误码不利于非英语母语国家（如阿拉伯语、希伯来语、俄罗斯语等）之间的开发者互相协作

人与系统的沟通

友好的错误码及错误信息的提示，能很好地增进人与系统的沟通

错误码规约

1、定义时要有字母也要有数字
2、要分级分类管理
3、不能直接输出给用户作为 提示信息使用
4、不要与业务架构或者组织架构挂钩
5、使用者避免随意定义新的错误码
6、便于不同语言的开发者之间协作

异常与日志综合实践

• 在Controller层统一捕获异常

下层异常向上抛，到流量出入口（一般在请求处理层）统一处理

各层分布式部署在多台机器时，异常日志是否需要每层单独记录，为什么？
需要每层单独记录，不然：
发生异常后，不同层之间，不知道是哪边的异常，没有记录日志，区分责任找哪个？
确认是本层的异常，没有数据，怎么排查？

• 全局异常处理组件的定义和使用
全局异常处理器GlobalExceptionHandler

• API层异常设计实践
1、严格约束条件判断
2、客户端返回要友好
3、下层异常转译
4、错误码文档要规范

• Service层异常设计实践
1、严格约束条件判断
2、抛出指定类型的异常
3、转译DAO层异常

• DAO数据处理层异常日志实践
通用DaoException
使用继承自Runtime Exception的通用DaoException封装DAO层异常并向上抛出

框架层面有选择性的记录数据操作
在DAO层（框架层面）有选择的记录数据操作的有效信息，比如：
每次操作的原始SQL 语句及其执行时间

实现Mybatis拦截器来记录

• 使用MDC实现轻量级调用链路追踪
分布式链路追踪
将一次分布式请求还原成调用链路，将一次分布式请求的调用
情况集中展示，比如各个服务节点上的耗时、请求具体到达哪
台机器上、每个服务节点的请求状态等等

什么是调用链接追踪，为什么要使用？
对于上图的业务调用流程：发生异常，打印了N多的日志。
排查异常时，异常日志可能分布在不同服务的不同机器的不同文件上
以什么为日志的唯一标识来查找是哪次调用产生的异常？
更长的调用链路，怎样分析那个环节（服务）调用消耗性能更严重？
需要使用到分布式链路追踪

traceID：完整请求链路的ID
parentID：上层调用者ID
spanID：调用者的调用ID

链路跟踪主要功能
• 故障快速定位

通过追踪 添加的参数（一次调用的唯一标识）快速定位故障

• 链路性能可视化

普罗米修斯

• 链路分析

用户行为的分析：用traceID记录时，知道用户在页面上停留了多长时间，在那个操作上停留了多长时间。需要配合前端的追踪技术

• 用有限的异常类处理业务中复杂多变的无限可能
通用ServiceException
定义继承自RuntimeException的
通用ServiceException业务异常

结合ErrorCode
结合与业务关联的ErrorCode实
现复杂多变的业务异常需求