在 ServiceBus 上发送大消息的最佳实践答案

【问题标题】：Best practice for sending large messages on ServiceBus在 ServiceBus 上发送大消息的最佳实践
【发布时间】：2015-02-04 04:06:20
【问题描述】：

我们需要在 ServiceBus 主题上发送大量消息。当前大小约为 10MB。我们最初的做法是在 BlobStorage 中保存一个临时文件，然后发送一条引用该 blob 的消息。该文件被压缩以节省上传时间。它工作正常。

今天我读到这篇文章：http://geekswithblogs.net/asmith/archive/2012/04/10/149275.aspx 建议将消息分成更小的块，然后在接收端再次聚合它们。

我承认这是一种“更简洁的方法”，避免了往返 BlobStore。另一方面，我更喜欢保持简单。分裂机制引入了增加的复杂性。我的意思是他们从一开始就没有将其包含在 ServiceBus 中一定是有原因的......

有没有人在现实生活中尝试过拆分方法？

有更好的模式吗？

【问题讨论】：

【解决方案1】：

我前段时间写了那篇博客文章，目的是实现使用服务总线的拆分器和聚合器模式。我在寻找更好的选择时偶然发现了这个问题。

我同意最简单的方法可能是使用 Blob 存储来存储消息正文，并在消息中发送对该正文的引用。这是我们目前正在为客户项目考虑的场景。

我记得几年前发布了一些示例代码，这些代码将从客户端应用程序中抽象出服务总线和存储队列，并在需要时处理大型消息体的 Blob 存储使用。（我认为是微软的 CAT 团队，但我不确定）。

我无法通过 Google 快速搜索找到该示例，但由于它可能已有几年的历史，它将会过时，因为服务总线客户端库从那时起已经改进了很多。

当消息大小太大时，我使用了消息拆分，但由于这是用于批量遥测数据，因此无需聚合消息，我可以在接收端处理一些较小的批次。一封大邮件。

拆分器-聚合器方法的另一个缺点是它需要会话，因此需要启用会话的队列或订阅。这意味着所有消息都需要会话，甚至更小的会话，并且会话 ID 不能在实现中用于其他目的。

如果我是你，我不会相信博文中的代码，它是很久以前写的，从那时起我学到了很多:-)。

Blob 存储方法可能是要走的路。

问候，

艾伦

【讨论】：

附言。如果有人找到带有服务总线和 Blob 存储的代码示例，请发布链接。
感谢艾伦的反馈。我已经决定坚持使用 BlobStorage 方法。它稳定，简单，并且可以如您所说的轻松封装。顺便说一句，我很欣赏您在斯德哥尔摩的 Azure TechX 演讲！
嗨。您可能会发现此链接很有趣“使用 Azure 队列处理大型消息的最佳实践”msdn.microsoft.com/en-us/library/azure/hh690942.aspx。它基于存储队列，但应该是使用服务总线队列进行类似植入的良好起点。
msdn 链接已损坏，通过“使用 Azure 队列处理大型消息的最佳实践”搜索也没有给我文章
查看存储队列和 blob Dealing with large Service Bus messages using claim check pattern的示例