3

私のサービスは DService で、サービス チェーンの 4 番目のリンクです。つまり、コール フローは、オンライン ユーザー -> AService -> BService -> CService -> DService -> EService です。

DService から EService を呼び出すと、HttpTimeoutException のような再試行可能な例外がスローされることがあります。私は通常、2 ～ 3 回再試行し、2 ～ 3 回再試行しても失敗した場合は例外をスローします。

私の質問は、私が CService にスローしている例外は、再試行可能または再試行不可である必要がありますか? 両方のオプションの長所と短所の私の評価を以下に見つけてください

DService から 再試行可能な例外をスローすることの短所 - DService が再試行可能な例外をスローした場合、同じ規則に従って、CService も DService を 2 ～ 3 回再試行し、CD の呼び出しごとに、D は E サービス呼び出しに対して 2 ～ 3 回再試行します。同様に、最終的に EService への呼び出しは、呼び出しチェーンを上るにつれて指数関数的に増加します。したがって、EService ネットワークが実際に長時間ダウンしていた場合、不要な呼び出しが多数発生していることになります。これは、チェーン内の各呼び出しにタイムアウトを設定することで軽減できますが、不要な数の呼び出しに対して十分な軽減策であるかどうかはまだわかりません.

DService から再試行可能な例外をスローすることの長所 - CService は、その後の再試行で正しい値が得られる可能性があるため (制限時間内に) しばらくしてから再試行します - 特にクライアントがバックエンド ジョブである場合、あきらめる前に指数関数的に長時間再試行できます。 . Un-Retriable 例外をスローすると、このオプションが取り除かれます

これについてあなたの意見や提案をお寄せください

ありがとう、ハリッシュ

4

4 に答える 4

3

DService が再試行するか、CService が再試行する必要があるかどうか、サービスが何をするかを知らなければ、はっきりとは言えません。ただし、私の哲学は、呼び出されるサービスが再試行されるサービスであってはならないということです。この場合、EService はばかげて例外をスローし、何も処理しません。この背後にある理由は、チェーンの最後はステートレスである必要があり、呼び出し元に代わって決定を下すべきではないためです。

呼び出し元は、エラーを再試行する必要があるかどうかについて、許容できるものとそうでないものの範囲内で、ある程度決定することができます。つまり、EService がデータベースへの接続を試み、DService がルックアップ サービスを実行している場合、DService の範囲内で、特定のテーブルに特定の情報が見つからない場合、チェックインすることができます。代わりに別のテーブル。ただし、EService によるデータベースへの接続の失敗は、CService によって要求された情報を返すことだけがスコープとなる DService の頭上を飛んでしまいます。

CService は、その動作に応じて、特定の情報を取得するための呼び出しを行った後、データベース接続を受信し、そのデータに対してバッチ処理を実行しているため、遅延後に何度も再試行を試みる場合があります。データベースがオンラインに戻りました。または、Web ページでユーザーに表示する情報を取得している場合は、すぐに失敗し、代わりに適切なエラー メッセージをユーザーに表示してデータベース接続エラーに対処する必要があります。

それは、サービスの機能とその責任がどこにあるかに完全に依存します。同様に、例外が再試行可能かどうかは、サービス自体ではなく、呼び出し元の必要性に依存する必要があります。一度だけ試行される再試行可能な例外を呼び出し元に提示することは完全に実行可能です。

それが役立つことを願っています!

于 2016-03-11T11:26:44.303 に答える
1

あなたが言うように、各サービスがそれを行うと、問題に直面する可能性があるため、そもそも DService で再試行しないでください。したがって、例外が呼び出しスタックをバブルアップさせ、可能な限り最も外側のサービスで処理されるようにします。ユーザーになることもできます。

理論的根拠: CService、BService、または AService が再試行するかどうかを決定するのが DService になるのはなぜですか?

ただし、例外の頻度やリトライの成功率にもよると思います。例外が頻繁に発生するが、呼び出しが通常 1 回目または 2 回目の再試行で成功する場合、それは 1 日に 1 回発生する例外とは別のものであり、再試行はほとんどの場合無駄です。

于 2016-03-11T11:22:51.793 に答える
1

インボーカーに何をスローするか、また、インボーカーにスローするものが「ただし、これを再試行できます」という提案も含むかどうかは、サービスの意図したセマンティクスによってのみ決定する必要があります。

(さらに、Java Exception オブジェクトがそのようなプロパティを正式に保持しているとは聞いたことがありませんが、それは私が少し遅れているためかもしれません。)

編集。

失敗した操作を「再試行」するかどうかは、あなた(そしてあなただけ) が決めることです。ただし、再試行することを決定した場合、何回失敗したら再試行を停止して 1 日で終了するかを決定するのもユーザーの責任です。その時点で、呼び出し元に例外をスローして、彼は「再試行」することもできます。

于 2016-03-11T11:26:02.673 に答える