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

Question

我正在开发一个应用程序，该应用程序可能会在客户机上生成一个非常紧的循环中的数千条消息，然后在服务器上进行处理。一连串的事件是这样的：

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

其思想是所有通信都是异步的，因为web服务将有许多客户端。我知道MSMQ可以直接做到这一点，但我们并不总是拥有客户端的那种管理功能来设置安全性等。

我的问题是关于每个阶段的消息的粒度。最简单的方法是，客户端上处理的每一项都生成一个客户端消息/web服务调用/服务总线消息。这很好，但我知道，如果可能的话，最好将web服务调用分批处理，除非在大粒度的web服务DTO与数据库上的短运行事务之间进行权衡。这个特殊的场景不需要一个“业务事务”，在这里所有或没有项目都被处理，我只是想实现消息大小与web服务调用的数量与数据库事务的数量之间的最佳平衡。

有什么建议吗？

Answer 1

聊天接口(即，大量的消息)从将传入的消息(以及客户端上的回复)发送到正确的代码以处理消息(这将是每条消息的固定成本)的过程中往往会有很高的开销。而大消息倾向于使用资源来处理消息。

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

但是，如果没有消息处理的一些细节，就很难做到具体，除了针对聊天接口的一般建议，因为固定的开销。

Answer 2

先测量，再优化。除非你能做出一个能证明最简单的解决方案会产生令人无法接受的高负荷的封套估计，尝试它，建立良好的监督措施，看看它的表现和规模。然后开始考虑批处理的数量和位置。

当然，这种方法要求您能够在部署后更改web服务接口，因此您需要一种版本控制方法来处理可能尚未重新设计的客户端，同时支持多个WS版本。但是，不管怎么说，不考虑版本控制总是会把你困在不太理想的界面中。

Answer 3

抽象消息队列

并有一个可交换的消息队列后端。通过这种方式，您可以通过测试的许多后端，并在您选择错误的后端或逐渐喜欢出现的新后端时，为自己提供一个简单的纾困。消息传递的开销通常是打包和处理请求。随着时间的推移，不同的系统被设计成不同水平的流量和不同的对称性。

如果您抽象出基本特性，您可以在需求变化时交换机制，或者进行更准确的评估。

您还可以在应用程序或消息路由的不同部分转换来自不同队列类型的消息，因为收件人的压力会发生变化，因为它们正在处理，例如，在更高级别上处理1000:1/s和10:1/s。

好运