通过切面记录业务日志记录的一种模式

挑水做饭 2020年04月22日 211次浏览

## 背景

我们在做业务系统研发的时候,总会有这种需求,用户做了哪些操作、修改了哪些数据都需要记录下来,有没有一种通用的方式来记录业务日志并且与业务逻辑解耦,今天我们就来讲一种通过切面来记录日志的一种方式,并通过约定对开发流程定一些基本的规范来达到减少硬编码的目的。

原理

1、【客户端】提交的内容都是变更内容的核心参数,非变更内容不提交。所有修改操作 Request Body 需要绑定 提交前的变更内容快照。

2、【服务端】通过自定义注解 + 拦截器方式,解析参数并模板化变更内容。

规范

1、注解 @ApiLog 标记
【服务端】所有修改操作(新增/修改/删除/上线/下线/...)的Controller方法上,都需要标记 @ApiLog 。只有带上 @ApiLog 拦截器才能识别,并保存操作记录。示例如图一:
在这里插入图片描述
图一

  • ApiLog,包含两个属性,name 表示操作名称,act 表示操作动作。
  • 所有返回 Result 都需要 带上 withId 。因为这里离ID最近,因此也最方便。如果要在拦截器中萃取,判断太多。因此,在这里统一加上。

2、新增/修改POST提交
a、【客户端】所有新增/修改操作都必须是POST的提交方式为RequestPayload。Content-Type: application/json

b、【客户端】所有修改操作提交,只需要提交变更参数和对应的主键ID。

c、【服务端】Controller 方法入参只能有1个 RequestBody,且必须继承 BaseDO 基类。

3、修改操作须绑快照
1、【客户端】客户端提交修改操作时,需要在 Request Body 中绑定 snapshot 参数和值。snapshot的值表示修改提交之前的快照。格式和外面保持一致。如图所示:
在这里插入图片描述
图二
在这里插入图片描述
图三
在这里插入图片描述
图四
4、入库结果示例
在这里插入图片描述
其中 request_params 为提交入库参数模板化内容。

解析request_params字段,需要根据两个参进行判断:操作类型(日志) 和 参数形式(日志)

当 action_type = 修改 且 param_type = Body 时,内容如:[{"after":"aiqiyi211","before":"aiqiyi111","key":"apk包名"}],前后记录都有了。
其他情况,内容如:[{"key":"ID","value":9}]