工作流引擎作为通信通道：让微服务发布/订阅取代直接调用

在微服务环境中，一种存在明显争议、”人们的观点两极分化”的用法是让不同微服务直接pub/sub到中心工作流引擎，而不经过任何其他通信渠道（既不是消息传递也不是REST调用）——这延续了[[关联流程模型与代码的三种方式发布订阅引用代码与预建连接器]]描述的pub/sub机制，只不过这里把它当成了服务间通信本身，而不只是流程内部绑定胶水代码的手段。具体做法是：订单履约服务不需要写任何胶水代码去调用支付服务，支付服务直接订阅类型名为retrieve-payment的服务任务，发货服务订阅ship-goods——任务类型名本身就是连接信息，pub/sub机制天然解耦了两个服务：支付服务完全不需要了解订单履约服务的存在，只需要执行所有名为retrieve-payment的任务。这样一来，工作流引擎实际上变成了架构里的一个共享系统，功能类似消息系统。务实的公司喜欢这种做法的简单性——不用额外引入一套消息系统就能获得pub/sub式的暂时解耦；但也有公司不愿意让工作流引擎处于如此核心的通信枢纽位置，这些公司如果想要pub/sub的能力，会选择单独运行一套消息总线或事件总线。这两条路都可行，也都各有取舍，第7章会围绕自治、边界、隔离的话题进一步展开这个判断背后的推理。