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