第五天、日志处理以及一场记录

377 阅读4分钟

1. JAVA异常体系

java异常机制是Java语言特性中很厉害也很重要的一种处理机制。

1. 异常的描述

 - 异常应当描述导致当前异常发生的原因
 - 根据异常栈快速定位到异常发生的位置
 - 结合异常描述和异常栈解决异常

2. Java异常处理流程

以下为try...catch...finally的处理流程 image.png

3. Java的异常处理机制

image.png

4. Java的异常体系

image.png

2. 异常处理设计与实践

1. 异常抛出与捕获原则

  • 非必要不使用异常
  • 使用描述性消息抛出异常
  • 力所能及的异常一定要处理
  • 异常忽略要有理有据

    2. JAVA异常体系捕获

    目前基本上都是使用try...catch...finally体系来进行异常的捕获,但是在JDK7以后对资源的关闭有了一个新姿势tr with resource来对需要关闭资源的流进行捕获。 image.png

    3. NPE场景及其对应的处理对策

    NPE:NullPointException
    • 使用JDK8的Optional优雅的防止NPE
      • 实例化Optional Optional.ofNullable(obj)
      • 使用orElse()方法解决NPE问题。该方法的作用是设置默认值,当发生NPE时,返回指定的默认值
      • 使用ifPresent()方法解决NPE问题。
      • 对象非空判断性能高 当循环总数<10000时,使用Optional与普通的嵌套null非空检测的查询都稳定在30ms。但是当总数循环>10000&<10000000时,Optional比普通嵌套null飞控检测查询性能提升了10-20倍,Option消耗时间稳定在35-65ms之间。当循环总数>10000000时,性能呈指数上升。

3. 日志规约

1. 日志的功能

  • 监控告警
  • 记录行为轨迹
  • 快速定位问题

2. 日志失效规约

  • 当天日志命名。以应用名换.log来保存。
  • 过往日志命名。以{logname}.log.{保存日期}命名,日期格式为:yyyy-MM-dd。
  • 日志文件至少保存15天。便于排查某些以周为频次发生的异常。
  • 敏感信息联机存储6个月。网络安全相关法律的规定。

3. 日志记录规约

  • 系统应使用日志框架(SLF4J,JCL)的API而不时具体日志库中的。
  • 在日志输出时,字符串变量之间的拼接应该使用占位符的方式。使用+会导致性能的消耗。
  • 日志打印时禁止使用JSON工具直接将对象转为String。
  • 尽量用英文来描述日志错误信息。

4. 日志输出规约

  • 日志级别开关判断。对于trace/debug/info级别的日志输出,必须进行日志级别的开关判断。
  • 异常日志信息要完成。应该包括:案发现场信息,异常堆栈信息。
  • 避免重复打印日志。重复打印日志,浪费磁盘空间,务必在日志配置中设置additivity=false

5. 扩展日志的设计与规约

  • 扩展日志单独存储。比如:打点,临时监控,访问日志等。
  • 错误日志单独存储。业务日志与错误日志分开存储。

4. 错误码规约

1. 规约

  • 定义时要有字母也要有数字
  • 要分级分类管理
  • 不能直接输出给用户作为提示信息使用
  • 不要与业务架构或者组织架构挂钩
  • 使用者避免随意定义新的错误码
  • 便于不用语言的开发者之间协作
  • 例如Http错误吗。403:网站访问错误提示。401:一般为登录信息错误。404:找不到资源等等

2. 示例

image.png

5. 异常与日志综合实践

1. 在Controller统一捕获异常

2. 使用全局异常处理组件:GlobalExceptionHandler

3. API层异常设计实践

  • 严格约束条件判断。API层需要保证进入的数据时合法的合规的。包括基本判断约束+实体属性约束。
  • 客户端返回要有好。API层要给客户端返回状态码及其对应的错误消息。
  • 下层异常转义。将Service层、Manager层异常转译为API层异常。
  • 错误码文档要规范。系统状态码对应的异常或错误细腻些以及可能发生异常的原因,要整理成方便用户查阅的文档,同步给接口调用方。

4. Service层异常设计实践

  • 严格约束条件。基本判断约束+实体约束条件+业务条件约束(根据业务来)。
  • 抛出指定类型的异常。Service层抛出带有状态码或者指定类型的异常。
  • 转移DAO层异常。将DAO层的异常转译为Service层或者更高层能够理解的异常。

5. DAO数据处理层异常实践

  • 通用的DaoException并向上抛出。
  • 框架层面有选择性的记录数据操作。

6. 怎么用有限的异常类处理业务中复杂多变的无限可能

  • 定义通用的ServiceException。
  • 结合多变的ErrorCode来对业务的各种情况进行定义。

7. 通过合理的设计降低系统的维护难度

  • 通用模块单独拆分

  • 合理的领域划分

  • 合适的工程结构