Window Azure ServiceBus Messaging消息队列技术系列1-基本概念和架构

前段时间研究了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等消息中间件都支持，也是我们接下来深入研究的重点。