2

我正在考虑消息传递。目前我们正在使用 Rebus 增加一些场景。我们也在考虑 NServiceBus。

我们正在尝试构建的场景是后台任务处理系统的概念证明。今天，我们有一些以不同方式托管的后端服务。（网络、Windows 服务、控制台应用程序）我希望将它们连接到 rebus 并开始使用竞争消费者来消费消息，一些消息将有一个侦听器，而一些消息将共享消息负载。优雅的 ：）

我从另一个问题中得到了一个很好的开始，我应该如何为一个生产者和许多消费者设置 rebus，它在概念验证中运行良好。

现在我想开始报告进度。我最初的方法是设置 pub/sub 并启动一个服务来监听来自所有服务的进度事件。如果一项服务对未来的特定进展感兴趣，则很容易订阅感兴趣的消息并开始收听。

但是我应该如何设置竞争消费者和发布/订阅？它是两个独立的东西吗？（在 rebus 情况下，一个适配器使用 UseSqlServerInOneWayClientMode / UseSqlServer 和另一个使用我们想要的协议为发布/订阅设置的适配器？）

还是有比这里有两个“公共汽车”更好的解决方案？

4

1 回答 1

3

我自己已经构建了几次类似的东西，并且使用 SignalR 报告这种后端工作进程的进度，我取得了很好的结果。

我们的设置有一堆 WPF 客户端、一个 SignalR 集线器和一堆后端工作进程。然后，所有 WPF 客户端和所有后端工作人员将建立与中心的连接，允许工作人员在工作时发送进度报告。

SignalR 有一些很好的特性，使其非常适合这种确切的问题：

  1. 发布的消息“逃逸”了 Rebus 工作单元，允许从单个消息处理程序中多次发送进度报告消息，即使它可能需要很长时间才能完成
  2. 很容易将消息一路传递给客户端，因为他们直接订阅
  3. 我们可以使用中心组功能对用户进行分组，这样我们就可以将来自后端的进度/状态消息定位到所有用户或单个用户（也可以用于部门等）

我想，最重要的一点是，这个进度报告的事情（至少在我们的例子中）不如我们的 Rebus 消息重要，即它不需要相同的可靠性等，我们可以利用它来发挥我们的优势，然后选择一项具有其他一些很好的特性的技术，这些特性被证明很酷。

于 2014-03-01T09:41:59.087 回答