探索服务总线消息有效负载和序列化
消息中承载着有效负载和元数据。 元数据以键值对属性的形式存在，用于描述有效负载，并向服务总线和应用程序提供处理指令。 有时，光有元数据就足以传递发送程序想要与接收程序沟通的信息，此时有效负载一直为空。
适用于 .NET 和 Java 的正式版服务总线客户端的对象模型与服务总线支持的线路协议相互映射。
服务总线消息包括服务总线从未在服务端以任何形式处理过的二进制有效负载部分，以及两组属性。 中转站属性是系统定义的属性。 这些预定义属性要么控制中转站内的消息级功能，要么映射到常见的标准化元数据项。 用户属性是一组由应用程序定义和设置的键值对。
消息路由和关联
部分中转站属性（特别是 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 协议将对象序列化为 AMQP 对象。 接收方可以使用 GetBody<T>() 方法检索这些对象，并提供所需的类型。 使用 AMQP，对象都被序列化为 ArrayList 和 IDictionary<string,object> 对象的 AMQP 图，任何 AMQP 客户端都可以将其解码。
尽管这种隐藏序列化的神奇操作十分方便，但如果应用程序应明确控制对象序列化，并先将对象图转为流，再将它们包含到消息中，则它们应该在接收程序端进行相反的操作。 尽管 AMQP 有功能强大的二进制编码模型，但它与 AMQP 消息生态系统关联，导致 HTTP 客户端无法解码此类有效负载。