Hystrix：カスタムサーキットブレーカーとリカバリロジック
Hystrix ガイドを読んで、デフォルトの回路ブレーカーと回復期間がどのように動作するか、そしてそれらの動作をカスタマイズする方法について頭を悩ませようとしています。
明らかに、回路がトリップした場合、HystrixはコマンドのgetFallBack()メソッドを自動的に呼び出します。これだけ理解しています。しかし、そもそも回路をトリップさせるにはどのような基準がありますか？理想的には、サービスがオフライン/異常であると見なして回路ブレーカーを作動させる前に、バッキングサービスを数回（たとえば、最大3回）ヒットしてみてください。 これをどのように実装できますか？
ただし、デフォルトの回路ブレーカーをオーバーライドする場合は、デフォルトの回復期間を処理するメカニズムもオーバーライドする必要があると思います。バッキングサービスがダウンした場合、次のいずれかの理由が考えられます。
- クライアントとサーバーの間にネットワークの停止があります
- サービスは、クライアントに有効な応答を返すことができないバグでデプロイされました
- クライアントは、サーバーに有効なリクエストを送信できなくなるバグでデプロイされました
- いくつかの奇妙な瞬間的なサービスの一時的な中断（おそらく、サービスは大規模なガベージコレクションを行っているなど）
- 等.
これらのほとんどの場合、[〜＃〜] n [〜＃〜]秒待ってから再試行するだけの回復期間を設けるだけでは不十分です。サービスにバグがある場合、または誰かがデータセンターでネットワークケーブルを引っ張った場合、常にこのサービスから障害が発生します。ごく少数の場合にのみ、クライアントサービスは人間の介入なしに自動的に自己修復します。
したがって、次の質問は部分的に「デフォルトのリカバリ期間戦略をカスタマイズするにはどうすればよいですか？」だと思いますが、主に「サービスがダウンして手動介入が必要な場合にHystrixを使用してDevOpsに通知するにはどうすればよいですか？ "
hystrixがフォールバックメソッドを呼び出す理由は基本的に4つあります：例外、タイムアウト、並列リクエストが多すぎる、または前の呼び出しでの例外が多すぎる。
サービスから受け取った戻りコードまたは例外が再試行に意味があることを示している場合は、run（）メソッドで再試行することをお勧めします。
コマンドのフォールバックメソッドでは、タイムアウトが発生したときに再試行する場合があります。並列リクエストが多すぎたり、例外が多すぎたりすると、通常、同じサービスを再度呼び出すことは意味がありません。
また、質問されたようにdevopsに通知する方法：サーキットブレーカーのステータスと成功した呼び出しと失敗した呼び出しの比率をポーリングする監視システムをHystrixに接続する必要があります。 metrics Publishers 提供のJMXを使用するか、HystrixのAPIを使用して独自のアダプターを作成できます。リーマンとZabbix用の2つのアダプターを 私が準備したチュートリアル ;で作成しました。そのためのコードは数行で新しくなります。
チュートリアルには、いくつかのシナリオを試すためのサンプルアプリケーションとロードドライバーも含まれています。
Br、アレクサンダー。