（使用Azure队列）的最佳实践

Question

我正处于设计基于Azure的应用程序的早期阶段。考虑到我可能期望的需求变化，吸引我进入Azure的一个原因是可扩展性。因此，我试图保持松散耦合，以便在需要时添加实例。

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

我正在考虑从web角色进行简单插入操作的情况 - 我可以将其设置为消息，将其发送到队列中，并让工作者角色接收并执行插入，似乎很多双重处理。但是我也很感激，从长远来看这可能会更好，万一web角色不堪重负，或者插入需要更复杂的逻辑。

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

Answer 1

这是我的比喻，用它做你想做的事

想象一下，你正在进入一个夜总会，这个夜总会与一个狡猾的地区接壤，但是一旦进入你的地方就没问题。

管理层在门上雇用了一些肉腥的保镖来解决riff raff。如果你是一个白痴，你就没有进入。尽可能多地扩展这个比喻。

如果你没事，那么他们会让你进门，你加入，是的，The Queue在票房付钱进入实际的俱乐部。

根据足球的不同，你可能需要更多的保镖，但这可以独立于票房工作人员。繁忙的夜晚，你可能会打开另一个窗口来更快地获得资金，但你可能不会做的事情让保镖处理现金。他们还有其他事情要做。

所以：

• 保镖 - 网络角色。处理 传入流量，击退无效 请求并添加有效请求 致：
• 队列 - 队列！
• 票房 - 工作人员角色，对webrole执行不同的角色

所以，没有理由说你的网络角色不能担任票房角色，但最好不要长期使用

这是我的比喻

托比

Answer 2

我想说插件不需要工人角色。无论如何，您都要插入队列，因此您不会在Web角色中保存任何内容。最好的办法是将您的插入（以及所有数据访问）隔离到Web角色中的单独类（或类）中。这将允许您将Web角色中的其余代码与您正在使用的特定数据存储系统分离。这使得以后更改数据存储变得更加容易。如果您的插入最终需要更多处理，您可以在需要时添加队列和辅助角色，但我仍然会说您希望直接插入表存储，然后将计算或其他业务逻辑放到工人角色。然后，该worker角色可以处理来自队列的消息，或者仅查询表存储以获取新的（未处理的）记录。

当我需要对数据进行计算或其他处理时，我看到使用队列与工作者角色进行通信的方式变得最有效。我最常使用的那个实际上是Azure SDK中的一个示例，它显示了如何制作缩略图。我的Web角色将上载的图像插入Azure blob存储以及相关描述和其他字段到Azure表存储中。它还在队列上放置一条消息，让工作者角色知道有一个需要生成缩略图的新图像。实际上，我为每个图像生成了一些不同大小，以便在网站的不同部分使用。辅助角色只生成这些缩略图，不需要将任何类型的通知发送回Web角色。当缩略图尚不可用时，任何使用图像的地方都有逻辑使用原始上传或其他占位符。

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

编辑以回复评论：当我发布此答案时，我说只是在缩略图不可用时才使用UI中的全分辨率图像。现在我正在使用一个只使用默认缩略图的网站，该图像显示“正在处理”，直到生成的缩略图可用。选择权在您手中，并且取决于应用UI的要求。

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

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

Answer 3

使用分布式队列（Azure或亚马逊或其他）相当令人惊讶的微妙。我发布了一篇博文covering frequent subtleties of Azure Queues。结论：我建议您从业务逻辑（内容和队列处理）中仔细抽象出您的基础架构逻辑（支持队列）。