分布式系统权威测评机构 Jepsen 发布了对 Orkes Conductor 5.3.2 的深度分析报告。Conductor 是 Netflix 于2016年开源的工作流编排系统，Orkes 公司由其原班创始团队创立，提供商业托管版本。本次测试基于典型的 Postgres 数据库加 Redis 队列部署，通过进程暂停、崩溃和网络分区等故障注入手段，共发现九类问题。其中包括三个严重安全性缺陷：部分工作流被永久遗弃在 RUNNING 状态、已确认的工作流凭空消失，以及从未执行的任务被错误标记为 COMPLETED 状态。此外还发现任务意外并发执行、任务停滞长达一小时、空工作流 ID、SQL 语法错误、重复键错误，以及将实际成功的请求误报为连接失败等问题。值得注意的是，即使在无故障的健康集群中，任务并发执行也会每隔几分钟到几小时出现一次。Orkes 已在 5.5.0 和 5.5.6 版本中修复多数严重问题，Jepsen 建议用户升级至 5.5.6。报告同时强调，Conductor 的安全性高度依赖底层存储系统，单节点 Redis 及 AWS ElastiCache、Google Memorystore 等托管服务在网络分区时均可能丢失已确认的写入。本次研究由 Orkes 出资，并遵循 Jepsen 伦理准则。
事件分析
Jepsen 测评向来被视为分布式系统的试金石，此前 Redis、MongoDB、Kafka 等知名系统都曾在其测试中暴露设计缺陷。此次报告的价值不仅在于揭示 Conductor 的具体 Bug，更在于系统展示了工作流编排引擎在部分失效下的行为边界。随着微服务与 AI Agent 编排需求快速增长，此类系统的正确性愈发关键，报告中航班被取消后又被重新预订的案例说明，非幂等任务与乱序副作用可能造成真实业务损失。另一个易被忽视的要点是存储层安全：上层系统的可靠性承诺最终受制于 Redis、Postgres 等底座的选择，各托管服务持久化配置的差异值得基础设施团队重新审视。后续可关注 #3、#6 两个未决问题的修复进展，以及 Jepsen 对 Cassandra、MySQL 等其他存储后端的扩展测试。
核心观点：工作流引擎的可靠性承诺终将受制于最弱的存储底座，幂等设计才是分布式编排的真正生命线。
原文链接：Hacker News
