インメモリ データ グリッド ベースのアプリケーションのサーバー側で Spring を使用することは賢明ですか?
私の直感では、低遅延の高性能システムではナンセンスだと思います。私の同僚は、Spring を含めることを主張しています。そのような包含の長所と短所は何ですか?
私の立場は、Spring はクライアントで使用しても問題ありませんが、サーバーには重すぎて、依存関係が多すぎて、考えるにはもう 1 つの漏れやすい抽象化であるということです。
インメモリ データ グリッド ベースのアプリケーションのサーバー側で Spring を使用することは賢明ですか?
私の直感では、低遅延の高性能システムではナンセンスだと思います。私の同僚は、Spring を含めることを主張しています。そのような包含の長所と短所は何ですか?
私の立場は、Spring はクライアントで使用しても問題ありませんが、サーバーには重すぎて、依存関係が多すぎて、考えるにはもう 1 つの漏れやすい抽象化であるということです。
一般に、データ グリッド システムはメモリと I/O を集中的に使用します。Spring を使用しても影響はありません (Spring は大量の Bean を作成すると主張するかもしれませんが、ガベージ コレクションを適切に調整すれば問題ありません)。
一方、Spring (またはその他の DI) を使用すると、コードの構造化とテストに役立ちます。
そのため、Data Grid システムに基づく何らかのサーバーの実装を使用している場合は、GC、OS のソケット (メモリ バッファとソケット メモリ) を適切に調整することに注意してください。これらは、DIを削減するよりもはるかに多くのメリットをもたらします.
まず、「リーキーな抽象化」というコメントに驚いています。これについて Spring を批判する人を聞いたことがありません。実際、それは正反対です。Spring は、データ グリッドなどのインフラストラクチャの実装の詳細をアプリケーション コードから取り除き、一貫性のある使い慣れたプログラミング モデルを提供することで、ビジネス ロジックに集中できるようにします。Spring は、構成とデータ グリッド (特に Gemfire) へのアクセスを強化するために多くのことを行い、通常、ランタイム オーバーヘッド自体を作成しません。Spring アプリケーションの初期化中に、Spring はリフレクションや AOP などのツールを内部で使用するため、アプリケーションの起動時間が長くなる可能性がありますが、これは実行時のパフォーマンスには影響しません。Spring は、多くの高スループットで低レイテンシーの本番アプリケーションで実証されています。極端な場合、
「Spring はあまりにも多くの依存関係をもたらします」はよくある不満ですが、誤りです。Spring は、実行する必要があることに対して、正確に適切な量の依存関係をもたらすと言えます。さらに、Spring Boot スターターとプラットフォーム BOM は依存関係管理を簡素化するために多くのことを行うため、バージョンの非互換性や共通の依存関係を明示的に宣言することについて心配する必要はありません。これについては、あなたの同僚の側に立つ必要があります。