Conductor 生产环境部署指南：架构拆解、Docker 部署与高可用配置-育师

Conductor 生产环境部署指南：架构拆解、Docker 部署与高可用配置

【免费下载链接】conductorConductor is an event driven agentic workflow engine providing durable and highly resilient execution engine for applications and AI Agents项目地址: https://gitcode.com/GitHub_Trending/co/conductor

Conductor 是开源、可自托管的编排引擎，生产部署意味着在自有基础设施上运行服务端，并为工作流引擎搭配数据库、队列、索引与分布式锁等后端组件。本篇以 docs/devguide/running/deploy.md 为骨架，结合仓库内真实的 Docker Compose 文件、服务端配置文件与ConductorProperties源码，完整讲解部署架构、Docker 运行方式、数据库/队列/索引/锁的配置方法、横向扩展、监控与常见故障排查，读完即可落地一套可投入生产的多实例 Conductor 集群。

部署架构总览

一个完整的 Conductor 部署由以下组件构成：

各组件职责如下：

组件	职责
API Server	暴露面向工作流与任务操作的 REST 和 gRPC 端点。
Decider	核心状态机。评估工作流状态并调度下一批待执行任务。
Sweeper	后台进程，轮询运行中的工作流并触发 decider 进行求值；长耗时工作流能否持续推进，依赖 sweeper 的正常运行。
System Task Workers	在服务端 JVM 内执行内置任务类型（HTTP、Event、Wait、Inline、JSON_JQ 等）。
Event Processor	监听配置的事件总线，根据到达的事件触发工作流或完成任务。
Database	持久化工作流定义、执行状态、任务状态与 poll 数据。
Queue	管理任务调度：待执行任务、延迟任务以及 sweeper 自身的工作队列。
Index	支撑 UI 与搜索 API 中的工作流/任务检索。
Lock	分布式锁，防止多个服务端实例对同一工作流并发求值。生产环境必须启用。

其中 Sweeper、System Task Workers、Event Processor 都内嵌在 Conductor server 进程中运行，这是后续配置线程数、进行容量规划的前提。

使用 Docker 快速运行

单机一体镜像（standalone）

想先跑起来看效果，可以用官方提供的 standalone 镜像。它内置服务端、UI 和 SQLite 持久化，无需任何外部依赖：

docker run -p 8080:8080 conductoross/conductor:latest

启动后访问以下地址：

URL	说明
`http://localhost:8080`	Conductor UI
`http://localhost:8080/swagger-ui/index.html`	REST API 文档
`http://localhost:8080/api/`	API 基础地址

生产环境应固定发布标签（如conductoross/conductor:3.4.0）而不是latest，以便在可控时机完成升级。

Docker Compose 组合后端

仓库自带了多套将服务端与生产后端配对编排的 compose 文件（位于 docker/ 目录）：

git clone https://github.com/conductor-oss/conductor cd conductor docker compose -f docker/docker-compose.yaml up

这会在本机拉起 Conductor + Redis（同时充当数据库与队列）+ Elasticsearch（索引），服务端与 UI 监听8080端口。从源码构建镜像时，Compose 会使用 docker/server/Dockerfile，该文件基于azul/zulu-openjdk-debian:21构建 server JAR，再用debian:stable-slim作为运行时镜像并内置 nginx 托管 UI 静态资源。

仓库提供的预编排组合：

Compose 文件	数据库	队列	索引
`docker-compose.yaml`	Redis	Redis	Elasticsearch 7
`docker-compose-es8.yaml`	Redis	Redis	Elasticsearch 8
`docker-compose-postgres.yaml`	PostgreSQL	PostgreSQL	PostgreSQL
`docker-compose-postgres-es7.yaml`	PostgreSQL	PostgreSQL	Elasticsearch 7
`docker-compose-mysql.yaml`	MySQL	Redis	Elasticsearch 7
`docker-compose-cassandra-es7.yaml`	Cassandra	Redis	Elasticsearch 7
`docker-compose-redis-os2.yaml`	Redis	Redis	OpenSearch 2
`docker-compose-redis-os3.yaml`	Redis	Redis	OpenSearch 3

