kafka中的消息路由

我們正在嘗試使用通過kafka進行異步通信的微服務來構建平臺。按照我的理解，看起來很自然，每個微服務中的每個聚合類型有1個主題。因此，實施用戶註冊的微服務會將用戶相關事件發佈到「用戶」主題中。其他微服務將監聽從「用戶」微服務創建的事件，並實現其自己的邏輯並相應地填充其DB。問題是其他微服務可能不會對用戶微服務產生的所有事件感興趣，而是對這些事件的一部分產生興趣，例如UserCreated（沒有UsernameChanged ...）。使用RabbitMq很簡單，因爲事件處理程序是根據消息類型調用的。kafka中的消息路由

您是否曾經通過kafka實現基於消息的路由/過濾？
我們是否應該消費所有消息，反序列化它們並忽略消費者不需要的消息？（聽起來像是一個開銷）
我們應該轉發這些主題以將這些消息轉向風暴並將這些消息重定向到針對消費者的主題？（聽起來像一個矯枉過正的和未調整的）
使用分區似乎不符合邏輯，因爲一個路由機制

來源

2016-03-11 hsen

1 - 在使用卡夫卡的一年中從未像現在這樣。 2 - 很多，是的，除非你有更多的粒度或目標主題。好消息是，如果你的客戶端功能齊全，支持快速支持，那麼從卡夫卡消費便宜3 - 只有你可以回答。駱駝可以完成更輕的路由。 4 - 這根本不是分區的目的。當你有大量的數據快速提供時，Kafka是一個非常強大的工具，這是以更微妙的控制如何分配爲代價的。你不會用噴水器給花園澆水。 –

不僅卡夫卡消費便宜，而且從生產方面來看，讀取整個流和扔你想要的東西實際上相當便宜。線性讀取與隨機讀取相比，磁盤驅動器的速度要快100到1000倍。這是Kafka設計理念的重要組成部分：https：//kafka.apache.org/08/design.html –

使用每個標準對象操作的不同的主題：創建，讀取，更新和刪除，像「UserCreated」，「UserRead」等命名約定。如果你仔細想想，你可能會在每個對象中有不同的模式。創建將需要一個有效的對象;閱讀需要某種過濾器;更新你可能想要處理增量更新（添加10到特定的字段等）。

如果不同的動作有不同的模式，它使得反序列化困難。如果您使用的是像JavaScript這樣的寬鬆語言，那麼確定 - 沒什麼大不了的。但是像Scala這樣嚴格類型的語言，在這個相同的主題中有不同的模式是有問題的。

它也可以解決你的問題 - 你可以準確地聽取你想要的動作類型，不多也不少。

來源

2016-03-11 02:45:48

這意味着我們必須爲每個事件類型創建一個kafka主題。考慮到幾個微服務，這意味着＃個主題=所有服務中事件類型的數量。這不會降低卡夫卡的表現嗎？最重要的是，這意味着我們失去了每個聚合的事件類型排序：UserCreated然後UserNameChanged事件可以按順序發送到其他服務，這增加了複雜性 – hsen

有額外的主題不會是一個問題（請參閱此處：https://www.quora.com/How-many-topics-can-be-created-in-Apache-Kafka），並且您對訂購事件絕對正確。然而，你應該每個主題都有一個模式。這是一個醃菜，當然。 –

kafka中的消息路由

回答

相關問題