4

現在、CQRS ベースのプロジェクトをセットアップしています。各 Web プロジェクト インスタンスは NEventStore を実行しますが、すべて同じ EventStore 永続性 (基礎となるデータベース) を共有します。

ここで、保存されたイベントを発行したいと思います。ReadModel (Web プロジェクト インスタンスごとに 1 つ) だけでなく、追加のイベント コンシューマ (たとえば、システムから何らかの方法でイベントを通知する必要があるレガシー アプリケーションなど) にも発行します。もっと）。

したがって、x 個のイベント コンシューマー (= イベント ハンドラー) と y 個のイベント パブリッシャーがありますが、イベントの「実際のソース」は 1 つだけです (基になる EventStore データベース)。

Q1:パブリッシュ/サブスクライブを介してこれらのシステムを接続するためのベスト プラクティスはありますか?

NServiceBus を介して EventStore からイベントを発行することを考えました。すべてのコンシューマーは、必要なイベント タイプをサブスクライブする必要があります。したがって、各コンシューマーも、おそらく複数のパブリッシャーでサブスクライブする必要があります。Q2 : これは可能ですか? 複数の場所で同じイベントをサブスクライブできないことを読みました。次を参照してください: David Boike 「QueueName@WebServer1 で Message1 をサブスクライブすると、QueueName@WebServer2 からの Message1 をサブスクライブすることもできなくなります。」

その他の未解決の質問: Q3:コンシューマーが完全にシャットダウンされたことを検出する方法 (バスからのサブスクライブが正常に解除されていない場合)。-> キューがいっぱい!? これを、ネットワーク接続が少しだけ失われた状況と区別する方法は?

Q4:サブスクリプション サービスと EventStore の間の接続が不安定で失敗した場合はどうなりますか? コンシューマはサブスクリプション サービスに正常に登録されますが、EventStore は新しいサブスクリプションを認識せず、メッセージを配信しません...

Q5:一般に: NServiceBus はキューをどのように処理しますか? 消費者が長時間 (たとえば、数日) 連絡が取れない場合はどうなりますか?

4

1 に答える 1

2

Q1: メッセージの購読方法によって異なります。NServiceBus は、データを共有できないビジネス サービス (境界付けられたコンテキスト) があるという前提で構築されました。ただし、CQRS では、サブスクライバーが読み取りモデルに情報を保存できるように公開される、大量のデータを含むファット イベントがあります。この読み取りモデルは、ユーザー インターフェイスなどで使用されます。通常の UI または複合 UI (複数のビジネス サービスから情報を収集する) を介して。したがって、それはあなたが探しているものに依存します。

Q2: 複数のイベントにサブスクライブできます。ただし、イベントの論理パブリッシャーは 1 つだけです。したがって、イベント「CustomerWasBilled」は、ComponentA と ComponentB から発生することはありません。ただし、さまざまなイベントをサブスクライブできます。もちろん、各パブリッシャーはさまざまなサブスクライバーを持つことができます。

[Udi] 特定のパブリッシャーを複数のサーバーにスケールアウトすることができ、NServiceBus がそれを処理します。各マシンにサブスクライブする必要はありません。

Q3: これは純粋な行政だと思います。オンラインのままメッセージを受信すると、キューがいっぱいになります。永続的にダウン/オフラインにする必要があり、メッセージが処理されない場合は、コンポーネントがダウンした後すぐにわかります。ただし、どのサブスクライバーとパブリッシャーが相互に接続されているか、メッセージまたはコンポーネントを変更するとどうなるかを文書化することを強くお勧めします。

[Udi] 整然としたシャットダウンの場合は、配信停止を含める必要があります。それが一時的なクラッシュである場合は、標準の監視 (WMI) でそれを検出します。キューがいっぱいになるのを防ぐために、TimeToBeReceived 属性を使用してメッセージをいつ破棄するかを定義できます。

Q4: これは NServiceBus で処理されます。サブスクリプションは、SQL Server、RavenDB、InMemory などのデータストアに保存されます。ただし、サブスクリプションをメモリに保持し、新しいサブスクリプションが追加されたかどうかを定期的にチェックします。NServiceBus では問題になりません。

Q5: MSMQ は、それ自体で信頼性があります。もちろん、サーバー全体がクラッシュし、すべてのメッセージがフリーディングした HD にあった場合、それは問題です。コンポーネントに長時間アクセスできない場合、これが発生するかどうかは SLA に依存します。着信キューまたはエラー キューのメッセージ数を監視できます。DeadLetterQueue も忘れないでください。ただし、NServiceBus を使用すると、メッセージの処理にかかる時間を監視することもできます。

コンポーネントが長時間 (たとえば、数日) 到達できない場合、ビジネスは何をすべきかを決定する必要があります。メッセージが処理されることが重要な場合は、クラスタリングなどを導入してください。

お役に立てれば

于 2013-06-25T19:16:26.290 に答える