azure多功能成像好用吗_Azure功能：在队列和事件中心之间进行选择

azure多功能成像好用吗

性能和吞吐量方面的考虑

我每周大约有两次谈话。 某个人已经决定，他们想为即将到来的项目利用无服务器Azure功能的好处，但是当开始布局该体系结构时，会弹出一个问题：

“我们应该使用Azure事件中心，队列还是事件网格？”

老实说，这是一个很好的问题-这是一个有后果的问题。 这些消息传递技术中的每一种都具有自己的一套行为，这些行为可能会影响您的解决方案。 在以前的博客中，我花了一些时间解释事件网格 ， 事件中心排序保证 ，如何在队列/主题中具有排序保证以及如何保持事件中心流流程具有弹性 。 在此博客中，我特别想处理另一个重要方面：可变工作负载的吞吐量。 这是我上周遇到的情况：

我们有一个解决方案，可以放入数千条记录进行处理。 一些记录只需要几毫秒的处理时间，而其他记录则可能需要几分钟。 现在，我们正在通过事件中心将消息推送到功能，并注意到在处理所有消息方面存在一些重大延迟。

如果您了解每个触发器的行为，那么这里的问题就很微妙，但是很简单。 如果您只有一堆需要完成的任务，则可能需要排队。 这不是一个完美的规则，但是队列经常会出现您正在寻找的行为。 实际上，该博客将表明选择错误的消息传递管道可能导致处理时间差异一个数量级。 让我们看一下原因。

每个任务大小的可变性

如果您看看上面的客户提出的问题，那么一个关键因素会让我知道，这里的队列可能是最好的。

“……某些记录只需要几毫秒的处理时间，而其他记录则可能需要几分钟。”

如果我有需要调整图像大小的队列，则100kb图像的调整大小比100mb全景图像的调整快得多。 最大的问题是：“我的处理管道如何响应冗长的任务？” 这有点像在高速公路上开车。 对于单车道的道路，与五车道的道路相比，道路上的事件影响要大得多，无服务器管道的情况也是如此。

事件中心行为随任务时间而变化

Azure Event Hubs关心两件事，并且在这两件事上做得很好：订购和吞吐量。 它可以非常快速地接收和发送大量消息，并保留这些消息的顺序。 我们的团队之前已发布过有关Azure事件中心如何使我们能够在Azure Functions中每秒处理10万条消息的信息 。 我可以消耗了一批多达200条信息中的每一个的事实功能的执行是为一大原因。 但是，订购和吞吐量这两个核心问题也可以相互融合。

>如果您还不熟悉Event Hubs如何保留订单，那么值得 阅读此博客， 了解如何 先订购 然后再 订购 。

想象一下，我有一系列事件都落在同一事件中心分区中。 假设我的Azure Function将来自该分区的50个事件分批提取到一个函数中。 消息1–9在几毫秒内处理完毕，但是消息10则需要几分钟才能处理。 事件11–50会怎样？ 他们被卡住了。 事件中心关心排序，因此消息10需要在消息11开始之前完成。 想象一个场景，假设您收到的事件是股市事件，您非常在意“买入”事件在“卖出”事件发生之前发生，因此您会很高兴它坚持下去。 但是，如果您的方案不关心订购怎么办？ 如果在等待消息10完成时事件11–50，甚至51–1,000，该怎么办？ 在这种情况下，事件中心的行为将大大降低您的性能。 在当前批处理以及该批处理中的每个事件完成之前，事件中心将不会处理分区中的下一个批处理。 因此，一个坏事件可能会占用整个分区。

将行为与任务时间可变地排队

队列呢？ 标准队列不太关心排序¹（ 启用会话的队列则如此 ）。 队列更关心确保每个消息都得到处理并得到完全处理。 进入任何政府大楼，您通常会见证分布式队列处理的实际应用。 您只有一行人需要完成某项工作，还有几张员工的桌子可以提供帮助（希望超过一分😄）。 尽管有些员工可能需要花费几分钟的时间，但其他员工将在有空时立即抓住下一个人。 一个长期的要求不会阻止所有工作继续进行。 队列触发器将相同。 无论您的应用程序的哪个实例可以进行更多工作，都将抓住下一个任务。 没有任务取决于队列2中另一个任务的完成。

服务总线队列和存储队列

似乎在事件中心，事件网格和队列之间做出决定并不是一件容易的事，存储队列与服务总线队列之间存在一个子决策。 我在这里不会做得很深入。 有一份详细的文档将列出最大的差异。 简而言之，Service Bus是一种企业级消息代理，具有某些强大的功能，例如会话，托管死信队列和自定义策略。 存储队列是存储帐户的一部分，非常简单，超轻量级队列。 我经常坚持使用存储队列，因为我的Azure功能已经有一个存储帐户，但是如果您需要更多的事务性和企业级（或主题）的内容，Service Bus绝对是您想要的。

