ブローカー型メッセージングシステムと非ブローカー型メッセージングシステムの利点と欠点 質問する

私は、さまざまなハードウェアやネットワークに合わせて分散、拡張、再構成できるモジュール式のリアルタイム監視および制御システムを設計しようとしています。

何らかの分散型エンタープライズ メッセージング システムが必要だという結論にすぐに達しました。しかし、世の中には多くの選択肢があり、それぞれに長所と短所があり、そのいくつかは異なるアーキテクチャを必要とします。ブローカー システムとブローカーレス システムのどちらが必要か、一部のシステム (RabbitMQ など) のメッセージの信頼性が必要か、ZeroMQ のようなシステムの軽量で高スループットが必要か、Kafka の「順番に到着」する高スループットが必要かを検討中です。

まず、これらのアーキテクチャは意味があるのでしょうか?

ZeroMQタイプの「ブローカーレス」システム:

ノート：

各「パート B」には複数の「パート A」があり、複数の「パート B」が「パート C」につながることもあります。

利点:

• 高スループット、低レイテンシ
• コンポーネントに簡単に統合でき、軽量なデプロイメント (ブローカーをデプロイする必要はありません)。

デメリット

• メッセージの配信は保証されません。一部はドロップされる可能性があります。これはオレンジ色で強調表示された領域で問題になる場合があります。GUIにとっては重要ではありませんが、ローカル制御モジュールが決定を下す場合は、かもしれないすべての情報が必要です。(よく考えてみると、最新の情報だけで十分でしょう。古いデータで決定を下しても意味がありません)。同様に、A と B の間のネットワークがダウンすると、ヒストリアンは不完全な履歴しか持たなくなります。しかし、これはどれほど重大なのでしょうか。
• 「検出」はありません。コンポーネント間の関係をさらに管理する必要があります。

RabbitMQ タイプのブローカー システム:

利点:

• メッセージの配信が保証されます。
• ブローカーを通じて管理される検出。

デメリット

• 非常に遅く、レイテンシが高い
• 展開と保守がさらに必要 (ブローカー/RabbitMQ はマシンにインストールする必要があり、モジュールに組み込まれているだけではありません)

  ---

中間のオプション:

Kafka を調べました。ブローカーなので、検出は自動的に行われます。ただし、RabbitMQ よりもはるかに軽量で、配信は保証されませんが (したがって、より高速で低遅延)、順序は維持されます。これは RabbitMQ では実行されません。また、メッセージをバッファリングするため、ネットワークに問題がある場合でもメッセージを取得できます。

これを書き出した後、保証された配信がどれほど重要であるかはわかりません。制御モジュールがメッセージを受信した場合、それが「古い」かどうかは問題ではありません。履歴担当者が完全な履歴を持っていれば素晴らしいのですが、それは必須でしょうか?

障害発生時にメッセージを保存するネットワーク通信用に、ZeroMQ に独自の「メッセージ バッファ」を実装することも選択肢の 1 つです。RabbitMQ よりも制御性が高く、信頼性の低い (ネットワーク経由) メッセージングに必要なときに実装できます。

当然ながら、これらの利点や欠点を比較検討するのが私の仕事です。私の質問は次のとおりです。他に考慮すべきことはありますか?そしてこれら 2 つのオプションのアーキテクチャは意味がありますか?

実装の大部分は C# で行う予定ですが、現時点ではメッセージング システムの経験はまったくありません。