# 示例：全部使用 PostgreSQL docker compose -f docker/docker-compose-postgres.yaml up # 示例：Redis + Elasticsearch 8 docker compose -f docker/docker-compose-es8.yaml up # 示例：Redis + OpenSearch 3 docker compose -f docker/docker-compose-redis-os3.yaml up

若使用 Elasticsearch 8，需设置conductor.indexing.type=elasticsearch8，并选用 config-redis-es8.properties 或等效的自定义配置。以 docker-compose.yaml 为例，服务端通过环境变量CONFIG_PROP=config-redis.properties加载配置，并依赖 ES 与 Redis 的 healthcheck 通过后才启动；docker-compose-postgres.yaml 则使用postgres:16镜像并以POSTGRES_USER=conductor/POSTGRES_PASSWORD=conductor初始化数据库。

自定义配置注入

镜像在CONFIG_PROP环境变量指向某个 properties 文件时，会从/app/config读取该文件。挂载自己的文件并设置变量即可：

docker run -p 8080:8080 \ -e CONFIG_PROP=config.properties \ -v /path/to/my-config.properties:/app/config/config.properties \ conductoross/conductor:latest

注意：不设置CONFIG_PROP时，服务端会忽略挂载的文件，直接以内置的 SQLite 默认配置启动。这一点在 startup.sh 中有明确逻辑——未设置CONFIG_PROP时直接java -jar conductor-server.jar运行，设置后则以-DCONDUCTOR_CONFIG_FILE=/app/config/$CONFIG_PROP加载配置。

JVM 参数通过JAVA_OPTS环境变量传入，例如-e JAVA_OPTS="-Xms2g -Xmx4g"。

停止服务

# Ctrl+C 停止，然后： docker compose down

生产配置详解

Conductor 的所有配置均通过 Spring Boot properties（application.properties）或环境变量完成，也可以以 Docker volume 挂载。配置项在源码中都有对应的属性定义与默认值，核心集中在 ConductorProperties.java，下文各默认值均与源码一致。

数据库

数据库负责持久化工作流定义、执行状态、任务状态与事件处理器定义：

conductor.db.type=postgres

支持的数据库后端：

后端	属性值	适用场景	备注
PostgreSQL	`postgres`	生产首选。ACID 事务，同时可充当索引后端。	需要`spring.datasource.*`配置。
MySQL	`mysql`	团队已在使用 MySQL 时的备选。	需要`spring.datasource.*`配置；队列需另配 Redis。
Redis	`redis_standalone`	快速、简单，适合中等规模。	需要`conductor.redis.*`配置；也支持`redis_cluster`与`redis_sentinel`。
Cassandra	`cassandra`	高写入吞吐、多区域部署。	需要`conductor.cassandra.*`配置。
SQLite	`sqlite`	仅限本地开发。单文件、零配置。	默认值，不可用于生产。

PostgreSQL

conductor.db.type=postgres conductor.external-payload-storage.type=postgres spring.datasource.url=jdbc:postgresql://db-host:5432/conductor spring.datasource.username=conductor spring.datasource.password=<password> # 可选调优 conductor.postgres.deadlockRetryMax=3 conductor.postgres.taskDefCacheRefreshInterval=60s conductor.postgres.asyncMaxPoolSize=12 conductor.postgres.asyncWorkerQueueSize=100

MySQL

conductor.db.type=mysql spring.datasource.url=jdbc:mysql://db-host:3306/conductor spring.datasource.username=conductor spring.datasource.password=<password> # 可选调优 conductor.mysql.deadlockRetryMax=3 conductor.mysql.taskDefCacheRefreshInterval=60s

Redis

conductor.db.type=redis_standalone # 格式：host:port:rack（多主机用分号分隔） conductor.redis.hosts=redis-host:6379:us-east-1c conductor.redis.workflowNamespacePrefix=conductor conductor.redis.queueNamespacePrefix=conductor_queues conductor.redis.taskDefCacheRefreshInterval=1s # 连接池 conductor.redis.maxIdleConnections=8 conductor.redis.minIdleConnections=5 # SSL conductor.redis.ssl=false # 认证（密码取自第一条 host 条目：host:port:rack:password） # 或直接设置 conductor.redis.username 和 conductor.redis.password

