Javaを使用して拡張性の高いWebアプリケーションを構築する必要がある場合、どのフレームワークを使用しますか。その理由は何ですか。
私は、Thinking-in-java、Head Firstサーブレット、およびManningのSpring Frameworkの本を読んでいますが、実際には、高度にスケーラブルなアーキテクチャなどに焦点を当てたいと思います。
tomcat、hibernate、ehcacheを使用しますか？
（トラフィックタイプの応答を取得するときに心配することを探すのではなく、規模に合わせて設計する必要があると想定してください）
答えは、「スケーラブル」が何を意味するかによって異なります。多くは、実装するために選択したフレームワークではなく、アプリケーションに依存します。
どのフレームワークを選択しても、それを展開するハードウェアには、処理できる同時リクエスト数の上限があります。より多くのトラフィックを処理したい場合は、より多くのハードウェアを投入し、負荷分散などを含める必要があります.
その場合に関連する部分は、共有状態に関係しています。共有状態が多い場合は、スレッド セーフであること、必要に応じて「スティッキー」であること、クラスター全体でレプリケートされることなどを確認する必要があります。これはすべて、展開先のアプリ サーバーに関係します。フレームワークではなく、アプリの設計方法です。
Tomcat は「フレームワーク」ではなく、サーブレット/JSP エンジンです。クラスタリング機能を備えていますが、他のほとんどの Java EE アプリ サーバーも同様です。Spring をすでに選択している場合は、EJB がないことを意味するため、Tomcat を使用できます。Jetty、Resin、WebLogic、JBOSS、Glassfish - どれでも構いません。
あなたがすでにそれをよく知っているなら、春は良い選択です. Spring のイディオムに従うことで、アプリがレイヤー化され、アーキテクチャ的に健全である可能性が高くなると思いますが、スケーラビリティに関しては、それが決定的な要因ではありません。
Hibernate を使用すると開発作業が楽になりますが、データベースのスケーラビリティはスキーマやインデックスなどに大きく依存します。Hibernate は保証されません。
「スケーラブル」は、簡単に捨てられがちな包括的な用語 (「軽量」など) の 1 つですが、多くの考慮事項が含まれています。フレームワークの単純な選択が問題を完全に解決するかどうかはわかりません。
ApacheMinaをチェックします。ホームページから：
Apache MINAは、ユーザーが高性能でスケーラビリティの高いネットワークアプリケーションを簡単に開発できるようにするネットワークアプリケーションフレームワークです。これは、JavaNIOを介したTCP/IPやUDP/ IPなどのさまざまなトランスポートを介した抽象・イベント駆動型・非同期APIを提供します。
その上にHTTPエンジンAsyncWebが構築されています。
それほど過激ではない提案（！）は、パフォーマンスと小さなフットプリントを対象としたサーブレットコンテナであるJettyです。
私が主に注目する 2 つのキーワードは、AsynchronousとStatelessです。または、少なくとも「可能な限りステートレス: もちろん状態は必要ですが、本格的な RDBMS を使用する代わりに、ドキュメント中心のデータストアを検討してください。
async に関するAKKAと、データストアとしてのCouchDBまたはMongoDBをご覧ください...
フレームワークは、パフォーマンスではなく、開発のスピードアップを目的としています。必要のないユースケースを処理するため、フレームワークにはいくらかのオーバーヘッドがあります。確かに、オーバーヘッドは低く、ほとんどのフレームワークは拡張性が証明されているパターンを示しますが、それらのパターンはフレームワークなしでも使用できます。
したがって、「ベアメタル」、つまり純粋なサーブレット（はい、さらに低いレベルに行くこともできますが、独自のhttpソケットレイヤーを作成したくないと想定しています）、ストレートJDBCなどを想定してアーキテクチャを設計します.戻って、どのフレームワークがアーキテクチャに最も適しているかを判断し、開発をスピードアップし、オーバーヘッドを追加しすぎないようにしてください。Tomcat とその他のコンテナー、Hibernate とその他の ORM、Struts とその他の Web フレームワークの比較 - 重要なパフォーマンスのボトルネックについて間違った決定を下すと、どれも問題になりません。
ただし、より良いアプローチは、開発時間を最適化するフレームワークを選択し、ボトルネックを見つけて、発生したときにそれらに対処することです。そうしないと、決して発生しないケースに対して時期尚早に最適化して、車輪を回転させる可能性があります。しかし、それはおそらく「トラフィックが発生したときに心配する」というカテゴリに分類されます.
よく使われている最新のフレームワーク (および「スタック」) はすべて適切に作成されており、正しく使用すれば、パフォーマンスやスケーリングに脅威を与えることはありません。そのため、事前にスケーラビリティから始めるのではなく、要件に最適なスタックに注目してください。
特定の要件がある場合は、それについて質問し、それを処理するための最適な方法についての推奨事項を得ることができます。
魔法のように Web サービスをスケーラブルにするフレームワークはありません。
スケーラビリティの鍵は、ボトルネックになっている (またはボトルネックになる可能性がある) 機能を複製することです。サービスの作成に真剣に取り組んでいる場合は、アプリケーションの特性を十分に理解することから始める必要があります。したがって、ボトルネックがどこにある可能性が高いかを把握する必要があります。
次に、どの程度スケーラブルにするかを決定する必要があります。数百、数千、数百万の同時ユーザーをサポートする必要がありますか? (スケーラビリティの程度が異なると、異なるアーキテクチャと異なる実装アプローチが必要になります。)
これらのことを把握したら、サポートする必要があるレベルのトラフィックに対処できる既存のフレームワークがあるかどうかを判断します。そうでない場合は、問題のある領域でスケーラブルになるように独自のシステム アーキテクチャを設計する必要があります。
商用システムを使用できる場合は、Jazz Foundation ( http://jazz.net ) を参照することをお勧めします。これは、IBM Rational の新製品のベースです。このプロジェクトは、オープンソース化される前に IBM 内で Eclipse を開発した人々によって主導されています。プラグ可能な DB レイヤーを備え、複数のアプリケーション サーバーをサポートします。クラスタリングとマルチサイト タイプの展開を処理するように設計されています。OAuth サポートやライセンス管理などの優れた機能を備えています。
他の人がすでに答えているように、スケーラビリティは使用するフレームワークに関するものではありません。もちろん、各ノードからできるだけ多くのパフォーマンスを絞り出すのは良いことですが、理想的には、別のノードを追加してアプリケーションを直線的にスケーリングすることです。
アプリケーションは個別のレイヤーで設計する必要があります。これにより、アプリケーションのさまざまなレイヤーにより多くの機能を追加し、さまざまな階層化されたキャッシュを追加することもできます。キャッシングは、アーカイブ速度の鍵です。
大きな webapp のレイヤーの一例:
上記に加えて：
JMS (Java Message Service) をよく見てください。これは非常に過小評価されているテクノロジーです。TibCo EMS、Oracle などのベンダー ソリューションがありますが、Active MQ などの無料のスタックもあります。
JMS を使用すると、キューを使用して同期および非同期ソリューションを構築できます。永続キューまたは非永続キューを選択できます。