我处于可以在本地使用Service Fabric但不能利用Azure Service Bus（或任何“云”）的情况。排队/发布-订阅的必然结果是什么？允许Service Fabric，因为它可以在本地容器中运行，并且是“免费的”。其他第三方消息传递基础结构（例如RabbitMQ）也不在桌面上。
我已经使用基于MSMQ和WCF的本地增长的总线构建了系统，但是我看不到如何在SF中完成相同的任务。我怀疑我可以让SF服务使用公开msmq的自定义ICommunicationListener，但是只能在集群内部使用（以我的理解方式）。我可以在它们前面构建一个HTTPBridge（在SF中）以使它们在集群外部可用，但是那样我会失去生命周期的解耦功能（即使该服务不在线，客户端也可以使用队列来调用服务）当时），因为网桥本身不会从排队的任何方面中受益。
我有几种可能，但所有人都患有某种疾病，这些疾病仅因局部原因而存在。另外，相同的代码需要轻松部署到完整的Azure SF（我可以在其中使用ASB，并且这个问题消失了），所以我不想仅仅因为在某些情况下将其托管在其中而构建两个单独的系统。
感谢任何提示。
答案 0 :(得分：1)
BrokerService来将消息数据分发到订阅的服务和参与者。通过在集群内部运行队列系统，您不会引入外部依赖性。
答案 1 :(得分：1)
问题不是SF，设计的主要问题是将体系结构需求与实现耦合在一起。 SF在VirtualMachines之上运行，最后，唯一的区别是SF将服务放入这些计算机中，使用另一种解决方案，您将需要一个Agent在其中部署这些服务或进行手动部署。挑战是一样的。
从描述中很明显，您的设计要求是需要消息队列，队列的概念是相同的，无论是服务总线，RabbitMQ还是MSMQ都无关紧要。然后每个人都将具有队列的基本基础，每个队列都具有每种实现的细节，有些可能添加事务，有些可能实现多种模式，等等。
如果您基于特定的实现进行设计，则将解决方案与实现耦合在一起，使解决方案难以维护，并面临您所描述的挑战。
诸如NServiceBus和Masstransit之类的解决方案可以减少代码中的许多耦合，如果您认为这些还不够，可以创建自己的抽象。然后，您可以使用配置将业务逻辑与实现联系起来。
尽管有上述建议，但我不建议您使用其他建议 每个环境的解决方案，因为如前所述，每个解决方案 具有自己的实现，并且它们可能不会彼此同化，例如，您可能会遇到以下问题： 生产，因为您是针对DEV和TEST上的MSMQ开发的 环境，并且当您使用ServiceBus部署到生产环境时，它们 有不同的限制，例如邮件大小，保留期限和儿子 上。
如果愿意使用MSMQ，则可以将MSMQ添加到运行群集的VM并从服务进行连接而不会出现任何问题。首先看看这个SO：How can I use MSMQ in Azure Service Fabric