Spring Boot集成Temporal：用代码定义分布式工作流实战

“订单卡在支付页，客服说系统正在重试，结果三天后还在重试。

”

这不是段子，是上周隔壁公司真实上演的 P0 事故。

传统订单链路里，库存、支付、物流像三条各自奔跑的火车，谁晚点谁背锅，最后锅全甩给运维半夜修数据。

Temporal 这玩意儿，相当于给火车装了自动挂钩和GPS，脱轨也能原地重启，关键是代码写得像写本地方法，不用自己造轮子。

先说痛点。

以前做订单，状态字段从 0 写到9，再加个定时任务每分钟扫表，扫到超时就把状态回滚。

听起来简单，真上线后：

– 网络抖一下，库存扣了，支付没回调，订单永远卡在 3。

– 重试逻辑写在 5 个服务里，改个超时时间要发 5 次版。

– 凌晨三点报警，日志像天书，只能人肉比对数据库。

Temporal 怎么救场？

一句话：把流程当代码写，把状态交给引擎。

写个 Workflow 接口，里面顺序调用Activity（库存、支付、物流），每一步自动落盘，断点续跑。

重试策略直接注解搞定，超时、补偿、回滚全是声明式，不用自己写 ifelse。

更香的是 Web UI能实时看到订单跑到哪一步，像追剧一样拖动进度条，还能直接发信号改地址，不用重启服务。

有人担心 Spring Boot 3 兼容性，实测官方 starter已经跟上，自动配置改了点名字，老项目升上去半小时搞定。

本地开发？

一行命令 temporal server start dev，浏览器打开 localhost:8233，UI 比Swagger 还直观。

生产部署？

Helm 一键上 K8s，PostgreSQL 做持久化，Prometheus 拉指标，Grafana画大屏，老板看了都说高级。

多租户命名空间直接按业务线隔离，A 业务炸了不影响 B业务，再也不用“全站停服修数据”。

举个实战栗子。

普通订单走标准三步，VIP 订单多加个“人工审核”Activity，用条件分支一行代码搞定。

某天运营突然说“618大促要支持改地址”，直接在工作流里加信号处理器，老订单实例也能收到新指令，不用灰度迁移。

版本升级更离谱，Workflow 里加个 sleep 做A/B，旧实例继续跑旧逻辑，新实例走新逻辑，零停机。

有人吐槽 Temporal 学习曲线陡？

实则就三个注解@WorkflowInterface、@ActivityInterface、@Worker，剩下的都是 Spring那套。

真正门槛是思维转换：别再想着“数据库状态机”，而是“把业务流程拍成一部电影，引擎负责放映”。

彩蛋：社区有人把 Temporal 和 LangChain 拼在一起，让 GPT生成工作流代码，再交给引擎跑，产品经理自己就能上线流程，程序员当场失业（开个玩笑）。

最后留个小作业：

如果让你用 Temporal重构“外卖下单到骑手送达”整个链路，你会把哪一步拆成单独 Activity？

评论区聊聊，说不定下周文章就按你的思路写。