企业官网建设流程全解析

上篇我们在做分布式事务选型时，对比了 XA、TCC、Saga、本地消息表等几种主流方案，结论是：长事务、跨服务、对实时一致性要求不苛刻的业务场景，Saga 是很合适的选择。这篇作为“大V维权 Omega”系列的下篇，我们把重心从理论移到代码上，专门拆解 Saga 实现中 Omega 客户端的原理、注解、配置和完整落地流程。

如果你第一次接触 Omega，可以先把它理解成一个部署在每个业务服务里的“事务代理”。业务代码只需要负责两件事：实现正向操作、实现补偿操作。事务事件的采集、上报、回放动作都由 Omega 自动完成。读完这篇文章，你会理解 Omega 在 Saga 事务里的具体职责、最关键的两个注解怎么用，以及一个订单-库存-积分链路的完整补偿案例怎么跑通。文章会保留足够多的代码和配置，方便你直接对照修改。

1. 先别急着写代码：Omega 在 Saga 里到底负责什么

1.1 分布式事务的“同一份数据”困境

在单体应用里，一次下单操作往往涉及订单表、库存表、积分表，保证数据一致性只需要一个数据库事务。所有写操作要么全部提交，要么全部回滚，逻辑非常清晰。

一旦系统拆成微服务，订单数据在订单服务，库存数据在库存服务，积分数据在积分服务，就没有一个“全局数据库事务”可以帮你同时控制三个库。常规做法是引入分布式事务，但分布式事务也要付出代价。XA 方案通过两阶段提交保证强一致，代价是锁时间变长、协调器容易成为瓶颈，而且很多 NoSQL 或 MQ 并不支持标准 XA。TCC 方案通过 Try、Confirm、Cancel 三个动作实现业务级事务，灵活性高，但每个业务都要实现三组接口，开发量不小。本地消息表则依赖数据库表记录消息状态，侵入性低，但是对消息表的管理、清理和轮询都是一项长期维护工作。

在订单、积分这类链路较长、实时一致性要求不高、允许短暂不一致的场景里，Saga 是更轻量的选择。它把一个大事务拆成多个局部事务，每个局部事务都有对应的补偿操作。一旦某个环节失败，就按照相反顺序逐个执行补偿，最终恢复到业务可接受的状态。

1.2 Saga 把大事务拆成一串小事务

Saga 的核心思想非常直观。假设一条业务链路是 A -> B -> C，那么 Saga 会依次执行 A、B、C 三个正向操作。如果 C 失败，Saga 会逆序执行 B 的补偿、A 的补偿，把已经产生的副作用撤销掉。

这里需要注意，Saga 不是数据库意义上的“回滚”，而是业务层面的补偿。比如下单成功后订单状态变成“已创建”，补偿操作不一定是物理删除订单，也可能是把订单状态改成“已取消”。扣减库存成功后补偿操作是“加回库存”。增加积分成功后补偿操作是“扣减积分”。这些补偿逻辑需要业务自己实现，因为只有业务才清楚什么叫“补偿”。

Saga 的优点是本地事务依然使用普通数据库事务，没有跨库锁，对性能影响小。缺点是它做不到强一致，某个时刻外部系统可能看到“库存已扣减但积分还没增加”的中间状态。所以 Saga 适合那些允许最终一致的场景，不适合账务、资金类强一致要求非常高的场景。

1.3 Alpha 与 Omega 的分工

在 ServiceComb Saga 的实现中，整个体系由两类角色组成：Alpha 和 Omega。

Alpha 是协调器，负责接收每个服务上报的事务事件，形成完整的全局事务状态，并在某个参与者失败时向其他已经成功的参与者发送补偿指令。Omega 是客户端组件，部署在每个业务服务内，负责采集本地事务的事件事项，上报给 Alpha，同时监听 Alpha 下发的补偿命令，触发对应的补偿方法。

可以看下面这个简化的示意图：

Alpha 协调器 ▲ │ 事件上报 │ │ 补偿指令 │ ▼ Omega-A ── Omega-B ── Omega-C │ │ │ 订单服务 库存服务 积分服务

业务服务之间的调用靠 RestTemplate 或 Feign 完成，Omega 通过拦截这些调用自动把当前事务上下文传递给下一个服务。业务开发人员不需要手动组装事务 ID，也不需要写上报事件代码。

1.4 Omega 的完整事务生命周期

一次正常的 Saga 调用会经历下面几个阶段：

