イベント駆動アーキテクチャのメリットとデメリット
Sal
inhouse_se イベント駆動型アーキテクチャスタイルは、非同期通信のみに依存するという点で、他のアーキテクチャスタイルに比べて独自の特徴を提供します。非同期通信は、システムの全体的な応答性を向上させるための強力な手法です。

イベント駆動アーキテクチャのメリットとデメリット

  1. 参考
  2. なぜイベント駆動アーキテクチャを採用するのか?
  3. イベント駆動アーキテクチャの構成
  4. イベント駆動アーキテクチャの概要
  5. イベント駆動アーキテクチャ - ブローカータイプ -
  6. ブローカータイプの構造
  7. ブローカータイプのメリット
  8. メディエイターパターンとは
  9. イベント駆動アーキテクチャのエラー処理
  10. イベント駆動アーキテクチャの総評
  11. 備考
## 参考
「FundamentalsOfSoftwareArchitecture.md」という記事を参考にしてます。 https://github.com/zhangjunhd/reading-notes/blob/master/software/FundamentalsOfSoftwareArchitecture.md#13service-based-architecture-style ちなみのこの記事は「ソフトウェアアーキテクチャの基礎」という書籍の関連資料である。
## なぜイベント駆動アーキテクチャを採用するのか?
イベント駆動型アーキテクチャスタイルは、非同期通信のみに依存するという点で、他のアーキテクチャスタイルに比べて独自の特徴を提供します。 非同期通信は、システムの全体的な応答性を向上させるための強力な手法です。 イベント駆動アーキテクチャは高度にスケーラブルで高パフォーマンスなアプリケーションを実現できる。 また、適応性に優れており、小規模なアプリにも大規模なアプリにも使うことができる
## イベント駆動アーキテクチャの構成
イベント駆動アーキテクチャは分散非同期型のアーキテクチャスタイルです。 このアーキテクチャを実装したアプリケーションは、いわゆる要求ベースのモデルに従います。 まずこのモデルではシステムに対して行われた要求は全て、要求オーケストレーターに送信されます。 リクエストオーケストレーターはユーザーインターフェイスですが、APIレイヤーとして実装することもでき、 主な役割はさまざまなリクエストプロセッサーにリクエストを同義的かつ同期的に送信することです。 要求プロセッサは、データベース内の情報を取得または更新して、要求を処理します。 以下にその図を示します。
## イベント駆動アーキテクチャの概要
イベント駆動アーキテクチャには、メディエータートポロジとブローカートポロジの2タイプがあります。 - メディエータートポロジは、イベントプロセスのワークフローを制御する必要がある場合に一般的に使用されます。 - ブローカートポロジは、イベントの処理に対して高度な応答性と動的制御を必要とする場合に使用されます。
## イベント駆動アーキテクチャ - ブローカータイプ -
ブローカートポロジは、中央イベントメディエーターがないという点でメディエータートポロジとは異なります。 よく使われるのは、 - オンラインオークションに入札するような単純なイベント - 転職や結婚などの健康給付システムにおけるより複雑なイベント などです。
## ブローカータイプの構造
開始イベントは、処理のためにイベントブローカーのイベントチャネルに送信されます。 イベントを管理および制御するブローカー・トポロジーでは、単一のイベント・プロセッサーがイベント・ブローカーからの開始イベントを受け入れ、そのイベントの処理を開始します。 開始イベントを受け入れたイベントプロセッサは、そのイベントの処理に関連する特定のタスクを実行し、処理イベントと呼ばれるものを作成することによって、システムの残りの部分にそれが行ったことを非同期的に連絡します。 この処理イベントは、必要に応じてさらに処理するためにイベントブローカーに非同期で送信されます。 他のイベントプロセッサは、処理イベントをリッスンし、何かを実行してそのイベントに反応し、新しい処理イベントを介して実行したことをアドバタイズします。 このプロセスは、最終的なイベントプロセッサが何をしたかに誰も興味がなくなるまで続きます。
## ブローカータイプのメリット
他のイベントプロセッサがそのアクションが何であるかを気にするかどうかに関係なく、各イベントプロセッサのブローカートポロジ内で、システムの残りの部分にそれが行ったことをアドバタイズすることはとても良い設計です。 なぜならこの方法は、そのイベントの処理に追加の機能が必要な場合に、アーキテクチャの拡張性を提供します。 ex) たとえば、複雑なイベントプロセスの一部として、電子メールが生成され、実行された特定のアクションを顧客に通知するとします。 通知イベントプロセッサは、電子メールを生成して送信し、トピックに送信された新しい処理イベントを通じて、そのアクションをシステムの残りの部分に連絡します。 ただし、この場合、他のイベントプロセッサはそのトピックに関するイベントをリッスンしていないため、メッセージは単に消えます。 これは、アーキテクチャの拡張性の良い例です。 無視されるメッセージを送信するリソースの浪費のように見えるかもしれませんが、そうではありません。 ex) 例えばここで、顧客に送信された電子メールを分析するための新しい要件が発生したとします。 この新しいイベントプロセッサは、インフラストラクチャを追加したり、他のイベントプロセッサに変更を適用したりすることないです。 電子メールトピックを介して新しいアナライザに電子メール情報を提供できるため、最小限の労力でシステム全体に追加できます。
## メディエイターパターンとは
イベントメディエーターは前節で説明したブローカートポロジーの欠点をいくつか解消できる。 イベントメディエーターパターンの中心には常に「イベントメディエーター」というコンポーネントが存在する。 このイベントメディエーターは、イベント処理に必要なステップのみを知っており、対応する処理イベントを生成してP2Pのメッセージング方式でイベントチャネルに送信する。 イベントチャネルは受け取ったメッセージをもとに処理を実施するが、完了した報告をイベントメディエーターに行う。
## イベント駆動アーキテクチャのエラー処理
コンポーネント同士で意思の疎通が取れない場合はどうすれば良いか。 それは以下のように、エラー時に通常のコンポーネントではなく、エラーを処理するコンポーネントに送ることで対応が可能である。 エラーを処理するコンポーネントでは、通常GUIとしてダッシュボードなどに表示される。 ダッシュボードにはエラーメッセージと、エラーを起こした処理が表示される。 このエラーを人間が手で修正し、再度エラーを起こしたコンポーネントに送信することで処理が可能である。
## イベント駆動アーキテクチャの総評
ワークフローの確実性と制御が必要な場合は、適切に構造化されたデータ駆動型のリクエスト(顧客プロファイルデータの取得など)に対してリクエストベースのモデルを選択することをお勧めします。 例えば、ECの注文処理など。 複雑で動的なユーザー処理を伴う、高レベルの応答性とスケールを必要とする柔軟なアクションベースのイベントには、イベントベースのモデルを選択しましょう。
## 備考
title:イベント駆動アーキテクチャのメリットとデメリット description:イベント駆動型アーキテクチャスタイルは、非同期通信のみに依存するという点で、他のアーキテクチャスタイルに比べて独自の特徴を提供します。非同期通信は、システムの全体的な応答性を向上させるための強力な手法です。 img:https://camo.githubusercontent.com/5fa13d62667b078243172113f9340d6658fa2f894f1339b90edc8cfb1f503963/68747470733a2f2f6c6561726e696e672e6f7265696c6c792e636f6d2f6c6962726172792f766965772f66756e64616d656e74616c732d6f662d736f6674776172652f393738313439323034333434372f6173736574732f666f73615f313430312e706e67 category_script:page_name.startswith("2")