仓库自带的 config-redis.properties 展示了这一组合的实际写法，并额外启用了management.health.redis.enabled=true让 Redis 健康状态参与/actuator/health判定。

队列

队列后端负责任务调度：追踪哪些任务处于 pending、delayed 或 ready 状态，sweeper 与系统任务 worker 都依赖它：

conductor.queue.type=postgres

支持的队列后端：

后端	属性值	适用场景
PostgreSQL	`postgres`	数据库也用 PostgreSQL 时，栈最简单。
Redis	`redis_standalone`	数据库是 Redis 或 MySQL 时使用，低延迟。
SQLite	`sqlite`	仅限本地开发。

提示：让队列后端与数据库匹配。PostgreSQL 数据库 + PostgreSQL 队列是生产中最简单的组合——少一个外部依赖；若数据库用 MySQL，则用 Redis 充当队列。

索引

索引后端支撑 UI 及/api/workflow/search、/api/tasks/search接口的工作流与任务搜索：

conductor.indexing.enabled=true conductor.indexing.type=postgres

支持的索引后端：

后端	属性值	适用场景	备注
PostgreSQL	`postgres`	数据库同为 PostgreSQL 时最简单的组合。	需设置`conductor.elasticsearch.version=0`禁用 ES 客户端。
Elasticsearch 7	`elasticsearch`	大规模下搜索性能最佳，支持全文检索。	设置`conductor.elasticsearch.version=7`。
Elasticsearch 8	`elasticsearch8`	配合 ES8 persistence 模块使用。	设置`conductor.elasticsearch.version=8`。
OpenSearch 2	`opensearch2`	开源的 ES 替代方案。	兼容 ES 7 查询语法。
OpenSearch 3	`opensearch3`	最新版 OpenSearch。
SQLite	`sqlite`	仅限本地开发。
禁用	不适用	设置`conductor.indexing.enabled=false`，UI 搜索将不可用。

PostgreSQL 索引

conductor.indexing.enabled=true conductor.indexing.type=postgres # 禁用 Elasticsearch 客户端 conductor.elasticsearch.version=0

Elasticsearch 7

conductor.indexing.enabled=true conductor.elasticsearch.url=http://es-host:9200 conductor.elasticsearch.version=7 conductor.elasticsearch.indexName=conductor conductor.elasticsearch.clusterHealthColor=yellow # 性能调优 conductor.elasticsearch.indexBatchSize=1 conductor.elasticsearch.asyncMaxPoolSize=12 conductor.elasticsearch.asyncWorkerQueueSize=100 conductor.elasticsearch.asyncBufferFlushTimeout=10s conductor.elasticsearch.indexShardCount=5 conductor.elasticsearch.indexReplicasCount=1 # 认证（如开启了安全） conductor.elasticsearch.username=elastic conductor.elasticsearch.password=<password>

Elasticsearch 8

conductor.indexing.enabled=true conductor.indexing.type=elasticsearch8 conductor.elasticsearch.url=http://es-host:9200 conductor.elasticsearch.version=8 conductor.elasticsearch.indexName=conductor conductor.elasticsearch.clusterHealthColor=yellow

OpenSearch

conductor.indexing.enabled=true conductor.indexing.type=opensearch2 # 或 opensearch3 conductor.opensearch.url=http://os-host:9200 conductor.opensearch.indexPrefix=conductor conductor.opensearch.clusterHealthColor=yellow conductor.opensearch.indexReplicasCount=0

异步索引

高吞吐场景下建议开启异步索引，将索引写入路径与工作流执行路径解耦：

conductor.app.asyncIndexingEnabled=true conductor.app.asyncUpdateShortRunningWorkflowDuration=30s conductor.app.asyncUpdateDelay=60s