第一阶段，发起方通过 @SagaStart 开启一个全局事务。Omega 生成一个全局事务 ID，并把事务状态置为“开始”。第二阶段，业务 A、B、C 依次执行，每个服务上的 Omega 在执行成功后将相应事件上报给 Alpha。第三阶段，如果全部成功，发起方方法正常返回，Alpha 记录全局事务结束。第四阶段，如果某个环节抛出异常，Alpha 会将该全局事务标记为“终止”，并向已经成功的参与者下发补偿命令。第五阶段，各参与者收到补偿命令后，执行对应的补偿方法并上报补偿结果。

理解这个流程后，再去写代码就清楚多了：业务代码需要关心的只是正向方法和补偿方法，事务状态的维护、补偿命令的分发全部交给 Omega。

2. 为什么是 Omega：与其他事务方案的差异

2.1 AT、TCC、Saga 对业务侵入度的差别

先看 Seata 的 AT 模式。AT 模式通过数据源代理自动生成反向 SQL 实现回滚，业务代码侵入最小，但需要在数据库表中加入 undo_log 表，并且对数据库类型有一定要求。TCC 模式需要把每个操作拆成 Try、Confirm、Cancel，业务侵入最明显，但是性能很好。Saga 介于两者之间，它要求业务提供补偿方法，但不需要像 TCC 那样拆成三个接口。

Omega 正好体现了 Saga 的侵入度特点。你只需要在正向方法上标注 @Compensable，然后额外写一个补偿方法。相比 TCC 需要设计三个接口的实现，Omega 这种注解方式要轻量得多。

2.2 Omega 的事件模型带来的特点

Omega 的运行依赖于事件机制：正向操作成功就上报“成功事件”，补偿操作执行完毕就上报“补偿完成事件”，Alpha 最终根据事件组合判断整个 Saga 的状态。事件式设计的优点在于，Alpha 可以做得比较薄，只负责接收事件、存储状态、发布补偿命令。在多副本部署 Alpha 时，事件经过可靠存储后，可以一定程度上保证全局状态的一致性。

这种设计也带来一些约束。补偿命令的下发和补偿方法的执行不是即时的，中间存在延迟。订单服务收到补偿命令时，可能已经过去几十毫秒甚至几秒。因此集成 Omega 的业务方法必须做好“延迟补偿”的心理预期，不能假设补偿会立刻发生。

2.3 Omega 适合什么、不适合什么

Omega 适合的场景有：订单创建链路、积分变动链路、营销活动发放链路、内容审核流程等。这些链路跨服务、耗时较长、允许短暂状态不一致，同时业务上具备明显的“正向操作”和“逆向操作”。

Omega 不适合的场景主要是强一致场景。例如账户扣款、转账、余额查询等领域，用户希望读到的是绝对准确的数据，Saga 的中间状态很难满足需求。另外，如果某个子事务的补偿逻辑非常复杂，或者根本无法逆向，这类服务也不建议加入 Saga 链路，建议改成异步对账或定时修复。

3. 环境准备与项目结构

3.1 运行环境说明

本文示例以 JDK 8、Maven 3.6+、Spring Boot 2.x 为基准。需要提醒的是，ServiceComb Saga 社区更新节奏不快，不同版本对 Spring Boot 的兼容范围不同。所以这里不写死一个“绝对可用”的版本号，搭建时先去官方文档确认 omega-spring-starter 和 Spring Boot 的版本兼容关系，再锁定依赖。

本地运行还需要一个 Alpha 协调器。你可以通过官方发布包启动，也可以使用官方提供的 Docker 镜像。具体启动方式以你获取的版本为准，下面给出一个通用的启动思路：

# 方式一：使用 Docker 启动 Alpha（镜像名和端口以官方文档为准） docker run -d --name alpha-server -p 8090:8090 alpha-server:版本号 # 方式二：下载官方 release 包后解压，运行 alpha-server.jar java -jar alpha-server.jar

Alpha 启动后默认会监听一个端口用于接收 Omega 上报事件，也会提供一个简单控制台页面查看全局事务状态。端口号请根据你下载版本的默认配置调整。

3.2 示例工程目录结构

为了让代码更容易看懂，我们设计一个最小可运行的 Saga 链路。工程包含四个模块：

omega-saga-demo/ ├── pom.xml ├── saga-orchestrator/ # 编排服务，端口 8081 ├── saga-order-service/ # 订单服务，端口 8082 ├── saga-inventory-service/ # 库存服务，端口 8083 └── saga-points-service/ # 积分服务，端口 8084

saga-orchestrator 是 Saga 发起方，它不直接操作数据库，而是调用其他三个服务。saga-order-service 保存订单，saga-inventory-service 扣减库存，saga-points-service 增加积分。为了演示补偿，我们会在积分服务中留一个失败开关：当请求参数中的 triggerFailure 为 true 时，积分服务直接抛出异常，触发订单服务和库存服务的补偿。

