Netflix 重新设计了其工作流编排引擎 Conductor，以应对公司范围内日益扩大的业务规模。目前，Conductor 支持着 150 个应用程序中定义的约 20 万个工作流，每月执行工作流约 4.2 亿次。这次重新设计将支持的工作流规模从约 2500 个任务扩大到 30000 个任务，同时将 p99 工作流评估延迟降低了约 40%。
Conductor 架构从 1.0 版到 3.0 版的演变（图片来源：Netflix 博客）
Conductor 负责协调 Netflix 内容与工作室工程、广告和游戏部门之间的分布式工作流。其演进过程包括：将执行数据从 Dynomite 迁移至 Cassandra，将大型任务的输入和输出迁移至 Amazon S3，以及用 Timestone 取代 DynoQueues。随后，他们引入 Kafka 将索引操作与执行路径解耦，并由 Elasticsearch 和 Iceberg 分别负责索引和长期存储。
在 Conductor 4.0 版本中，Netflix 发现，工作流评估仍然存在瓶颈。早期版本在评估过程中会将完整的工作流状态加载到内存中，随着工作流规模的扩大，这会造成很大的压力。新设计将工作流元数据与任务和用户数据分离，并将任务单独存储。评估器使用轻量级的工作流蓝图，仅加载下一次决策所需的任务数据。
此前，Conductor 社区的讨论已经揭示了其中的一些可扩展性挑战。2022 年，有用户报告称，55745 个工作流和 31 万个任务导致 JVM 堆内存的使用量达到 5 GB。来自 Netflix 的 Conductor 维护者 Aravind Ramkumar 解释说，该引擎会将整个正在运行的工作流加载到内存中进行评估，不过，仅加载必要部分的功能已经列入路线图。另一则 2022 年的讨论则提到了一个 1.7 MB 的工作流，其中包含近 5000 个任务条目。该用户报告称，存储工作流定义耗时近两分钟，而且从数据库中反复加载定义会影响执行时间。
Conductor 4.0 架构（图片来源：Netflix 博客）
这次重构还将待处理任务状态和终态任务状态分开存储，并在应用层进行协调（以终态为优先），从而消除了任务状态协调中的锁定机制。工作流评估被移出同步请求路径，更新被放入专用的 Timestone 队列中按顺序进行异步处理。Netflix 报告称，锁获取失败时的尝试次数——在资源竞争高峰期曾达到每个周期约 2700 次——现在已经几乎降为零。
早前的讨论还突显了工作进程扩展方面的限制。在一次关于 Conductor 的讨论中，有用户报告称，有 25000 到 30000 个正在运行的工作流，而且 HTTP 任务队列不断积压。Ramkumar 指出，增加轮询次数并不会改善处理效率，反而可能导致系统过载，因此建议采用水平扩展的方式。
Conductor 4.0 新增了原生并发控制、动态工作线程分配以及一个类型安全的 Java Workflow SDK。Netflix Ads 将其用于创意素材导入和数据清洁室工作流。Conductor 采用基于任务的编排方式，并结合了工作流定义和独立的执行引擎。两者均面向长期运行的分布式工作流。
随着 Netflix 业务向直播内容、游戏和播客等领域扩展，该公司预计工作流需求可能会增长五倍。Netflix 于 2023 年 12 月停止维护其公开发布的 Conductor 开源代码库，理由是公司正转向使用内部的 Conductor 分支，而社区贡献的模块和扩展仍然保留在独立的 Conductor 社区代码库中。
原文链接：https://www.infoq.com/news/2026/09/netflix-conductor-4-workflow/