サーキットブレーカーはどこに行くべきですか?

Aug 18 2020

私は新しいRESTAPIを開発していて、いくつかのプロジェクトがサーキットブレーカーをに配置しているのを見てきましたController。以前はに配置していましたDAO

私が言える最初の違いは、DAOこのサードパーティを消費するすべてのサービスがエラーシナリオで開かれるということです。そして、それをに配置すると、Controller最終的に、このサードパーティを消費するすべてのルートが開かれます。すぐにはなりません。しかし、(のController)2番目の選択肢は維持するのが簡単なようです。

どこに行くべきかについての推奨事項はありますか?

回答

3 Christophe Aug 19 2020 at 17:02

この答えには2つの部分があります。最初の部分は、すでにによって対処されたロバート・ハーヴェイの彼のコメントで:

  • クリスリチャードソンのマイクロサービスパターンのカタログによると、サーキットブレーカーはリモートサービスのプロキシにある必要があります。APIGatewayはそのための良い場所です。
  • 別の代替手段は、サーバー側の検出です。特に、回復戦略が同じサービスの他の実行中のインスタンスの検索を意​​味する場合はそうです。

しかし、2番目の部分があります。サーキットブレーカーの目標は、サービスが利用できないことが検出された場合に迅速に失敗することであり、後で失敗して多くのフラストレーションを生み出すステップを蓄積することではありません。したがって、回路ブレーカーは、消費サービスがブレークに対応する準備ができている場合にのみ完全に理解されます。

  • おそらく、リモートサービスが不可欠であり、消費サービスはそれ自体を保留にすることを決定する可能性があります(つまり、内部回路ブレーカー)。
  • リモートサービスは必須ではなく、消費サービスはサービスを継続することを決定する可能性がありますが、劣化モードになります。
  • (サービス検出ベースのブレーカーはおそらく失敗しませんが、別の機能するサービスを見つけ、消費者は気付かないでしょう)。

一般的な観点から、動作におけるこの種の選択はコントローラーの責任です。コントローラーはサービスの要素間を調整し、「失敗」情報に基づいて処理を適応させることができます。

ただし、あなたの場合、それは他の場所からデータを取得することだけであり、エラー処理戦略が常に同じである場合(必須と非必須の違いはありません。たとえば、利用可能な場合はキャッシュされた値を使用し、それ以外の場合は失敗します)。それをdaoimhoに入れることを完全にうまく決めることができました。