【问题标题】:NService Bus - Get all Pending Messages on a QueueNServiceBus - 获取队列中的所有待处理消息
【发布时间】:2011-03-31 21:16:57
【问题描述】:

我有一个应用程序通过 WCF 从许多其他应用程序接收数据。

我现在有客户也希望收到该数据的副本,但不同的客户有不同的需求。

  • 客户 A 希望我们调用 Web 服务向他发送数据
  • 客户 B 希望我们通过电子邮件向他发送数据
  • 客户 C 想要建立自己的系统,该系统将轮询我提供的 Web 服务以接收他的数据。

我想使用 NServiceBus 已经有一段时间了,看来这是一个不错的应用程序。我想我可以通过设置端点以他们想要的格式/协议向他们提供数据来处理客户 A 和 B。不过客户 C,我很苦恼。

我在 NService 总线中看到的所有示例都涉及订阅队列并在消息进入时触发事件。我想我想在这里做的是当客户调用他的数据时,我会抓住为他在队列中的所有消息并传递它们。

我的问题是,这是 NServiceBus 的正确应用还是该工作的错误工具?如果是这样,是否有任何代码示例可以告诉我如何处理客户 C?

【问题讨论】:

    标签: c# .net nservicebus


    【解决方案1】:

    这是一个很好的问题,因为它切入了基于消息的系统(特别是 NServiceBus 如何解决很多问题)的核心。

    对于 A 和 B,您肯定朝着正确的方向前进 - 只需订阅适当的消息,然后使用他们选择的机制将数据转发/推送给您的客户。如果他们离线,没什么大不了的,基于消息的系统比其他系统更优雅地处理故障。

    有趣的是,客户 C 的服务方式与 A 和 B 几乎完全相同,但需要一些额外的步骤。首先,只需设置另一个订阅适当消息的 NSB 端点,然后使用客户 C 指示的所需结构将它们写入持久存储。您可以将消息写入本地数据库、JSON 文件甚至 Amazon S3 斑点。从那里您只需要设置某种 HTTP 端点(不使用 NServiceBus),允许客户查询和检索适当的数据。如果您使用 S3 并发送 JSON blob,您甚至可能不需要设置 HTTP 服务器——只需让 Amazon 完成所有工作。

    另一个非常酷的副作用是,如果未来的客户 D 和 E 决定他们也想要轮询,但他们需要彼此和客户 C 略有不同的格式,您可以通过设置另一个处理程序来适应他们根据文件指定的格式写出文件(或数据库插入)——所有这些都不会改变您的系统行为。

    【讨论】:

    • 我担心这会成为答案,因为这意味着增加一些复杂性和更多存储等,但它会完成工作。使用您提出的解决方案,我是否还将 NSB 放在 Web 服务和持久性(在您的示例中为 s3)之间,还是应该以“正常”同步方式构建它?
    • 每当客户直接查询数据时,只需以最简单的方式将其提供给他们,而不必担心将 NServiceBus 添加到混合中。此外,您现在可能正在添加“复杂性”,但实际上并非如此——您通过将关注点分开来使事情变得简单。这有助于在您的成长过程中保持架构的整洁和可扩展性。
    • 这可能应该是另一个问题,但是有1个队列更有意义,然后根据客户(消息中的数据)切换传递机制,还是更好每个客户都有单独的队列?我倾向于后者。
    • 这取决于每个客户的 SLA 要求。如果有严格的 SLA 并且为高可用性和集群支付更多费用,我绝对会隔离队列。否则,只会增加开销。
    【解决方案2】:

    可以通过 WCF 公开端点,但它用于将消息获取到总线上。如果有人想轮询服务,我会单独托管它,并让他们在调用时进行管理。

    【讨论】:

      猜你喜欢
      • 2015-10-15
      • 1970-01-01
      • 1970-01-01
      • 2020-08-22
      • 2013-12-13
      • 1970-01-01
      • 2018-08-10
      • 1970-01-01
      • 2013-10-01
      相关资源
      最近更新 更多