Seata：为微服务项目的XID传播设计全局的RequestInterceptor-将XID传播与具体FeignClient行为解耦

分布式事务中Seata请求拦截器的逻辑分析

在分布式系统中，跨服务的事务一致性是一个复杂问题。Seata 是一种流行的分布式事务解决方案，通过全局事务ID（XID）协调多个服务的操作。本文将分析一个基于 Feign 的请求拦截器 SeataRequestInterceptor，它在分布式事务中扮演了传递 XID 的关键角色。我们将从背景知识入手，逐步拆解其实现逻辑，并深入讲解每一处细节。

背景知识：分布式事务与拦截器

1. 分布式事务的挑战

在单体应用中，数据库事务可以通过 BEGIN、COMMIT 和 ROLLBACK 保证一致性。但在分布式系统中，多个服务各自操作自己的数据库，如何确保所有操作要么全部成功，要么全部回滚？Seata 提供了一种解决方案，通过全局事务ID（XID）标识一个分布式事务，并在服务间传递 XID 来协调操作。

2. Seata 的工作原理

Seata 的核心组件包括：

• TC（Transaction Coordinator）：事务协调者，管理全局事务状态。
• TM（Transaction Manager）：事务发起者，定义全局事务的边界。
• RM（Resource Manager）：资源管理器，处理分支事务（如数据库操作）。

在服务调用链中，XID 需要从发起方传递到所有参与方，通常通过请求头（如 X-SEATA-XID）携带。

3. Feign 与拦截器

Feign 是一个声明式的 HTTP 客户端库，广泛用于微服务间的通信。Feign 提供了 RequestInterceptor 接口，允许我们在发送请求前修改请求内容（如添加头信息）。这里，我们利用它传递 Seata 的 XID。

4. 技术假设

• 框架：Spring Boot 应用，使用 Feign 进行服务调用。
• 分布式事务 ：集成 Seata，通过 @GlobalTransactional 注解开启全局事务。
• 工具 ：使用 Hutool 库的 StrUtil 处理字符串。

---

拦截器逻辑：从整体到细节

以下是 SeataRequestInterceptor 的实现，我们将逐步分析其逻辑。

1. 定义拦截器

拦截器实现了 Feign 的 RequestInterceptor 接口，并通过 Spring 的注解进行配置：

@Component
@ConditionalOnClass({RequestInterceptor.class, GlobalTransactional.class})
public class SeataRequestInterceptor implements RequestInterceptor {

• @Component：将拦截器注册为 Spring Bean，自动注入到 Feign 客户端。
• @ConditionalOnClass ：条件注解，确保类路径中存在 RequestInterceptor 和 GlobalTransactional，即仅在 Feign 和 Seata 都可用时生效。这提高了代码的兼容性。

2. 核心方法：apply

apply 方法是拦截器的入口，每次 Feign 发送请求时都会调用：

@Override
public void apply(RequestTemplate template) {
    String currentXid = RootContext.getXID();
    if (StrUtil.isNotBlank(currentXid) && !template.url().startsWith("/auth/checkToken") && !template.url().startsWith("/auth/checkRbac")) {
        template.header("X-SEATA-XID", currentXid);
    }
}

逐步解析：

1. 获取当前 XID：

   String currentXid = RootContext.getXID();

   • RootContext：Seata 提供的上下文工具类，存储当前线程的分布式事务信息。
   • getXID() ：返回当前全局事务的 XID，如果当前不在事务中，则返回 null。

2. 条件判断：

   if (StrUtil.isNotBlank(currentXid) && !template.url().startsWith("/auth/checkToken") && !template.url().startsWith("/auth/checkRbac"))

   • StrUtil.isNotBlank：Hutool 工具方法，检查字符串是否非空且非空白。
   • URL 过滤 ：排除特定路径（如认证相关的 /auth/checkToken 和 /auth/checkRbac），避免在无关请求中传递 XID。
   • 逻辑：只有当 XID 存在且请求不是认证相关时，才需要添加头信息。

3. 添加请求头：

   template.header("X-SEATA-XID", currentXid);

   • RequestTemplate：Feign 的请求模板，封装了请求的 URL、方法、头信息等。
   • header ：添加名为 X-SEATA-XID 的头，值为当前 XID。
   • 作用：下游服务通过读取此头获取 XID，加入同一分布式事务。

3. 日志记录

private static final Logger logger = LoggerFactory.getLogger(SeataRequestInterceptor.class);

在实际应用中，可以在异常或调试时使用，例如记录 XID 为空的情况：

if (StrUtil.isBlank(currentXid)) {
    logger.debug("当前请求无分布式事务XID，URL: {}", template.url());
}

---

完整流程总结

1. 触发时机：Feign 发起 HTTP 请求时，拦截器被调用。
2. 获取 XID：从 Seata 的上下文获取当前事务的 XID。
3. 条件检查：确保 XID 有效且请求不是认证相关。
4. 传递 XID：将 XID 添加到请求头，传递给下游服务。
5. 执行请求：拦截器完成任务后，Feign 继续发送请求。

---

脱敏后的完整代码

以下是去除了项目特定标识的通用实现：

package com.example.common.config;

import cn.hutool.core.util.StrUtil;
import feign.RequestInterceptor;
import feign.RequestTemplate;
import io.seata.core.context.RootContext;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.boot.autoconfigure.condition.ConditionalOnClass;
import org.springframework.stereotype.Component;

@Component
@ConditionalOnClass({RequestInterceptor.class})
public class SeataRequestInterceptor implements RequestInterceptor {

    private static final Logger logger = LoggerFactory.getLogger(SeataRequestInterceptor.class);

    @Override
    public void apply(RequestTemplate template) {
        String currentXid = RootContext.getXID();
        if (StrUtil.isNotBlank(currentXid) && !template.url().startsWith("/auth/checkToken") && !template.url().startsWith("/auth/checkRbac")) {
            template.header("X-SEATA-XID", currentXid);
        }
    }
}

脱敏说明

• 包名 ：从 com.hnustmall.cloud.common.database.config 改为通用 com.example.common.config。
• 常量 ：移除了 Auth 类中的特定常量（如 CHECK_TOKEN_URI），直接使用硬编码路径（可根据实际替换为配置）。
• 注释：删除了作者和日期等个人信息。

---

深入分析：为什么这样设计？

1. 为什么用拦截器？

手动在每个 Feign 调用中添加 XID 既繁琐又容易出错。拦截器将这一逻辑集中处理，所有 Feign 请求自动携带 XID，提高开发效率和代码一致性。

2. 为什么过滤认证请求？

认证请求（如 token 验证）通常不参与业务事务，传递 XID 无意义且可能增加开销。过滤这些请求是性能优化的体现。

3. 为什么用 RootContext？

RootContext 是 Seata 提供的线程上下文工具，基于 ThreadLocal 存储 XID。它确保在同一线程内，XID 可以被所有组件访问和传递。

---

结语

SeataRequestInterceptor 是一个简单却高效的实现，通过 Feign 的拦截机制无缝传递分布式事务的 XID。它体现了中间件设计的精髓：将通用逻辑从业务代码中抽离，提升系统的可维护性和扩展性。希望这篇博客能帮助你理解 Seata 在微服务中的应用，以及拦截器设计的巧妙之处！