前段時間研究了Window Azure ServiceBus Messaging消息隊列技術，搞了很多技術研究和代碼驗證，最近准備總結一下，分享給大家。
首先，Windows Azure提供了兩種類型的消息隊列機制：Azure Queues和ServiceBus Queues。
其中，Azure Queues，作為Azure Storage基礎設施的一部分，提供了一套簡單的基於Rest的Interface，面向不同的服務間提供可靠的、持久化的消息隊列。
ServiceBus Queues作為Azure Messaging基礎設施的一部分，支持隊列和發布訂閱模式，支持WebService和集成模式。
本系列主要介紹ServiceBus Queues。關於二者的選型比較，各位可以參考：
https://azure.microsoft.com/zh-cn/documentation/articles/service-bus-azure-and-service-bus-queues-compared-contrasted
Service Bus（服務總線）支持兩種不同的消息模式：relayed messaging and brokered messaging. 即：中繼消息模式和代理消息模式。
中繼消息模式Relayed messaging，最大的特點就是：收發消息要求服務端和客戶端同時在線，不支持異步模式。
消息處理過程：
當Client發送請求到ServiceBus，Azure的負載均衡器將請求路由到任意一個網關節點（Gateway Nodes）。如果請求是一個監聽類的請求，網關節點創建一個新的
中繼（Relay）。如果請求是一個連接到指定中繼（Relay）的請求，請求被轉向指定中繼所在的網關節點，這個網關節點發送一個交會的請求給監聽Client，要求監聽Client創建一個臨時的通道來接收消息。當中繼連接建立之后，
Client之間通過網關節點（Gateway Node）就可以交換消息了。
代理消息模式Borkered messaging：異步、解耦、消息發送者（Producer）和消費者（Consumer）不需要同時在線，消息存儲在Broker中（代理），等待消息消費者消費處理。其核心組件包含：隊列（Queue）、主題（Topic）、發布訂閱等。
消息處理過程：
當Client發送請求到ServiceBus，Azure的負載均衡器將請求路由到任意一個網關節點（Gateway Nodes）。如果這個請求中包含一個消息實體（隊列、主題、訂閱），網關節點（Gateway Node）首先在網關存儲（Gateway Store）中查找定位這個消息實體應該存儲到哪個消息存儲（Message Store）以及消息存儲對應的消息代理節點（Messaging Broker），然后將消息發送到指定的消息代理節點，消息代理節點處理請求、存儲消息並更新消息實體狀態（Delivered）。消息代理節點發送一個響應返回給請求所在網關節點，進而再返回給請求的Client。
代理消息模式Borkered messaging是一種最常見的通用的消息模式，業界的ActiveMQ、RabbitMQ等消息中間件都支持，也是我們接下來深入研究的重點。