2、核心概念回顾：分布式事务（XA、TCC、Saga、Seata）、鉴权拦截（OAuth2、JWT、Spring Security Filter）
在进入 Development 环境移植适配之前，必须对齐两个核心知识域：分布式事务与鉴权拦截。本章将系统梳理 XA、TCC、Saga、Seata 四种事务模型，以及 OAuth2、JWT、Spring Security Filter 三套鉴权拦截机制，为后续的环境适配打下理论基础。
2.1 分布式事务模型对比
分布式事务用于保证跨多个数据库、服务或消息队列的数据一致性。根据一致性强度与实现方式，主流模型分为以下四类：
| 模型 | 一致性级别 | 典型协议/实现 | 适用场景 | 主要缺点 |
|---|---|---|---|---|
| XA | 强一致性（ACID） | 2PC（两阶段提交） | 短事务、数据库原生支持 | 阻塞协议、性能低、单点风险 |
| TCC | 最终一致性 | Try-Confirm-Cancel | 长事务、业务可补偿 | 业务侵入性强、需实现三阶段接口 |
| Saga | 最终一致性 | Choreography / Orchestration | 跨服务长流程、事件驱动 | 补偿逻辑复杂、无隔离性 |
| Seata | 最终一致性（AT模式） | AT / TCC / Saga / XA | 微服务、云原生、多语言 | AT模式依赖全局锁、性能有损耗 |
2.2 四种事务模型详解
2.2.1 XA（2PC）
XA 是基于两阶段提交（Prepare + Commit/Rollback）的分布式事务规范。所有参与者先投票（Prepare），协调者根据投票结果决定全局提交或回滚。其核心流程如下：
- 阶段一（Prepare）： 事务管理器向所有资源管理器发送 prepare 请求，资源管理器执行事务但不提交，返回 yes/no。
- 阶段二（Commit/Rollback）： 若全部返回 yes，则发送 commit；否则发送 rollback。
2.2.2 TCC（Try-Confirm-Cancel）
TCC 将每个事务操作拆分为三个阶段，由业务代码显式实现：
- Try： 预留资源、检查业务条件。
- Confirm： 确认执行业务操作，使用 Try 阶段预留的资源。
- Cancel： 取消业务操作，释放 Try 阶段预留的资源。
2.2.3 Saga
Saga 将长事务拆分为一系列本地事务，每个本地事务对应一个补偿事务。若某个本地事务失败，则按逆序执行补偿事务。Saga 有两种编排模式：
- Choreography（ choreography）： 每个服务在本地事务完成后发布事件，触发下一个服务。
- Orchestration（编排）： 由协调器（Orchestrator）统一调用各服务并处理补偿。
2.2.4 Seata
Seata 是阿里开源的分布式事务框架，支持 AT、TCC、Saga、XA 四种模式。其中 AT 模式 是 Seata 的核心创新：通过代理数据源自动生成 undo log，实现无侵入的最终一致性。Seata 架构包含三个核心组件：
- TC（Transaction Coordinator）： 事务协调器，维护全局事务状态。
- TM（Transaction Manager）： 事务管理器，开启/提交/回滚全局事务。
- RM（Resource Manager）： 资源管理器，管理分支事务资源。
2.3 鉴权拦截核心机制
鉴权拦截是微服务安全的第一道防线。本节回顾 OAuth2、JWT、Spring Security Filter 三者的定位与协作关系。
| 机制 | 核心职责 | 典型组件/协议 | 开发环境常见问题 |
|---|---|---|---|
| OAuth2 | 授权框架，颁发访问令牌 | Authorization Code / Client Credentials / Password | 回调地址配置、Token 端点不可达 |
| JWT | 令牌格式，携带用户身份与声明 | Header.Payload.Signature | 密钥不一致、过期时间、签名算法 |
| Spring Security Filter | 请求拦截链，执行认证与授权 | SecurityFilterChain / OncePerRequestFilter | Filter 顺序错乱、忽略路径配置 |
2.3.1 OAuth2 授权流程
OAuth2 定义了四种授权模式，开发环境最常用的是 Authorization Code（授权码模式） 和 Client Credentials（客户端模式）。核心参与角色：
- Resource Owner（资源所有者）： 用户，授权客户端访问其资源。
- Client（客户端）： 需要访问资源的应用程序。
- Authorization Server（授权服务器）： 颁发令牌。
- Resource Server（资源服务器）： 保护资源，验证令牌。
2.3.2 JWT 令牌结构
JWT（JSON Web Token）由三部分组成，以点号分隔：
// JWT 示例结构
eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWUsImlhdCI6MTUxNjIzOTAyMn0.POstGetfAytaZS82wHcjoTyoqhMyxXiWdR7Nn7A29Dlcr7ZQq7Z8lBZ1wqAq2pF7iA0b7iK8g- Header： 令牌类型（JWT）和签名算法（如 RS256、HS256）。
- Payload： 声明（Claims），包含用户身份、角色、过期时间等。
- Signature： 对 Header 和 Payload 的签名，防止篡改。
2.3.3 Spring Security Filter 链
Spring Security 通过 Filter 链实现请求拦截。每个 Filter 负责一项安全职责，按顺序执行。典型的 Filter 链顺序如下：
- SecurityContextPersistenceFilter： 从 Session 中恢复 SecurityContext。
- UsernamePasswordAuthenticationFilter： 处理表单登录。
- BearerTokenAuthenticationFilter： 解析 JWT Bearer Token。
- FilterSecurityInterceptor： 执行 URL 权限判断。
- ExceptionTranslationFilter： 处理认证/授权异常。
2.4 分布式事务与鉴权拦截的交叉点
在微服务架构中，分布式事务与鉴权拦截并非孤立存在。以下场景是 Development 环境移植适配的高频交叉点：
- 事务上下文传递： 跨服务调用时，分布式事务 ID（如 Seata 的 xid）需通过请求头传递，而鉴权 Token（JWT）同样在请求头中传递。两者可能共用拦截器或 Filter。
- Filter 顺序冲突： 事务拦截器（如 SeataHandlerInterceptor）与 Spring Security Filter 的执行顺序若配置不当，可能导致 Token 未解析时事务已开启，引发空指针或认证失败。
- 本地开发环境模拟： 在单机开发环境中，需同时模拟 OAuth2 授权服务器和 Seata TC 服务，端口冲突与配置覆盖是常见问题。