源码中asyncIndexingEnabled默认值为false（ConductorProperties.java），需要显式开启。

索引内容开关

控制具体索引哪些内容：

conductor.app.taskIndexingEnabled=true conductor.app.taskExecLogIndexingEnabled=true conductor.app.eventMessageIndexingEnabled=true conductor.app.eventExecutionIndexingEnabled=true

分布式锁

生产必配。多个服务端实例并发评估同一工作流时，分布式锁可防止竞态条件。生产环境务必启用基于 Redis 或 Zookeeper 的分布式锁。

conductor.workflow-execution-lock.type=redis conductor.app.workflowExecutionLockEnabled=true

支持的锁提供方：

提供方	属性值	适用场景
Redis	`redis`	推荐。栈中已有 Redis 时直接使用。
Zookeeper	`zookeeper`	已有 Zookeeper（如 Kafka 部署）时使用。
Local	`local_only`	仅限单实例开发。多实例不安全。

Redis 锁

conductor.workflow-execution-lock.type=redis conductor.app.workflowExecutionLockEnabled=true conductor.app.lockLeaseTime=60000 # 锁最多持有 60s conductor.app.lockTimeToTry=500 # 获取锁最多等待 500ms conductor.redis-lock.serverType=SINGLE # SINGLE、CLUSTER 或 SENTINEL conductor.redis-lock.serverAddress=redis://redis-host:6379 # conductor.redis-lock.serverPassword=<password> # conductor.redis-lock.serverMasterName=master # Sentinel 模式使用 # conductor.redis-lock.namespace=conductor # key 前缀 conductor.redis-lock.ignoreLockingExceptions=false

Sentinel 多端点：使用SENTINEL类型时，可加分号分隔的多个 sentinel 地址以提升高可用：
conductor.redis-lock.serverType=SENTINEL conductor.redis-lock.serverAddress=redis://sentinel-0:26379;redis://sentinel-1:26379 conductor.redis-lock.serverMasterName=mymaster
即使某个 sentinel 节点宕机，锁客户端仍能发现 master。

Zookeeper 锁

conductor.workflow-execution-lock.type=zookeeper conductor.app.workflowExecutionLockEnabled=true conductor.app.lockLeaseTime=60000 conductor.app.lockTimeToTry=500 conductor.zookeeper-lock.connectionString=zk1:2181,zk2:2181,zk3:2181 # conductor.zookeeper-lock.sessionTimeoutMs=60000 # conductor.zookeeper-lock.connectionTimeoutMs=15000 # conductor.zookeeper-lock.namespace=conductor

需要说明的是，源码中workflowExecutionLockEnabled的默认值实际上是true（ConductorProperties.java），lockLeaseTime默认 60000ms、lockTimeToTry默认 500ms（同文件 L80、L85），与文档中的推荐值一致——在生产多实例部署中请务必确认锁提供方（conductor.workflow-execution-lock.type）已正确配置。

Sweeper 调优

sweeper 是监控运行中工作流的后台进程：它轮询需要求值的工作流队列并触发 decider。没有 sweeper，长耗时工作流将无法推进。sweeper 内嵌在 Conductor server 中自动运行，可按工作流量调整线程数：

# sweeper 线程数（默认：availableProcessors * 2） conductor.app.sweeperThreadCount=8 # 轮询 sweep 队列的等待时间（默认：2000ms） conductor.app.sweeperWorkflowPollTimeout=2000 # 每次 sweep 轮询的批大小（默认：2） conductor.app.sweeper.sweepBatchSize=2 # 队列 pop 超时时间 ms（默认：100） conductor.app.sweeper.queuePopTimeout=100

Sweeper 容量建议：从sweeperThreadCount = 2 * CPU 核数起步。若工作流长时间停留在 RUNNING，则调大；若空闲时 CPU 占用过高，则调小。

系统任务 Worker

系统任务 worker 在 Conductor server JVM 内部执行内置任务类型（HTTP、Event、Wait、Inline、JSON_JQ_TRANSFORM 等），轮询内部队列执行已调度的系统任务：

