将 Azure 事件中心与 Azure Functions 结合使用的解决方案受益于无服务器体系结构,该体系结构可缩放、经济高效并且能够近乎实时地处理大量数据。 尽管这些服务可以无缝地协同工作,但仍有许多功能、设置和复杂性会增加其关系的复杂性。 本文通过强调性能、复原能力、安全性、可观测性和缩放的关键注意事项和技术,提供有关如何有效利用此集成的指导。
事件中心核心概念
Azure 事件中心是高度可缩放的事件处理服务,每秒可接收数百万个事件。 在深入了解 Azure Functions 集成的模式和最佳做法之前,最好先了解事件中心的基本组件。
下图显示了事件中心流处理体系结构:
事件
事件是表示为过去发生的事实的通知或状态更改。 事件是不可变的,保留在事件中心中,在 Kafka 中也称为“主题”。 事件中心由一个或多个分区组成。
分区
当发送方未指定分区时,接收到的事件将分布在事件中心的各分区之间。 每个事件只写在一个分区中,而不是跨分区多播。 每个分区以日志形式运行,其中记录以仅追加模式写入。 “提交日志”的比喻经常用于描述如何将事件添加到分区中序列末尾的性质。
使用多个分区时,允许在同一事件中心内使用并行日志。 此行为提供了多程度的并行性,并增强了使用者的吞吐量。
使用者和使用者组
一个分区可由多个使用者使用,每个使用者都可从中读取和管理自己的偏移量。
事件中心具有使用者组的概念,使多个使用应用程序都能够各自具有事件流的单独视图,并以其自己的节奏和偏移量独立读取流。
有关详细信息,请参阅深入了解事件中心的概念和功能。
配合 Azure Functions 使用事件
Azure Functions 支持事件中心的触发器和输出绑定。 本部分介绍 Azure Functions 如何使用触发器响应发送到事件中心事件流的事件。
事件中心触发的函数的每个实例由单个 EventProcessorHost 实例提供支持。 触发器(由事件中心提供支持)确保只有一个 EventProcessorHost 实例能够在给定分区上获得租约。
例如,考虑具有以下特征的事件中心:
- 10 个分区。
- 1,000 个事件均匀分布在所有分区中,每个分区中的消息数量不同。
首次启用函数时,该函数只有一个实例。 我们将第一个函数实例命名为 Function_1
。 Function_1
具有单个 EventProcessorHost 实例,此实例在所有 10 个分区上都有租约。 此实例从分区 1-10 读取事件。 从此时开始,将发生下列情况之一:
不需要新的函数实例:在 Functions 的缩放逻辑生效之前,
Function_1
可以处理所有 1,000 个事件。 在这种情况下,所有 1,000 条消息都由Function_1
处理。添加其他函数实例:基于事件的缩放或其他自动或手动逻辑可能会确定
Function_1
的消息超出了其处理能力,然后会创建新的函数应用实例 (Function_2
)。 此新函数也有一个关联的 EventProcessorHost 实例。 基础事件中心检测到新主机实例正在尝试读取消息时,会在主机实例之间对分区进行负载均衡。 例如,可以将分区 1-5 分配给Function_1
,将分区 6-10 分配给Function_2
。额外添加 N 个函数实例:基于事件的缩放或其他自动或手动逻辑确定
Function_1
和Function_2
的消息数都超出了它们的处理能力,则会创建新的 Function_N 函数应用实例。 会一直创建实例,直到 N 等于或大于事件中心分区数为止。 在我们的示例中,事件中心再次对分区进行负载均衡,在本例中是在实例Function_1
...Function_10
之间进行的。
缩放时,N 个实例的数量可能大于事件中心分区的数量。 当事件驱动的缩放稳定实例计数时,或者其他自动或手动逻辑创建的实例多于分区时,可能发生这种情况。 在这种情况下,EventProcessorHost 实例将仅在其他实例释放锁时在分区上获取锁,因为在任何给定时间,只有同一使用者组中的一个函数实例可以访问/读取具有锁的分区。
当所有函数执行都完成时(不管是否有错误),则会将检查点添加到关联的存储帐户。 检查点设置成功后,永远不会再次检索所有 1,000 条消息。
使用消耗和高级 Azure 计划,可以实现基于事件的动态缩放。 Kubernetes 托管的函数应用还可以利用事件中心的 KEDA 缩放器。 当函数应用托管在专用(应用服务)计划中时,无法进行基于事件的缩放,这要求你根据工作负载确定正确的实例数。
有关详细信息,请参阅 Azure Functions 的 Azure 事件中心绑定和适用于 Azure Functions 的 Azure 事件中心触发器。
作者
本文由 Microsoft 维护, 它最初是由以下贡献者撰写的。
主要作者:
- David Barkol | 首席解决方案专家 GBB
若要查看非公开的 LinkedIn 个人资料,请登录到 LinkedIn。
后续步骤
相关资源
- 监视无服务器事件处理提供了有关监视事件驱动式无服务器体系结构的指导。
- 无服务器事件处理是一个参考体系结构,详细说明了此类型的典型体系结构,其中包含代码示例和重要注意事项的讨论。
- 使用事件中心在无服务器事件处理中取消批处理并筛选更详细地介绍了该参考体系结构的这些部分的工作原理。