Service Fabric - 本地集群 - 排队答案

【问题标题】：Service Fabric - Local Cluster - QueuingService Fabric - 本地集群 - 排队
【发布时间】：2019-03-21 01:46:06
【问题描述】：

我处于可以（本地）使用 Service Fabric 但无法利用 Azure 服务总线（或任何“云”）的情况。排队/发布订阅的必然结果是什么？允许使用 Service Fabric，因为它能够在本地容器中运行，并且是“免费的”。其他 3rd 方消息传递基础设施，如 RabbitMQ，也没有考虑（目前）。

我使用本地开发的总线构建了系统，基于 MSMQ 和 WCF，但我不知道如何在 SF 中完成同样的事情。我怀疑我可以让 SF 服务使用公开 msmq 的自定义 ICommunicationListener，但这只能在集群内部使用（我理解它的方式）。我可以在它们前面构建一个 HTTPBridge（在 SF 中）以使它们在集群外部可用，但是我会失去生命周期解耦（客户端能够调用服务，使用队列，即使该服务不在线当时）因为桥本身不会从排队的任何方面受益。

我有几种可能性，但都患有一些仅因 SF 而存在的疾病，本地。此外，相同的代码需要轻松部署到完整的 Azure SF（我可以在其中使用 ASB，这个问题就消失了），所以我不想仅仅因为我在某些情况下托管它而构建两个单独的系统。

感谢任何提示。

【问题讨论】：

标签： wcf azure-service-fabric msmq bus queuing

【解决方案1】：

您可以自己构建它，例如like this。这使用 BrokerService 将消息数据分发给订阅的服务和参与者。
您还可以使用volumes 运行容器化队列平台like RabbitMQ。

通过在集群内运行队列系统，您不会引入外部依赖。

【讨论】：

【解决方案2】：

问题不在于 SF，您设计的主要问题是您将架构需求与实现耦合。 SF 在 VirtualMachines 之上运行，最后，唯一的区别是 SF 将服务放在这些机器中，使用另一种解决方案，您将有一个代理在其中部署这些服务或进行手动部署。挑战是一样的。

从描述中可以看出，你的设计需求是需要一个消息队列，不管是Service Bus、RabbitMQ还是MSMQ，队列的概念都是一样的。然后每个都将具有队列的基本基础以及每个实现的细节，有些可能会添加事务，有些可能会实现多种模式，等等。

如果您基于特定的实现进行设计，您会将解决方案与实现耦合，并使您的解决方案难以维护并面临您所描述的挑战。

NServiceBus 和 Masstransit 等解决方案可减少代码中的大量耦合，如果您认为这些还不够，您可以创建自己的抽象。然后您使用配置将您的业务逻辑绑定到实现。

尽管有上述建议，但我不建议您使用不同的每个环境的解决方案，因为如前所述，每个解决方案有自己的实现，它们可能不会相互同化，例如，您可能会遇到问题生产，因为您在 DEV 和 TEST 上针对 MSMQ 开发环境，当部署到生产环境时，您使用 ServiceBus，它们有不同的限制，如消息大小、保留期和儿子开。

如果您愿意使用 MSMQ，您可以将 MSMQ 添加到运行集群的 VM 并从您的服务连接而不会出现任何问题。先看看这个 SO：How can I use MSMQ in Azure Service Fabric

【讨论】：

对。我计划分解出一个“总线”抽象，以便我可以插入其他实现（一个是“本地”总线，位于公司网络中，使用可用的部分，MSMQ 就是其中之一）。我还将构建一个针对 ASB 的实现。关键是部署/利用满足需求的总线（钱和“将我的数据保存在本地”）是我见过的两个最大因素。谢谢你的提示。我将更多地研究 MSMQ 在 SF 内部的工作方式，了解它所施加的限制。如前所述，RabbitMQ、nServiceBus 和类似的中间件是禁止使用的——但我在设计时没有这种限制。