1. 为什么我们需要讨论"不用AOP做操作日志"
在Java企业级开发中，操作日志记录几乎是每个系统必备的功能。传统做法中，AOP（面向切面编程）因其"非侵入式"的特性，常被视为记录操作日志的银弹方案。但我在实际项目中发现，过度依赖AOP反而会带来一系列问题：
- 日志逻辑与业务代码物理分离，导致排查问题时需要频繁切换文件
- 切面中难以获取完整的业务上下文
- 复杂日志逻辑会使切面代码膨胀，违背单一职责原则
- 对异步方法的支持不够友好
最近接手的一个电商平台项目就遇到了典型问题：订单状态变更日志需要记录前后值变化，但AOP切面中无法便捷获取修改前的数据。这促使我开始思考——是否有更合适的日志记录方案？
2. 操作日志的三种实现模式对比
2.1 传统AOP方案解析
典型的AOP日志实现如下：
java复制@Aspect
@Component
public class OperationLogAspect {
@AfterReturning(pointcut = "@annotation(com.example.OperationLog)", returning = "result")
public void afterReturning(JoinPoint joinPoint, Object result) {
// 解析注解参数
MethodSignature signature = (MethodSignature) joinPoint.getSignature();
OperationLog annotation = signature.getMethod().getAnnotation(OperationLog.class);
// 记录日志
OperationLog log = new OperationLog();
log.setOperation(annotation.value());
log.setParams(JsonUtils.toJson(joinPoint.getArgs()));
log.setResult(JsonUtils.toJson(result));
logService.save(log);
}
}
这种方案的优点在于：
- 业务代码零侵入
- 统一处理日志逻辑
- 通过注解灵活控制记录范围
但缺点也很明显：
- 无法获取方法执行前的状态
- 复杂业务场景下注解配置会变得冗长
- 异步方法需要特殊处理
2.2 命令模式实现方案
命令模式将操作封装为独立对象，天然适合日志记录：
java复制public interface Command {
Object execute();
String getOperation();
default Object getBeforeState() { return null; }
default Object getAfterState() { return null; }
}
public class CreateOrderCommand implements Command {
private OrderService orderService;
private OrderDTO orderDTO;
private Order beforeState;
@Override
public Object execute() {
beforeState = orderService.getCurrentState(orderDTO.getId());
return orderService.create(orderDTO);
}
@Override
public String getOperation() {
return "创建订单";
}
@Override
public Object getBeforeState() {
return beforeState;
}
}
优势在于：
- 完整记录操作前后状态
- 业务逻辑与日志逻辑内聚
- 支持复杂操作的事务管理
缺点是：
- 需要为每个操作创建命令类
- 增加了代码结构复杂度
2.3 事件溯源模式探索
事件溯源（Event Sourcing）将状态变更记录为一系列事件：
java复制public class Order {
private List<OrderEvent> events = new ArrayList<>();
public void updateStatus(OrderStatus newStatus) {
OrderStatus oldStatus = this.status;
this.status = newStatus;
events.add(new OrderStatusChangedEvent(
oldStatus,
newStatus,
LocalDateTime.now()
));
}
public List<OrderEvent> getEvents() {
return Collections.unmodifiableList(events);
}
}
核心价值：
- 完整保存业务状态变更历史
- 天然支持审计追踪
- 可以重建任意时间点的状态
挑战在于：
- 需要改变传统的数据持久化思维
- 查询效率需要特别优化
3. 实战：电商订单日志系统改造
3.1 原有AOP方案的问题
在订单中心模块中，我们原有基于AOP的日志实现遇到了几个典型问题：
- 无法记录订单修改前后的差异
- 部分异步操作日志丢失
- 复杂的操作类型判断逻辑污染了切面代码
java复制@OperationLog("更新订单状态")
public Order updateStatus(Long orderId, OrderStatus status) {
// 业务逻辑
}
当需要记录状态变更详情时，注解方式就显得力不从心。
3.2 采用命令模式重构
重构后的核心流程：
java复制public class UpdateOrderStatusCommand implements Command {
private Long orderId;
private OrderStatus newStatus;
private OrderRepository orderRepository;
private Order originalOrder;
public UpdateOrderStatusCommand(Long orderId, OrderStatus status) {
this.orderId = orderId;
this.newStatus = status;
}
@Override
public Order execute() {
originalOrder = orderRepository.findById(orderId);
Order updatedOrder = orderRepository.updateStatus(orderId, newStatus);
// 自动记录日志
logService.recordOrderStatusChange(
originalOrder.getStatus(),
updatedOrder.getStatus(),
getChangeReason()
);
return updatedOrder;
}
private String getChangeReason() {
// 根据业务规则生成变更原因
}
}
3.3 混合方案的折中实践
对于简单操作，我们保留了AOP注解的简洁性；对于复杂操作，则采用命令模式：
java复制public class OrderService {
@SimpleLog("查询订单")
public Order getById(Long id) {
return orderRepository.findById(id);
}
public Order updateStatus(UpdateOrderStatusCommand command) {
return command.execute();
}
}
4. 性能与可维护性对比
4.1 性能测试数据
我们对三种方案进行了JMeter压测（100并发）：
| 方案 | TPS | 平均响应时间 | 内存占用 |
|---|---|---|---|
| 纯AOP | 1256 | 78ms | 较低 |
| 命令模式 | 982 | 102ms | 中等 |
| 事件溯源 | 843 | 118ms | 较高 |
4.2 可维护性评估
从长期维护角度考虑：
- 代码可读性：命令模式将相关逻辑集中，更符合人类阅读习惯
- 调试便利性：非AOP方案可以在IDE中直接跟踪完整流程
- 新人上手成本：AOP的"魔法"特性会增加理解难度
- 扩展灵活性：命令模式更容易添加新的日志字段和逻辑
5. 选型建议与最佳实践
根据项目特点选择合适方案：
- 简单管理系统：AOP注解仍是最快捷方案
- 复杂业务系统：推荐命令模式，特别是需要记录前后状态的场景
- 金融/审计系统：考虑事件溯源，确保完整的历史追溯能力
5.1 日志记录的黄金法则
- 完整性：记录足够重现问题的信息
- 可读性：日志消息要让人能看懂
- 性能：避免同步日志阻塞主流程
- 结构化：采用JSON格式便于分析
5.2 异步日志的通用方案
无论采用哪种模式，都建议：
java复制// 使用Spring的@Async
@Async
public void recordLogAsync(LogEntry entry) {
logRepository.save(entry);
}
// 或者使用消息队列
public void recordLog(LogEntry entry) {
kafkaTemplate.send("log-topic", entry);
}
6. 常见问题排查指南
6.1 日志信息不全
现象：日志缺少关键业务参数
解决：
- 检查命令对象是否完整捕获了输入参数
- 对于AOP方案，确认ProceedingJoinPoint能获取到所有参数
6.2 异步日志丢失
现象：高并发时部分日志未保存
解决：
- 引入消息队列确保可靠性
- 添加本地缓存作为fallback
6.3 性能瓶颈
现象：日志记录拖慢主流程
解决：
- 采用内存队列缓冲日志
- 考虑批量写入策略
- 对非关键日志采用采样记录
7. 进阶优化方向
7.1 智能日志过滤
通过动态配置决定哪些操作需要记录：
java复制public boolean shouldLog(Operation operation) {
return logConfig.getEnabledOperations()
.contains(operation.getType());
}
7.2 日志分级存储
- 热数据：保留在关系型数据库
- 温数据：迁移到Elasticsearch
- 冷数据：归档到对象存储
7.3 自动化审计报告
基于操作日志自动生成：
- 用户行为分析
- 操作频次统计
- 异常操作预警
在最近的项目实践中，混合使用命令模式与简化AOP的方案取得了良好效果。对于核心业务操作，命令模式提供了完整的上下文捕获能力；而对于简单的查询类操作，保留AOP注解则维持了代码的简洁性。这种务实的折中方案，可能是大多数业务系统的最佳选择。