0

UI、ビジネスロジック、データベースなどのさまざまな層にコードを配布したいWebアプリケーションを構築しています。これが私の使用シナリオを説明する私の望ましい機能です：

  • リアルタイムの高性能要求/応答タイプのアプリケーション
  • UI、ビジネスロジック、データベースなどのさまざまなレイヤーに分割されるアプリケーション-各レイヤーはコンピューターのクラスターで動作します
  • レイヤーは、他の相互作用するレイヤーに対して透過的であることが望ましいロードバランシングおよびフェイルオーバー機能をサポートする必要があります。
  • 将来的にはさまざまな言語との相互運用性が追加の望ましい機能になります
  • これらのレイヤーは、組織自体の内部に存在します。つまり、現時点では、外部の組織サービスとやり取りするつもりはありません。

RMIを試しましたが、欠点はJavaロックインであり、負荷分散とフェイルオーバー機能がサポートされていませんでした。私はJMSを検討しましたが、負荷分散、MOMのフェイルオーバーなどの機能は非常に魅力的ですが、リアルタイムの要求/応答タイプのアプリケーションには適していないようです（間違っていると思われる場合は訂正してください）。

このユースケースのシナリオに最適な、人気のある適切なフレームワークを提案してください。

更新：
SOAを調べてみると、SOAPとRESTの2つの著名なオプションに出くわしました。私が述べたように、アプリケーションのモジュール/レイヤー間で内部的に使用する通信方法を選択する必要があります。迅速な要求/応答と高いスケーラビリティ、負荷分散、フェイルオーバーのシナリオを探すときに、それらの間で行うべき明白で人気のある選択はありますか？この投稿をRESTとSOAPの議論に変換するつもりはありませんが、この場合、簡単なライト比較が役立つ場合があります。私が見逃しているSOAにそれがあれば、私は3番目の選択肢も受け入れます。実際の展開シナリオからのいくつかの例も役立ちます。

4

2 に答える 2

2

リアルタイムと分散は、ちょっと反比例します。

はい、JMSベースのソリューションは非同期性に適していますが、リアルタイムには適していません。

分散SOAサ​​ービス（はい、Webサービス）ソリューションを想定している種類の実装には、適しているようです。負荷分散されたクラスター環境で実行されるサービスにより、高可用性が提供されます。必要なリアルタイムの量によって異なります。

とはいえ、外部とのやり取りの必要性が見当たらない場合は、アプリサーバーに1つのバンドルとしてデプロイされたui-service-dao/dalレイヤーを使用して直接デプロイを実行する方がリアルタイムです。セッションフェイルオーバーをサポートするクラスター化されたノードを使用して、負荷分散とフェイルオーバーを引き続き実現できます。これは相互運用性を提供しないかもしれませんが、本当に必要なときにそのラッパーを提供することができます。

于 2012-08-29T02:22:06.693 に答える
1

アーキテクチャ要件を掘り下げてみましょう。

  1. リアルタイムの高性能要求/応答タイプのアプリケーション

    • アプリケーションのレイテンシをほぼゼロにしようとしている場合は、memcachedなど、Webレイヤーの近くにあるほとんどすべてのものをキャッシュし、非同期で更新を延期または作成する必要があります。
    • RESTの使用も検討してください。これは、SOAPよりも必要なオーバーヘッドが少なく、JSONをドキュメント形式として使用できます。これはXMLよりもコンパクトであり、ネットワークスループット要件が低くなります。

  2. UI、ビジネスロジック、データベースなどのさまざまな層に分割されるアプリケーション-各層はコンピューターのクラスター上で動作します。

    • 使用する層が多いほど、アプリケーションのレイテンシーが大きくなる可能性があります。データベースは、ほとんどすべてのアーキテクチャで最もスケーラブルでないアイテムです。その場合、すべてのリクエストでデータベースにアクセスしないようにする必要があります。強力なキャッシュが必要になります。

  3. 層は、他の相互作用する層に対して透過的であることが望ましい負荷分散およびフェイルオーバー機能をサポートする必要があります。

    • サーバー間のセッション状態の同期は非常に高価であり、スティッキーセッションを使用したロードバランサーは単一のサーバーがクラッシュしたときに問題になるため、スケーラブル性とフェイルオーバーを向上させるには、サービスのステートレス性を追求する必要があります。
    • HTTPロードバランサーは非常に透過的です。

  4. 将来的にはさまざまな言語との相互運用性が追加の望ましい機能になります

    • SOAPには、すべての言語で十分にサポートされていない、より優れた機能があります。RESTを使用する場合は、おそらくここでより安全になります。通常、RESTインターフェースは、SOAPのWSDLよりも設計が簡単で、特定のテクノロジーへの依存度が低くなります。

  5. これらのレイヤーは、組織自体の内部に存在します。つまり、現時点では、外部の組織サービスとやり取りするつもりはありません。

    • サービスリポジトリ外の他のサービスとやり取りする場合は、標準を使用しない場合は、メッセージ変換を行う一種のゲートウェイ層が必要になる可能性があることを知っておく必要があります。
于 2012-08-29T11:34:11.427 に答える