今天是孤尽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实
现复杂多变的业务异常需求