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

Question

我正在研究一个应用程序，该应用程序可能会在客户端上以相当严格的循环生成数千条消息，以便在服务器上进行处理。事件链如下：

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

这个想法是所有的通信都是异步的，因为会有很多web服务的客户端。我知道MSMQ可以直接做到这一点，但我们并不总是有这样的管理功能在客户端设置安全等东西。

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

有什么建议吗？

Answer 1

查询界面（即大量和大量的消息）将分派传入消息（并在客户端，回复）到正确的代码来处理消息（这将是一个固定的每条消息的成本）。虽然大消息倾向于使用资源来处理消息。

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

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

Answer 2

先测量，稍后优化。除非你可以做出一个反馈信息的估计，表明最简单的解决方案会产生不可接受的高负载，那么尝试一下，建立好的监督测量，看看它是如何执行和扩展的。 然后开始考虑批量和在哪里。

这种做法，当然，需要你能够在部署之后更改Web服务接口，所以你需要一个版本的方法来处理它可能没有经过重新设计的客户端，支持若干个并联的WS版本。但是，无论如何，不​​考虑版本控制几乎总是会让你陷入次优界面。

Answer 3

摘要信息队列

，并具有可交换消息队列后端。这样，你可以测试许多后端，并让自己容易纾困，如果你选错了一个或成长像一个新的出现。消息传递的开销通常是打包和处理请求。不同的系统针对不同级别的流量和不同的对称性进行设计。

如果您抽象出基本功能，您可以根据需要更改或调整机械，或更准确地进行评估。

您也可以在应用程序或消息路由的各个部分翻译来自不同队列类型的消息，因为接收方的压力因为处理而发生变化，例如1000：1/s比较高级别上的10：1/s。

好运