# 系统任务 worker 线程数（默认：availableProcessors * 2） conductor.app.systemTaskWorkerThreadCount=20 # 单次最多轮询的任务数（默认：与线程数相同） conductor.app.systemTaskMaxPollCount=20 # 轮询间隔（默认：50ms） conductor.app.systemTaskWorkerPollInterval=50ms # 回调间隔——多久重新检查一次异步系统任务（默认：30s） conductor.app.systemTaskWorkerCallbackDuration=30s # 队列 pop 超时时间（默认：100ms） conductor.app.systemTaskQueuePopTimeout=100ms

以上默认值均可在 ConductorProperties.java 中查到源码佐证（systemTaskWorkerThreadCount默认availableProcessors * 2，systemTaskMaxPollCount默认等于线程数，systemTaskWorkerCallbackDuration默认 30s，systemTaskWorkerPollInterval默认 50ms）。

独立运行系统任务 Worker

大型部署中，可将系统任务 worker 拆分到专用实例上，与 API server 分离。通过execution namespace隔离由哪个实例处理系统任务：

# API 专属实例——设置一个没有 worker 监听的 namespace conductor.app.systemTaskWorkerExecutionNamespace=api-only conductor.app.systemTaskWorkerThreadCount=0 # 专用系统任务 worker 实例——保持 namespace 一致 conductor.app.systemTaskWorkerExecutionNamespace=worker-pool-1 conductor.app.systemTaskWorkerThreadCount=40 conductor.app.systemTaskMaxPollCount=40

隔离系统任务 Worker

需要按任务域隔离（将特定任务路由到特定 worker 组）时：

# 每个隔离组的线程数（默认：1） conductor.app.isolatedSystemTaskWorkerThreadCount=4

延后阈值

当系统任务被轮询多次仍未完成（例如 Join 等待分支）时，Conductor 会渐进式延迟重新求值，避免忙轮询：

# 超过该轮询次数后开始指数退避（默认：200） conductor.app.systemTaskPostponeThreshold=200

事件处理

事件处理器监听配置的事件总线，根据到达的事件触发工作流或完成任务：

# 事件处理线程数（默认：2） conductor.app.eventProcessorThreadCount=4 # 事件队列轮询 conductor.app.eventQueueSchedulerPollThreadCount=4 # 默认：CPU 核数 conductor.app.eventQueuePollInterval=100ms conductor.app.eventQueuePollCount=10 conductor.app.eventQueueLongPollTimeout=1000ms

关于 Kafka、NATS、AMQP、SQS 事件队列的具体配置，参见事件驱动食谱。Kafka 相关实现位于 kafka/ 与 kafka-event-queue/，NATS 位于 nats/。

Payload 大小限制

Conductor 强制 payload 大小上限，防止超大 payload 拖垮性能。超过阈值时，数据会自动存入外部 payload 存储（S3、PostgreSQL 或 Azure Blob）：

# 工作流输入/输出——超过则移入外部存储（默认：5120 KB） conductor.app.workflowInputPayloadSizeThreshold=5120KB conductor.app.workflowOutputPayloadSizeThreshold=5120KB # 工作流输入/输出——硬性上限，超过则工作流失败（默认：10240 KB） conductor.app.maxWorkflowInputPayloadSizeThreshold=10240KB conductor.app.maxWorkflowOutputPayloadSizeThreshold=10240KB # 任务输入/输出——超过则移入外部存储（默认：3072 KB） conductor.app.taskInputPayloadSizeThreshold=3072KB conductor.app.taskOutputPayloadSizeThreshold=3072KB # 任务输入/输出——硬性上限，超过则任务失败（默认：10240 KB） conductor.app.maxTaskInputPayloadSizeThreshold=10240KB conductor.app.maxTaskOutputPayloadSizeThreshold=10240KB # 工作流变量——硬性上限（默认：256 KB） conductor.app.maxWorkflowVariablesPayloadSizeThreshold=256KB

