5

Java での非同期 I/O の利点について、特にアプリケーション スタックの設計から詳細を探しています。

Node.js、Tornedo などのイベント ドリブン サーバーの例を数多く見つけました。

私が理解できなかったのは、JBoss または Weblogic アプリ サーバーを使用して Java EE でアプリケーション スタック全体を持っている人が、なぜイベント ドリブン アーキテクチャに移行するのかということです。

これらのサーバーでさえ、ノンブロッキング I/O をサポートしています。はい、彼らはリクエストごとにスレッドを割り当てていますが、スレッドプールを配置すると、リソースは良好なパフォーマンス パラメータの範囲内に収まるのではないでしょうか?

次の行に沿っていくつかの情報を提供してください。

  1. Apache-Tomcat/JBoss/Weblogic を使用した従来の Java EE アーキテクチャが、イベント駆動型アーキテクチャへの移行を検討する理由。
  2. イベント駆動型アーキテクチャは、デバイスに依存しない Web サイト/アプリケーションを提供するのに役立ちますか?
  3. クラウド上でアプリケーションを設計する場合、非同期 I/O を採用するでしょうか。
  4. イベント駆動型アーキテクチャのパフォーマンスは、従来の Java EE アーキテクチャよりも優れているのでしょうか、それとも神話ですか。
4

3 に答える 3

2

あなたが言及した重要な概念の1つは次のとおりです。

はい、リクエストごとにスレッドを割り当てています

目標が多数の同時ユーザーをサポートすることである場合、IO バウンド アプリでリクエストごとにスレッドを使用すると、最終的にスレッド プールが使い果たされることが何度も示されています。結局のところ、あなたが話している Node.js、Tornado などのフレームワークは、アプリケーションが何かが発生するのを待っている可能性が最も高く、CPU をまったく使用しない多数の同時ユーザーの処理に優れています。バインドされたタスクはまったくありません。言い換えれば、これらのツールは、オンライン ゲーム、チャットルーム、ロギング システム、通知システムなどのリアルタイム アプリを構築するのに最適です。主な目標は、小さなメッセージ パッシングを多くのユーザーとできるだけ早く調整することです。

実際、これらのツールは、リアルタイムまたはほぼリアルタイムのエクスペリエンスをユーザーに提供することを目的としているため、Websocket ベースのアプリケーションの作成に最適です。

多くの企業が最初からこれらのプラットフォームを利用しているのは事実ですが、従来のスタックを使用している企業では、イベント駆動型ツールをシステムの補足として使用することがより一般的だと思います. node.js や Tornado のようなものを使用すると、独自の API やドライバーをロールバックすることを優先して、依存している多くの組み込みソフトウェアをあきらめることに気付くかもしれません。node.js はかなり前から存在しており、実際にはデータベース、nosql プラットフォーム、およびビルドシステムに接続するための優れたサポートが多数ありますが、そこに到達するまでにはしばらく時間がかかりました。

実験として、リクエストごとに 1 つのスレッドを使用する単純な tcp チャット アプリケーションを作成して、サポートできるユーザー数を確認してください。最終的には、起動できる OS スレッドの数が制限に達しますが、これは非常に高価です。

次に、デフォルト スレッドである 1 つのスレッドだけを使用して、node.js でどこまで到達できるかを確認します。1 秒間に非常に多くの同時リクエストをサポートできることがわかります。スレッドによって制限されていないため、数百万にスケールすることが知られています。メモリ、ファイル記述子の数、およびその時点での CPU によってのみ制限されます。

あなたの質問にできる限り答えるために：

  1. node.js とイベント ドリブン アーキテクチャがいかに優れているかを聞いたからといって、単にプラットフォーム全体を捨てることは現実的ではないと思います。IO バウンドの高度な並行アプリケーションを構築する必要がある場合は、自問する必要があります。もしそうなら、既存のスタックを補完するためにそれを使用してみませんか?
  2. 2 番目の質問についてはよくわかりませんが、デバイスとはどういう意味ですか?
  3. イベント ドリブン アーキテクチャを使用するのと同じように、従来のツールに基づいてクラウドで優れたアプリケーションを構築できます。それが「クラウド」アプリケーションである可能性があるという事実は、プラットフォームの選択とはまったく関係ありません。
  4. パフォーマンスよりも規模の問題だと思います。同じコードを実行する Java アプリよりも、node.js アプリの実行速度が遅い、または速い場合があります。しかし、node.js でできることは、前述のスレッド制限に達することがないため、はるかに高いスループットを可能にすることです。また、これは、ブロックしない適切なイベント駆動型アプリケーションを構築したことを意味します。ブロックすると、システム全体がダウンします。
于 2013-08-15T18:59:54.317 に答える
1

私はそれが基礎となる実装とそれがもたらすオーバーヘッドの掘り出し物についてもっと考えています：

リクエストを処理するための新しい専用スレッドのスピン。各スレッドはブロッキング I/O を行います。ただし、スレッドレベルでそのような同時実行を管理するのは面倒です。

対

応答性を維持し、将来的に処理することを約束する 1 つのスレッドを使用します。I/O の実行中にブロックしません。スレッド レベルでの同時実行管理は必要ありません。OSにそれを処理させます。

Apache-Tomcat/JBoss/Weblogic を使用した従来の Java EE アーキテクチャがイベント駆動型アーキテクチャへの移行を検討する理由。

おそらく彼らはあまりにも一般的で重いソリューションにうんざりしていて、新しい軽量の代替案をチェックしたいと思っているのでしょう。これらの代替手段は、開発と展開が非常に簡単で、非常にうまく拡張できます。

イベント駆動型アーキテクチャは、デバイスに依存しない Web サイト/アプリケーションを提供するのに役立ちますか?

これらはあまり関係ないと思います。同じ JVM で複数の言語を実行できます。これは、複数のホストで実行し、デバイスに依存しない機能をもたらす標準 API を公開する JVM の機能です。もう 1 つの例は、Web ブラウザーです。

クラウド上でアプリケーションを設計する場合、非同期 I/O を使用しますか。

要件によります。非同期 I/O がすべての問題を解決するわけではありません。ただし、簡単に作成でき、迅速に拡張できるソリューションを探している場合は、役立つかもしれません。制限が厳しい新しいスタートアップに適しています。

イベント駆動型アーキテクチャのパフォーマンスは、従来の Java EE アーキテクチャよりも優れているのでしょうか、それとも神話ですか。

ビジネスの要件に合わせて調整された、いくつかの優れたベンチマークを使用してパフォーマンスをより適切にテストします。

于 2013-08-15T19:11:19.133 に答える