分散式引擎与共享引擎的取舍：自主隔离与运维简化的对立

“应该部署多少个工作流引擎”是流程自动化架构里最常见的争论之一，答案取决于组织对自主权和运维成本的权衡。分散式引擎：每个需要工作流引擎的微服务各自拥有一个引擎实例，这是微服务思维下的默认选择——延续了[[SOA与微服务架构下编排位置的根本差异]]中”自治”的逻辑，团队想更新或重新配置引擎时可以完全独立行动，甚至自主选择工具，除本团队外任何人都访问不到自己的引擎，这强化了服务边界；代价是每个团队都要自己评估和运维引擎，具体复杂度取决于技术栈（已用公有云则托管服务很容易，已用容器则Kubernetes operator能减轻负担），剩下的挑战是如何在分散的引擎上获得集中的可观测性（第11章展开）。共享引擎：为整个公司或每个部门部署一个集中式引擎，运维更简单，但代价是失去了运行时数据和产品版本两个层面的隔离性，且集中式工具本身需要具备可伸缩性和弹性，避免成为性能瓶颈或单点故障。

结构图：

flowchart TB
    subgraph 分散式["分散式引擎（微服务思维默认选择）"]
        S1[订单服务] --> E1[引擎A]
        S2[支付服务] --> E2[引擎B]
        S3[发货服务] --> E3[引擎C]
    end
    subgraph 共享式["共享引擎（简化运维）"]
        M1[订单服务] --> CE[集中式引擎]
        M2[支付服务] --> CE
        M3[发货服务] --> CE
    end
    分散式 -->|优势| A1[自主性+隔离性]
    分散式 -->|代价| A2[各团队自评估自运维+需第11章的集中可见性方案]
    共享式 -->|优势| B1[运维成本低]
    共享式 -->|代价| B2[失去运行时和版本隔离+需应对单点故障]