操作日志设计思路
需求
在产品的使用过程中，经常要针对某个订单表、申请表等进行操作日志记录，希望有一个统一的服务可以一次性解决这个痛点
设计思路
服务结构图
- 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操作。
- 灵活度高 对于个别需求给出了扩展接口。
- 损耗小 客户端只负责发送日志，产生在日志服务实现。
