在电信运维平台中，工单管理（JOM, Job Order Management）是连接网络问题发现与现场处理的核心纽带。一个典型的工单创建流程往往涉及多个微服务的协同操作：

1. 资源服务 (NetMgr)：锁定或更新基站/小区的状态。
2. 工单服务 (JOM)：生成工单记录，初始化流程实例。
3. 通知服务 (Notification)：向相关维护人员发送短信或 APP 推送。
4. 绩效服务 (Perf)：记录该次事件对网络考核指标的影响。

在传统单体架构中，这些操作在一个数据库事务中完成，ACID 特性天然保证一致性。但在基于 Spring Cloud Alibaba 的微服务架构下，数据分散在不同的数据库中，本地事务失效。如果工单创建成功但通知发送失败，或者资源状态未更新，就会导致“脏数据”和业务流程中断。

本文将深入探讨如何利用 Seata 的 AT 模式，在跨服务工单流转场景中实现高效、透明的分布式事务管理，确保业务数据的最终一致性。

一、 为什么选择 Seata AT 模式？

Seata 提供了多种事务模式，其中 AT (Automatic Transaction) 模式最适合大多数业务场景，原因如下：

• 无侵入性：业务代码只需添加 @GlobalTransactional 注解，无需修改 SQL 或引入复杂的补偿逻辑。
• 高性能：相比 TCC 模式需要编写 Prepare/Commit/Rollback 三个阶段的代码，AT 模式利用全局锁机制，在一阶段就提交本地事务，释放数据库连接，吞吐量更高。
• 自动回滚：Seata 会自动生成 Undo Log，当任何分支事务失败时，能自动反向补偿，恢复数据原状。

二、 业务场景建模：手动派单流程

以 ManualOrderController对应的业务为例，前端 Vue 页面发起“一键派单”请求，后端需执行以下原子操作：

1. 校验资源状态：确认目标小区是否存在且处于可派单状态。
2. 创建工单：在 jom_db 中插入 work_order 记录。
3. 更新资源状态：在 netmgr_db 中将小区标记为“故障处理中”。
4. 发送通知：调用消息队列或第三方接口通知代维人员。

若第 3 步更新资源失败，第 2 步创建的工单必须撤销，否则会出现“有工单但资源状态正常”的逻辑矛盾。

三、 架构集成与配置

1. 引入依赖

<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-seata</artifactId>
</dependency>

2. 配置 Seata 客户端

在 application.yml 中配置 Seata 注册中心与事务组：

seata:
  enabled: true
  application-id: ${spring.application.name}
  tx-service-group: my_test_tx_group # 事务组名称
  service:
    vgroup-mapping:
      my_test_tx_group: default # 映射到默认的 TC 集群
    grouplist:
      default: 127.0.0.1:8091 # Seata Server 地址
  registry:
    type: nacos # 使用 Nacos 作为注册中心
    nacos:
      server-addr: 127.0.0.1:8848

3. 初始化 Undo Log 表

在每个参与事务的数据库（jom_db, netmgr_db）中执行 Seata 提供的 DDL 脚本，创建 undo_log 表。这是 AT 模式实现自动回滚的核心基石。

四、 核心代码实现

1. 全局事务发起方 (JOM Service)

在工单服务的入口方法上添加 @GlobalTransactional 注解。

@Service
public class WorkOrderServiceImpl implements WorkOrderService {

    @Autowired
    private WorkOrderRepository workOrderRepository;
    
    @Autowired
    private NetMgrFeignClient netMgrFeignClient;
    
    @Autowired
    private NotificationFeignClient notificationFeignClient;

    @Override
    @GlobalTransactional(name = "create-work-order-tx", rollbackFor = Exception.class)
    public String createManualOrder(WorkOrderCreateDto dto) {
        // 1. 本地事务：创建工单
        WorkOrder order = new WorkOrder();
        order.setCellId(dto.getCellId());
        order.setStatus(OrderStatus.CREATED);
        workOrderRepository.save(order);
        
        // 2. 远程调用：更新资源状态 (NetMgr Service)
        // 如果此处抛出异常，Seata 会触发全局回滚
        netMgrFeignClient.updateCellStatus(dto.getCellId(), CellStatus.FAULT_PROCESSING);
        
        // 3. 远程调用：发送通知 (Notification Service)
        notificationFeignClient.sendSms(dto.getMaintainerPhone(), "新工单已派发");
        
        return order.getOrderId();
    }
}

