关联流程模型与代码的三种方式：发布/订阅、引用代码与预建连接器

延续[[流程解决方案是流程模型加胶水代码工作流引擎不存储业务实体]]“远离低代码、把模型和代码关联起来”的立场，添加胶水代码有三种常见思路。发布/订阅（pub/sub）：工作流引擎自身充当消息代理，无须额外部署专门的消息代理，胶水代码去订阅引擎（常见实现是长轮询），流程运行到对应服务任务时就触发订阅方处理逻辑；这种方式让胶水代码完全由开发者掌控，带来三个明显优势——任务执行与否可控（外部服务不可用时可以直接关闭订阅，所有跑到该任务的流程实例都会安静等待，恢复订阅后自动继续处理）、胶水代码的扩缩容能和工作流引擎解耦（既可以扩容承载胶水代码的应用，也可以单独建一个worker专门处理某类任务并对其扩缩容，反过来还能限制某类资源的并发，比如OCR工具授权限制只能单任务并行时，用订阅机制天然实现”一次只处理一个”）、能在胶水代码里自主处理超时（比如视频转码这种耗时任务，胶水代码里启动转码、完成后再和引擎交互，引擎本身不会因此超时）。引用代码：直接在流程模型里引用代码，工作流引擎在自己的线程/事务上下文里执行这段代码——听起来简单，却带来技术选型受限（只能用引擎所在环境的语言）、缺乏解耦（每次引擎执行到该任务都会调用，7.1节会进一步讨论耦合话题）、必须面对计算时间/超时/事务控制等约束三重代价，最终行为不仅取决于引擎本身，还取决于引擎配置和胶水代码里的具体操作，让排障变得困难——作者早年在多个开源工作流引擎项目里最初都用引用代码（图省事），但随时间推移pub/sub在多数场景下被证明更可取，云原生架构和多语言团队进一步推动了这一偏好，现代引擎因此更专注pub/sub。预建连接器：用平台自带的连接器（如HTTP连接器）通过流程模型配置引用，常见缺点是灵活性受厂商设计局限（一旦触及连接器上限，只能等厂商扩展功能）、测试更难（连接器超出流程解决方案范围，测试灵活性也受限）、厂商专用不可移植；作者明确表示这不是首选，但组合无服务器函数或RPA机器人这类场景下连接器仍有用武之地。

结构图：

flowchart TD
    A[关联流程模型与代码的三种方式] --> B[发布/订阅 pub/sub<br/>引擎充当消息代理,长轮询]
    A --> C[引用代码<br/>引擎线程内直接执行]
    A --> D[预建连接器<br/>厂商提供,流程模型内配置]
    B -->|优势| B1[任务可控开关+扩缩容解耦+超时自主处理]
    C -->|代价| C1[技术选型受限+缺乏解耦+计算时间事务约束,排障困难]
    D -->|代价| D1[灵活性受限+测试难+厂商锁定]
    B -.现代引擎的主流选择.-> E[云原生+多语言团队进一步推动]