北京
支持AMQP协议说起来简单，实际差别巨大。一个能在5671端口接收TCP连接、完成OPEN/BEGIN帧交换的消息代理，技术上就算"会说AMQP"。但另一个能每秒处理数十万条消息、完整支持PeekLock语义、死信路由和会话状态的系统，同样也叫AMQP兼容。当模拟器宣称支持AMQP时，真正的问题是：这种兼容性到底能走多远？够不够深，能不能支撑真正的消息处理框架？
这篇文章讲的就是实践中这意味着什么，以及为什么我们知道Topaz通过了测试——因为我们先搞砸过，然后才修好。
Service Bus兼容性分两层。大多数讨论集中在控制平面：能不能通过ARM或Azure CLI创建命名空间、队列和主题？这一层确实重要——它让az servicebus queue create和azurerm_servicebus_queue能在本地运行——但对消息处理代码来说，这不是关键层。
关键层是AMQP数据平面，它再细分为两个子层：
SDK兼容性——Azure Service Bus SDK能否连接、认证、发送和接收？这个门槛相对低。SDK通过CBS（基于声明的安全）连接，打开发送链接和接收链接，用基本 settled transfer 完成大部分操作。一个勉强够用的模拟器用几百行AMQP链接处理代码就能搞定。
框架兼容性——MassTransit、NServiceBus或Rebus这类消息处理框架能不能真正跑起来？框架会驱动更完整的AMQP规范子集。它们会在接收链接之外打开管理链接，用$management请求-响应链接执行SDK未直接暴露的操作，依赖unsettled transfer和显式客户端结算，还指望正确的credit补充来维持吞吐量。这些行为不是可选功能，是正常运行的必经之路。
这两个门槛之间的差距，比看上去大得多。
MassTransit的Azure Service Bus传输层（MassTransit.Azure.ServiceBus.Core）以Azure SDK为底层客户端，但叠加了一层消息约定。当ReceiveEndpoint启动时，它会：
打开AMQP会话和指向队列的接收链接；
立即打开第二个链接指向/$management——这是一个请求-响应链接，用于com.microsoft:update-disposition和com.microsoft:renew-lock等管理操作；
在接收链接上发送AMQP FLOW帧，带上初始链接credit，表明准备接收多少消息；
处理每条消息时，发送DISPOSITION帧来完成或放弃消息，然后指望代理更新会话的投递状态并补充credit。
第二步就是大多数半吊子AMQP实现栽跟头的地方。Azure Service Bus SDK并不直接暴露这些管理操作，MassTransit却依赖它们来实现锁续期、消息处置等核心功能。模拟器如果只做了SDK兼容性，框架一跑就露馅。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
