0

私たちが持っているとしましょう

  • HTTP ゲートウェイ アウトバウンド サービスを使用するクライアント ノード
  • HTTP ゲートウェイ インバウンド サービスを備えたサーバー ノード

クライアントノードでMSMQ自体が何らかの理由で停止する状況を考えます。現在の実装では、Rebus HTTP ゲートウェイが例外をキャッチします。

キャッチするだけでなく、MessageQueueException 例外をサーバー ノードに送信してエラー キューに入れるというアイデアについてどう思いますか? (エラーキューの名前はヘッダーから収集できます)

したがって、追加のインフラストラクチャ サーバーがなければ、クライアントに問題があることがわかり、誰かが対応できるようになります。

アップデート：

回答に記載されている問題が発生すると思いました。私のシナリオをもっと詳しく説明するべきでした:)申し訳ありません。ここにあります：

InboundService がメッセージの送信と受信の両方を実行できるように、HTTP ゲートウェイを変更します。そのため、サーバーから新しいメッセージを取得してそのメッセージをサーバーに送信するために、接続を開始するのは OutboundService だけです (定期的に、たとえば 5 分に 1 回)。これは、クライアント ノードがサーバーではなく、NAT の背後にある多くのクライアントの 1 つと見なされるためです。

実際、サーバー自体はクライアントの状態には関心がありませんが、 HTTP ゲートウェイの HTTP ゲートウェイ コードを使用するクライアント側で個別のアラート サービスを作成する代わりに、HTTP ゲートウェイでこれを行うことができると思いました。サイドランニング。

クライアントがサーバーにまったく到達できない場合はどうなりますか?

MSMQ は死んでしまうので、私はhttp://ayende.com/blog/4540/building-a-managed-persistent-transactional-queueのようなインプロセスのスタンドアロンの永続的なキュー オブジェクトを使用することを考えました (単なる実装例です。サーバーに到達できるまでクライアント側で例外を集約するためのライセンスの種類がわからない）。

また、エラーが発生したことをクライアントがサーバーに通知する頻度は?

その部分についてはよくわかりません-5分に1回などのメッセージ同期のスケジュールされた時間に関連している可能性があると思いましたが、現在の実装（while（true）ループ）のようにスケジュールされた時間がない場合はどうなりますか？たぶん、configで設定できますか？

私はエラー処理について一貫した戦略を持ちたいと思っています。これには通常、単純な古い NLog ロギングが含まれます

クライアント ノードは、NAT 標準の監視技術の背後にあるインターネットにあるため、機能しません。キューを NLog トランスポートとして使用することを考えましたが、MSMQ が機能しなくなるため、機能しません。

HTTP を NLog トランスポートとして使用することも考えましたが、サーバー側ではキューが必要になるので (実際にはそうではありませんが、キューに格納したいと思います)、sbus と HTTP ゲートウェイに戻ります...そのような NLog トランスポートはHTTP ゲートウェイの事実上のクローンになります。

更新 2: NLog トランスポートとしての HTTP (トランスポートとはターゲットを意味します) には、「クライアントがサーバーにまったく到達できない場合はどうなりますか?」で説明したように、クライアント側のキューも必要になります。セクション。NLog に埋め込まれた HTTP ゲートウェイのクローンになります。狂気:)

すべてのことは、クライアントが信頼できないということです。そのため、サーバー側でクライアントに関するすべての情報を取得し、そこにログインしたいと考えています。

更新3

別の解決策として、別のサービスを作成することもできますが、これは HTTP ゲートウェイの一部になります (例: OutboundAlertService)。その後、次の 3 つの目標が達成されます。

  • 共有送信ループ コード
  • 追加のサーバー インフラストラクチャは不要
  • OutboundService に悪影響を与えません (インプロセス キューを追加する複雑さはありません)。

OutboundService から例外を受け取ることはありませんが、MSMQ 自体を定期的にチェックします。


さらに他の代替ソリューションは、MSMQ キュー以外を NLog ターゲットとして使用することですが、それは見苦しいやり過ぎです。

4

1 に答える 1

2

あなたのシナリオに関して、私の最初の考えは、クライアントに問題があるのはサーバーの問題であってはならないということです。そのため、クライアントが失敗したときにサーバーにメッセージを送信しないでしょう。

私が見ているように、そのアプローチには複数の問題/障害/課題があります。たとえば、クライアントがサーバーにまったく到達できない場合はどうなるでしょうか。また、エラーが発生したことをクライアントがサーバーに通知する頻度は?

もちろん、私はあなたのセットアップの詳細を知らないので、具体的なアドバイスをするのは難しいですが、一般的には、エラーの処理について一貫した戦略を持ちたいと思っています. Windows イベント ログ。

これにより、さまざまなツール (Service Center Operations Manager など) をセットアップして、すべてのマシンのイベント ログを監視し、問題が発生したときにエラー フラグを立てることができます。

私はあなたが使用できる何かを言ったことを願っています:)

アップデート

もう少し考えた後、私はあなたの問題を理解し始めていると思います。クライアントが相手側の HTTP リスナーに問題があることを知らせ、次に HTTP リスナーに知らせる解決策を好むと思います。反対側では（多分？）それをエラーとしてログに記録できます。

もう 1 つのオプションは、反対側の HTTP リスナーにイベントReceivedClientErrorまたは何かを持たせ、それにアタッチして、特定の状況で適切なことを行うことです。

あなたの場合、メッセージをエラーキューに入れるかもしれません。エラーキューの目的を混乱させると思うので、一般的な解決策としてエラーキューに何かを入れることは避けます-エラーキューの「もの」はメッセージではなく、再試行できませんなど.

于 2014-09-02T09:26:05.800 に答える