13

まず、概念的な質問があります。「分散」という言葉は、アプリケーションが複数のマシンで実行されることだけを意味するのでしょうか? または、アプリケーションが分散されていると見なすことができる他の方法があります (たとえば、多くの独立したモジュールが相互に作用しているが、同じマシン上にある場合、これは分散されていますか?)。

2 番目に、4 種類のタスクを実行するシステムを構築したいと考えています。複数の顧客が存在し、それぞれの顧客が各種類のタスクを定期的に実行する必要があります。例: customer1 は今日 task_type1 になり、2 日後に task_type2 になります。customer1 の task_type1 のように、task_type1 を同時に実行する customer2 がいる可能性があります。つまり、同時実行が必要です。タスクを実行するための構成は DB に保存され、これらのタスクの結果も DB に保存されます。顧客は Web ブラウザー (html ページ) からシステムを使用してシステムと対話します (基本的に、タスクを構成し、結果を確認します)。HTMLページが同時実行のためにスレッドと通信し、バックエンドでスレッドを使用する残りのWebサービス（JAX-RSを使用）を使用することを考えました。質問:

  1. これは簡単に聞こえますが、正しい方向に進んでいますか? または、たとえばJava Beansなどの他のテクノロジーまたは概念を使用する必要がありますか?

2.私のアプローチに問題がない場合、JSP などのスクリプト言語を使用する必要がありますか?それとも、html フォームを残りの URL に直接送信して結果を取得できますか (たとえば、JSON を使用)?

  1. アプリを配布したいのですが、私の考えで可能ですか？そうでない場合、何を使用する必要がありますか？

質問が多くて申し訳ありませんが、私はこれについて本当に混乱しています。

4

3 に答える 3

9

すでに投稿されている回答に1点追加したいだけです。私がこれまでに構築したすべてのWebアプリケーションは1台のサーバーでのみ実行されているため（アプリケーションを「配布」する可能性のあるHerokuにデプロイされたアプリケーションを除く）、一言で言ってください。

スケーラビリティのためにアプリケーションを配布する必要があると思われる場合、最初に考慮すべきことは、 Webサービス、マルチスレッド、メッセージキュー、EnterpriseJavaBeansなどではありません。

最初に考えることは、アプリケーションドメイン自体と、アプリケーションが何をするかです。CPUを集中的に使用する部品はどこにありますか？それらの部分の間にはどのような依存関係がありますか？システムの各部分は自然に並列プロセスに分解されますか？そうでない場合は、システムを再設計してそうすることができますか？重要：スレッド/プロセス間で共有する必要のあるデータは何ですか（同じマシンで実行されているか、異なるマシンで実行されているか）？

理想的な状況は、各並列スレッド/プロセス/サーバーが独自のデータチャンクを取得し、共有する必要なしにそれを処理できる場合です。さらに良いのは、システムの特定の部分をステートレスにすることができる場合です。ステートレスコードは（簡単かつ自然に）無限に並列化できます。並列プロセス間でデータを共有する頻度が高くなるほど、アプリケーションのスケーラビリティは低下します。極端な場合、アプリケーションを配布してもパフォーマンスが向上しない場合があります。（これはマルチスレッドコードで確認できます。スレッドが常に同じロックをめぐって競合する場合、プログラムは1つのスレッド+CPUよりも複数のスレッド+CPUの方が遅くなる可能性があります。）

実行する作業の概念的な内訳は、アプリケーションを配布するために実際に使用するツールや手法よりも重要です。概念的な内訳が適切であれば、1台のサーバーから始めると、後でアプリケーションを配布するのがはるかに簡単になります。

于 2012-07-05T08:51:37.040 に答える
5

「分散アプリケーション」という用語は、アプリケーション システムの一部が異なる計算ノード (異なるマシン上の異なる CPU/コア、または同じマシン上の複数の CPU/コア間) で実行されることを意味します。

システムをどのように構築できるかという問題には、さまざまな技術的解決策があります。あなたは Java テクノロジについて質問していたので、たとえば、Google の Web Toolkit を使用して Web アプリケーションを構築できます。これにより、リッチなブラウザ ベースのクライアント ユーザー エクスペリエンスが得られます。システムのサーバー展開部分については、Tomcat などのサーブレット コンテナーで実行される単純なサーブレットを使用して開始できます。サーブレットは、HTTP ベースのリモート プロシージャ コールを使用してブラウザから呼び出されます。

後でスケーラビリティの問題が発生した場合は、ビジネス ロジックの一部を EJB3 コンポーネントに移行し始めることができます。EJB3 コンポーネント自体は最終的に、Glassfish などのアプリケーション サーバーのコンテキスト内の多くの計算ノードにデプロイできます。実行するまで、この問題に取り組む必要はないと思います。顧客が実行するタスクの性質について、さらに詳しく知る必要があるかどうかを判断するのは困難です。

于 2012-07-05T03:08:27.473 に答える
4

最初の質問に答えるには、残りの URL に直接送信するフォームを取得できます。明らかに、それはあなたの要件に正確に依存します。

上記のコメントで @AlexD が述べたように、常にアプリケーションを配布する必要はありませんが、配布したい場合は、ほぼすべてのアプリケーションを実行できるメッセージング API であるJMSを検討することを検討する必要があります。ワーカー アプリケーション マシンの数、メッセージ キューからのメッセージの準備と処理。

たとえば、リソースの少ない複数の VM (Amazon EC2 Micro インスタンスなど) または物理ハードウェアで実行するために、動的に分散されたアプリケーションを作成したい場合は、必要に応じて自由に追加および削除できます。アプリケーションノードのクラスタリングを可能にする Java フレームワークであるProject Shoalと統合し、いつでも表示/非表示にすることを検討してください。Project Shoal は、基盤となる通信プロトコルとして JXTA と JGroups を使用します。

もう 1 つの方法は、アプリケーション サーバーで実行されているEJBを使用してアプリケーションを配布することです。

于 2012-07-05T03:17:05.243 に答える