3.3 Maven 依赖引入

每个业务服务都需要引入 Omega 相关依赖。核心依赖是 omega-spring-starter。传输模块需要根据服务间调用方式选择，如果使用 RestTemplate，就引入 RestTemplate 对应的模块；如果使用 Feign，就引入 Feign 对应的模块。下面是一个依赖配置示例：

<properties> <saga.version>请以官方文档为准</saga.version> <maven.compiler.source>1.8</maven.compiler.source> <maven.compiler.target>1.8</maven.compiler.target> </properties> <dependencyManagement> <dependencies> <dependency> <groupId>org.apache.servicecomb.saga</groupId> <artifactId>omega-spring-starter</artifactId> <version>${saga.version}</version> </dependency> </dependencies> </dependencyManagement>

子模块引入依赖时，按下面方式添加：

<dependency> <groupId>org.apache.servicecomb.saga</groupId> <artifactId>omega-spring-starter</artifactId> </dependency> <!-- 传输模块：根据实际调用方式引入 RestTemplate 或 Feign 模块 -->

注意，这里我故意不写具体版本号，是因为该项目的版本组合需要在实际环境中验证。你可以在本地新建一个只有 Omega 依赖的空工程，先跑通 Alpha 与 Omega 的连接，再继续添加业务代码。

3.4 基础配置

在业务服务的 application.yml 中，需要配置应用名称、端口以及 Omega 的连接信息。

server: port: 8082 spring: application: name: order-service omega: enabled: true alpha: cluster: address: localhost:8090

这里的 omega.enabled 表示是否启用 Omega 客户端，alpha.cluster.address 是 Alpha 协调器的地址。如果你的 Alpha 还配置了注册中心，也可以改成注册中心地址。每个业务服务都要把 omega.enabled 设置为 true，否则 Omega 不会拦截请求。

4. Omega 注解与核心代码实战

4.1 用 @SagaStart 开启一次全局事务

@SagaStart 是 Saga 发起方使用的注解，一般标注在编排方法上。当这个方法被调用时，Omega 会生成一个全局事务 ID，并在方法结束前向 Alpha 上报事务状态。

package com.example.orchestrator; import org.apache.servicecomb.saga.core.SagaStart; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.stereotype.Service; import org.springframework.web.client.RestTemplate; @Service public class OrderOrchestrator { @Autowired private RestTemplate restTemplate; @SagaStart public void placeOrder(OrderRequest request) { restTemplate.postForEntity( "http://localhost:8082/internal/order", request, Void.class); restTemplate.postForEntity( "http://localhost:8083/internal/inventory/deduct", request, Void.class); restTemplate.postForEntity( "http://localhost:8084/internal/points/add", request, Void.class); } }

这个方法的重点是顺序。先创建订单，再扣库存，最后加积分。只要中间任何一个调用抛出异常，Omega 就会根据已经成功的事件，向对应服务发送补偿指令。

4.2 用 @Compensable 标记可补偿子事务

参与者服务需要在正向方法上标注 @Compensable，并通过 compensationMethod 指定补偿方法。下面以库存服务为例：

