我们需要在ServiceBus主题上发送大量消息。目前的大小约为10MB。我们最初的做法是将一个临时文件保存在BlobStorage中，然后发送一条消息来引用blob。该文件被压缩以节省上传时间。它工作正常。在ServiceBus上发送大量消息的最佳做法
今天我读到这篇文章：http://geekswithblogs.net/asmith/archive/2012/04/10/149275.aspx 建议有将信息拆分成小块并在接收端聚合它们。
我可以承认这是一种“更简洁的方法”，避免了往返BlobStore。另一方面，我宁愿保持简单。分割机制增加了复杂性。我的意思是，一定有一个原因，为什么他们从一开始就没有将它包含在ServiceBus中......
有没有人在现实生活中尝试过分裂的方法？
有更好的模式吗？
前一段时间我写了这篇博客文章，目的是使用服务总线实现 分离器和聚合器模式。在寻找更好的选择时，我偶然发现了这个问题。
我同意最简单的方法可能是使用Blob存储来存储消息正文，并发送消息中的引用。这是我们现在正在为客户项目考虑的情景。
我记得几年前，发布了一些示例代码，可以从客户端应用程序中抽象出Service Bus和Storage Queues，并在需要时处理大型邮件正文的Blob存储的使用。 （我认为这是微软的CAT团队，但我不确定）。
我找不到带有快速谷歌搜索的示例，但因为它可能已经过了两三年了，它将会过时，因为自那以后服务总线客户端库已经得到了很多改进。
我在消息大小过大的情况下使用了消息拆分，但由于这是针对批量遥测数据，因此无需汇总消息，并且可以在接收端处理一些较小的批次而不是一个大消息。
分离器 - 聚合器方法的另一个缺点是它需要会话，因此会话启用队列或订阅。这意味着所有的消息都需要会话，甚至更小的会话，并且Session ID也不能用于实现中的其他目的。
如果我是你，我不会相信博客文章中的代码，它是很久以前写的，从那以后我学到了很多东西:-)。
Blob存储方法可能是要走的路。
问候，
艾伦
PS。如果有人发现Service Bus和Blob Storage的代码示例，请发布链接。 – 2015-03-09 11:27:21
谢谢Alan的反馈。我已经决定坚持BlobStorage方法。它是稳定的，简单的，可以像你说的那样容易被封装。顺便说一下，我很欣赏你在斯德哥尔摩的Azure TechX上的谈话！ – 2015-03-10 08:29:37
嗨。您可能会发现此链接有趣“使用Azure队列处理大型邮件的最佳做法”https://msdn.microsoft。COM/EN-US /库/蔚蓝/ hh690942.aspx。它基于存储队列，但应该是使用服务总线队列进行类似植入的良好起点。 – 2015-03-11 10:04:38