我们需要在 ServiceBus 主题上发送大消息。当前大小约为 10MB。我们最初的做法是在 BlobStorage 中保存一个临时文件，然后发送一条引用 Blob 的消息。该文件被压缩以节省上传时间。它工作正常。
今天读到这篇文章:http://geekswithblogs.net/asmith/archive/2012/04/10/149275.aspx
建议将消息分成更小的块，然后在接收端再次聚合它们。
我可以承认这是一种“更清洁的方法”，避免了到 BlobStore 的往返。另一方面，我更喜欢保持简单。拆分机制引入了增加的复杂性。我的意思是他们从一开始就没有将其包含在 ServiceBus 中肯定是有原因的......
有没有人在现实生活中尝试过拆分方法？
有更好的模式吗？
最佳答案
前阵子写过那篇博文，打算实现
使用服务总线的拆分器和聚合器模式。我在寻找更好的选择时偶然发现了这个问题。
我同意最简单的方法可能是使用 Blob 存储来存储消息正文，并在消息中发送对该正文的引用。这是我们现在正在为客户项目考虑的场景。
我记得几年前，发布了一些示例代码，可以从客户端应用程序中抽象出服务总线和存储队列，并在需要时处理对大型消息体的 Blob 存储的使用。 (我认为是 Microsoft 的 CAT 团队，但我不确定)。
我无法通过 Google 快速搜索找到该示例，但由于它可能已经有几年的历史了，所以它会过时，因为从那时起 Service Bus 客户端库得到了很大改进。
当消息大小太大时，我使用了消息拆分，但由于这是批量遥测数据，因此不需要聚合消息，我可以在接收端处理一些较小的批次，而不是一个大的批次信息。
拆分器-聚合器方法的另一个缺点是它需要 session ，因此需要启用 session 的队列或订阅。这意味着所有消息都需要 session ，甚至更小的消息，并且 session ID 不能用于实现中的其他目的。
如果我是你，我不会相信博文上的代码，它是很久以前写的，从那时起我学到了很多:-)。
Blob 存储方法可能是要走的路。
问候，
艾伦
关于size - 在 ServiceBus 上发送大消息的最佳实践，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/27325171/