使用 Azure 事件中心和 Azure 函数进行管道处理答案

【问题标题】：Pipeline processing with Azure Event hubs and Azure functions使用 Azure 事件中心和 Azure 函数进行管道处理
【发布时间】：2017-03-15 06:19:39
【问题描述】：

我是 azure 事件中心的新手，我想看看是否可以使用 EventHubs/azure Functions 实现管道处理（组件链，其中第一个输出到链中的下一个）？

我有一个来自事件中心的数据流，我有一些组件，其中每个组件执行特定的功能并将结果传递给下一个组件。下一个组件可能需要事件原始数据和前一个组件生成的结果（可以具有排序依赖性）。事件中心/天蓝色功能是否适合此类场景？我的理解是每个消费者都有自己的事件副本，因此它不能对消费者进行管道传输。

在 azure 中的大型事件流上设计组件流水线（以便在需要时可以在管道中添加新组件）的最佳方法是什么？或者 azure even hub 中的唯一选择是让单个消费者创建完整的组件处理管道（这将有些耦合）。我不想在每个组件之间使用不同的事件中心（即使完全解耦，但要管理的事件中心太多）

【问题讨论】：

【解决方案1】：

Eventhubs 构成数据/事件管道的数据摄取端。然后从那里处理、分析（实时）和存储数据，并可能对历史数据进行分类，然后再分析历史数据。这形成了一个典型的管道。您正在寻找使用不同组件/规则引擎等对摄取到事件中心的每条消息应用一系列不同类型的处理。

我能想到的选项是

1) EventProcessorHost - 在这里您可以编写自己的自定义代码（一个接一个的组件）以异步方式从事件中心的所有或特定分区接收消息。这涉及在代码中连接所有逻辑。所以如果你需要引入一个新的组件意味着它会涉及到代码的改变和新的部署。

2）根据您的观点，您还可以拥有多个中间事件中心并进行处理，但这可能会变得昂贵。您可能希望将服务总线队列视为加载消息以进行后续处理的中间点，这将是一个更便宜的选择。

3) 逻辑应用为您提供工作流编排类型模型。在这种情况下，您可以将 eventthubs 中的事件作为启动工作流的触发器。但不确定这是否完全符合您的要求，如果摄取的数据量很大，也可能存在扩展和性能问号。

【讨论】：

为什么服务总线队列会比事件中心便宜？
按照天蓝色定价。事件中心标准层级成本约为 37 美元，而标准层级服务总线基本费用为 10 美元，其余部分基于操作，并随着您使用的更多而减少。 2个服务的目的也不同。在这种情况下，组件之间的中间队列就足够了，因为只有一个入口和出口
在这种情况下，我们已经使用了事件中心，因此已经产生了每月费用。无论如何，对于任何数量可观的消息，每月的成本都可以忽略不计。 Hubs 与 SB 相比，每条消息的价格更低。
好的。正如我所说，这肯定取决于入口数据的数量。当有多个客户端发布数据时首选事件中心，而在这种情况下引入队列只是为了解耦。