azure - 事件中心是否应该根据消息类型进行拆分？

Question

我正在考虑将 Azure 事件中心用于我当前正在进行的项目。今天我们使用服务总线队列来执行命令，在这里我们对每种消息类型使用一个队列。

拥有多个事件中心是否有意义，还是使用一个中心处理多种消息类型更好？

Answer 1

这是一个充满权衡和判断的问题，您希望现在和将来构建什么系统以及它们如何使用不同的事件类型。

以下是 some of the guidance 的摘录Jay Kreps 曾在 Apache Kafka 之上设计系统，该系统也适用于事件中心(主要异常(exception)是较短的保留期和消费者组数量的限制)。

Let’s begin with pure event data—the activities taking place inside the company. In a web company these might be clicks, impression, and various user actions. FedEx might have package deliveries, package pick ups, driver positions, notifications, transfers and so on.

These type of events can be represented with a single logical stream per action type. For simplicity I recommend naming the Avro schema and the topic the same thing, e.g. PageViewEvent. If the event has a natural primary key you can use that to partition data in Kafka, otherwise the Kafka client will automatically load balance data for you.

...

We experimented at various times with mixing multiple events in a single topic and found this generally lead to undue complexity. Instead give each event it’s own topic and consumers can always subscribe to multiple such topics to get a mixed feed when they want that.

我基本上同意这个建议(如果您正在事件中心/Kafka/Kinesis 上设计系统，您应该阅读整篇博客文章)。订阅者需要忽略他们不感​​兴趣的消息，这不仅令人烦恼，而且如果其中一种事件类型开始主导组合流，以后还会出现问题。

但是拥有多个流并将它们组合在一起确实会产生成本，并且在做出决定时需要权衡这些成本。我列出了一些想到的。

1. 来自同一来源的不同类型事件之间的顺序会丢失，除非您努力将其添加回来。

2. 如果您想一起提交不同主题的进度，那么您需要管理它们。

3. 如果您在主题之间共享的主键上对事件流进行分区，并希望每个主题中的分区一起移动，则不能使用 EventProcessorHost 等高级客户端。因为分区最终可能会自动平衡到不同的进程。

4. 每个分区一个线程的使用者最终会将所需的线程数乘以主题数。除非您有无法共享的昂贵结构，否则可能不是问题。

在我自己的部署中，我们对不同的事件类型使用不同的事件中心，尽管我们当前使用相同的代码来处理所有这些事件。这仅仅是因为我希望添加只关心某些事件类型的新组件。我希望这会有所帮助，最坏的情况是我告诉你去看看 Kafka 的指南，因为原理是一样的，而且它已经存在了更长时间。