当前位置:网站首页>操作日志设计思路

操作日志设计思路

2021-02-22 11:35:17 那个男孩很坏

需求

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

设计思路

服务结构图
结构图

  • 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操作。
  • 灵活度高 对于个别需求给出了扩展接口。
  • 损耗小 客户端只负责发送日志,产生在日志服务实现。

版权声明
本文为[那个男孩很坏]所创,转载请带上原文链接,感谢
https://www.cnblogs.com/boychen/p/14427666.html