Windows Azure Service Bus Messaging
Service Bus Messaging 有两种模式（Model），即Brokered Messaging和Relayed Messaging。以下图说明关系：
Brokered Messaging是一种中间模式，在消息交换过程中充当中间人的角色。
发送者将消息发给Broker，接受者从Broker那接受消息；
发送者和接受者两者不需要碰面，也不需要同时在线；
Broker将消息保存在队列中，具有持久功能（Durability），在消息到期前保存直到被接收者取出，
这也说明Broker有一定的伸展功能（Scalability）；
Broker还有机制确保接收者能够接收消息最少一次（At-Least-Once）和最多一次（At-Most-Once）的可用性（Availability）。
而Relayed Messaging是一种中继模式，在消息交换过程中充当中继或者说连接的作用，打个比方说是为男女牵线的红娘。
这种模式下接收者必须在线侦听（Listen），发送者通过Relay找到侦听者，连接成功后发送消息的。
下面详细分享下Queue、Topic、Relay的工作原理。
Queue
前面Service Bus Namespace已经讲过namespace 的作用。 要想通过Service Bus 发布Service，需要在Service Bus的Namespace 节点上注册
（Register）一个端点（Public EndPoint），这样可以通过NamespaceManager来管理Sender或者Receiver的客户端（Client）。
从上图可以清晰的看到，Service Bus 在中间，Brokered Messaging模型的Queue模式，Queue是通过Service Bus Namespace 来管理的，
左边是Queue的客户端（QueueClient），也是消息的发送者（Sender），发送者通过QueueClient（通过NamespaceManager创建的）连接
Service Bus Queue，然后向Queue发送消息。
右边也是Queue的客户端（QueueClient），消息的接收者（Receiver），通过QueueClient连接Service Bus Queue，从里面接收消息。
接收者接收消息的方式有两种，分别是ReceiveAndDelete和PeekAndLock。
ReceiveAndDelete是从Queue的队头获取消息并将消息删除掉，这样的好处就是读取快，缺点是如果消息处理失败或者丢失，就不能找回来了。
而PeekAndLock是从Queue的队头获取消息，不删除掉，但是将其加锁，使其他的Receiver不能读取这条消息，待处理完消息，再将其解锁删除。
这样能保证消息能够接收At-Least-Once，但是如果Receiver处理消息时间比较长，被Lock的消息因为加锁时间到期会自动解锁，使得其他的接收
者又接收此消息，照成重复处理的情况。为保证Queue的消息被At-Most-Once接收，消息有MessageId和SessionId来为保证，以后有机会可详谈。
如果要求不同的消息被不同的Receiver来接收处理，怎么办呢，显然Queue是做不到的，Topic能。
Topic
首先也可以看张图:
从图上看Topic和Queue比较相似，唯一不同的中间不部分，Topic下面分成不同的子队列或者说订阅（Subscription），
也可以用Pub/Sub模式来解释，Sender作为发布者发布消息，Topic接收消息然后按照不同飞Filter分发消息到不同的Subscription，
接收者订阅不同的Subscription接收消息。消息的接收方式和队列是一样的。
Message
在Queue和Topic模式下传递的消息格式是一样的，都是Message，它的结构图如下：
他包含两部分，Properties和Body。
Properties包含键值对（Key，Value），所有的键值的大小加起来不能超过64K，前面说的MessageId，SessionId都保存在这里；
Body保存的是二进制值，一般是序列化的数据，比如序列化一个对象等，Body也可以为空。整个消息Message的大小不能超过256K。
Relay
上面分享的是Brokered Messaging，下面说一下Relayed Messaging。
Relay刚才说过了，就是连接Sender和Receiver的中继站，不能像队列一样保存数据，只起连接作用，使得Sender和Receiver能够握手通信。
Relay有几种连接方式：
1、中继单向点播和多播（Relayed One-Way Unicast and Multicast）
2、中继双向通信（Relayed Rendezvous）
3、中继直连通信（Relayed Direct Connect）
这几种方式的共性都是Receiver首先得向Service Bus注册一个Public Endpoint并处于侦听状态，也就是说Receiver必须首先向Service Bus注册的Public Endpoint发出（outbound）一个双向套接字连接（Bi-directional Socket），并处于侦听状态（Listen）。
然后Sender通过这个Public Endpoint连接到Service Bus，与侦听者（Sender）通信。
One-Way
以单向单点为例：
蓝颜色的区域为Service Bus, 绿颜色区域为Receiver, 黄颜色的的区域为Sender。
从图中看出从连接到消息通信有4步：
1）Receiver用Namespace注册Public Endpoint，发出双向连接侦听；
2）Sender通过Namespace发出单向连接到Service Bus，Service Bus进过内部路由（Route）找到Sender的侦听节点，建立连接；
3）Sender通过建立的通道发送Message；
4）Receiver通过建立的连接通道接收Message。
Event
单向多播模式，在上面One-Way的基础上，多增加Receiver即可，也就是其他的Receiver向同一个namespace注册，并侦听，对消息发送者来说一样的，只是绑定Endpoint的方式由NetOneWayRelayBinding改成NetEventRelayBinding。
如图：
One-Way和Event方式发送的消息，有大小限制，不能大于60K，而且只能单向通信。
Rendezvous
约会模式，即双向通信模式。
抛开Receiver注册Endpoint,侦听步骤。
1）Sender向Service Bus 发出双向Socket连接
2）Service Bus通过向Sender侦听着发出Ctrl消息（要与其建立双向通信通知）
3）Receiver接到Ctrl通知
4）Receiver发出约会模式绑定，与Sender建立约会绑定。然后就Sender和Receiver两者角色无差异的发送和接收消息。
Hybrid Connect
也可以叫直连。如果约会模式下需要交换大量及时的消息，Service Bus会感到吃力，因为所有消息都要进过他之手，他会很忙的，而且“及时”的传递消息具有挑战（消息路由过程不可免）。
如果Sender和Receiver能够不通过Service Bus交换消息就好了。如图：
在约会模式的基础上，Sender和Receiver同时发出NAT 探索（Probing），探测对方的可以
穿透防火墙的端口。如果成功即可升级成直连了，这样消息的传递就不需要Service Bus了。
关于如何穿透防火强，这里有篇文章