我正在研究Windows Azure上用于高规模Web性能应用程序（此时是理论上的）的架构，并且想要了解“Windows Azure队列（不是SB）”以及如何最好地扩展/创建它们 .
我基本上看的是MVC前端（Web角色），Windows Azure队列（异步消息解耦），工作者角色和黑化的SQL DB .
我的理解是，我们在Web角色上收到一条消息，然后将其传递给Queue，Worker Role将轮询队列{do work ...例如SQL DB CRUD操作}并发回完成消息 .
处理Windows Azure队列创建以进行扩展以及通过Web角色和工作者角色来回传递消息的最佳方法是什么？是否最好有一个队列来发送工作，例如订单，然后是另一个通知队列，例如状态消息
我看过很多帖子说你应该在你的应用程序代码之外创建你的队列，这是有意义的，但你如何使用当前的队列限制扩展它“单个Windows Azure队列的可伸缩性目标”受限于“500个事务/秒”？
MSDN有一些关于通过队列进行扩展的很好的资源 .
•角色实例扩展是指添加和删除其他Web或辅助角色实例以处理时间点工作负载 . 这通常包括更改服务配置中的实例计数 . 增加实例计数将导致Windows Azure运行时启动新实例，而减少实例计数将导致其关闭正在运行的实例 .
•进程（线程）扩展是指通过根据当前工作负载上下调整线程数来维持给定角色实例中处理线程的足够容量 .
总之，我正在寻找以下问题的答案：
-
队列创建最佳实践？
-
Web角色（MVC App）如何跟踪消息，即在消息传递完成后轮询“通知”队列，处理Web角色中的消息关联以发送回客户端的最佳方法是什么（网络消费者）？
-
扩展选项是否是最好的方法，还是我应该动态地查看队列的动态扩展（如果是这样的话？我认为SB队列在这种情况下可能更好）创建新的队列以规避500个事务/秒局限性？
如上所述，我的问题在这个时刻更具理论性，我希望建筑师和未来证明任何解决方案 .
谢谢
2 回答
对于如何跟踪响应的问题，我通常会执行以下操作：
Web角色将消息写入包含作业ID的队列 .
Worker角色完成工作并将结果写入包含分区键的表 .
Web角色正在轮询该表的那一行 . 一旦它存在，答案就会回来 .
然后，如果这是一个用户交互式事物，用户实际上在等待打开的HTTP连接以获得结果，那么最好只使用同步通信并跳过队列 .
如果我是你，我至少要看看使用像0MQ（ZeroMQ，或其新的fork Crossroads I / O）这样的东西，它可以在原始套接字上提供很好的抽象，这对于这类东西很有用 . 例如，Web服务器通过PUSH套接字发送消息，工作者角色通过PULL套接字接收，工作者角色通过PUB套接字发布响应，Web角色通过SUB套接字接收响应 . PUSH / PULL执行负载 balancer ，PUB / SUB处理将消息返回到等待的Web角色 . 仅供参考，这正是Mongrel2使用的消息传递架构和技术 .
就每秒超过500次操作而言，您可以随机创建多个队列并向其发送消息 . （每个工作人员通常会对所有工作人员进行轮询 . ）但请记住，单个存储帐户的每秒操作限制为5,000次，因此在创建了10个队列之后，您需要创建一个新的存储帐户才能获得更可靠的可扩展性 .
我建议你考虑使用这种模式-IF-你想要一个快速同步（和可扩展）的解决方案 .
使用该模式的原因是队列允许您独立地扩展Web和工作者角色 . 它确实意味着相当多的队列，但它意味着您可以，例如，如果您需要，可以有2个Web工作者角色，并从6到8个工作者角色扩展 .
我想这可以比轮询SQL更快，它比不使用队列更有弹性 .
更多细节在这里：https://msdn.microsoft.com/en-us/library/dn589781.aspx