消息队列方案 - 排队和远程Web服务

Question

（请参阅下面的幻灯片链接）我正在尝试创建与审计能力的请求和响应服务，该服务与远程Web服务交互。我在确定我的方法的正确实现方面遇到了一些麻烦。基本上，我需要实现如何工作如下。

• 请求者应用程序（A）将生成请求XML并将其添加到请求“队列”。一个 然后，请求处理器将从“队列”中获取未处理的记录 将其发布到具有唯一ID的远程Web服务（X），如果请求不成功请求保留/（requestComplete flag = 0）在请求'队列'中重试晚点。

• 如果请求 成功，则会保留/（requestComplete flag = 1）并且不会重试

• 稍后，Receiver Web服务（B）会收到来自请求中调用的“X”服务的响应。

• 'B'然后搜索请求记录以查找原始请求并关联'A'请求和'X'响应（使用唯一ID进行匹配）。

• 对响应进行了一些额外的处理，“队列”中的记录更新为已完成。

通过这种方式，可以获得从请求到响应的完整审计跟踪。我可以看到原始请求何时发出，如果通过查看“队列”记录而发出请求错误。同样的响应，我可以看到它何时被收到。

我有两种方法可以实现这一点。

1. Scenario 1使用充当请求队列的数据库表，将响应队列和审计跟踪合二为一。具有GUID的表中的一行可以在流程的任何阶段（请求 - >处理 - >收据）中引用并在此过程中更新。麻烦的是，我收集的这个实现并不像MSMQ（推/弹）这样的真正的队列，可以交易，而不是可扩展的。
2. Scenario 2对于实际的队列实现，我做了一些研究，并考虑使用可能有多个队列的MSMQ;一个处理器队列，用于处理请求的处理和发送，然后将完成的请求推送到Receiver Queue以等待来自'X'的响应。这种方法的唯一问题是没有明确的审计跟踪，即一旦接收到请求就从队列中删除，同样响应。除非我使用数据库表来存储请求和响应队列以进行审计。我已经读过有MSMQ的日记类型交易确实记录了哪些记录排队，但我正在寻找更完整的解决方案或确实有关此问题的建议。

只是几点说明：

• 请求'A'使用唯一ID发送给'X'，'X'向引用该唯一ID的'B'发送响应。这允许'B'跟踪请求记录'A'。
• 我需要能够重试失败的'X'尝试（任何错误400或404需要重试）
• 我需要能够为请求/响应保留审计跟踪。
• 我正在使用C＃，WCF，MSMQ，SQL Server 2008 R2，VS 2012。

如果任何人对处理上述情景的最佳做法有任何建议或指导，任何评论或任何知识，那将是非常有益的。

Answer 1

我建议看一辆带有传奇的服务巴士（我的偏好是Rhino Service Bus，但NServiceBus也有很多牵引力，还有Mass Transit）

基本上，服务总线将处理排队（也称为发送）消息和出队（也称为接收和处理它们）的管道。然后，一个传奇将协助维持对话的状态（对话由多个消息组成）。

以后重试的问题可以非常优雅地处理Rhino Service Bus中的延迟消息，以及NServiceBus中的超时（我没有Mass Transit的经验）。

我会将结果日志存储在数据库中，以便于查询和查询。报告。我还宁愿使用带有MSMQ（或任何其他队列）的servicebus，而不是使用数据库表作为“队列” - 前者是为您的场景精确设计的，而后者是处理许多不同场景的更通用的产品。因此它不会像队列实现那样有效（例如MSMQ）（虽然它可以做到 - 但缩放变得更难）。