当然可以！不过在切换之前，得先理清几个关键的可行性点和需要注意的差异，结合你的场景（Windows Server 2016节点、NServiceBus使用背景），我给你拆解一下：

一、可行性基础：Windows Server 2016对MSMQ的支持 #

你的Service Fabric节点都是Windows Server 2016，而MSMQ是Windows系统原生支持的消息队列组件，完全可以在这些节点上启用和使用：

• 可以通过服务器管理器的「添加角色和功能」向导安装MSMQ，或者用PowerShell命令快速部署：

  Install-WindowsFeature MSMQ, MSMQ-Server -IncludeManagementTools
  

• 安装完成后，确保每个节点上的MSMQ服务（Message Queuing）处于运行状态，并且配置好对应的权限，让Service Fabric应用的运行账户有队列的读写权限。

二、NServiceBus的平滑切换优势 #

你已经在用NServiceBus，这绝对是个加分项——NServiceBus对MSMQ传输有成熟的支持，切换起来工作量很小：

• 只需要修改应用的配置，把原来的Azure Service Bus传输替换成MSMQ传输。比如在代码配置里指定：

  endpointConfiguration.UseTransport<MsmqTransport>();
  

• 调整队列相关的配置（比如队列名称、路径），NServiceBus会自动帮你处理消息的发送、接收和重试逻辑，和你用Azure Service Bus时的开发体验基本一致，完美契合你之前提到的「切换队列技术便捷」的需求。

三、必须考虑的差异与权衡 #

虽然技术上可行，但MSMQ和Azure Service Bus是两种完全不同的队列方案，你得结合自己的需求权衡：

• 运维复杂度：Azure Service Bus是托管服务，微软帮你搞定高可用、灾备、补丁更新；而MSMQ是本地组件，你需要自己维护每个节点上的MSMQ服务，处理队列的备份、故障转移，还要管理权限和监控。
• 跨场景兼容性：如果你的应用需要和非Windows系统的服务通信，MSMQ基本没戏；但Azure Service Bus支持AMQP、HTTP等多种协议，跨平台兼容性强。
• 可靠性与灾备：Azure Service Bus自带地域冗余、消息持久化，即使单个节点故障也不会丢消息；MSMQ要实现类似的高可用，需要配置MSMQ集群或者第三方复制工具，额外的工作量不小。
• 监控与排查：Azure Service Bus有现成的Azure Monitor面板、告警和日志分析；MSMQ的监控需要自己用性能计数器、事件日志或者自定义脚本搭建排查体系。

总结建议 #

如果你的业务场景是纯Windows环境、没有跨平台通信需求，且团队有能力承担MSMQ的运维工作，那么用MSMQ替代Azure Service Bus是完全可行的，而且借助NServiceBus能快速完成切换。但如果更看重托管服务的便捷性、高可用和扩展性，Azure ServiceBus仍然是更省心的选择。

内容的提问来源于stack exchange，提问作者Hoots