从UI层面避免分布式事务的解决方案探讨

一、通用解决方案：跨服务事务与协作模式 #

针对核心服务依赖多支撑服务的场景，通用方案可采用两种模式组合：

• 后端编排（Saga模式）：由核心服务（Activity服务）作为协调者，统一调用各支撑服务接口，并处理失败后的补偿逻辑；
• 事件驱动最终一致性：通过消息队列异步触发跨服务操作，配合状态监听实现数据最终对齐。

二、是否让Activity服务具备创建Patient的能力？ #

不建议直接赋予Activity服务创建Patient的逻辑，理由如下：

• 违反单一职责：Patient服务的核心是患者数据全生命周期管理（含外部病历系统对接），Activity服务应专注于事件记录与事务核心流程，混同职责会导致服务耦合度飙升，后续维护成本剧增；
• 数据入口混乱：Patient数据需在Activity场景外复用，若由Activity服务创建，会导致患者数据的创建入口不唯一，难以统一校验规则、外部集成逻辑（比如病历系统同步）。

但可让Activity服务作为调用方触发Patient创建——即Activity服务通过调用Patient服务的接口来完成患者创建，而非自行实现创建逻辑。

三、UI发起顺序API调用是否可行？ #

可行，但存在明显局限性：

• 优势：实现简单，无需额外后端组件，适合初期业务规模较小的场景；
• 风险：
  • 网络波动或服务超时可能导致流程中断（比如Patient创建成功，但Activity创建失败），需前端做重试或补偿，增加前端复杂度；
  • 若后续需聚合更多服务（比如关联医生、工单），UI端调用链会越来越长，难以维护；
  • 多服务调用叠加会延长页面等待时间，影响用户体验。

若采用该方案，必须配套：

• 前端幂等性控制：确保重复调用不会生成重复的Patient或Activity；
• 失败后的状态提示与重试机制：比如Activity创建失败时，允许用户手动重试，或前端自动触发补偿（如删除已创建的无效Patient）。

四、最终一致性方案能否满足UX需求？ #

可以，但需针对性适配UX逻辑，核心思路是本地乐观展示+后台异步同步：

1. 即时反馈逻辑：
   • 用户点击保存后，前端立即生成临时的Activity只读展示数据（含前端临时ID或占位符），直接切换到只读模式；
   • 同时后台发起异步流程：先调用Patient服务创建患者，再创建Activity，最后将真实的Patient ID和Activity ID同步到前端。
2. 状态同步与异常处理：
   • 前端通过WebSocket或轮询监听后台流程状态，流程完成后自动替换临时数据为真实数据；
   • 若流程失败，前端弹出提示，允许用户重新发起创建，同时通知Patient服务清理未关联的无效患者记录。
3. 关键适配点：
   • 确保前端临时展示的核心字段（如患者姓名、来电事由）与最终真实数据完全一致；
   • 依赖真实ID的后续操作（如编辑Activity），需在流程完成后才开放入口。

总结建议 #

结合你的业务约束与需求，优先推荐后端Saga模式+前端乐观展示的组合：

1. 后端层面：让Activity服务作为Saga协调者，统一调用Patient服务创建患者，再完成自身的Activity创建；任一环节失败则触发补偿逻辑（如删除已创建的Patient）；
2. 前端层面：点击保存后立即展示乐观只读视图，通过WebSocket接收后端流程状态更新，自动同步真实数据；
3. 配套保障：
   • 所有服务接口实现幂等性，避免重复创建；
   • 记录流程日志，便于问题排查与人工补偿；
   • Patient服务提供清理未关联患者的接口，用于异常场景的数据回收。

内容的提问来源于stack exchange，提问作者Logan Cooper