Spring单体转MSA遇分布式事务，Netflix等企业用哪些具体技术解决？

以下是Netflix等头部互联网企业实际生产环境大规模使用的非抽象实现，完全适配不需要落地DDD的需求：

Saga模式轻量实现（适配你仅需Saga能力的场景） #

• Spring Cloud State Machine：Spring生态原生组件，无DDD绑定约束，可自定义编排Saga状态流转、补偿节点，直接接入现有Spring微服务链路，Netflix边缘业务、国内多数电商企业的轻量Saga场景都在使用。
• Seata Saga模式：阿里开源的分布式事务组件，Saga模块完全独立，无需引入其他模式依赖，支持注解式定义补偿逻辑、可视化编排Saga流程，对Spring项目适配性极高，零额外架构改造即可接入，阿里、字节核心交易链路、海外大量中型互联网公司都有大规模落地。
• Temporal：Uber开源的工作流引擎，Saga是核心支持场景之一，无需绑定DDD概念，直接通过代码定义Saga执行步骤、重试规则、补偿逻辑，Netflix流媒体调度业务已大规模使用该组件做分布式事务管控。
• Axon 独立Saga依赖：如果已经有Axon使用基础，可单独引用其Saga核心包，排除EventSourcing、CQRS相关依赖，仅使用Saga状态管理、事件触发能力，无需落地完整DDD概念即可运行。

其他场景适配的分布式事务技术 #

• Seata AT模式：低侵入自动2PC实现，无需手动编写补偿逻辑，适合微服务链路均使用关系型数据库的场景，性能比原生XA协议高30%以上，阿里内部核心交易场景大规模使用，海外电商企业落地率也很高。
• 本地消息表+消息队列：Netflix核心链路使用最广泛的最终一致方案，无需引入第三方事务组件，本地业务执行+消息写入绑定在同一个本地事务中，异步扫描消息表推送MQ到下游服务，下游消费成功后更新消息状态，实现逻辑简单、可用性极高，适合对一致性延迟容忍度在秒级的场景。
• RocketMQ 事务消息：将本地消息表逻辑封装在MQ侧，无需自行维护消息表扫描逻辑，通过半消息发送、本地事务执行、消息提交/回滚三步即可实现最终一致，适合已经使用RocketMQ作为消息组件的架构。
• SQS+Lambda事务编排：Netflix云上业务大量使用的云原生方案，基于SQS的死信队列、延迟队列能力配合Lambda实现事务补偿，无需维护额外的事务组件。

内容的提问来源于stack exchange，提问作者henry-jo