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

【问题标题】：Message Granularity for Message Queues and Service Buses消息队列和服务总线的消息粒度
【发布时间】：2010-11-02 23:41:55
【问题描述】：

我正在开发一个应用程序，该应用程序可能会在客户端上以相当紧凑的循环生成数千条消息，然后在服务器上进行处理。事件链类似于：

客户端处理项目，放入本地队列。
本地队列处理提取消息并调用 Web 服务。
Web 服务在服务器的服务总线中创建消息。
服务总线处理消息到数据库。

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

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

有什么建议吗？

【问题讨论】：

标签： c# message-queue servicebus

【解决方案1】：

Chatty 接口（即大量消息）在将传入消息（以及客户端上的回复）分派到正确的代码以处理消息（这将是固定成本）方面往往会产生高开销每条消息）。虽然大消息倾向于使用资源来处理消息。

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

但是如果没有消息处理的一些细节，就很难具体说明，除了由于固定开销而反对聊天界面的一般建议。

【讨论】：

【解决方案2】：

先测量，后优化。除非您可以粗略估计，表明最简单的解决方案会产生不可接受的高负载，否则请尝试它，建立良好的监督测量，看看它的性能和扩展性如何。然后开始考虑要批处理多少以及在哪里进行批处理。

这种方式当然需要你能够在部署后改变web服务接口，所以你需要一个版本控制的方式来处理可能没有重新设计的客户端，支持多个WS并行版本。但无论如何，不考虑版本控制几乎总是会让您陷入次优界面。

【讨论】：

【解决方案3】：

抽象消息队列

并且有一个可交换的消息队列后端。通过这种方式，您可以测试许多后端，并在您选择错误的后端或逐渐喜欢出现的新后端时轻松解决问题。消息传递的开销通常是打包和处理请求。随着时间的推移，不同的系统针对不同级别的流量和不同的对称性而设计。

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

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

祝你好运

【讨论】：