我有不同类型的事件。例如，有些数据是遥测数据，有些是错误信息等。
我认为创建多个 IEventProcessor 实现是一个好主意，每个事件类型一个。所以每个实现都会以不同的方式处理事件。就像写入文件或数据库一样。
将事件路由到特定 EventProcessor 的最佳方式是什么？
我必须说，我发现 partitionkey 和 consumergroup（如果有的话）之间的关系记录得很差。
我使用了选项 2，但到目前为止，每个 EventProcessor 都从所有消费者组名称中获取消息，而不仅仅是在 EventProcessorHost 构造函数中指定的那个。
好问题！
在回答之前 - 我想重申我们在构建 EventHubs 时遵循的几个原则。
我们希望事件中心成为一个高度持久、高吞吐量的事件摄取管道。当我们已经在 Azure 上拥有现有的 pub-sub 服务（如 Queues/Topics（类似于 AWS SQS、Google Pub-sub））时，提出新服务的主要区别因素是提供更高的吞吐量变体（当然，低延迟）。我们能够实现这个目标——通过权衡——我们不执行任何每条消息的计算——比如在服务上执行过滤器等。当您需要每条消息的语义时 - 例如每条消息的重复数据删除，每条消息的确认接收，在您的情况下，根据每条消息的属性进行过滤- 并且吞吐量要求很低 - 队列/主题可能是您最好的选择。
我们还设想，发件人（或发布者）的规模要大得多，并且会因场景而异。所以我们介绍了 3 种发送模式（发送、使用 PartitionKey 发送、直接发送到分区）。因此，在发送时，您会注意到 PartitionKey 的概念 - 这又将转换为特定分区（将 PartitionKey 视为 EventHub 服务的线索，以计算具有相同 PartitionKey 的所有事件在相同分区上的位置）。但是，在消费事件时，EventHubs 没有直接暴露 PartitionKey 的概念。没有关系 b/w ConsumerGroups 和 PartitionKey。
接收者通常只是计算角色，数量有限。因此，我们公开了 1 个通用接收（消费）模式 - 从分区接收。现在，在消费事件时，可能会有基于不同因素的不同类型的消费者——例如：消费速度（实时与历史）或数据类型——因此——我们暴露了多个消费者群体。尽管您可以创建 20 个 CG，但我们在这里遇到的一个有趣的限制是 - 每个购买的吞吐量单元可以产生 1 MBPS 的输入和 2 MBPS 的输出 - 如果在发送端充分利用它将限制为 2 个 CG。因此，如果您正在处理完全相同的流并且有不同的方式来处理每个事件，但每个事件都需要相同的时间来处理 - 那么，使用相同的 ConsumerGroup 更有意义。
回答你的问题：这真的取决于。
这里有几个解决方案：
因为，您的场景中有多种事件类型 - 您需要预见/决定是否有任何场景，其中需要由单个消费者/处理器读取和处理所有类型的事件。一个例子：我们通常看到的是 - 使用一个 ConsumerGroup 您想要计算所有错误，而其他消费者组实际上会针对每个错误类型执行特定操作。如果您不需要 - 将每个 EventType 发送到不同的 eventthubs，然后使用具有特定 IEventProcessor 的 1 个使用者组 - 是一种选择。
如果您有需要将所有事件发送到同一个 EventHub 的场景，并且如果您知道某些 eventTypes 的处理速度非常快（或需要） - 您应该考虑使用不同的消费者组，每个消费者绑定到特定 IEventProcessor 实现的组，它将忽略其他 EventType。例如：如果 ErrorInfo 事件和特殊事件需要实时关注，并且遥测数据由于处理缓慢或高峰加载时间而可以承受 15 分钟的打击 - 我会选择一个 ConsumerGroup 并将其命名实时并将其与处理 2 种类型的 IEventProcessor 联系起来 - 错误和特殊。创建 2nd ConsumerGroup 并将其与处理遥测事件的 IEventProcessor 绑定。