外部 payload 存储配置参见外部 Payload 存储。仓库中 S3、GCS、Azure Blob 等存储实现分别位于 awss3-storage/、gcs-storage/、azureblob-storage/。

监控与可观测性

Conductor 暴露 Prometheus 兼容指标：

conductor.metrics-prometheus.enabled=true management.endpoints.web.exposure.include=health,info,prometheus management.metrics.web.server.request.autotime.percentiles=0.50,0.75,0.90,0.95,0.99 management.endpoint.health.show-details=always

其中management.endpoints.web.exposure.include一行与服务端默认一致，因此即使不做自定义配置，health、info、prometheus三个端点也已暴露。Prometheus 直接抓取http://<conductor-host>:8080/actuator/prometheus即可。可用指标清单见服务端指标与客户端指标。

健康检查

存活与就绪探针指向http://<conductor-host>:8080/actuator/health。若想专门验证 API 层，请求GET /api/metadata/workflow，健康服务端返回200。注意：不存在/api/health端点。镜像内置的 HEALTHCHECK 亦使用curl -I -XGET http://localhost:8080/health（见 Dockerfile）。

多实例部署与横向扩展

为实现高可用与横向扩展，可在负载均衡器后面运行多个 Conductor server 实例。所有实例共享同一套数据库、队列、索引与锁后端——这也是工作流引擎支撑海量并发执行的架构前提。

必要条件：

必须启用分布式锁（redis或zookeeper）。否则多个实例并发求值同一工作流会引发竞态。
所有实例必须指向同一套数据库、队列与索引后端。
负载均衡建议使用 round-robin 或 least-connections 策略。

可选：拆分 API 与 Worker 实例：

┌──────────────────┐ ┌──────────────────┐ │ API Instance 1 │ │ API Instance 2 │ ← 处理 REST/gRPC，系统任务线程低 │ (systemTask=0) │ │ (systemTask=0) │ └────────┬─────────┘ └────────┬─────────┘ │ │ ┌────┴────────────────────────┴────┐ │ Load Balancer │ └────┬────────────────────────┬────┘ │ │ ┌────────┴──────────┐ ┌───────┴───────────┐ │ Worker Instance │ │ Worker Instance │ ← 系统任务线程高，承载 sweeper │ (systemTask=40) │ │ (systemTask=40) │ └───────────────────┘ └───────────────────┘

该拆分正是上文"独立运行系统任务 Worker"小节中 execution namespace 机制的集群级应用：API 实例设置systemTaskWorkerExecutionNamespace=api-only与systemTaskWorkerThreadCount=0，worker 实例设置匹配的 namespace 并放大线程数。

故障排查速查表

问题	修复
内存不足或性能缓慢	检查 JVM 堆占用，按需调整`-Xms`/`-Xmx`。用`jstat`或`/actuator/health`监控。
Elasticsearch 停留在 yellow 状态	设置`conductor.elasticsearch.clusterHealthColor=yellow`，或增加 ES 节点达到 green。
工作流卡在 RUNNING	确认 sweeper 在运行且`sweeperThreadCount > 0`；确认锁提供方可达。
系统任务不执行	确认`systemTaskWorkerThreadCount > 0`且队列后端可达。
配置改动不生效	properties 在构建镜像时被打入 Docker 镜像。请改用挂载 volume 而不是重新构建镜像。

最后一条尤其值得注意：由于配置在镜像构建阶段固化，生产环境调整配置时推荐通过CONFIG_PROP+ volume 挂载方式覆盖（见上文"自定义配置注入"），而不是反复重建镜像。

结语

从组件架构看，Conductor 的生产部署本质上是把"数据库 + 队列 + 索引 + 锁"四个后端正确组合并调优；从运行方式看，standalone 镜像适合体验、Compose 组合适合快速验证、自定义挂载适合生产收敛配置；从可靠性看，分布式锁与 sweeper 线程数是多实例下工作流推进的命门。配合本仓库 docker/ 下的 compose 与 properties 模板，以及 ConductorProperties.java 中的默认值清单，即可对照本文逐项落地一套可监控、可扩展、可排障的生产部署。

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考