6

現在、Linux ボックスで Java 統合アプリケーションを実行しています。まずはアプリ概要から。

Java アプリケーションはスタンドアロン アプリケーションです (OracleAS、WebLogic、JBOSS などの Java EE アプリケーション サーバーにはデプロイされません)。スタンドアロンとは、デスクトップ アプリケーションではないことを意味します。ただし、メイン クラスのコマンド ラインから実行されます。ユーザーはこのアプリケーションを直接操作しません。メッセージはAPIを使用してキューにダンプされ、24時間年中無休で実行されているアプリケーションによって読み取られます。ユーザーはデスクトップ アプリと直接対話しないため、これをデスクトップ アプリとは見なしません (これがデスクトップ アプリとして認定する正しい理由かどうかはわかりません)。

Spring を使用し、WebSphere MQ および Oracle データベースに接続します。WebSphere MQ のキューをリッスンする Spring リスナー (Spring Message Driven POJO) を使用します。キューにメッセージがあると、アプリケーションは MQ からメッセージを読み取り、それをデータベースにダンプ (挿入/更新) します。

問題は次のとおりです。

  1. このアプリケーションを水平方向にスケーリングするにはどうすればよいでしょうか? より多くのボックスを配置して、この同じアプリケーションの複数のインスタンスを実行するだけということですが、それは実行可能なアプローチですか?
  2. Spring MDP から EJB MDB への移行を検討する必要がありますか? これにより、アプリケーション サーバーにデプロイされます。そうすることで何か追加の利点はありますか？
  3. アプリケーションを高可用性 (HA) にする要求がありますか? スタンドアロン アプリケーションの HA を実現するために導入できる、推奨される方法論または戦略は何ですか?
4

6 に答える 6

2

データの需要が増加するにつれて、アプリケーションの水平方向のスケーリングは最終的に限界に達します。これらの制限は、負荷とサーバー/データベースのパフォーマンスによって決まります。ある時点で、スケーリングによって需要と負荷が増加した場合、サーバー/データベースの数も同様に増加する必要があります。保存されているデータに応じて、サーバー/データベースを複製して同期するか、何らかのハッシュ アルゴリズムを使用して複数のサーバーにデータを分割する必要があります。同期するデータ ソースの数を増やすと、それらのサーバーの複製/同期のコストも増加します。そのため、コストを最小限に抑えるには、ハッシュ化されたアプローチがより魅力的である可能性があります。

真の高可用性ソリューションは、実装に非常に費用がかかります。さまざまな程度の HA も見てきましたが、定義上、ダウンタイムが最小限またはまったくないこと、またはデータ ソースへのアクセスが失われることを意味します。これを実現するには、データ ソースの 1 つに障害が発生した場合でも、データにアクセスする機能を失うことなく、冗長ハードウェアを利用できる、多くの冗長ハードウェア、ネットワーク、およびソフトウェアが必要です。ハードウェア障害は避けられず、停電やその他のランダムな自然現象と同様に発生します。このデータの重要性に応じて、HA ソリューションには、複数の独立した電力網上に複数のデータ センターが必要になります。これは明らかに非常に高価になるため、このデータがエンドユーザーにとってどれほど重要であるかによって異なります。

したがって、HA は高価なアーキテクチャを必要とする極端なシナリオです。ほとんどの場合、ダウンタイムを最小限に抑えることに関心があることがわかりました。データ ソースのサイズによっては、データ ソースのホット スペアを追加することで、これをかなり安価に実現できます。

于 2009-02-18T15:41:16.970 に答える
2
  1. メッセージ駆動型アプリの水平スケーリングは簡単です...ほとんどの場合。同じキューで動作する別のメッセージ リスナーを確実に追加できます。ただし、メッセージの順序に微妙な依存関係がある可能性があるため、注意してください。プロセッサーが 1 つしかない場合は、現在は問題にならないかもしれませんが、複数のプロセッサーを使用すると、ある時点でメッセージが「順不同」に処理されることが保証されます。
  2. EJB MDP は、Spring MDB 以外には何も提供しません。機能しているものに固執します。
  3. プロセッサを水平方向にスケーリングすることから始めますが、これにはもう少し議論が必要です。

HA については、要件を明確にする必要があります。「高可用性」は、キューベースのアプリにとって興味深い質問です。アプリが数分間ダウンすると、メッセージがキューに山積みになります。アプリを再起動して実行できる限り、これらのメッセージは引き続き処理されますが、レイテンシが少し長くなります。おそらく、「メッセージの最大許容レイテンシーはどれくらいですか?」と尋ねる価値があります。

ハードウェアの障害、データセンターの喪失などに関する懸念事項がある可能性があります。これらは、同じ場所での水平スケーリングでは対処できません。キュー自体、プロセッサ、バックエンド データベース、およびそれらを接続するすべてのネットワーク ハードウェアなど、すべてのレイヤーですべてのコンポーネントを複製する必要があります。

これは費用のかかる提案であるため、「HA シナリオと非 HA シナリオの間のダウンタイムの年間損失予測のデルタは?」と尋ねることも価値があります。ALE には、直接損失と規制または法務コストの両方が組み込まれているため、ダウンタイムのコストを把握するのに適した方法です。

于 2009-03-15T17:24:39.460 に答える
1

「スタンドアロン」==「デスクトップ」ですか？

ユーザーは、メッセージ駆動型Beanを所有するコントローラーとどのように対話しますか？

あなたの質問に対する私の意見：

  1. それぞれが独自のスレッドで実行されるため、リスナープールにメッセージリスナーを追加することでスケーリングできます。データベース接続プールのサイズをメッセージリスナーに一致させる必要があるため、これも増やす必要があります。サーバーを追加する前にそれを行ってください。手元に十分なRAMがあることを確認してください。
  2. EJBMDBがSpringMDBを介して何を購入するのかわかりません。あなたは「アプリサーバー」を参照し続けます。具体的には、WebLogic、WebSphere、JBOSS、Glassfishな​​どのJava EEアプリサーバーを意味しますか？SpringをTomcatにデプロイしている場合、この会話ではTomcatを「アプリサーバー」と見なすためです。
  3. HAは、負荷分散とフェイルオーバーを意味します。同期されているか、ホットリデプロイ可能なデータベースが必要です。キューと同じです。F5は、負荷分散に最適なハードウェアソリューションです。インフラストラクチャの担当者がいる場合は、その担当者に相談します。
于 2009-02-18T14:33:55.383 に答える
0

複数のボックスを作成しようとしましたか? MQ のドキュメントが表示されると思いますか? 複数のボックスを実行するには、MQ でいくつかの構成が必要になる場合がありますが、ISA は実行されます

于 2009-07-08T14:52:28.483 に答える
0

.1. キューにさらに多くのリスナーを作成すると、コンシューマーの数をスケーリングできます。コンシューマーが停止しても、残りのコンシューマーは実行を続けることができます。注: MQ とデータベースには、高可用性ソリューションも必要です。

.2. あなたの場合、アプリケーションサーバーがどのような違いをもたらすかわかりません。おそらく、使用する予定の機能を説明できますか?

.3. HA については、1. に対する私の回答を参照してください。

于 2009-03-15T18:27:26.143 に答える