6

我正在研究 Windows Azure 上的大规模 Web 性能应用程序（目前是理论上的）架构，并想就“Windows Azure 队列（不是 SB）”以及如何最好地扩展/创建它们来开动脑筋。

我基本上在看 MVC 前端（Web 角色）、Windows Azure 队列（异步消息解耦）、工作角色和黑化的 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 个事务/秒的限制?

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

谢谢

4

2 回答 2

8

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

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

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

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

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

于 2012-08-20T04:05:22.977 回答
3

我建议您考虑使用这种模式 - 如果您想要一个快速同步（和可扩展）的解决方案。

在此处输入图像描述

使用该模式的原因是队列允许您独立扩展 Web 和工作角色。这确实意味着相当多的队列，但这意味着您可以，例如，拥有 2 个 Web 工作人员角色，如果需要，可以从 6 个工作人员角色扩展到 8 个工作人员角色。

我想这可能比轮询 SQL 更快，并且比不使用队列更有弹性。

更多详细信息在这里：https ://msdn.microsoft.com/en-us/library/dn589781.aspx

于 2015-09-03T04:57:01.843 回答