web-dev-qa-db-ja.com

メッセージ駆動型アーキテクチャと水平スケーリング

マイクロサービスのイベント駆動型アーキテクチャでペットプロジェクトに取り組んでいるときに、クライアントに応答を配信するという問題に直面しました。

enter image description here

各マイクロサービス（APIゲートウェイなど）には多くのレプリカがあり、独自のロードバランサー（Kubernetesサービス）があります。

使用事例：

  1. 20クライアント（JSアプリ）が「アカウントリクエストの登録」を送信します

  2. 10個のクライアントが「API Gateway 1」と10個の「API Gateway 2」に接続します。ゲートウェイは接続を保持します（ロングポーリング）

  3. 各APIゲートウェイは、Apache Kafkaを介してデータプロセッサにリクエスト処理を委任します。トピック「registerAccount」

  4. データプロセッサは「registerAccount」トピックにサブスクライブされています。 onMessage（）はアカウントを登録し、新しいアカウントのIDをKafkaに戻します。トピック「newAccountId」

  5. APIゲートウェイはnewAccountIdを受け取ります（どれですか？すべてですか？）

  6. APIゲートウェイはnewAccountIdを適切なクライアントに送信します（API GatewayはどのようにこのnewAccountIdを受信する必要があるクライアントを決定できますか？）

私が見つけた唯一の解決策は、各メッセージにクライアントIDを追加してからメッセージをフィルターすることです。

誰かがそのような問題を経験しましたか？

javamicroservicesmessage-queue
4
ovnia

Kafka=でコンシューマーを効果的に負荷分散する方法は、各クライアントノード/プロセスを単一のコンシューマーグループに登録することです。

コンシューマーは自身にコンシューマーグループ名のラベルを付け、トピックに公開された各レコードは、サブスクライブしている各コンシューマーグループ内の1つのコンシューマーインスタンスに配信されます。コンシューマインスタンスは、個別のプロセスまたは個別のマシンに配置できます。

すべてのコンシューマインスタンスに同じコンシューマグループがある場合、レコードはコンシューマインスタンス間で効果的に負荷分散されます。

すべてのコンシューマインスタンスに異なるコンシューマグループがある場合、各レコードはすべてのコンシューマプロセスにブロードキャストされます。

[ソース] https://kafka.Apache.org/intro

これはかなり基本的なクライアント構成です。 Kafkaには「メッセージキュー」という概念はありませんが、トランザクションベースのメッセージ駆動型イベントをこの方法で確実に処理できます。

3
maple_shaft