我正在考虑将 Azure 事件中心用于我目前正在从事的项目。我们今天使用服务总线队列来执行命令，这里我们为每个消息类型使用一个队列。
拥有多个事件中心是否有意义，或者将一个中心用于多种消息类型是否更好？
问问题
2365 次
1 回答
12
这是一个充满权衡和判断的问题，您希望现在和将来构建什么系统，以及它们如何使用不同的事件类型。
以下是 Jay Kreps 为在 Apache Kafka 之上设计系统提供的一些指导的摘录，这些指导也适用于事件中心（主要例外是保留期短和对消费者组数量的限制） .
让我们从纯事件数据开始——公司内部发生的活动。在网络公司中，这些可能是点击、印象和各种用户操作。联邦快递可能有包裹递送、包裹取件、司机位置、通知、转移等等。
这些类型的事件可以用每个动作类型的单个逻辑流来表示。为简单起见，我建议将 Avro 模式和主题命名为相同的东西，例如 PageViewEvent。如果事件有一个自然主键，你可以使用它来对 Kafka 中的数据进行分区，否则 Kafka 客户端会自动为你负载均衡数据。
...
我们在不同时间尝试将多个事件混合在一个主题中，发现这通常会导致过度的复杂性。相反，给每个事件它自己的主题，消费者可以随时订阅多个这样的主题，以便在需要时获得混合提要。
我通常同意这个建议（如果你在 Event Hubs/Kafka/Kinesis 上设计一个系统，你应该阅读整篇博文）。订阅者需要忽略他们不感兴趣的消息不仅很烦人，而且如果其中一种事件类型开始主导组合流，以后也会出现问题。
但是拥有多个流并将它们组合在一起确实有成本，在做出决定时需要权衡它们。我列出了一些想到的。
除非您努力将其添加回来，否则您会失去来自同一来源的不同类型事件之间的排序。
如果您想共同致力于不同主题的进展，那么您需要管理它们。
如果您在主题之间共享的主键上对事件流进行分区，并希望每个主题中的分区一起传输，则不能使用EventProcessorHost等高级客户端，因为分区最终会自动平衡到不同的进程。
每个分区有一个线程的消费者最终将所需的线程数乘以主题数。除非您有无法共享的昂贵结构，否则可能不是问题。
在我自己的部署中，我们为不同的事件类型使用不同的事件中心，尽管我们目前使用相同的代码来处理它们。这仅仅是因为我希望添加只关心某些事件类型的新组件。我希望这会有所帮助，最坏的情况是我告诉你去看看 Kafka 的指导，因为原理是一样的，而且它已经存在了更长的时间。
于 2015-03-20T10:40:09.590 回答