メモリ内のデータグリッドベースのアプリケーションのサーバー側でSpringを使用することは理にかなっていますか？メモリデータグリッドアプリケーションのスプリング
低遅延の高性能システムではナイスであると私には分かります。私の同僚はそれに春を含めることを主張しています。そのような包含の長所と短所は何ですか？
私の立場は、Springはクライアントで使用することはOKですが、サーバーにとっては重すぎることです。それはあまりにも多くの依存性をもたらし、思いつくためのもう一つの漏れやすい抽象です。
データグリッドシステムは一般的にメモリとI/O集約型です。 Springを使用しても影響はありません（Springは多くのBeanを作成しますが、適切なGarbage Collectionチューニングを行うと問題はありません）。
一方、Spring（または他のDI）を使用すると、コードを構造化してテストするのに役立ちます。
データグリッドシステムに基づく何らかのサーバーの実装を使用している場合は、OS（メモリバッファとソケットメモリ）のGC、ソケットを適切に調整することに注意してください。それらはあなたにDIを減らすより多くの利点を与えるでしょう。
まず、「漏れ抽象」のコメントに驚いています。私はこれを批判する人は誰も聞いたことがありません。実際、それはちょうど反対です。 Springは、アプリケーションコードからデータグリッドなどのインフラストラクチャの実装の詳細を削除し、一貫性のある使い慣れたプログラミングモデルを提供し、ビジネスロジックに集中することができます。 Springは、特にGemfireのようなデータグリッドの設定やアクセスを強化するために多くのことを行い、一般的にランタイムオーバーヘッド自体を作成しません。 Springアプリケーションの初期化中、SpringはリフレクションやAOPのようなツールを内部的に使用するため、アプリケーションの起動時間が長くなる可能性がありますが、これは実行時のパフォーマンスには影響しません。 Springは、多くの高スループット、低遅延生産アプリケーションで実証されています。極端な場合には、通常、ネットワークレイテンシやシリアル化などの外部からの懸念がパフォーマンスに影響を及ぼす最大の要因です。
「Springはあまりに多くの依存関係をもたらします」は一般的な苦情ですが、誤りです。私は、Springが必要とするものに対して正確な量の依存関係をもたらすと言います。さらに、SpringブートスターターとプラットフォームBOMは依存関係管理を簡素化するために多くのことを行います。したがって、バージョンの非互換性や共通の依存関係を明示的に宣言する必要はありません。私はあなたの同僚とこの面接をしなければなりません。