仮定
- いくつかの単純な API エンドポイント (たとえば、リードスルー キャッシュ、データベースへのエントリの保存) を公開するステートレス マイクロ サービスを構築しています。
- mysqlやredisなどのノンブロッキング データベース クライアントを使用しています。
- マイクロサービスが HTTP 経由で相互に通信することを常に望んでいます (EC2 インスタンスをロードバランサーの背後に配置することにより)
質問
- 複数の標準バーチクルを使用する必要があるのはいつですか (つまり、マイクロサービス全体を 1 つのバーチクルとして記述し、その n インスタンスをデプロイします (n = イベントループ スレッドの数))。より多くのバーティクルを追加すると、シリアライゼーションとコンテキスト切り替えのコストが増えるだけではないでしょうか?
- マイクロサービスを複数の標準バーチクルに分割したとしましょう (何らかの理由で)。それぞれの n (n = イベントループ スレッドの数) インスタンスを展開しても、異なる比率のインスタンスを展開するよりも常に優れたパフォーマンスが得られるわけではありません。各バーティクルはアドレスの単なるリスナーであり、すべてのイベント ループ スレッドがあらゆる種類のメッセージを処理でき、それらは既に負荷分散されていることを意味します。
- アプリケーションをクラスター モードで実行するのはいつですか? ドキュメントに基づいて、クラスター モードは複数のバーティクルがある場合にのみ意味があると感じています。また、クラスター化の実際のユースケースがある場合にも意味があると感じています。たとえば、異なる EC2 インスタンスが異なるユーザーのリクエストを処理してデータの局所性を支援します発火）
PS、上記の質問のいずれかに答えられる場合でも、助けてください。