0

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

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

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

感谢您的任何提示。

4

2 回答 2

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

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

于 2018-10-16T14:14:25.647 回答
1

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

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

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

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

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

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

于 2018-10-16T17:04:54.863 回答