SpringAop实战之记录关键业务请求分析

　　AOP，中文名称，切面。在不影响业务代码情况下，实现想要的功能，是个真炫酷的事。这不，最近来了个需求 。

　　业务需求：希望记录多个关键业务的请求及操作情况！这本身是ok的，但是这些需求规律性太强，咱们不能硬干，否则就一个字low。

　　aop是个好东西，记录日志是必须的。

　　记录数据也一样的，那么也是可以用aop来实现的，这里借助注解一起解决问题吧。

　　因为是关键业务，所以意味着不是所有业务，那么自然地就想到了，可以使用过滤的方式，也就是使用注解，如果有注解那么就代表要记录数据，否则不记录。

　　记录过程需要做什么呢？

　　首先，因为是记录业务数据，那么我们可以抽象出一个方法出来，也就是 xxx.addRec()。也就是就切面里只需调用记录方法即可。

　　那么还剩下几个问题，怎样找到这个方法？参数的处理怎么办？需要使用规范限制吗？

　　找到这个方法，我们可以使用反射调用，当然需要注解进行调用的类和方法名称（如果固定死则无需标注），用反射的好处就是自由，想怎么写就怎么写，要么失败要么成功。但是low！

　　参数判定，可以根据输入的类，进行if..else.. 判定，然后直接处理相应参数即可。这样可以很自由，想怎么写参数就怎么写参数。但是这样的话，这个切面就和业务代码完全耦合在一起了，还多了n多无谓的判断。很low！

　　那么问题来了，怎样才不low呢？

几个理论可以借鉴下：

　　1. 面向接口编程而非面向类编程；

　　2. 使用枚举值进行注解统一规划；

　　3. 使用泛型，进行参数上下限处理；

　　4. 使用模板方法模式封装参数；

　　5. 使用线程池；

让我们细看下～

　　面向接口编程，即规定所有业务处理类都实现一个公共的接口，从而使方法不至于凌乱，定义一个清晰的接口，更易于理解含义。各实现类只需关注自己的逻辑即可。
使用枚举值进行注解参数的限定，可以使所有业务操作都在一处进行罗列，且都符合必须的规范。另外，当哪天发现参数无法满足某些需求时，可方便地在该枚举中加入相应参数以完成需求。
　　使用泛型，将参数限定一定范围内，如要求入库参数必须继承某个基类以实现统一参数处理，也防止了传入任意参数而必须做相应转换的性能消耗。
　　使用模板方法模式进行参数封装，因入参中都要求继承一个基类，也就是具有共性的参数，所以应具备自动处理公共参数的能力，但是不可越权处理各业务实现的处理，应让实现类有能力自行处理个性化参数（实现类也可以不处理）。交由实现类处理个性化参数时，应使其具有绝对的能力，不应限制其发挥。
　　使用线程池技术，将额外的工作交给额外的线程，从而使主业务不爱影响。
具体代码撸一遍：
1. 注解开启新篇章，无注解，不工作。

@Component
public class UserTestService {

// 添加注解，代表需要进行相应的逻辑处理
@BizRecordTrans(bizType = BizRecordTypeEnum.USER_ADD_FLOW)
public ResponseEntity<Boolean> addUser(UserlDto terminalReq) {
ResponseEntity<Boolean> ret = ResponseBuilder.buildResponse();
// 完成自己的业务...
return ret;
}
}

2. 切面配置，做一个幕后的老兵。

@Component
@Aspect
public class BizRecordAop {
private Logger logger = LoggerFactory.getLogger(this.getClass());

@Around("execution(* com.xxx.dubbo.*.*(..))) and @annotation(com.xxx.spring.annotation.BizRecordTrans)")
public Object deal(ProceedingJoinPoint pjp) throws Throwable {
Object retVal = null;
String methodName = pjp.getSignature().getName();
Object[] args = pjp.getArgs();
Class<?> classTarget = pjp.getTarget().getClass();
Class<?>[] argTypes = ((MethodSignature) pjp.getSignature()).getParameterTypes();
Method objMethod = classTarget.getMethod(methodName, argTypes);
BizRecordTrans bizRecordTrans = objMethod.getAnnotation(BizRecordTrans.class);
BizRecordTypeEnum bizRecordTypeEnum = null;
if (BizRecordTrans != null) {
bizRecordTypeEnum = BizRecordTrans.bizType();
}
try {
retVal = pjp.proceed();
} catch (Exception e) {
// ignore
throw e;
} finally {
if (bizRecordTrans != null) {
Class<? extends SvcBaseEntity> bizRecEntityCls = bizRecordTypeEnum.getBizRecEntityCls();
SvcBaseEntity recEntity = (SvcBaseEntity) bizRecEntityCls.newInstance();
if (args[0] instanceof BaseDto) {
BaseDto baseDto = (BaseDto) args[0];
fillBaseFields(recEntity, baseDto);
}
try {
ThreadPoolTaskExecutor executor = (ThreadPoolTaskExecutor) SpringContextsUtil.getBean("threadPoolTaskExecutor");
executor.execute(() -> {
BizRecBaseService<BaseEntity> recService = (BizRecBaseService<SvcBaseEntity>) SpringContextsUtil
.getBean(bizRecordTypeEnum.getHandlerBeanName());
recService.fitOwnParams(recEntity, args);
recService.addRecord(recEntity);
});
} catch (Exception e) {
logger.error("发生异常", e);
}
}
}
return retVal;
}

/**
* 填充公共参数
*/
private void fillBaseFields(BaseEntity baseEntity, BaseDto base) {
baseEntity.setUserId(base.getUserId());
baseEntity.setSeqId(base.getSeqId());
baseEntity.setAddIp(base.getAddIp());
}
}

3. 写一个基础接口，让业务去实现。

public interface BizRecordBaseService<T extends BaseEntity> {
/**
* 执行业务方法
*/
public Integer addRecord(T bizRecord);

/**
* 个性化参数填充方法，选择性实现
*/
default void fixOwnParams(T bizRecord, Object[] rawData) {
System.out.println("可以不实现");
}
}

4. 写一个基础类，让所有其他业务实体继承以实现公共参数的封装。

@Data
public class SvcBaseEntity {
/**
* ID
*/
private Long id;

/**
* 用户ID
*/
private Long userId;

/**
* 请求序列id
*/
private String seqId;

/**
* 添加ip
*/
private String addIp;

}

5. 打一个组合拳，搞定。

　　原理浅显，易懂。性能嘛，也ok，无需太担心。

　　嘿！ 每一个奇怪的业务，都是一次实践的机会。