BizTalk 2020 SB-Messaging适配AMQP及大消息传输问题求解决方案

问题背景 #

我们在混合架构部署中，以本地BizTalk 2020作为本地与Azure环境的衔接枢纽。公司其他团队已敲定采用Azure Service Bus（高级层，支持超256KB消息）作为异步消息方案，但BizTalk 2020自带的SB-Messaging适配器基于SBMP协议，消息大小仍被限制在1MB内（微软官方文档明确说明），且微软近期无计划为该适配器升级AMQP协议，CU4更新也未解决此问题。

我们原本倾向于Azure Blob Storage适配器结合事件驱动（通过Service Bus发送文件就绪通知）的方案，但无法说服内部团队变更决策。现需找到除自行开发AMQP兼容适配器外的可行变通方案，或确认是否必须自行开发。

可行变通方案 #

1. 消息分片与重组 #

• 在BizTalk发送端对超过1MB的消息进行分片，拆分出多个≤1MB的小消息，每个消息携带分片ID、总片数、序号等元数据。
• 在Azure接收端（或BizTalk接收端）编写重组逻辑，依据元数据将分片消息拼接为完整大消息。
• 关键细节：可借助Service Bus的**会话（Session）**功能保证分片顺序，同时添加重试机制处理分片丢失或重复的情况。

2. 配置WCF-Custom适配器对接AMQP协议 #

• 利用BizTalk自带的WCF-Custom适配器，通过配置对接Service Bus的AMQP端点，绕过SB-Messaging适配器的SBMP限制：
  1. 创建WCF-Custom发送端口，绑定类型选择Microsoft.ServiceBus.NetMessagingBinding；
  2. 配置Service Bus命名空间、共享访问密钥等参数，同时调整MaxReceivedMessageSize、MaxBufferSize等属性，匹配Service Bus高级层的大消息限制；
  3. 接收端同理配置WCF-Custom接收端口，实现基于AMQP的大消息传输。
• 优势：无需额外开发，直接复用现有WCF扩展能力，完全适配Service Bus高级层的消息大小上限。

3. 以Azure Function作为中转代理 #

• 在Azure侧部署Azure Function，作为BizTalk与Service Bus之间的中转层：
  • BizTalk侧：通过SB-Messaging适配器向Service Bus发送包含Blob存储地址的小消息（提前将大消息上传至Azure Blob Storage），或直接调用Azure Function的HTTP端点传递分片消息；
  • Azure Function侧：读取Blob中的大消息并发送至Service Bus，或重组分片后发送；反之，从Service Bus接收大消息后写入Blob，再通知BizTalk读取。
• 这种方式让BizTalk仅处理轻量通知消息，彻底规避SB-Messaging的大小限制，同时保留Service Bus作为核心消息枢纽的架构。

4. 开发轻量BizTalk管道组件 #

• 开发发送管道组件：自动将大消息上传至Azure Blob Storage，仅向Service Bus发送包含Blob地址、消息ID的小通知；
• 开发接收管道组件：从Service Bus获取小通知后，自动从Blob下载完整大消息，交付给BizTalk流程处理。
• 优势：相比自定义适配器，管道组件开发复杂度低，可直接集成到现有BizTalk流程中，无需替换SB-Messaging适配器的使用链路。

是否必须自行开发适配器？ #

如果上述方案均无法满足业务需求（例如极端性能要求、不允许任何中转环节），则需要自行开发支持AMQP协议的自定义适配器。但从成本、复杂度和落地效率来看，优先尝试WCF-Custom适配器配置或管道组件扩展的方案，通常能快速解决大消息传输问题。

内容的提问来源于stack exchange，提问作者Alexzander