Azure 队列创建最佳实践和规模

我正在研究 Windows Azure 上的大规模 Web 性能应用程序的架构（目前是理论上的），并想请教一下您有关“Windows Azure 队列（不是 SB）”以及如何最好地扩展/创建它们的知识。

我基本上关注的是 MVC 前端（Web 角色）、Windows Azure 队列（异步消息解耦）、Worker 角色和黑化 SQL DB。

我的理解是，我们在 Web Role 上接收消息，然后将其传递到队列，Worker Role 将轮询队列{执行工作...例如 SQL DB CRUD 操作}并发回完成消息。

处理 Windows Azure 队列创建以实现扩展以及通过 Web 角色和辅助角色来回传递消息的最佳方法是什么？最好有一个队列来发送工作，例如订单，然后是另一个通知队列，例如状态消息

我看到很多帖子说您应该在应用程序代码之外创建队列，这是有道理的，但是如何使用当前的队列限制来扩展它“单个 Windows Azure 队列的可扩展性目标被“限制”在 500 个事务/秒”？

MSDN 有一些关于通过队列进行扩展的优秀资源。

• 角色实例扩展是指添加和删除额外的Web 或辅助角色实例以处理时间点工作负载。这通常包括更改服务配置中的实例计数。增加实例计数将导致 Windows Azure 运行时启动新实例，而减少实例计数将导致其关闭正在运行的实例。

• 进程（线程）扩展是指通过根据当前工作负载上下调整线程数量，在给定角色实例中保持足够的处理线程容量。

简而言之，我正在寻找以下问题的答案：

1. 队列创建最佳实践？
2. Web 角色（MVC 应用程序）如何跟踪消息，即在传递消息后是否轮询“通知”队列，处理 Web 角色中的消息相关性以发送回客户端的最佳方法是什么（网络消费者）？
3. 上面的扩展选项是最佳方法还是我应该考虑动态扩展队列（如果是这样怎么办？我认为 SB 队列在这种情况下可能会更好）创建新队列以规避 500 个事务/秒的限制？

如前所述，我的问题目前更具理论性，我想构建并证明未来的任何解决方案。

Thanks

对于如何跟踪回复的问题，我通常会执行以下操作：

1. Web 角色将一条包含作业 ID 的消息写入队列。
2. 辅助角色完成工作并将结果写入带有分区键的表中。
3. Web 角色正在轮询表的该行。一旦存在，答案就会回来。

话又说回来，如果这是一个用户交互的事情，用户实际上正在等待打开的 HTTP 连接来获取结果，那么您最好只使用同步通信并跳过队列。

如果我是你，我至少会考虑使用 0MQ（ZeroMQ，或其新分支 Crossroads I/O）之类的东西，它为你提供了在原始套接字之上的很好的抽象，这对此类事情很有用。例如，Web 服务器通过 PUSH 套接字发送消息，辅助角色通过 PULL 套接字接收消息，辅助角色通过 PUB 套接字发布响应，Web 角色通过 SUB 套接字接收响应。 PUSH/PULL 执行负载平衡，PUB/SUB 负责将消息返回给等待的 Web 角色。仅供参考，这正是 Mongrel2 使用的消息传递架构和技术。

为了达到每秒 500 次以上的操作，您可以创建多个队列并向它们随机喷射消息。 （每个工作线程通常会轮询所有队列。）但请记住，单个存储帐户的限制为每秒 5,000 次操作，因此在创建 10 个队列后，您需要创建一个新的存储帐户才能获得可扩展性更有保证。