2. 分支事务参与方 (NetMgr Service)

资源服务只需正常编写业务逻辑，无需特殊注解。Seata 代理的数据源会自动拦截 SQL 执行，解析前后镜像并生成 Undo Log。

@Service
public class CellServiceImpl implements CellService {

    @Autowired
    private CellRepository cellRepository;

    @Override
    public void updateCellStatus(String cellId, CellStatus status) {
        Cell cell = cellRepository.findById(cellId)
            .orElseThrow(() -> new BusinessException("Cell not found"));
        
        cell.setStatus(status);
        cellRepository.save(cell); 
        // Seata DataSourceProxy 在此处自动记录 Before Image 和 After Image
    }
}

五、 Seata AT 模式工作原理深度解析

为了理解其如何保证一致性，我们需要看清背后的两阶段提交过程：

阶段一：Prepare & Commit

1. 解析 SQL：Seata 拦截 JDBC 请求，解析出要更新的记录。
2. 查询前镜像：查询更新前的数据状态。
3. 执行更新：执行真实的 SQL 更新数据库。
4. 查询后镜像：查询更新后的数据状态。
5. 插入 Undo Log：将前镜像、后镜像、SQL 信息存入本地的 undo_log 表。
6. 提交本地事务：向 TC (Transaction Coordinator) 注册分支事务，并汇报状态。注意：此时本地数据库锁已释放，性能极高。

阶段二：Commit 或 Rollback

• 若全局成功：TC 通知所有分支异步删除 undo_log 记录。
• 若全局失败（如 Notification 服务超时）：
  1. TC 通知所有分支进行回滚。
  2. Seata 根据 undo_log 中的前镜像，生成反向 SQL（如将状态从 FAULT_PROCESSING 改回 NORMAL）。
  3. 执行反向 SQL 恢复数据。
  4. 删除 undo_log 记录。

六、 常见问题与优化

1. 全局锁冲突

AT 模式依赖全局锁来保证隔离性。如果两个事务同时修改同一行数据，后到的事务会等待全局锁。

• 优化：尽量减小事务粒度，避免在长事务中持有全局锁。对于高并发场景，可考虑使用 Seata Saga 模式 或 TCC 模式。

2. 幂等性设计

在网络抖动导致重试时，通知服务可能会收到重复的请求。

• 优化：在 notification_service 中利用 Redis 或数据库唯一索引实现接口幂等性，确保同一工单只发送一次短信。

3. Vue 前端的超时处理

分布式事务耗时通常比本地事务长。

• 优化：前端 Axios 请求适当增加 timeout 设置，并在 UI 上展示“处理中”的 Loading 状态，提升用户体验。

// Vue 3 Composition API
const submitOrder = async () => {
  loading.value = true;
  try {
    await createWorkOrder(formData);
    ElMessage.success('派单成功');
  } catch (error) {
    ElMessage.error('派单失败，请稍后重试');
  } finally {
    loading.value = false;
  }
};

七、 总结

通过引入 Seata AT 模式，我们成功解决了电信运维系统中跨服务工单流转的数据一致性难题。

• 开发效率提升：开发者只需关注业务逻辑，无需手动编写补偿代码。
• 数据强一致：确保了工单、资源状态、通知记录之间的逻辑闭环。
• 架构解耦：各微服务依然保持独立部署和扩展能力。

在实际生产中，建议结合 Sentinel 进行流量防护，防止因分布式事务锁等待导致的线程堆积，共同构建高可用、高一致的电信级微服务架构。

互动环节
💬 你们公司的工单引擎是怎么实现的？遇到过哪些难题？欢迎在评论区分享！

⭐ 如果觉得这篇文章有帮助，欢迎点赞、收藏、转发！

🔔 关注我，下一篇将分享《Vue 3 + TypeScript 构建大型电信运维平台的前端架构设计》

版权声明：本文为原创文章，转载请注明出处。商业转载请联系作者获得授权。

作者简介：系统架构 师，专注于电信大数据平台架构设计与运维。目前负责日均处理2亿条消息的ucp平台，擅长分布式系统设计、消息中间件运维和高可用架构