1分散システムが直面する問題
複数のマイクロサービス間でサービスアバランシェが呼び出された場合、マイクロサービスAがマイクロサービスBとマイクロサービスCを呼び出し、マイクロサービスBとマイクロサービスCが他のマイクロサービスを呼び出すと仮定します。これは「ファンアウト」と呼ばれます。発信リンク上のマイクロサービスの呼び出し応答時間が長すぎるか利用できないため、マイクロサービスAへの呼び出しがますます多くのシステムリソースを占有するため、システムがクラッシュします。いわゆる「アバランシェ効果」は高いトラフィックアプリケーションの場合、単一のバックエンド依存関係により、すべてのサーバー上のすべてのリソースが数秒で飽和状態になる可能性があります。障害よりも悪いことに、これらのアプリケーションは、サービス間の遅延の増加、バックアップキュー、スレッド、およびその他のシステムリソースへの負担を引き起こし、システム全体でより多くのカスケード障害を引き起こす可能性があります。これらはすべて、単一の依存関係の障害がアプリケーションまたはシステム全体をキャンセルできないように、障害と遅延を分離して管理する必要があることを示しています。したがって、通常、モジュールの下のインスタンスに障害が発生した場合、このモジュールはこの時点でもトラフィックを受信し、問題のあるモジュールは他のモジュールも呼び出すため、カスケード障害またはなだれが発生します。 。
2hystrixとは
Hystrixは、分散システムの遅延と障害耐性に対処するために使用されるオープンソースライブラリです。分散システムでは、タイムアウトや例外など、多くの依存関係の呼び出しに必然的に失敗します
。Hystrixは、依存関係の問題が発生した場合に、全体的なサービス障害につながることはありません。カスケード障害を回避して、分散システムの復元力を向上させます。
「サーキットブレーカー」自体は一種のスイッチングデバイスです。サービスユニットに障害が発生すると、サーキットブレーカーの障害監視（ヒューズの切れと同様）を通じて、
予期された処理可能な代替応答（FallBack）が呼び出し元に返されます。
長時間待機したり、呼び出し元が処理できない例外をスローしたりする代わりに、サービス呼び出し元のスレッドが
長時間不必要に占有されないようにすることで、分散システムでの障害の拡散、さらには雪崩を回避します。 。
何ができますか
https://github.com/Netflix/Hystrix/wiki/How-To-Use
1. 服务降级
2. 服务熔断
3. 实时监控
3サービスの低下、融合、電流制限の違い
サービスの低下
サーバーがビジーです。後でもう一度やり直してください。クライアントを待たせず、すぐにわかりやすいプロンプトを返します。フォールバック
どのような条件がダウングレードをトリガーしますか：
- タイムアウト
- 異常な
- ダウンタイム
- サービス融合
- スレッドプール/セマフォがいっぱいです
サービスブロー
ヒューズが閉じられ、開かれ、半開きになります。
类比保险丝达到最大服务访问后，直接拒绝访问，拉闸限电，
然后调用服务降级的方法并返回友好提示
服务的降级->进而熔断->恢复调用链路
サーキットブレーカーはどのような状況で機能し始めますか
回路ブレーカーに関連する3つの重要なパラメーター：スナップショット時間ウィンドウ、要求の総数のしきい値、およびエラー率のしきい値。
1：スナップショット時間ウィンドウ：回路ブレーカーがオンになっているかどうかを判断するには、いくつかの要求およびエラーデータをカウントする必要があります。統計時間範囲はスナップショット時間ウィンドウで、デフォルトでは最新の10秒です。
2：リクエストの総数のしきい値：スナップショットの時間枠内で、フュージングの対象となるには、リクエストの総数のしきい値を満たす必要があります。デフォルト値は20です。これは、hystrixコマンドの呼び出し回数が20回未満の場合、10秒以内に
すべての要求がタイムアウトしたり、その他の理由で失敗したりしても、回路ブレーカーが開かないことを意味します。
3：エラー率のしきい値：スナップショットの時間枠内にリクエストの総数がしきい値を超えた場合、たとえば30回の呼び出しが発生した場合、これらの30回の呼び出しのうち、15回のタイムアウト例外、つまり
50％を超えるエラーが発生しますパーセンテージ、デフォルト設定の50％しきい値では、この時点で回路ブレーカーが開きます。
サーキットブレーカの開閉条件
1. 当满足一定阀值的时候（默认10秒内超过20个请求次数）
2. 当失败率达到一定的时候（默认10秒内超过50%请求失败）
3. 到达以上阀值，断路器将会开启
4. 当开启的时候，所有请求都不会进行转发
5. 一段时间之后（默认是5秒），这个时候断路器是半开状态，会让其中一个请求进行转发。如果成功，断路器会关闭，若失败，继续开启。重复4和5
サーキットブレーカーをオンにした後
1:再有请求调用的时候，将不会调用主逻辑，而是直接调用降级fallback.通过断路器，实现了自动地发现错误并将降级逻辑切换为主逻辑，减少响
应延迟的效果。
2:原来的主逻辑要如何恢复呢?
对于这- -问题，hystrix也为我们实现了 自动恢复功能。
当断路器打开,对主逻辑进行熔断之后，
hystrix会启动一个休眠时间窗,在这个时间窗内,
降级逻辑是临时的成为主逻辑,
当休眠时间窗到期，断路器将进入半开状态,
释放一次请求到原来的主逻辑上,如果此次请求正常返回,
那么断路器将继续闭合,
主逻辑恢复，如果这次请求依然有问题，
断路器继续进入打开状态,休眠时间窗重新计时。
サービス電流制限
秒杀高并发等操作，严禁一窝蜂的过来拥挤，大家排队，一秒钟N个，有序进行
hystrixダッシュボード
除了隔离依赖服务的调用以外，Hystrix还提供 了准实时的调用监控(Hystrix Dashboard)，Hystrix会持续地记录所有通过Hystrix发
起的请求的执行信息，拟统计报表和图形的形式展示给用户，包括每秒执行多少请求多少成功，多少失败等。Netflix通过
hystrix-metrics-event-stream项目实现了对以上指标的监控。
Spring Cloud也提供了Hystrix Dashboard的整合，对监控内容转化成
可视化界面。