3

いくつかの外部システム (FTP、SOAP-WS、REST-WS、トピック、キューなど...) 間の統合を行うために Camel を使用する予定です。

おそらくSpringの設定（Camel context XML）を利用することになり、情報量が多いのでTomcatのクラスタにデプロイする予定です。

それが可能な構成であり、両方のアプリケーション（最初は2つのTomcatであるとしましょう）が干渉する可能性がある場合、ドキュメントは見つかりませんでした。

アップデート

Camel を 3 年間使用した後、一部のケースでは非常にうまく管理されているように見えます: 「JMS」および Web サービス、これらのケースでは負荷分散がうまく機能しますが、「JMS」の場合、次の場合にメッセージの順序が失われます。ヘッダーは使用しませんJMSXGroupID。

ただし、ファイル (または FTP、sFTP、FTPS) から消費するサービスについては、まだ問題が残っています。現時点では、このソースから消費するレッグを 1 つだけアクティブにします。レッグがダウンした場合、残念ながら、FTP ファイルを消費するための 2 番目のレッグでのルートの自動開始はありません。

4

1 に答える 1

1

HTTP セッションに書き込みを行わない限り、何も気にする必要はありません。ロード バランサーの背後にいくつかの Tomcat ノードを配置するだけです。HTTP セッションに書き込む場合、それはまだ簡単ですが、おそらく (選択した構成に応じて) セッション レプリケーションを構成する必要があります。

私は、リクエストの負荷が高い状態で動作する 2 つの同様のシステム統合プロジェクトに取り組んできました。デプロイメント環境として、Apache サーバー (AJP コネクターを介して通信) と BigIP ロードバランサー (しばらくして Nginx に切り替えた後) の背後にあるクラスター化された Tomcat インスタンスを選択しました。

これらのアプリケーションはどちらも HTTP 要求を受け入れました。そのうちの 1 つは完全にステートレス (プロキシのような) で、もう 1 つはセッション固有の情報を保持する必要がありました。後者の場合、セッションに入れられるすべてのオブジェクトがシリアライズ可能であることを確認し、セッション レプリケーションを構成する必要がありました。

私たちは多くのテストを行い、最終的には戦闘で証明された DeltaManager、スティッキー セッションなし、同期レプリケーション モードに行き着きました。これは、システム アーキテクチャに応じて非常に慎重に検討する必要があるものですが、役立つ非常に優れたドキュメントがあります。

スティッキー セッションは使用しませんでした。これは、すべてのリクエストが大きな処理を必要とするためです。私たちが行ったテストと受信するリクエストの性質に基づいて、特定のクライアント セッションで同じサーバーに何度もアクセスするのではなく、ラウンド ロビン処理を行う方が適切でした。また、スティッキー セッションが有効になっていないため、同期レプリケーションを使用して、応答がクライアントに配信される前にすべてのノードが完全なセッションを受信するようにしていました (単一の要求のみがブロックされるため、心配する必要はありません)。セッションに巨大なオブジェクトを保存していなかったので (いくつかの重要な情報のみ)、セッションがデフォルトですべてのノードにレプリケートされることに問題はありません。ただし、それがボトルネックであることがわかった場合は、ノードの一部のサブセットをクラスターに配置して構成を調整できます。

于 2013-06-29T22:09:52.623 に答える