0

Web サービスをホストする Java でオーケストレーター システムを設計しています。要求に応じて、XML で記述されたフローを呼び出します。これは、次々に実行されるステップにすぎませんが、XML はユーザーにフローが何であるかを伝え、ユーザーはXML を変更してフローを変更することもできます。新しいサービスを追加して、それを XML に追加できます。しかし、設計している間、私は今、次のようなことで混乱しています.

  1. ブロッキング キューを使用してサービスを実行可能にし、エグゼキューターにスケジュールすることでサービスを常に有効にしておく必要があります。これにより、新しいリクエストが到着したときにリクエストがブロッキング キューにプッシュされ、サービスがそれを処理します。そして、異なるサービス間でメッセージ パッシング タスクを実行するメールボックスを作成します。

  2. サービスを実行可能にする代わりに、クラスをシングルトンにするSpring IOCを使用する必要があります。したがって、インスタンスは1つだけになり、リクエストをサービスメソッドに直接送信します。したがって、スレッドがないため、面倒なことはありません。また、メールボックスを実装する必要もありませんでした。

  3. nodejsやngnixのようにイベント駆動型システムがどのように高速であるかについて読んだので、disuptorフレームワークを使用してすべての着信リクエストをリングバッファーにプッシュし、リクエストの処理を開始するオーケストレーターにイベントを発行するハンドラーを作成して、また、オーケストレーターが完了すると、コールバックを使用して呼び出し元に応答を返すように、要求と共にコールバックを送信します。しかし、リクエストは同じタイプではないため、ディスラプター オブジェクトの割り当てを利用することはできません。

システムは、低遅延で最大のスループットを提供する必要があります。システムは、将来的に新しいサービス/フローを XML に追加するため、パフォーマンスに影響を与えずに新しいフローを採​​用する必要があります。私はJava 7のみを使用でき、Scalaは使用できないため、制限があります。

4

1 に答える 1

1

答え 1 はひどい考えです。サービスごとにスレッドを効果的に結び付けます。サービスの数がエグゼキュータ サービスをサポートするスレッドの数を超えると、即時の自動 DOS が発生します。さらに、サービスが相互に依存している場合...デッドロックする可能性のあるすべての方法。さらに、M (< N) しか実際に必要でない場合に N スレッドを使用することは非効率的です。

回答 #2: 提案されたフローが Request Parsing -> Dispatch -> Service Processing -> Callbacks である場合、コールバックが呼び出されたり、アプリケーションが DOS になったりするのを防ぐため、実際の「サービス」を汚さないように依存します。基本的に: サービスで例外が発生した場合はどうなりますか? それは、同じサービスや他のサービスへの今後のリクエストにも影響しますか?

また、並列処理の機会は、受信リクエストを処理するフレームワークの方法に限定されます。つまり、X リクエストがあり、フレームワークが本質的にそれらを連続して処理する場合、X リクエストのバックログが発生します。このようなシナリオでは、遅延要件を満たすのが難しい場合があります。

回答 #3: イベント ドリブン システムは確かに優れたアプローチです。スケジューラにジョブをエグゼキュータ サービスにファーム アウトさせて、システムがすべてのサービスの総負荷を動的に分散できるようにし、イベントを生成して反応するメカニズムを持たせ、イベントを処理します。制御フロー。これは、サービスの数が非常に多くなり、各「ジョブ」がかなりの量になる場合 (したがって、実行される実際の作業と比較して、スケジューリング/ディスパッチのオーバーヘッドが低くなります) に適しています。

于 2015-10-18T07:20:54.510 に答える