6

我正处于设计基于 Azure 的应用程序的早期阶段。考虑到我可能预期的需求的可变性,Azure 吸引我的一件事是可伸缩性。因此,我试图保持松散耦合,以便在需要时添加实例。

我看到的为 Azure 构建应用程序的建议包括将 Web 角色逻辑保持在最低限度,并在辅助角色中完成处理,使用队列进行通信以及某种后端存储,如 SQL Azure 或 Azure Tables。这对我来说似乎是个好主意,因为我可以毫无问题地扩展应用程序的一个或两个部分。但是我很好奇是否有任何最佳实践(或者如果有人有任何经验),什么时候最好让网络角色直接与数据存储对话,而不是通过队列发送数据?

我正在考虑我有一个简单的从网络角色插入的情况 - 虽然我可以将它设置为一条消息,将它发送到队列中,并让一个工作角色拿起它并进行插入,它似乎有很多双重处理。但是,我也很欣赏,从长远来看,这可能会更好,以防万一 Web 角色不堪重负或插入需要更复杂的逻辑。

我意识到这可能是一个答案是“这完全取决于情况,检查你的性能指标”的情况 - 但如果有人有任何想法,我会非常感激!

4

3 回答 3

5

这是我的比喻,随心所欲

想象一下,您正在进入一家夜总会,该夜总会靠近一个危险的区域,但是一旦您进入就可以了。

管理层在门口雇用了一些大块头的保镖来整理即兴表演。如果你是个白痴,你就不会进去。在这里尽可能多地扩展这个比喻。

如果你没问题,他们会让你进门,然后你加入,是的,排队在票房付钱进入真正的俱乐部。

根据足球是否开启或其他原因,您可能需要在门上放置更多保镖,但这可以独立于票房工作人员。忙碌的夜晚,您可能会打开另一个窗口以更快地取钱,但您可能不会让保镖处理现金。他们的手还有其他事情要做。

所以:

  • 保镖 - 网络角色。处理传入流量,拒绝无效请求并将有效请求添加到:
  • 队列——队列!
  • 票房 - 工人角色,执行与网络角色不同的角色

所以,你的网络角色没有理由不能做票房角色,但从长远来看,最好不要

这是我的比喻

托比

于 2010-03-16T11:52:46.607 回答
3

我会说像插入这样的东西不需要工人角色。无论如何,您都会在队列中插入,因此您不会在 web 角色中保存任何内容。最好的办法是将您的插入(和所有数据访问)隔离到您的 Web 角色中的一个单独的类(或多个类)中。这将允许您将 Web 角色中的其余代码与您正在使用的特定数据存储系统分离。这使得以后更改数据存储变得更加容易。如果您的插入最终需要更多处理,您可以在需要时添加队列和工作者角色,但我仍然会说您希望直接将插入到表存储中,然后将计算或其他业务逻辑委托给工人角色。

我看到使用队列与工作者角色进行通信的方式变得最有效是当需要对数据进行计算或其他处理时。我使用最多的实际上是 Azure SDK 中的示例之一,它展示了如何制作缩略图。我的 Web 角色将上传的图像插入 Azure Blob 存储,并将相关描述和其他字段插入 Azure 表存储。它还在队列中放置一条消息,让辅助角色知道有一个需要生成缩略图的新图像。我实际上为每个图像生成了几个不同大小的图像,用于网站的不同部分。worker 角色只生成这些缩略图,不需要将任何类型的通知发送回 web 角色。

如果您想完全跳过队列,同样的过程可以只使用对 blob 存储的查询来查找哪些图像仍需要处理。我还没有决定我是更喜欢使用队列还是只是轮询数据来查找需要辅助角色处理的记录。我认为队列效率更高,但它也增加了额外的复杂性和额外的潜在故障点。

编辑以回应评论:当我发布这个答案时,我说如果缩略图不可用,只需在 UI 中使用全分辨率图像。现在我正在一个网站上工作,该网站只使用默认的缩略图图像,上面写着“正在处理”,直到生成的缩略图可用。选择权在您手中,实际上取决于您的应用程序 UI 的要求。

您可以做的一件事是使用 SignalR 或一些 AJAX 在有新缩略图可用时通知用户浏览器,而无需等待新页面加载。

在工作线程上进行图像处理时查看占位符缩略图比在生成缩略图时等待页面加载要好得多。

于 2010-03-14T01:32:35.820 回答
1

使用分布式队列(Azure 或 Amazon 或其他)非常微妙。我已经发布了一篇博客文章,涵盖了 Azure Queues 的常见细节。底线:我建议从业务逻辑(队列的内容和处理)中仔细抽象出您的基础架构逻辑(支持队列)。

于 2010-03-17T11:05:48.960 回答