新来的老大，剑走偏锋，干掉AOP做操作日志，实现后我们都惊呆了

前言

用户在操作我们系统的过程中，针对一些重要的业务数据进行增删改查的时候，我们希望记录一下用户的操作行为，以便发生问题时能及时的找到依据，这种日志就是业务系统的操作日志。

本篇我们来探讨下常见操作日志的实现方案和可行性

常见的操作日志类型

• 用户登录日志
• 重要数据查询日志 （但电商可能不重要的数据也做埋点，比如在淘宝上你搜索什么商品，即使不买，一段时间内首页也会给你推荐类似的东西）
• 重要数据变更日志 （如密码变更，权限变更，数据修改等）
• 数据删除日志
• ......

总结来说，就是重要的增删改查根据业务的需要来做操作日志的埋点。

实现方案对比

基于AOP（切面）传统的实现方案

• 优点：实现思路简单；
• 缺点：增加数据库的负担，强依赖前端的传参，不方便拓展，不支持批量操作，不支持多表关联；

基于数据库Binlog

• 优点：解除了数据新旧变化的耦合，支持批量操作，方便多表关联拓展，不依赖开发语言；
• 缺点：数据库表设计需要统一的约定；

方案实现细节

一、基于AOP切面+注解的传统方案

传统的做法就是切面+注解的方式，这种对代码的侵入性不强，通常记录ip、业务模块、操作账号、操作场景、操作来源等等，一般在注解+拦截器里这些值都拿得到，如下图所示：

这种常见的我们在通用方法都可以处理，但是在数据变更方面，一直没有较好的实现方式，比如数据在变更前是多少，变更后是多少。

以我们以前实现的一套方案来说，基于数据变更的记录方式不仅要和需求方约定好模板（上百个字段的不可能都做展示和记录），也要和前端做一些约定，比如在修改之前的值是多少，修改后的值是多少，如下代码客官请看：

    @Valid
    @NotNull(message = "新值不能为空")
    @UpdateNewDataOperationLog
    private T newData;

    @Valid
    @NotNull(message = &#