我们需要在ServiceBus主题上发送大量消息。目前的大小约为10MB。我们最初的做法是在BlobStorage中保存一个临时文件，然后发送一个参考blob的消息。压缩文件以节省上传时间。它工作正常。
今天我读了这篇文章：http://geekswithblogs.net/asmith/archive/2012/04/10/149275.aspx 建议将消息拆分为较小的块，并在接收方再次聚合它们。
我可以承认这是一种更清洁的方法＆＃34;，避免往返BlobStore。另一方面，我更喜欢保持简单。分裂机制引入了更高的复杂性。我的意思是他们从一开始就没有把它包含在ServiceBus中的原因一定有...
有没有人尝试过现实生活中的分裂方法？
是否有更好的模式？
答案 0 :(得分：5)
我刚才写了那篇博客文章，意图是实现 使用服务总线的分离器和聚合器模式。在寻找更好的选择时，我偶然发现了这个问题。
我同意最简单的方法可能是使用Blob存储来存储邮件正文，并在邮件中发送对它的引用。这就是我们正在考虑的客户项目的情景。
我记得几年前，发布了一些示例代码，它们将从客户端应用程序中抽象出Service Bus和Storage Queues，并在需要时处理大型邮件正文的Blob存储。 （我认为这是微软的CAT团队，但我不确定）。
我无法通过快速谷歌搜索找到该示例，但由于它可能已经过了几年，它将会过时，因为自那时起服务总线客户端库已得到很大改进。
当消息大小太大时，我使用了消息拆分，但由于这是批量遥测数据，因此无需聚合消息，我可以在接收端处理多个较小的批次一条大信息。
分割器 - 聚合器方法的另一个缺点是它需要会话，因此会话启用了队列或订阅。这意味着所有消息都需要会话，甚至更小的会话，并且会话ID也不能用于实现中的其他目的。
如果我是你，我不会相信博客文章中的代码，它是很久以前写的，从那时起我学到了很多东西： - ）。
Blob存储方法可能就是这样。
此致
艾伦