Azure功能和可变工作负载

为了说明可变工作负载在行为上的差异，我进行了一些测试。 这是实验。

我将1,000条相同的消息放入Azure事件中心，Azure服务总线队列和Azure存储队列中。 这些消息中有90％只需一秒钟即可处理，但10％（散布在整个消息中）则需要十秒钟。 我有三个几乎完全相同JavaScript函数 ，将开始对这些消息进行处理。 问题是：哪个处理速度最快？

实验结果：事件中心

鉴于上面的解释，这不足为奇，但是Event Hubs花费的时间比队列处理所有1,000条消息的时间长大约8倍。 所以发生了什么事？ 到队列功能应用程序完成时，它实际上已处理了大约90％的消息，但最后10％的尾巴很长。 原来，一个实例的分配分区很不幸，并且在十秒钟的任务中大约有40个实例。 在继续下一个事件集（可能包含另一个十秒任务）之前，它一直等待长的任务完成。 最后10％的强制顺序处理意义重大。

实验结果：存储队列和服务总线队列

就该实验的总处理时间而言（几秒钟之内），存储队列和服务总线队列非常接近。 我想在这里指出一个细微的区别。 在无服务器的幕后，有实例或工作程序节点（您甚至可以称它们为…服务器）来处理您的工作。 在我们为您处理扩展时，Azure Functions使您能够一次在单个节点上处理多个消息。 实际上，在许多情况下这非常有用，因为您可以拥有更好的连接池，缓存共享和资源利用率。 对于服务总线队列和存储队列，Functions运行时将提取一批消息，并在应用程序的每个运行实例上并行处理它们。 两种队列触发器的默认并发都是16条消息。 就我而言，在简短测试期间，我的功能可扩展到许多实例，因此我的总并发性高于16条消息，但每个实例处理的都是16条。

之所以如此重要，是因为存储和服务总线队列对批处理的处理略有不同。 最大的区别在于：“在检索下一条消息或一批消息之前，必须处理多少条消息。”

对于Azure存储队列，在检索下一个批次之前，必须超过“新批次阈值”。 默认情况下，这是批处理大小的一半，即8。这意味着主机将捕获16条消息并开始同时处理所有消息。 一旦该批次中剩下<= 8条消息，主机将抓取下一组16条消息并开始处理（直到待完成的计数再次达到<= 8条消息）。 在我的情况下，由于只有10％的消息很慢，因此通常可以信任此阈值以保持实例并发性很高。 但是，您仍然可以在Application Insights分析中看到批处理阈值的少量爆发。 急剧的跳跃与处理批次的大小以及何时检索新批次相关。

在单个实例上处理的邮件按5秒分组

Azure Service Bus队列依赖于Service Bus SDK提供的MessageHandler来提取新消息。 消息处理程序具有最大并发性选项（功能默认情况下设置为16），并且可以根据需要自动获取更多消息。 在我的实验中，您可以看到同时处理的消息的速度要平滑得多。 如果有1条慢速消息阻止了16个并发执行中的一个，则处理程序仍可以继续循环浏览其他15个消息。

与上面相同的图表，但正在处理的邮件速率要平滑得多

因此，正如您所期望的，当您的问题集为“我有很多需要按任何顺序执行的可变任务”时，两种类型的队列的性能要好得多。

那事件网格呢？

为什么不包括事件网格？ 与这些其他选项相比，Event Grid的吞吐量行为差异很大。 事件网格是基于推送的（通过HTTPS），而它们是pull 。 如果我收到1000个事件网格事件，则1000个并发HTTPS请求会戳我的函数。 他们必须尽快进行扩展，排队和处理。 我希望，因为不能保证事件网格的排序，它将更接近队列。 就是说，对于这个客户，他们特别考虑了下游系统的吞吐量，因此，他们希望灵活地通过Event Grid无法提供的更一致的单击来提取这些消息（无论是否需要，它们都会戳功能）。

关于事件网格，我要做的唯一其他说明是它用于处理事件，而不是消息。 有关该区别的详细信息， 请查看此文档 。

希望该实验有助于弄清消息传递选项并非千篇一律。 每个服务器都有其自己的优先级和优势，在创建无服务器体系结构时了解每个服务器很重要。

脚注

1. 队列可能关心顺序，但是对于分布式计算， 最好通过会话来实现 ， 以实现更好的吞吐量和分布 。
2. 请参见上面的脚注1😅

翻译自: https://hackernoon.com/azure-functions-choosing-between-queues-and-event-hubs-dac4157eee1c

azure多功能成像好用吗