强终端弱管道：分散式工作流工具拒绝"中心蜘蛛"式集中化

Martin Fowler在2014年那篇著名的微服务文章里区分了两种服务间通信思路：一种是企业服务总线（ESB）式的做法，把智能都塞进通信机制里，让ESB负责复杂的消息路由、编排、传输和业务规则处理；微服务社区偏向的另一种是”强终端弱管道”——服务本身尽可能保持松耦合高内聚、自己拥有领域逻辑，行为更像经典UNIX意义上的过滤器（接收请求、恰当处理、返回响应），彼此间用简单的类REST协议做编排，而不是WS-Choreography或BPEL这类复杂协议，更不用集中式工具编排。这篇文章至今依然成立，它本质上是对SOA和集中式BPM套件（见[[BPM与SOA时代集中式工具失败的具体教训]]）的一种共识性反思，也导致很多人（尤其在微服务社区）直接把”流程自动化”或”编排”这两个词和集中式工具画上等号——脑海中浮现出网络中一只”中心蜘蛛”的意象，这恰好与微服务追求隔离和自治的价值观背道而驰，因为它引入了架构单点，还会增加组织摩擦（人人都得去找”BPM团队”沟通）。但流程自动化本身根本不需要集中化：业务流程应按照限界上下文和服务边界设计，避免巨石流程；流程模型是领域逻辑，应该和其他领域逻辑代码放进同一个边界；工作流引擎完全可以分散运行——每个服务团队自主选择、自主运维自己的引擎，甚至可以完全不用工作流引擎。这也是本章最重要的思维转变：把”流程自动化”这个词彻底从”集中式工具”的联想中剥离出来。