【发布时间】：2017-07-04 11:02:16
【问题描述】：
现在有了 Azure 服务结构，是否还有使用单独队列解决方案（如 Windows 服务总线）的用例？缺点可能是新的单点故障，但有优点吗？队列可以添加一些缓冲，但另一方面，Service Fabric 应该能够很好地扩展并提供有状态的功能，所以不需要队列缓冲区？
【问题讨论】：
标签： .net message-queue azure-service-fabric
【发布时间】：2017-07-04 11:02:16
【问题描述】：
当然，好处是 Azure 服务总线和 Azure 存储队列等服务提供了 Service Fabric 中未包含的现成功能。所以要问自己的问题是：您是添加外部服务依赖项来获得该功能，还是通过自己在 Service Fabric 上构建它来保持自包含？ Service Fabric 上的自包含应用程序很好，但重新发明现有功能却很糟糕，因此您必须确定对您来说最有价值的地方并朝着这个方向发展。
例如，想想..
- 便携性。 Service Fabric 上自包含的应用程序可以托管在 Service Fabric 可以运行的任何地方，几乎可以在任何地方（Azure、其他公共云、您自己的计算机或数据中心等）。
- 没有外部依赖意味着更少的故障点、单一的工具集以及统一的开发、部署、升级和维护流程。
另一方面..
- Service Bus 等服务提供rich set of features。是否值得花时间在 Service Fabric 上构建和维护您自己需要的功能？
【讨论】：
-
Vaclav，明白了，问你一个问题，你知道 SF 消息队列的任何开源实现吗？我们的想法是，如果我们可以将其推广到社区中，那么我们就不必重新创建轮子了。消息队列功能似乎不会经常更改，一旦项目编写完成，它就会非常静态。
好问题！我也在纠结这个。就我而言，我正在使用 RabbitMQ 集群进行排队。我想避免它，并希望使用可靠队列来提供有状态的服务。我公开了一种将消息添加到服务的方法，并使用 RunAsync 方法在消息到达时将它们出列。与连接到 RabbitMQ 的无状态服务相比，我对使用这种方法的性能印象不深。但在我放弃之前，我计划将 Stateful 服务划分为 5 个节点，看看是否有任何性能改进，使用 Stateful 服务作为队列消费工作人员。
【讨论】：
-
我们的应用需要处理大量的对话。我从 5 个有状态服务开始，每个服务都有自己的分区，使用 Reliable Qs。分区用于帮助分配消息负载。使用这条路线，处理 1000 条消息需要 45 秒。使用 RMQ，跨 3 个分区的无状态服务，处理 1000 条消息只用了 0.350 秒！！！不仅在处理方面有了巨大的改进，而且不再需要有状态的副本。
-
为了进一步修改我上面所说的，@Vaclav Turecek 提到的缺点是应用程序的部分和部分更加分散而不是独立的。我们的一位工程师目前正在研究如何使用 Service Fabric 集群来集群 RMQ。还没有这方面的更新。我希望使用 Azure 服务总线，但业务不想与 Azure 绑定。
-
嗨@code5 - 出于兴趣，您最终对此做了什么？一直在研究类似的方法，并且对您上面的性能指标非常感兴趣。您是否将 RabbitMQ 视为来宾可执行文件或在容器中运行？
-
嗨@RobBird，实际上我们最初的想法是关于如何托管 RabbitMQ 是错误的。你看，SFX 是一个应用集群来支持我们的微服务。数据库集群也是如此。所以我们决定只生成一些 Linux 服务器（您也可以使用 Windows）并托管我们的 RMQueue 集群。因为我们需要非常高的吞吐量，所以我们选择了 Rabbit。消息服务总线提供了很好的维护方面。价格明智，它们是可比的。如果不是为了高性能我会选择MSB。总会有取舍。
-
@code5 精简的 Github Gist 将对社区有益