毒丸消息与死信队列：可执行流程模型的上下文优势

异步通信和消息系统会带来一类特有的顽固问题：毒丸消息（poisoned message）——比如前端把破损数据塞进了一条新用户订单消息，服务处理这条”带毒”消息时就会抛异常；这种异常没法回抛给任何客户端，只能交给消息系统处理，默认做法是重发给接收端，但这没什么用，只会白白增加系统负载，达到设定的重试次数后，消息系统通常会把它扔进死信队列（Dead Letter Queue, DLQ）。现实的困境是，即便到今天，大多数消息工具也没有提供像样的界面去监控DLQ、检查消息内容、重新投递它们，使用者往往被迫自己搭建定制的检查机制来应对这类状况；而即使有工具辅助，诊断故障根因也不容易，因为失败的消息本身携带的上下文信息很有限——如果订单是从多个渠道进来、又经过若干服务路由，找根因就需要不少取证功夫。这正是[[流式处理实现流程自动化的弹球机架构困境]]中提到的”让数据直接流经各种队列”的又一大劣势，也是选择用可执行流程模型而不是纯消息队列串联业务逻辑的重要理由：用工作流引擎时，一个失败的流程实例本身就携带了丰富的上下文——它是从哪里开始的、走了哪条分支路径、附加了什么数据，这些信息比一条孤立的死信消息能提供的排障线索多得多。