1

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

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

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

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

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

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

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

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

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

只是一些注意事项：

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

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

4

1 回答 1

1

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

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

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

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

于 2013-06-10T16:55:15.140 回答