消息队列场景 - 队列和远程 Web 服务

Question

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

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

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

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

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

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

通过这种方式，从请求到响应都有完整的审计跟踪。我可以通过查看“队列”记录来查看原始请求的发出时间，以及请求是否有错误。同样，我可以看到收到的回复，如果有的话。

我想到了两种实现方式。

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

只是一些注意事项：

• 请求“A”发送到具有唯一 ID 的“X”，“X”向“B”发送引用该唯一 ID 的响应。这允许“B”追踪请求记录“A”。
• 我需要能够重试失败的“X”尝试（需要重试任何错误 400 或 404）
• 我需要能够对请求/响应进行审计跟踪。
• 我正在使用 C#、WCF、MSMQ、SQL Server 2008 R2、VS 2012。

如果有人对采用哪种途径有任何建议或指导，有任何 cmet 或任何关于处理上述场景的最佳实践的知识，那将是非常有益的。

Answer 1

我建议看一下带有 sagas 的服务总线（我的偏好是 Rhino Service Bus，但 NServiceBus 也有很大的吸引力，还有 Mass Transit）

基本上，服务总线将处理排队（也就是发送）消息和出队（也就是接收和处理它们）的管道。然后，saga 将协助维护对话的状态（对话由多条消息组成）。

Rhino Service Bus 中的延迟消息和 NServiceBus 中的超时可以非常优雅地处理稍后重试的问题（我没有公共交通经验）。

我会将结果日志存储在数据库中，以便于查询和报告。我也宁愿使用带有 MSMQ（或任何其他队列）的服务总线，而不是将数据库表用作“队列”——前者专为您的场景而设计，而后者是一种更通用的产品，可以处理许多不同的场景和因此它不会像队列实现（例如 MSMQ）那样高效（尽管它可以做到 - 但扩展变得更加困难）。