目前我正在开发空间数据处理服务器。 以下是要求：
目前我已经测试过这种架构：
此外，所有服务都有配置方法和一些通过 WCF TCP 绑定调用的其他任务。
小型性能测试表明它运行得非常快，但我想知道这是将这些 MSMQ 和 WCF 一起用于此特定应用程序的最佳方式。或者也许有人可以给我一个方向？
【问题讨论】：
我不太确定您的具体问题，似乎更像是一个一般性的设计问题，但由于我喜欢 MSMQ，我会在这里插话。
MSMQ 确实有一些缺点，特别是在负载平衡事务性消息方面，但总的来说它非常棒。
但是，您的任何要求都没有提到使用 MSMQ 的任何具体原因：持久性、可恢复的消息传递、断开连接的客户端等。所以我假设您有其中一些要求，但没有明确指出它们。
要求 #1 应该很容易满足/满足，特别是如果这些消息是小消息并且没有对它们执行明显的逻辑（例如，只是普通插入/更新）并且 MSMQ 可以很好地处理竞争消费者。
要求 #2 除非您使用 MSMQ 的事务性消息传递，否则对 MSMQ 进行负载平衡以启用扩展并非不可能，但它有一些警告。您如何对 MSMQ 进行负载平衡？如果您还没有它们，请参阅How to Load-Balancing MSMQ: A Brief Discussion 了解一些详细信息。
除非使用负载平衡 MSMQ 可能会出现问题，但这些问题都不是不可克服的，这种方法没有任何问题。
扩展 MSMQ
MSMQ 可以很好地垂直扩展（同一台机器）和适度水平扩展（许多机器）。但是，要使 MSMQ 真正具有高可用性是很困难的，这可能是一个问题，也可能不是问题。有关使其高度可用的想法，请参阅此答案中已有的链接。
垂直缩放
垂直扩展 MSMQ 时，有许多队列读取器实例在单台机器上运行，从单个队列读取。 MSMQ 处理得很好。我们所有的队列数据都在本地机器上的临时存储中。
如果我们丢失了托管队列的机器会怎样？
客户端可以发送，消息会堆积在客户端的传出队列中，但在服务器恢复正常之前我们无法接收它们。
队列中的消息会发生什么变化？
如果不引入某种高度可用的支持磁盘子系统，它们可能会消失。即便如此，让另一个队列“连接”到该数据文件可能是一个挑战。理论上，你可以让他们回来。实际上，从边缘系统重新发送消息可能更容易。
根据事务量，队列大部分时间可能是空的，因此需要权衡数据丢失的风险以及使其高度可用的工作量/成本。
水平缩放
当水平扩展 MSMQ 时，每台处理机器上都有一个队列实例。每台机器可能有 [n] 个用于该队列的读取器，该队列运行在从队列接收消息的机器上。我们所有的队列数据都在多台机器上的临时存储中。
您可以使用文档中描述的任何方法对 MSMQ 进行负载平衡，但是，我的经验几乎始终是应用程序负载平衡，被描述为软件负载平衡：客户端具有可用 msmq 端点的列表交付给。托管队列的每台服务器都面临与单个队列相同的可用性问题。
还可能需要查看Nine Tips to Enterprise-proof MSMQ 以了解更多与 MSMQ 相关的信息。
【讨论】：
感谢您的回答和链接。我将 msmq 视为大量消息的可靠传输。每天 1-2 百万条信息。同样重要的是要保证服务器端的这些消息在服务器工作期间不会丢失。所以我认为我需要耐用性、可恢复的消息传递、断开连接的客户端等。
至于负载均衡：主要负载在数据解析和数据发布服务上。想法是将原始消息推送到一个队列中，并在不同的 PC 上拥有例如 3 个数据解析服务实例来解析来自它的消息并将它们存储在一个数据库中。与数据发布服务相同。或者像在 StockTrader 中那样，将通道缓存到节点并使用 wcf 向它们发送消息。
我也找不到有关 msmq wpf 绑定的性能和可扩展性的信息。尝试了 StockTrader，但对于测试目的和快速分析来说有点过于复杂。
再次感谢您的回答。
【讨论】：
真的只是在听对话，但我认为 MSMQ 通过缓冲消息实际上有助于解决并发问题是否正确。那么从队列中读取的服务器永远不会被淹没？这会将处理消息的组件上的问题从“基于事件”并发（如在网络服务器上）改变为更简单的拉取机制。
如果您仍处于未开发设计阶段，您可能还想查看 CCR 和 DSS，这些也有助于并发性。非常令人印象深刻的东西，但是如果您只需要将消息存储在数据库中，它可能对您没有多大帮助。
【讨论】：