SEDA: 条件の整ったスケーラブルなインターネット サービスのためのアーキテクチャ
「SEDA は、 staged event-driven Architectureの頭字語であり、複雑なイベント駆動型アプリケーションをキューで接続された一連のステージに分解します。」
これがアーキテクチャであり、SEDA には多くの実装があることを理解しています (ウィキペディアの記事を参照)。「ステージ」とは？ステージングされたイベント ドリブン アーキテクチャの概要と、従来の (ステージングされていない) イベント ドリブン アーキテクチャとの違いを誰かが詳しく説明してくれませんか?
ステージは「イベント」に似ています。考えを単純化するために、SEDA を、それらの間でメッセージを送信する一連のイベントと考えてください。
この種のアーキテクチャを使用する理由の 1 つは、ロジックを断片化し、それを接続して各イベントを切り離すことができるためです。これは主に、低レイテンシ要件の高性能サービスに適しています。
Java TPE を使用すると、各ステージの状態、スループット、エラー、レイテンシーを監視し、パフォーマンスのボトルネックがどこにあるかをすばやく見つけることができます。また、良い副作用として、コードの断片を小さくすることで、それらを簡単にテストし、コード カバレッジを増やすことができます (私の場合はそうでした)。
記録として、これは Cassandra (NoSQL) と Mule ESB (AFAIK) の内部アーキテクチャです。
元の論文を読むことをお勧めします（申し訳ありませんが、リンクが重複しています）：
Java EE の SEDA をモデル化するために作成したフレームワークを次に示します: http://code.google.com/p/seide/
ドキュメントはgithubで入手できます
ドキュメントで言及されている SEDA: 「SEDA 内の処理の基本単位はステージです。ステージは、イベント ハンドラー、着信イベント キュー、およびスレッド プールで構成される自己完結型のアプリケーション コンポーネントです...各ステージは管理されます。スケジューリングとスレッド割り当てに影響を与えるコントローラーによって. ステージ スレッドは、着信イベント キューからイベントのバッチを取り出し、アプリケーションが提供するイベント ハンドラーを呼び出すことによって動作します. イベント ハンドラーは、イベントの各バッチを処理し、0 個以上のイベントを他のステージのイベント キューにそれらをエンキューします。」
私にとっては、ステージをアプリケーション フローの論理的なモジュール化として設計できます。機能性、懸念事項の分離、パフォーマンス、運用と保守に基づいたものにすることができます。
添付の PDF を読んでいただきたいと思います。イベント キューを使用して要素を分離する必要性、コンポーネントの最大効率を達成するための論理的補完、ネットワーク、ストレージなどのアプリケーションが実行されている既存のリソースを効率的に再利用する方法について言及されています。 CPUサイクルなど
似ているように、組み立てラインの労働者が最初から最後まで何かを組み立てる一連の作業を行った場合、生産性が低下したという研究がありますが、彼らが孤立して単一の仕事をさせられ、部分的に組み立てられたユニットを次のグループに渡すと、一人一人が自分の仕事を効率的に管理できるようになりました。基本的に、何かを組み立てるフローは複数の段階に分割され、各段階またはそれらのグループが段階で作業する責任がありました。
ここで行われたのは、各個人またはグループのフレームワークと、ある個人/グループから別の個人/グループへの通信モードを有効にしてセットアップすることだけでした。これで、各個人/グループと、その周りに設定されたフレームワークをステージと比較できます。
SEDA にイベント ディメンションを追加するには、人物グループが互いにどのようにコミュニケーションするか、および関連するイベントの数について考えます。たとえば、ステージ 1 の担当者がステージを完了するためのナットとボルトを使い果たし、すぐにオーダー セクション マネージャーにナットとボルトについて通知したとします。注文課長は別のステージ 6 の担当者から、ナットとボルトが不足しているという同様の依頼を受けた可能性があります。今、彼はリクエストを中央のポイント (彼は SEDA のコントローラーのようなものです) で確認し、彼が保持しているすべてのエントリが配置されている注文のリクエスト (SEDA のキューのようなもの) がある Excel シートを確認します。 2 つの注文要求を送信する代わりに、それらを組み合わせて一度に注文します (SEDA でのスレッドおよびスケジュール管理)。
複数のコンポーネントがあり、さまざまなイベントを相互に送信し、それらを消費してそれに応じて動作するコントローラーを持っているソフトウェアアーキテクチャにそのようなメカニズムがある場合、おそらく非常に優れた段階的なイベント駆動型のセットアップが整っています。