操作留痕功能实现与探讨
背景
接手了一个单体应用项目,看系统介绍,说实现了【高性能的操作日志留痕】功能,就有点好奇它是怎么设计的,是阻塞队列还是怎样的线程池。结果我打开代码一看,真的是笑洗个人了。它是做了一个接口给前端去调用,代码和多线程一分钱关系都没有,直接是调用到接口,拼装了一下内容就入库了。这玩意哪里高性能了,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
中的内容,为了方便步骤讲解,拎出来说明
-
指明该切面指向的切点为
OptLog
@Pointcut("@annotation(org.example.springboot.job.annotation.OptLog)") public void optLogPointCut() {}
-
我们需要在使用注解的方法执行完成之后再记录他操作的信息
// 这个result是使用了注解的方法的返回值 @AfterReturning(pointcut = "optLogPointCut()", returning = "result") public void doAfterReturning(JoinPoint joinPoint, Object result) { handleOptLog(joinPoint, result, "SUCCESS"); }
这个handleOptLog方法还没实现,别急
-
如果出现了异常呢,那肯定是操作失败了,我们也要记录操作失败的信息
@AfterThrowing(value = "optLogPointCut()") public void doAfterThrowing (final JoinPoint joinPoint) { handleOptLog(joinPoint, null, "FAILED"); }
-
实现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请求到达后端时,后端采用异步入库,也可以提升不少的性能,但前端就无法得知操作留痕是否完成。