异步请求/响应的关联规则：三种消息关联ID方案的取舍

异步通信是非阻塞式的：发送方发出请求就无需等待，一般属于消息系统的领域；它本质上让通信本身变得透明并具备长期运行的特性，这正是[[何时引入工作流引擎的价值框架长期运行能力与可见性对ROI的贡献]]描述的能力可以派上用场的场景。为了让一个正在等待响应的流程实例在响应到达时被正确找到，工作流引擎需要某种”关联规则”，把发出去的请求和后来到达的响应对上号，书中给出三种在现实中验证过的方案：一是使用人造ID（如为每次通信专门生成的UUID），发送请求时在客户端本地生成一个全新UUID并存进流程变量，这个ID只服务于这一次通信的关联，不会受到任何干扰，是推荐做法；二是不要使用工作流引擎自身的ID（如流程实例ID）做关联键，因为运维层面重启流程实例可能产生不同的ID，厂商也可能修改ID生成规则，这类风险和”很多系统最终都从数字ID转向UUID”是同一类教训；三是谨慎使用业务数据（如订单ID）做关联键，虽然通常更简单、大多数时候也能正常运行，但存在风险——比如出于某种原因把一笔支付拆成两笔，一个订单号就会对应两笔支付，最终可能导致响应无法正确关联回对应的那一次请求。BPMN还支持把发送任务和接收任务合并进一个服务任务里，让异步通信隐藏在一个看起来很简单的服务任务背后，这通常能让流程模型更容易理解、更容易和业务利益相关者沟通，尤其是当整个系统里到处都在用异步通信时，这种封装能有效清理视觉上的混乱。