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

我是azure事件中心的新手，正在尝试查看 是否有一个选项用于使用EventHubs/azure函数实现管道处理（组件链，其中第一个组件的输出转到链中的下一个组件）

我有一个来自事件中心的数据流，我有一些组件集，其中每个组件执行特定的功能，并将结果传递给下一个组件。下一个组件可能需要事件原始数据和从上一个组件生成的结果（可以具有序列依赖性）。 事件中心/azure功能是否适合此类场景？我所理解的是，每个消费者都有自己的事件副本，所以它不能对消费者进行流水线操作

通过azure中的大量事件流设计组件管道（以便在需要时可以在管道中添加新组件）的最佳方法是什么？ 或者azure even hub中唯一的选择是让一个使用者创建组件的完整处理管道（这将有点耦合）。

---

我不想在每个组件之间使用不同的事件集线器（即使完全解耦，但要管理的事件集线器太多）

事件集线器构成数据/事件管道的数据摄取端。然后对数据进行处理、分析（实时）和存储，并可能进行分类，随后分析历史数据。这形成了一个典型的管道。 您希望在接收到事件中心的每条消息上使用不同的组件/规则引擎等应用一系列不同类型的处理

我能想到的选择是

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

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

---

3） 逻辑应用程序为您提供工作流编排类型模型。在这种情况下，您可以将eventhubs中的事件作为启动工作流的触发器。但我不确定这是否完全符合您的要求，而且如果接收的数据量很高，可能会出现扩展和性能问题。

为什么服务总线队列比事件中心便宜？这是根据azure定价的。活动中心标准层成本约为37美元，而标准层服务总线基本费用为10美元，其余费用基于ops，随着使用量的增加而降低。另外，两种服务的目的也不同。在这种情况下，组件之间的中间队列就足够了，因为在这种情况下，只有一个入口和出口。在这种情况下，我们已经使用事件中心，因此每月的成本已经发生。不管怎样，只要有相当数量的信息，每月的费用都是可以忽略的。对于集线器和SB，每条消息的价格更小。正如我所说，这当然取决于入口数据的数量。当有多个客户端发布数据时，最好使用事件中心，而在这种情况下，引入队列只是为了解耦。