我正在考虑将Azure event Hub用于我目前正在进行的项目。我们今天使用Service Bus Queues作为命令，这里我们每个消息类型使用一个队列。
拥有多个事件中心是否有意义，或者将一个集线器用于多种消息类型会更好吗？
答案 0 :(得分：8)
这是一个充满权衡的问题，并对您希望现在和将来构建的系统以及它们如何使用不同的事件类型进行判断。
以下摘自some of the guidance Jay Kreps在Apache Kafka之上设计系统，该系统也适用于事件中心（短期保留期限和数量限制的主要例外情况除外）消费者团体）。
让我们从纯粹的事件数据开始 - 公司内部发生的活动。在网络公司中，这些可能是点击次数，展示次数和各种用户操作。联邦快递可能有包裹递送，包裹提取，司机位置，通知，转移等。
这些类型的事件可以用每个操作类型的单个逻辑流表示。为简单起见，我建议将Avro架构和主题命名为相同的内容，例如： PageViewEvent。如果事件具有自然主键，您可以使用它来分区Kafka中的数据，否则Kafka客户端将自动为您平衡数据。
...
我们在不同时间通过在单个主题中混合多个事件进行实验，发现这通常会导致过度复杂化。相反，为每个事件提供自己的主题，消费者可以随时订阅多个此类主题，以便在需要时获得混合Feed。
我普遍同意这个建议（如果你在Event Hubs / Kafka / Kinesis上设计一个系统，你应该阅读整个博客文章）。需要忽略他们不感兴趣的消息的订阅者不仅烦人，如果其中一个事件类型开始支配合并流，则会成为问题。
但是拥有多个流并将它们组合在一起确实会产生成本，并且需要在做出决策时权衡它们。我已经列出了一些想到的东西。
除非您花费精力将其添加回去，否则您将失去来自同一来源的不同类型的事件之间的排序。
如果您想一起提交不同的主题，那么您需要管理它们。
如果要在主题之间共享的主键上对事件流进行分区，并希望每个主题中的分区一起传输，则不能使用EventProcessorHost之类的高级客户端作为分区最终自动平衡到不同的进程。
每个分区有一个线程的使用者最终会将所需的线程数乘以主题数。除非您拥有无法共享的昂贵结构，否则可能不是问题。
在我自己的部署中，我们为不同的事件类型使用不同的事件中心，即使我们当前使用相同的代码来处理它们。这只是因为我希望添加仅关注某些事件类型的新组件。我希望这会有所帮助，最糟糕的是我已经告诉过你去看看卡夫卡的指导，因为这个原则是相同的，并且它的存在时间更长。