4. 传统鉴权拦截的分布式事务问题

在微服务架构中，鉴权拦截通常作为网关或中间件层的通用横切关注点实现。当鉴权逻辑与业务逻辑处于不同的事务边界时，传统的“先鉴权、后业务”模式会暴露出三类典型的分布式事务问题：数据不一致、重复鉴权和日志丢失。这些问题并非由鉴权本身引起，而是由跨服务、跨数据库的分布式事务缺乏原子性保障所致。

4.1 问题全景：鉴权成功但业务失败

下图展示了传统鉴权拦截在分布式调用中的典型时序，以及故障发生的三个关键断裂点。

4.2 三大问题的详细分析

4.3 数据不一致：鉴权日志与业务状态分裂

这是最隐蔽也最严重的问题。考虑一个典型的支付场景：

1. 用户发起支付请求，网关鉴权通过，鉴权服务写入“用户XXX于T时刻通过鉴权”的日志。
2. 业务服务执行扣款，但因账户余额不足或库存锁定失败而回滚。
3. 鉴权日志已提交，无法回滚。审计系统看到“鉴权通过”但找不到对应的业务记录。

这种分裂状态会导致：

• 审计失真：安全审计报告显示大量“有鉴权无业务”的异常记录。
• 计费错误：按鉴权次数计费的场景下，用户被多计费。
• 合规风险：金融监管要求鉴权与业务记录严格对应，分裂状态直接违反合规要求。

4.4 重复鉴权：重试机制引发的幂等性灾难

当业务服务因网络抖动或超时触发重试时，鉴权拦截层可能被多次调用。传统鉴权拦截缺乏幂等性保障，导致：

• Token重复签发：每次鉴权通过都签发新Token，旧Token未失效，造成Token泛滥。
• 鉴权服务压力倍增：重试流量放大效应下，鉴权服务可能成为瓶颈。
• 日志重复写入：同一次业务请求产生多条鉴权日志，进一步加剧数据不一致。

// 传统鉴权拦截 — 非幂等实现示例
public AuthResult authenticate(String token) {
    // 每次调用都执行完整的鉴权逻辑
    AuthResult result = authService.verify(token);
    // 每次通过都写入日志
    auditLogRepository.save(new AuditLog(token, result));
    return result;
}
// 问题：业务重试时，auditLogRepository.save() 被多次执行

4.5 日志丢失：鉴权服务自身故障的连锁反应

鉴权日志是安全审计和攻击溯源的核心数据。在传统模式下，日志写入与业务调用是串行的：

1. 鉴权服务先写日志，再转发业务请求。
2. 如果鉴权服务在写完日志后、转发请求前宕机，业务请求丢失，但日志已写。
3. 如果鉴权服务在转发请求后、写日志前宕机，业务成功但日志丢失。

两种场景分别对应数据不一致和日志丢失，但后者更致命——安全团队完全不知道这次业务操作发生过。

4.6 问题根源总结

上述三个问题的共同根源在于：鉴权拦截与业务处理之间缺乏原子性保障。具体表现为：