11

ServiceMix 3.3.1 / Camel 2.1 /AMQ5.3アプリケーションをクラスタリングするためのオプションを決定しようとしています。大量のメッセージ処理を実行していますが、高可用性と水平方向のスケーラビリティを実現するためにクラスター化する必要があります。

これが基本的に私のアプリケーションが行うことです...HTTP->QUEUE-> PROCESS-> DATABASE-> TOPIC

from（ "jetty： http: //0.0.0.0/inbound "）.to（ "activemq：inboundQueue"）;

from（ "activemq：inboundQueue？maxConcurrentConsumers = 50"）.process（decode（））.process（transform（））.process（validate（））.process（saveToDatabase（））.to（ "activemq：topic：ouboundTopic" ）;

したがって、ServiceMixとAcitveMQのクラスタリングページをすべて読みましたが、どちらに進むべきかまだわかりません。

HAにマスター/スレーブセットアップを使用できることは知っていますが、それはスケーラビリティには役立ちません。

ブローカーのネットワークについて読みましたが、これがどのように適用されるかわかりません。たとえば、クラスター内の複数のノードに同一のCamelルートをデプロイした場合、それらはどのように正確に「相互作用」しますか？HTTPプロデューサーを1つのノード（NodeA）に向けると、どのメッセージがNodeBに送信されますか？キュー/トピックはノードA/B間で共有されますか？共有される場合、メッセージは分割または複製されますか？また、外部クライアントはどのようにして私の「outboundTopic」を正確にサブスクライブしますか（そしてすべてのメッセージなどを取得しますか）？

あるいは、複数のServiceMixインスタンス間でブローカーを共有するだけでよいと考えていました。管理するキュー/トピックのセットが1つしかないという点で、これはよりクリーンであり、インスタンスを追加することで拡張できます。しかし、今では単一のブローカーのスケーラビリティに制限されており、単一障害点に戻っています...

誰かが私にとってのトレードオフを明確にすることができれば...私はそれをいただければ幸いです。

4

1 に答える 1

10

ServiceMix / Camel / ActiveMQを使用している場合、スケールアップするための複数の戦略があります。ソフトウェアの各部分は非常に多くのオプションを提供するため、アプリのどの部分をスケーリングする必要があるかに応じて、さまざまなパスをたどることができます。以下は、いくつかの戦略の概要です。

  • インバウンドJettyインスタンスの数を増やす-これには、Webサーバーのインスタンスをさらに起動し、複数のインスタンス間でリクエストを負荷分散するか、複数のURLを公開して、ActiveMQの同じインバウンドキューにすべてのリクエストを送信する必要があります。

  • ActiveMQインスタンスの数を増やす-追加のActiveMQインスタンスを起動し、それらをネットワーク化することで、ブローカーのネットワークを作成します。一部のサークルでは、これを分散キューと呼びます。これは、特定のキューをネットワーク内のすべてのブローカーで使用できるようにするためです。ただし、ActiveMQの複数のインスタンスを起動する場合は、ServiceMixの追加のインスタンスを起動することを検討する必要があります。

  • ServiceMixインスタンスの数を増やす-ServiceMixの各インスタンスには、ActiveMQのインスタンスが埋め込まれています。ServiceMixのインスタンスの数を増やすことで、ActiveMQインスタンス（ブローカーのネットワークを形成するためにネットワーク化できる）の数を増やすだけでなく、ServiceMixのこれらのインスタンス全体にアプリケーションのコピーをさらにデプロイすることができます。 。ActiveMQまたはServiceMixインスタンスの数を増やす必要がある場合は、インスタンスごとに適切な数の同時コンシューマーを使用して、消費するアプリケーションをデプロイできます。メッセージは分割または複製されず、消費者の需要に基づいて、場所に関係なく、キュー上のすべての消費者にラウンドロビン方式で配信されます。つまり、ネットワーク内の1つのActiveMQインスタンスにコンシューマーがない場合、消費されるキューのインスタンスにメッセージがあります。これは私の最後の提案につながり、インバウンドキューをポーリングするコンシューマーの数を増やします。

  • インバウンドキューのJMSコンシューマーの数を増やす-これは、スループットを向上させるための、おそらく最も簡単で、最も強力で、最も管理しやすい方法です。消費するアプリケーションの追加のインスタンスをデプロイして、インバウンドキューからのメッセージを競合するようにするため、最も簡単です（ローカルキューと競合するか、ブローカーのネットワークを介して分散されるキューと競合するかは関係ありません）。これは、同時コンシューマーの数を増やすのと同じくらい簡単な場合もあれば、コンシューマーを含むアプリケーションの部分を分割してServiceMixの多くのインスタンスにデプロイすることによってもう少し複雑にする場合もあります。通常は難しくなく、イベント駆動型アプリケーションのスケーリングは常にコンシューマーの数を増やすことによって行われるため、これは最も強力です。それ'

この最後の提案は、アプリケーションをスケーリングするための最も強力な方法です。着信HTTPエンドポイントが大量のトラフィックを処理できる限り、インバウンドキューのコンシューマーを増やすだけで済みます。これを行う大きな理由は、消費者または彼らが引き渡すBeanのいずれかが、処理と検証の大部分であるすべての面倒な作業を行っていることです。通常、最終的に最も多くのリソースを必要とするのはこのプロセスです。

うまくいけば、これにより、アプリのどの部分を実際にスケーリングする必要があるかに応じて、一方向、または場合によってはいくつかの方向に進むために必要な情報が提供されます。ご不明な点がございましたら、お気軽にお問い合わせください。

ブルース

于 2010-02-09T04:12:00.193 に答える