消息、有效负载和序列化

Azure 服务总线负责处理消息。 消息中承载着有效负载和元数据。 元数据以键值对形式存在，用于描述有效负载，并向服务总线和应用程序提供处理指令。 有时，光有元数据就足以传递发送程序想要与接收程序沟通的信息，此时有效负载一直为空。

适用于 .NET 和 Java 的正式版服务总线客户端对象模型反映了抽象的服务总线消息结构，此结构与服务总线支持的线路协议相互映射。

服务总线消息包括服务总线从未在服务端以任何形式处理过的二进制有效负载部分，以及两组属性。 中转站属性由系统预定义。 这些预定义属性要么控制中转站内的消息级功能，要么映射到常见的标准化元数据项。 用户属性是一组可由应用程序定义和设置的键值对。

下表列出了预定义的中转站属性。 这些属性名可与所有正式版客户端 API 配合使用，同时还位于 HTTP 协议映射的 BrokerProperties JSON 对象中。

在高级消息队列协议 (AMQP) 协议级别中使用的等效名称会在括号中列出。 虽然以下名称使用帕斯卡拼写法，但 JavaScript 和 Python 客户端将分别使用驼峰式拼写法和蛇形拼写法。

借助抽象消息模型，可以通过 HTTP 将消息发布到队列，并能通过 AMQP 检索消息。 无论属于上述哪种情况，在相应协议的上下文中，消息看上去都很正常。 中转站属性会根据需要进行转换，用户属性会映射到相应协议消息模型上最合适的位置。 在 HTTP 中，用户属性直接与 HTTP 头相互映射；在 AMQP 中，用户属性与 application-properties 映射相互映射。

消息路由和关联

上面介绍的部分中转站属性（特别是 To、ReplyTo、ReplyToSessionId、MessageId、CorrelationId 和 SessionId）有助于应用程序将消息路由至特定目标。 为了说明这个功能，假设有以下几种模式：

• 简单请求/答复：发布者向队列发送消息，并希望收到消息使用者的答复。 为了接收答复，发布者拥有答复预期传递到的队列。 此队列的地址将通过出站消息的 ReplyTo 属性表示。 如果使用者响应，它会将已处理消息的 MessageId 复制到答复消息的 CorrelationId 属性，并将消息传递到 ReplyTo 属性指明的目标。 一个消息可以有多个答复，具体视应用程序上下文而定。
• 多播请求/回复：作为上一个模式的一种变体，发布者将消息发送到主题中，多个订阅者有资格使用该消息。 每个订阅者都可能会以先前描述的方式响应。 此模式用于发现或滚动呼叫方案，回应者通常通过用户属性或在有效负载内进行自我识别。 如果 ReplyTo 指向主题，可以向受众分发这样的一组发现响应。
• 多路复用：借助此会话功能，可以通过一个队列或订阅对相关消息流进行多路复用，以便相关消息的所有会话/组（与 SessionId 值匹配）可以路由到特定接收程序，同时接收程序能够使会话保持锁定状态。 若要详细了解会话，请单击此处。
• 多路复用请求/答复：借助此会话功能，可以启用多路复用答复，让多个发布者能够共享答复队列。 通过设置 ReplyToSessionId，发布者可以指示使用者将此值复制到答复消息的 SessionId 属性。 发布队列或主题并不一定是会话感知的。 在消息发送的同时，发布者可以专门等待具有给定 SessionId 的会话，以便有条件地接受会话接收程序，在队列上实现具体化。

可以使用自动转发链和主题订阅规则，实现服务总线命名空间内的路由。 跨命名空间路由可以使用 Azure LogicApps 实现。 如上面的列表所示，已保留 To 属性以供将来使用，最后可能会由已启用特别功能的中转站解析。 要实现路由的应用程序在这样做时，应以用户属性（而不是 To 属性）为依据；不过，现在这样做也不会导致兼容性问题。

有效负载序列化

在服务总线内传输或存储时，有效负载始终为不透明的二进制块。 使用 ContentType 属性，应用程序可以描述有效负载，对属性值采用符合 IETF RFC2045 MIME 内容类型描述的建议格式；例如，application/json;charset=utf-8。

与 Java 或 .NET Standard 变体不同，服务总线 API 的 .NET Framework 版本支持将任意 .NET 对象传递到构造函数，创建 BrokeredMessage 实例。

如果使用的是旧版 SBMP 协议，这些对象使用默认二进制序列化程序，或使用外部提供的序列化程序进行序列化。 对象将会序列化为 AMQP 对象。 接收方可以使用 GetBody\<T>() 方法检索这些对象，并提供所需的类型。 使用 AMQP，对象都被序列化为 ArrayList 和 IDictionary<string,object> 对象的 AMQP 图，任何 AMQP 客户端都可以将其解码。

尽管这种隐藏序列化的神奇操作十分方便，但应用程序应明确控制对象序列化，并先将对象图转为流，再将它们添加到消息中（在接收程序端，操作执行顺序相反）。 这样生产的是交互结果。 尽管 AMQP 具有功能强大的二进制编码模型，但它与 AMQP 消息生态系统相绑定，而 HTTP 客户端无法解码此类有效负载。

.NET Standard 和 Java API 变体仅接受字节数组。也就是说，应用程序必须控制对象序列化。

在处理消息有效负载中的对象反序列化时，开发人员应考虑到消息可能来自使用不同序列化方法的多个来源。 在演变单个应用程序时，旧版本可能继续与较新版本一起运行，也可能发生这种情况。 在这种情况下，如果第一次反序列化尝试失败，建议尝试其他反序列化方法。 支持此操作的一个库是 NServiceBus。 如果所有反序列化方法都失败，则建议将消息设为死信。

后续步骤

若要了解有关服务总线消息传送的详细信息，请参阅以下主题：

• 服务总线队列、主题和订阅
• 服务总线队列入门
• 如何使用服务总线主题和订阅