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

背景

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

原理

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}]

《通过切面记录日志》