Springアプリケーションコンテキストをスケーリングするにはどうすればよいですか？
私は現在、必要に応じてオンデマンドで動的にスケーリングする必要があるプロジェクトに取り組んでいます。
私の質問は、春のコンテキストのスケーリングについてです。私のWebアプリケーションには、クライアントアプリケーション（webapp、api）で使用する従来のマルチモジュールコア（サービス、永続性、ドメイン）があります。
ユーザーエンドアプリケーションはクラスター化でき、データベースもできますが、Springコンテキストの処理方法がわかりません。
私はScala SpringサービスでAkkaアクターを使用する予定ですが、アクターによって公開された1つのコンテキストを使用するソリューションには納得できません。アプリケーションの残りすべてはイベント駆動で構築されています手法（Springイベントはサービス層によって生成されます）。
ユーザーの役割（例：管理者、エンドユーザー）に応じてスケーリングするために、ユーザープロファイルごとにさまざまなwebappを既に構築しましたが、ビジネスオペレーション用のSpring Contextのみです。
質問：すべてのクライアントアプリケーションで共有される単一のコンテキストにマージする必要がありますか、それともアプリケーションごとに1つのコンテキストを初期化する必要がありますか？
ダイアグラムを理解するのは少し難しいです。左側のフロントエンドセクションはクライアントアプリケーションアーキテクチャ全体ですか？右のセクションはサーバー側ですか？それでも、フロントエンドにデータベースとスプリングレイヤーがある理由を理解できません。それは、各クライアントアプリケーションに対して一意にローカルなデータベースですか。
しかし、私の考えを言えば、Springアプリケーションコンテキストを使用する際の一般的な傾向は、それをシングルトンにして、サーバー側の1つのSpringコンテキストを意味するか、それがその本質であるか、またはその目的をすでに満たしていないことです。 Bean（サービスなど）はステートレスである必要があります。これにより、複数のクライアントが同じことを要求し、同じBean /サービスを使用する必要があるため、同時実行の問題が発生する可能性があるという望ましくない結果が生じないようにします。もちろん、それらをシングルトンにすることは、メモリを節約し、オンデマンドでのインスタンス作成を回避するための理想的な方法であり、使用後はガベージコレクションされます。ボトルネックは発生しませんが、代わりにオブジェクトがすでにメモリに読み込まれているため、実際にはより高速になり、一度呼び出されたオブジェクトを実行すると、各リクエストに独自のヒープが作成されます。つまり、基本的にシングルトンの方が高速で、より多くのメモリを節約できます。