Apache kafka kafka中的消息路由

我们正在尝试使用微服务构建一个平台，通过kafka异步通信。 按照我的理解，在每个微服务中，每个聚合类型有一个主题似乎是很自然的。因此，实现用户注册的微服务会将与用户相关的事件发布到主题“用户”中。 其他微服务将侦听从“用户”微服务创建的事件，并实现它们自己的逻辑并相应地填充它们的数据库。问题在于，其他微服务可能对用户微服务生成的所有事件不感兴趣，而是对这些事件的子集感兴趣，比如UserCreated only（例如，没有更改用户名）。 使用RabbitMq很容易，因为事件处理程序是根据消息类型调用的

您是否在kafka上实施过基于消息的路由/过滤

我们是否应该使用所有消息，对它们进行反序列化，并忽略消费者不需要的消息？（听起来像是一个开销）

我们是否应该将这些主题转发给storm，并将这些消息重定向到面向消费者的主题？（听起来有点过分，而且不可扩展）

使用分区作为路由机制似乎不符合逻辑

---

为每个标准对象操作使用不同的主题：创建、读取、更新和删除，并使用“UserCreated”、“UserRead”等命名约定。如果仔细考虑，每个操作中的对象可能有不同的模式。创建将需要一个有效的对象；读取将需要某种过滤器；更新您可能希望处理增量更新（将10添加到特定字段等）

如果不同的操作具有不同的模式，则会使反序列化变得困难。如果您使用的是像JavaScript这样松散的goosey语言，好吧——没什么大不了的。但是，像Scala这样的严格类型语言，在同一主题中使用不同的模式是有问题的

---

它还可以解决你的问题——你可以倾听你想要的行动类型，不多不少。

1-使用卡夫卡一年内，你似乎从未遇到过类似的情况。2-基本上，是的，除非你有更细粒度或更有针对性的主题。好的方面是，如果你的客户完全支持snappy support 3，那么从卡夫卡消费是便宜的——只有你才能回答这个问题。一个较轻的路线可以用驼峰完成。4-这根本不是分区的目的。卡夫卡是一个非常强大的工具，当您需要快速提供大量数据时，它的代价是更微妙地控制数据的分发方式。你不会用消防水龙带给花园浇水。不仅卡夫卡的消费很便宜，而且阅读整条溪流，抛撒你想要的东西，从生产方面来说，实际上也很便宜。磁盘驱动器的线性读取速度比随机读取速度快100到1000倍。这是卡夫卡设计理念的重要组成部分：这意味着我们必须为每种事件类型创建一个卡夫卡主题。考虑到几个微服务，这意味着#of topics=所有服务中事件类型的数量。这不会降低卡夫卡的表现吗？最重要的是，这意味着我们失去了对每个聚合的事件类型的排序：UserCreated然后UserNameChanged事件可以无序地传递到其他服务，这增加了复杂性。拥有额外的主题不会成为问题（请参见此处：），而且您对事件排序的看法绝对正确。然而，每个主题都应该有一个模式。当然，这是个难题。您好@DavidGriffin，失去订单担保对我来说总的来说是一个巨大的缺点。让我们假设我们有一个事件存储，所有运行在流上的投影仪都保证按顺序接收事件。如果他们不这样做，计算的状态可能完全不正确（如果没有这个订单保证，时间旅行根本不可能）。你能举一些系统对这种无序的事件流做出反应的例子，以及它们是如何处理的吗？我对卡夫卡很陌生，所以我可能会错误地表示手头的问题。@Gildas您解决订单问题了吗？