我参与了一个由以下应用程序组成的项目：
-
生产者应用程序：通过 ASP.NET Web API 接收来自客户端的消息，并将消息排队到消息队列中。
-
消费者应用程序：从上面的消息队列中取消消息的排队，并将消息发送到下面的处理程序应用程序。
-
处理程序应用程序：从消费者应用程序接收消息，并将消息发送到外部应用程序，如果失败，则将它们发送到死队列。
问题是： 使用者将消息从队列中取消排队，并将它们发送到处理程序。然后消费者被阻止(通过使用异步的后台线程)等待处理程序的进程。也就是说，使用者对处理程序应用执行 RPC 调用。
如果 Handler 成功将消息发送到外部应用，或者如果失败，则成功将它们排队到死队列，则 Consumer 将提交出队列。(从队列中删除邮件)
如果上述两者之一(外部应用程序或死队列)失败，使用者将回滚出队列(将消息放回队列)
我的问题是
-
使用处理程序应用程序的优缺点是什么，比较消费者除了执行消费者的当前逻辑之外还执行处理程序的逻辑？
-
删除处理程序应用程序并将处理程序的逻辑集成到消费者应用程序中是否更好？因此，消费者直接与外部应用程序通信，并处理死队列。要维护的应用程序少了一个。
让我们非常清楚：在抽象的意义上，你有两个实体——生产者和消费者。生产者发送原始消息，消费者处理它。 没有必要通过添加有关"处理程序"的详细信息来搅浑水，因为它是消费过程的逻辑部分。
那么看来，你真正的问题(也是我的)是"consumer(你的定义)增加了什么价值？请记住，没有人直接相互"交谈" - 他们通过消息队列进行通信。 在这方面，如果让最终处理部分直接将消息取消排队比使用一些中间管道更容易，那么就这样做。