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

Question

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

我主要关注的是 MVC 前端(Web 角色)、Windows Azure 队列(异步消息解耦)、Worker Role 和黑化 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 个事务/秒限制？

正如我所说，目前我的问题更多是理论性的，我想构建并证明 future 的任何解决方案。

谢谢

Answer 1

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

1. 网络角色将一条包含作业 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 个队列后，您需要创建一个新的存储帐户才能获得更有保障的可扩展性。