Design durable workflows with …

# Temporal电商订单处理工作流设计方案

一、整体架构

• 入口层：API/消息队列接收订单 → 通过 WorkflowClient 发起订单工作流
• 工作流层：OrderWorkflow 编排全流程（持久化状态，天然支持重试与超时）
• Activity层：拆分为幂等Activity（扣库存、创建支付单、查询支付状态、取消订单、释放库存）
• 吞吐层：5000 QPS 依赖 Worker 水平扩容 + TaskQueue 分片

二、核心工作流逻辑（伪代码）

```java

public String process(Order order) {

// 1. 扣库存，10秒超时，失败抛错即整体失败

Workflow.setTimeout(activityStubs.reserveStock(order), 10s);

// 2. 发起支付

String payId = activityStubs.createPayment(order);

// 3. 支付确认：两个信号竞争

// a. 支付成功信号 → 完成

// b. 15分钟定时器触发 → 查询支付状态

Workflow.await(15min, () -> paidSignalReceived);

if (!paid) {

// 未支付：取消订单并释放库存（幂等Activity）

activityStubs.cancelOrder(order.id);

activityStubs.releaseStock(order.id);

return "CANCELLED_TIMEOUT";

}

return "SUCCESS";

}

```

三、支付重试设计

• Activity重试策略：
• MaximumAttempts: 5
• InitialInterval: 1秒，BackoffCoefficient: 2（指数退避）
• MaximumInterval: 30秒
• 针对可重试错误（网络超时、5xx）才重试，业务错误（余额不足）直接失败
• 支付状态补偿：定时器触发前可先用“查询支付状态Activity”兜底，避免回调丢失
• 幂等性：支付创建带唯一请求ID，重试时服务端去重

四、15分钟超时取消库存

• 用 Workflow.sleep(15min) 或 Workflow.newTimer
• 触发后调用幂等的释放库存Activity（库存服务按订单号去重）
• 库存释放与取消订单建议用 Saga补偿模式，保证最终一致

五、支撑5000 QPS的关键配置

• Worker扩容：按QPS估算Worker实例数，单Worker建议并发上限设为几十到上百（实测调整）
• Namespace/TaskQueue拆分：按订单类型或分片路由，避免热分区
• History限流：关注单Workflow事件数上限（有默认配额），流程别拆太碎
• 数据库压测：Persistence层是瓶颈点，需提前压测
• 限流保护下游：Activity调用支付/库存接口时用令牌桶限流，防止雪崩

六、可观测与容错

• 接入 Temporal Web UI 监控 Workflow 失败率、超时率
• 记录 Workflow.getLogger() 关键日志
• 版本化用 Workflow.getVersion()，支持灰度升级逻辑

以上参数（重试次数、并发度、Worker数量）均为建议起点，