消息队列和服务总线的消息粒度

Question

我正在开发一个应用程序，它可以在客户端上以相当紧密的循环生成数千条消息，以便在服务器上进行处理。事件链如下：

1. 客户端处理项目，放置在本地队列中。
2. 本地队列处理接收消息并调用Web服务。
3. Web服务在服务器上的服务总线中创建消息。
4. 服务总线处理消息到数据库。

这个想法是所有通信都是异步的，因为Web服务会有很多客户端。我知道MSMQ可以直接执行此操作，但我们并不总是在客户端上具有这种管理功能来设置安全性等。

我的问题是关于每个阶段的消息的粒度。最简单的方法意味着在客户端上处理的每个项目都会生成一个客户端消息/ Web服务调用/服务总线消息。这很好，但我知道如果可能的话，最好对Web服务调用进行批量处理，除非在大型粒度Web服务DTO与数据库上的短期运行事务之间进行权衡。这种特殊情况不需要“业务事务”，其中处理所有项目或不处理任何项目，我只是希望实现消息大小与Web服务调用数量与数据库事务数量之间的最佳平衡。

有什么建议吗？

Answer 1

Chatty接口（即大量和大量的消息）往往会有很高的开销，即将传入的消息（以及客户端的回复）发送到正确的代码来处理消息（这将是一个固定的成本每条消息）。虽然大消息倾向于使用资源来处理消息。

此外，许多正在进行的Web服务调用将意味着要管理的许多TCP / IP连接，并发问题（包括锁定在数据库中）可能会成为一个问题。

但是如果没有处理消息的一些细节，除了针对繁琐的接口的一般建议之外，由于固定的开销，很难具体化。

Answer 2

先测量，稍后优化。除非您能够做出背后的估计，表明最简单的解决方案会产生无法接受的高负载，请尝试一下，建立良好的监控测量，看看它的执行和扩展。 然后开始考虑批量和批次的数量。

当然，这种方法要求您能够在部署后更改Web服务接口，因此您需要版本控制方法来处理可能未经过重新设计的客户端，从而支持多个WS版本并行。但是，不考虑版本控制几乎总是将您陷入次优的界面。

Answer 3

摘要邮件队列

并具有可交换的消息队列后端。通过这种方式，您可以测试许多后端，如果您选择了错误的后端或者想要出现一个新的后端，就可以轻松纾困。消息传递的开销通常是打包和处理请求。不同的系统是针对不同级别的流量和不同的对称性而设计的。

如果您抽象出基本功能，您可以根据需求的变化交换机制，或者更准确地评估。

您还可以在应用程序或消息路径的各个部分转换来自不同队列类型的消息，因为它们正在处理，例如1000：1 / s vs 10：1 / s更高级别。 / p>

祝你好运