package com.example.inventory.service; import org.apache.servicecomb.saga.core.Compensable; import org.springframework.stereotype.Service; @Service public class InventoryService { @Compensable(compensationMethod = "refundStock") public void deduct(InventoryRequest request) { // 正向后：减少库存 inventoryDao.deduct(request.getProductId(), request.getCount()); } public void refundStock(InventoryRequest request) { // 补偿：把库存加回来 inventoryDao.refund(request.getProductId(), request.getCount()); } }

正向方法和补偿方法都必须只有当前业务需要的参数。Omega 在触发补偿时，会把原始请求参数传给补偿方法，所以补偿方法里一般可以直接复用 request 中的字段。如果补偿方法需要更多上下文，可以在请求对象里额外带上事务相关数据。

4.3 补偿方法怎么写才安全

补偿方法并不是把数据库操作反向执行一遍那么简单。它需要考虑三个问题。

第一，幂等性。补偿方法可能因为网络超时被重复调用，也可能因为 Alpha 重试而执行多次。因此补偿逻辑必须支持幂等。例如恢复库存前先查询当前库存，或者使用数据库唯一键避免重复补偿。

第二，业务状态校验。正向操作成功但补偿时业务状态可能已经变化，比如用户已经取消了订单，库存也已经被其他订单占用。这时候直接加回库存可能导致超卖。保险的做法是补偿前校验当前状态，必要时记录补偿异常。

第三，错误处理。补偿方法本身也可能执行失败。Omega 会把补偿失败的事件重新上报，交给 Alpha 决定后续策略。因此业务侧最好把补偿失败的可疑数据落到日志表，便于人工处理。

4.4 配置说明

除了 application.yml，Omega 还支持通过启动参数覆盖部分配置。例如本地调试时可以这样启动：

java -jar order-service.jar \ --omega.enabled=true \ --omega.alpha.cluster.address=localhost:8090

如果服务使用 Spring Cloud，还可以将 Omega 配置放入配置中心，但要注意配置修改后需要重启服务才能生效。Omega 的配置项不算多，核心就是应用名、Alpha 地址和开关状态。若你在线上环境使用 Nacos 或 Apollo，建议把 omega.enabled 单独放在环境隔离的配置空间中，避免不同环境互相影响。

5. 完整案例：订单加库存加积分

5.1 业务假设

假设用户在前端提交一个下单请求，请求中带有商品编号、购买数量、用户编号和本次可获得积分。系统需要同时完成三件事：创建订单、扣减库存、给用户增加积分。

正常链路下，三件事全部成功，用户看到下单成功。一旦积分服务失败，虽然订单已经创建、库存已经扣减，系统也必须通过补偿把订单作废、把库存加回来，保证最终结果是不出库、不扣积分。

为了演示，积分服务提供一个 triggerFailure 开关。当请求里 triggerFailure=true 时，积分服务主动抛出异常，其余服务正常执行。

5.2 父工程配置

父 pom 只需要统一管理模块和依赖。

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>com.example</groupId> <artifactId>omega-saga-demo</artifactId> <version>1.0-SNAPSHOT</version> <packaging>pom</packaging> <modules> <module>saga-orchestrator</module> <module>saga-order-service</module> <module>saga-inventory-service</module> <module>saga-points-service</module> </modules> </project>

5.3 订单服务代码

订单服务负责插入订单记录，补偿时把订单标记为关闭。

订单服务 Controller：

package com.example.order.controller; import com.example.order.service.OrderService; import com.example.order.dto.OrderRequest; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.web.bind.annotation.PostMapping; import org.springframework.web.bind.annotation.RequestBody; import org.springframework.web.bind.annotation.RequestMapping; import org.springframework.web.bind.annotation.RestController; @RestController @RequestMapping("/internal/order") public class OrderController { @Autowired private OrderService orderService; @PostMapping public void createOrder(@RequestBody OrderRequest request) { orderService.createOrder(request); } }

订单服务 Service：

package com.example.order.service; import com.example.order.dao.OrderDao; import com.example.order.dto.OrderRequest; import org.apache.servicecomb.saga.core.Compensable; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.stereotype.Service; @Service public class OrderService { @Autowired private OrderDao orderDao; @Compensable(compensationMethod = "cancelOrder") public void createOrder(OrderRequest request) { orderDao.insert(request); } public void cancelOrder(OrderRequest request) { // 补偿：不物理删除订单，而是更新状态为已取消 orderDao.cancel(request.getOrderId()); } }

订单服务的补偿方法没有删除订单，而是把订单状态改为“已取消”。这是 Saga 补偿和数据库回滚最重要的区别：补偿是业务动作，不是数据翻转。

订单状态字段可以用枚举表示，例如 0=已创建，1=已取消。补偿时执行 update 语句，将状态改为 1，查询订单状态的接口需要过滤掉已取消的订单。

5.4 库存服务代码

库存服务的正向操作是扣减库存，补偿操作是回补库存。为了保证逻辑简单，我们直接用库存表数字增减。

package com.example.inventory.service; import com.example.inventory.dao.InventoryDao; import com.example.inventory.dto.InventoryRequest; import org.apache.servicecomb.saga.core.Compensable; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.stereotype.Service; @Service public class InventoryService { @Autowired private InventoryDao inventoryDao; @Compensable(compensationMethod = "refundStock") public void deduct(InventoryRequest request) { inventoryDao.deduct(request.getProductId(), request.getCount()); } public void refundStock(InventoryRequest request) { inventoryDao.refund(request.getProductId(), request.getCount()); } }

对应的 Controller：

package com.example.inventory.controller; import com.example.inventory.service.InventoryService; import com.example.inventory.dto.InventoryRequest; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.web.bind.annotation.PostMapping; import org.springframework.web.bind.annotation.RequestBody; import org.springframework.web.bind.annotation.RequestMapping; import org.springframework.web.bind.annotation.RestController; @RestController @RequestMapping("/internal/inventory") public class InventoryController { @Autowired private InventoryService inventoryService; @PostMapping("/deduct") public void deduct(@RequestBody InventoryRequest request) { inventoryService.deduct(request); } }

这里有一个细节：如果库存不足，正向方法应当抛出异常。一旦 deduct 抛出异常，该服务本身不会收到补偿指令，因为补偿只针对已经成功的参与者。如果库存不足发生在订单创建之后，那么订单服务会收到补偿，而库存服务只需要保证没有扣减成功。

5.5 积分服务代码

积分服务用于模拟失败。当 triggerFailure 为 true 时，直接在正向方法里抛出异常。

package com.example.points.service; import com.example.points.dao.PointsDao; import com.example.points.dto.PointsRequest; import org.apache.servicecomb.saga.core.Compensable; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.stereotype.Service; @Service public class PointsService { @Autowired private PointsDao pointsDao; @Compensable(compensationMethod = "cancelAddPoints") public void addPoints(PointsRequest request) { if (request.isTriggerFailure()) { throw new IllegalStateException("points service failure"); } pointsDao.add(request.getUserId(), request.getPoints()); } public void cancelAddPoints(PointsRequest request) { pointsDao.cancel(request.getUserId(), request.getPoints()); } }

积分服务对应的 Controller 和前面两个服务类似。注意，积分服务虽然是最后一个参与者，但它同样标注 @Compensable。虽然本例中它的正向方法失败后不会触发它自己的补偿，但在其他场景中，如果积分服务执行成功但后续还有别的服务失败，它的补偿方法就会被调用。

5.6 运行编排服务

编排服务的完整代码是 Saga 的入口。需要引入 RestTemplate 并配置 @SagaStart。

package com.example.orchestrator; import org.apache.servicecomb.saga.core.SagaStart; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.stereotype.Service; import org.springframework.web.client.RestTemplate; @Service public class OrderOrchestrator { @Autowired private RestTemplate restTemplate; @SagaStart public void placeOrder(OrderRequest request) { restTemplate.postForEntity( "http://localhost:8082/internal/order", request, Void.class); restTemplate.postForEntity( "http://localhost:8083/internal/inventory/deduct", request, Void.class); restTemplate.postForEntity( "http://localhost:8084/internal/points/add", request, Void.class); } }

还需要一个 RestTemplate 的配置类：

package com.example.orchestrator.config; import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.Configuration; import org.springframework.web.client.RestTemplate; @Configuration public class RestTemplateConfig { @Bean public RestTemplate restTemplate() { return new RestTemplate(); } }

编排服务的 Controller 接收用户请求：

package com.example.orchestrator.controller; import com.example.orchestrator.OrderOrchestrator; import com.example.orchestrator.dto.OrderRequest; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.web.bind.annotation.PostMapping; import org.springframework.web.bind.annotation.RequestBody; import org.springframework.web.bind.annotation.RestController; @RestController public class OrderController { @Autowired private OrderOrchestrator orderOrchestrator; @PostMapping("/orders") public void placeOrder(@RequestBody OrderRequest request) { orderOrchestrator.placeOrder(request); } }

5.7 触发补偿与日志验证

启动顺序建议为：Alpha 协调器优先启动，接着启动订单服务、库存服务、积分服务，最后启动编排服务。全部启动后，先用正常参数调用一次接口：

curl -X POST http://localhost:8081/orders \ -H "Content-Type: application/json" \ -d '{ "orderId": "1001", "productId": "P001", "count": 2, "userId": 1, "points": 50, "triggerFailure": false }'

预期结果是三张表都发生变更，订单状态为已创建，库存减少 2，积分增加 50。

再调用失败场景：

curl -X POST http://localhost:8081/orders \ -H "Content-Type: application/json" \ -d '{ "orderId": "1002", "productId": "P002", "count": 3, "userId": 2, "points": 30, "triggerFailure": true }'

预期日志顺序大致是：

order-service create order success, orderId=1002 inventory-service deduct success, productId=P002, count=3 points-service addPoints fail, triggerFailure=true inventory-service refundStock executed, productId=P002, count=3 order-service cancelOrder executed, orderId=1002 Saga transaction aborted

订单库中 1002 订单的状态最终是已取消，库存也没有被扣减。虽然积分服务没有被补偿，但积分本身就没增加，所以不需要处理。看到这组日志，说明 Omega 的补偿流程已经完整走通。

6. 常见问题与排查思路

6.1 补偿不触发的排查顺序

如果你遇到补偿不触发，建议按下面顺序排查：

第一步，确认发起方方法确实标注了 @SagaStart。如果没有这个注解，Omega 就不会创建