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

Question

我正在研究Windows Azure上用于高规模Web性能应用程序(此时是理论上的)的架构,并且想要了解"Windows Azure队列(不是SB)"以及如何最好地扩展/创建它们.

我基本上看的是MVC前端(Web角色),Windows Azure队列(异步消息解耦),工作者角色和黑化的SQL DB.

我的理解是,我们在Web角色上收到一条消息,然后将其传递给队列,工作者角色将轮询队列{do work ...例如SQL DB CRUD操作}并发回完成消息.

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

我看过很多帖子说你应该在你的应用程序代码之外创建你的队列,这是有意义的,但你如何使用当前的队列限制扩展它"单个Windows Azure队列的可伸缩性目标"受限于"500个事务/秒"？

MSDN有一些关于通过队列进行扩展的很好的资源.

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

•进程(线程)扩展是指通过根据当前工作负载上下调整线程数来维持给定角色实例中处理线程的足够容量.

总之,我正在寻找以下问题的答案:

1. 队列创建最佳实践？
2. Web角色(MVC App)如何跟踪消息,即在消息传递完成后轮询"通知"队列,处理Web角色中的消息关联以发送回客户端的最佳方式是什么(网络消费者)？
3. 扩展选项是否是最佳方法之上,还是我应该动态地查看队列的动态扩展(如果是这样的话？我认为SB队列在这种情况下可能更好)创建新队列以规避500个事务/秒限制？

如上所述,我的问题在这个时刻更具理论性,我希望建筑师和未来证明任何解决方案.

谢谢

Answer 1

对于如何跟踪响应的问题,我通常会执行以下操作:

1. Web角色将消息写入包含作业ID的队列.
2. Worker角色完成工作并将结果写入具有分区键的表.
3. Web角色正在轮询该表的那一行.一旦它存在,答案就会回来.

然后,如果这是一个用户交互式事物,用户实际上在等待打开的HTTP连接以获得结果,那么最好只使用同步通信并跳过队列.

如果我是你,我至少要看看使用像0MQ(ZeroMQ,或其新的fork Crossroads I/O)这样的东西,它可以在原始套接字上提供很好的抽象,这对于这类东西很有用.例如,Web服务器通过PUSH套接字发送消息,工作者角色通过PULL套接字接收,工作者角色通过PUB套接字发布响应,Web角色通过SUB套接字接收响应.PUSH/PULL执行负载平衡,PUB/SUB处理将消息返回到等待的Web角色.仅供参考,这正是Mongrel2使用的消息传递架构和技术.

就每秒超过500次操作而言,您可以随机创建多个队列并向其发送消息.(每个工作人员通常会对所有工作人员进行轮询.)但请记住,单个存储帐户的每秒操作限制为5,000次,因此在创建了10个队列之后,您需要创建一个新的存储帐户才能获得更可靠的可扩展性.