（マイクロ）サービス間の通信をRESTからKafkaに変更したいと考えています。 私はその話題については不明であり、そのことに関するいくつかの意見を聞きたいと思っていました。マイクロサービス間の通信のためにRestの代わりにKafka
次の設定を検討してください。 Webアプリケーション用のRESTを介してCRUD機能を提供するAPIゲートウェイがあります。だから私はユーザーが呼び出すことができる4つのエンドポイントがあります。 APIゲートウェイは要求を生成し、2番目のサービスからの応答を消費します。 2番目のサービスは要求を消費し、データベースにアクセスしてデータベースのCRUD操作を実行し、結果を生成します。
いくつのトピックを作成すればよいですか？ 8（2つのエンドポイント（要求/応答）ごとに）を作成する必要がありますか、それとももっと良い方法がありますか？
これに関するいくつかの経験や講演やドキュメントへのリンクをご希望ですか？
この質問に対する短い答えは、あなたのデザインによって異なります。
すべての操作に1つのトピックしか使用できないか、操作ごとに複数のトピックを使用できます。しかし、あなたはそれを知る必要があります。
あなたは作成した順番でkafkaにメッセージを生成しなければならず、一貫性を提供するために同じ順序でメッセージを消費する必要があります。 kafkaに送信されるメッセージは、トピックパーティション内で順序付けされます。異なるトピックパーティションのメッセージはkafkaによって注文されません。あなたがアイテムを作成し、そのアイテムを削除したとします。作成操作に関連するメッセージの前に、削除操作に関連するメッセージを消費しようとすると、エラーが発生します。このシナリオでは、これらの2つのメッセージを同じトピックパーティションに送信して、メッセージの作成後に削除メッセージが確実に消費されるようにする必要があります。
一貫性とスループットの間には常にトレードがあります。このシナリオでは、単一のトピックパーティションを使用してすべてのメッセージを同じトピックパーティションに送信すると、一貫性が提供されますが、メッセージを高速に消費することはできません。同じトピックパーティションからメッセージを1つずつ取得するため、前のメッセージが消費されたときに次のメッセージが表示されるためです。ここでスループットを向上させるには、複数のトピックを使用するか、トピックを複数のパーティションに分割します。これらの両方のソリューションでは、一貫性を確保するために、プロデューサ側にロジックを実装する必要があります。関連するメッセージを同じトピックパーティションに送信する必要があります。たとえば、トピックを異なるエンティティタイプの数に分割し、同じエンティティタイプのcrud操作のメッセージを同じパーティションに送信することができます。あなたのシナリオでの一貫性を保証するかどうかはわかりませんが、これは別の方法です。複数のトピックまたはトピックのパーティションに一貫性を持たせるロジックを見つける必要があります。それはあなたの場合に依存します。ロジックを見つけることができれば、一貫性とスループットの両方を提供できます。
あなたのケースでは、複数のパーティションで1つのトピックを使用し、プロデューサ側では、関連するメッセージを同じトピックパーティションに送信します。
--regards