操作留痕功能实现与探讨

操作留痕功能实现与探讨

背景

接手了一个单体应用项目，看系统介绍，说实现了【高性能的操作日志留痕】功能，就有点好奇它是怎么设计的，是阻塞队列还是怎样的线程池。结果我打开代码一看，真的是笑洗个人了。它是做了一个接口给前端去调用，代码和多线程一分钱关系都没有，直接是调用到接口，拼装了一下内容就入库了。这玩意哪里高性能了，url远程调用性能高？同步代码高？倒不是说这种方案完全不可取，文末会分析一下这适用于什么场景和优化建议。

最常用操作留痕设计

基于后端去实现操作留痕都会不可避免地对原代码有侵入性，但是我们要想出入侵性最低的方案——基于注解去实现。这么一来我们只需要在方法上加上一个注解和一些参数的设置，就可以完成操作日留痕功能的嵌入了。

操作留痕相对于主业务来说，它并不是重要的部分，所以我们没必要去等待操作留痕功能入库完成后再返回数据。操作留痕对于用户来说是无感的，应该用异步去实现。

编码实现

1.罗列操作留痕需要记录什么信息，哪些信息是可以自动获取的，哪些是要Hard Code的

package org.example.springboot.job.domain;

import lombok.Data;

import java.util.Date;

@Data
public class OptLogRecord {
    private Long id;    		// 主键
    private String userName; 	// 操作人员
    private String userId;		// 用户id

    private String optFunc;     // 菜单功能模块
    private String menuTitle;    // 具体的菜单
    private String optButton;     // 按钮

    private String status;      // 操作结果

    private Date optTime;       // 操作时间

    private String optReturn;   // 返回结果

}

以上是最基本的操作留痕信息，进阶考虑的话，可以有：请求参数、操作ip、操作地点、请求url、失败后的错误信息等。

其中，功能模块、菜单、按钮 这些业务类的信息是我们程序中无法区分的。当然，如果你能维护非常完美的方法名与业务信息的匹配枚举的话，那么我们可以通过切点获取方法名再映射出对应的业务信息。嗯，确实不错，就是有点麻烦。在这里我就使用Hard Code的方式去实现了。有需要的可以自己去实现方法名与业务信息的映射关系。

2.创建注解

package org.example.springboot.job.annotation;

import java.lang.annotation.*;

@Target({ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface OptLog {

    String optFunc() default "";	// 功能模块
    String menuTitle() default "";	// 菜单标题
    String optButton() default "";	// 按钮

}

3.对使用了注解的方法进行切面织入

导入依赖

<dependency>
    <groupId>org.aspectj</groupId>
    <artifactId>aspectjweaver</artifactId>
    <version>1.9.6</version>
</dependency>

创建切面类

@Aspect
@Component
public class OptLogAspect {
    
}

以下代码内容均为OptLogAspect中的内容，为了方便步骤讲解，拎出来说明

1. 指明该切面指向的切点为OptLog

       @Pointcut("@annotation(org.example.springboot.job.annotation.OptLog)")
       public void optLogPointCut() {}
   

2. 我们需要在使用注解的方法执行完成之后再记录他操作的信息

       // 这个result是使用了注解的方法的返回值
       @AfterReturning(pointcut = "optLogPointCut()", returning = "result")
       public void doAfterReturning(JoinPoint joinPoint, Object result) {
           handleOptLog(joinPoint, result, "SUCCESS");
       }
   

   这个handleOptLog方法还没实现，别急

3. 如果出现了异常呢，那肯定是操作失败了，我们也要记录操作失败的信息

       @AfterThrowing(value = "optLogPointCut()")
       public void doAfterThrowing (final JoinPoint joinPoint) {
           handleOptLog(joinPoint, null, "FAILED");
       }
   

4. 实现handleOptLog方法

       protected void handleOptLog(final JoinPoint joinPoint, Object result, String status) {
           MethodSignature methodSignature = (MethodSignature) joinPoint.getSignature();
           OptLog optLog = methodSignature == null ? null : methodSignature.getMethod().getAnnotation(OptLog.class);
           if (optLog == null) return;
   
           // TODO:获取当前用户 根据自己系统方式去获取用户
   
           OptLogRecord record = new OptLogRecord();
           // TODO: 设置用户名与用户id略过
   
           record.setStatus(status);    // 根据不同的切面来区分是否操作成功
           record.setOptReturn(result.toString());
           
           record.setOptTime(new Date());
   
           // 读取使用注解时的参数
           record.setOptFunc(optLog.optFunc());
           record.setMenuTitle(optLog.menuTitle());
           record.setOptButton(optLog.optButton());
   
           // 异步保存数据库
           TimerTask task = new TimerTask() {
               @Override
               public void run() {
                   // insert语句保存到数据库
                   System.out.println("insert：" + record.toString());
               }
           };
           ScheduledExecutorService executorService = Executors.newSingleThreadScheduledExecutor();
           executorService.schedule(task, 10, TimeUnit.MILLISECONDS);
       }
   

   这里的异步日志是使用定时任务线程去完成，延时10ms执行，不影响原本的方法执行效率。

注解使用示范

    @GetMapping("/test")
    @OptLog(optFunc = "系统管理", menuTitle = "菜单管理", optButton = "添加菜单")
    public String testCall() throws InterruptedException {
        Thread.sleep(1000);
        log.info("hello");
        AtomicInteger integer = new AtomicInteger();
        return "test";
    }

睡眠1秒模拟非常复杂的业务执行时间，测试结果如下

总结

到此该操作留痕功能基本已经实现完成，有些地方还需要继续优化和规范化。比如使用枚举、常量去规范一些Hard Code。

回到上面的问题，这种通过调用接口去实现操作留痕的方案，适用于对后端业务无法切入的情况。比如你开发的是一款具备身份权限校验等功能的快速框架，别人通过调用你的jar包即可改造自己已有的系统。为了方便别人的开发，不对已有代码进行过多的改造，那就只能通过这种调接口的方式实现操作留痕。

前端基于axios的拦截器，对发起的请求进行拦截，将操作记录信息通过接口调用的方式保存。这种方案的最大缺点就是对于大多数的业务场景都需要多进行一次http请求，这种性能开销不可忽视。如果说前端对操作留痕的http请求使用异步，那么日志留痕的可靠性也会降低不少，但随之提升的性能也会非常多。

当http请求到达后端时，后端采用异步入库，也可以提升不少的性能，但前端就无法得知操作留痕是否完成。