操作日志设计思路

需求

在产品的使用过程中，经常要针对某个订单表、申请表等进行操作日志记录，希望有一个统一的服务可以一次性解决这个痛点

设计思路

服务结构图

• client模块注解介绍：

注解	介绍	参数
@OperationLog	在DAO(MAPPER)层的方法上添加此注解，表示会发送日志请求	tableName-表名;type-操作类型;remark-备注;primaryTable-是否主表,如果有@Transactional注解 需要标记此字段
@OperationLogAlias	在参数实体类的字段里，添加此字段，表示显示的名字，不以数据库的备注，而是以此	key-字典表的key;type-别名类型;dataBaseName-库名;tableName-表名;fieldName-字段名;fieldId-表的id;attributeAlias-显示名字的别名
@OperationLogIgnore	在参数实体类的字段里，添加此字段，表示忽略此字段，不会保存到日志服务

• 数据库设计

操作表operation_{{databaseName}}，例：保存car库的车辆申请信息apply，databaseName：car

字段	类型	备注
database_name	char	目标的数据库名，如：car
table_name	char	表名，如：apply表
object_id	char	apply表的主键id
group_id	char	分组id，apply有扩展信息也要保存，那么在同一组，一般取apply表的主键id
operator	char	操作人姓名
operation_type	char	操作类型名称，比如，新增 保存
operation_alias	char	操作的别名，对于调皮的产品，总是有奇怪的想法，比如：某某人，左脚一跺，一条订单隐隐浮现到订单榜中

属性表attribution_{{databaseName}}

字段	类型	备注
operation_id	char	操作表id
attribute_alias	char	属性别名
old_value	char	旧值
new_value	char	新值
remark	char	备注：将{{attribute_alias}}由{{old_value}}改成{{new_value}}，写在触发器插入的时候

优点 | Advantages

• 独立性 日志服务和其他服务独立开来，耦合小。
• 使用简单 通过注解，轻松解决日志问题。
• 开发成本小 服务端不关注日志的实现，无需建表，无需重复写CRUD操作。
• 灵活度高 对于个别需求给出了扩展接口。
• 损耗小 客户端只负责发送日志，产生在日志服务实现。