0

次のアーキテクチャを持つまったく新しいアプリケーションを考えています

ディーラー <--> ネットワーク <--> イシュア

1) ディーラーは注文を出し、2) ネットワークはそれらを基本的な健全性のために処理し、処理のために発行者に渡します。3) 発行者はそれらを処理し、4) それらをネットワークに送り返します (ログを記録します)。ディーラーに戻します。

キューを使った実装を考えています。現時点では、JMS に関する私の知識は限られています。500 以上のディーラーがあったかどうか (たとえば、500 以上の受信キュー (各ディーラーからの受信メッセージごとに 1 つ) と、同じ数の送信キュー (ネットワークから各ディーラーへの送信メッセージごとに 1 つ) を持つことができますか?) .

発行者側でも同じことが繰り返されます。発行者が 50 人いるとしましょう (つまり、50 + その側の 50 キュー、合計 600 キュー)

このようなアーキテクチャは実用的であり、現在の種類の JEE5 アプリケーション サーバーでサポートされていますか? 上記のように、JEE5 サーバーのような通常の JMS プロバイダーで実現できる場合、websphere MQ のような重い MQ 実装を導入したくありませんか?

前もってthx、ルーバン

4

1 に答える 1

1

500以上のキュー？ああ、私の。それが不可能だと言うことは何も見つかりませんが、せいぜい維持するのは非常に難しいでしょう。

ディーラーがあなたのネットワークの外にいる場合、彼らはHTTP経由であなたに接続するだろうと想像するので、ディーラーごとの入力キューはなくなります。着信要求を処理するために、HTTPリスナーをクラスター化する必要があります。

ディーラーごとにメッセージ駆動型Beanのプールができる可能性がありますが、キュー/ MDBペアごとに1MBであっても、キューを作成するためだけに0.5〜1GBが必要になることを意味します。これは、JavaEEアプリサーバーの他のすべての要件に加えて行われます。

私には構成/管理の悪夢のように聞こえます。

なぜキューが必要だと思いますか？あなたを惹きつけるのは、「保証付き配信」、信頼性、非同期処理などですか？

各ディーラーが独自のキューを必要とするのはなぜですか？ディーラーごとに処理が異なりますか？

ディーラーごとにどのようなメッセージ量を観察しましたか？どんな成長が期待できますか？各メッセージの大きさはどれくらいですか？メッセージのペイロードは何ですか-XML、JSON、または他のもの？

このルートをとる前に、いくつかの選択肢を検討したことを確認しましたが、いずれもキューは必要ありませんでした。疑わしいと思います。

于 2011-04-13T02:19:42.623 に答える