マイクロサービスのフォールト トレランス Resilience4j フォールト トレランスの原理
4.1 マイクロサービス フォールト トレランスの概要
天猫ダブル11のような同時アクセスが多い状態では、トラフィックが流入し続け、サービス間の相互呼び出しの頻度が急激に増加し、システムの負荷が高くなりすぎるため、システムが依存するサービスの安定性が低下します。システムへの影響その影響は非常に大きく、ネットワーク接続の中断やサービスのダウンタイムなど、雪崩を引き起こす不確実な要因が多くあります。一般的なマイクロサービス フォールト トレラント コンポーネントは、電流制限、絶縁、劣化、回路ブレーカーなどの方法を提供し、マイクロサービス システムを効果的に保護できます。
4.1.1 隔離
マイクロサービス システム A は B を呼び出し、B は C を呼び出します。C が失敗すると、B を呼び出す多数のスレッド リソースがブロックされます。CPU が 100% に使い果たされるまで、B のスレッドの数はゆっくりと増加し続けます。マイクロサービス全体が利用できなくなると、利用できないサービスを分離する必要があります。
4.1.1.1. スレッドプールの分離
スレッド プールの分離は Java スレッド プールによって実現されます。サービス B はサービス C を呼び出し、固定数のスレッド (12 スレッドなど) を割り当てられます。この時点でサービス C がダウンしている場合、たとえ多数のリクエストが届いたとしても、サービスはサービス C を呼び出します。 C が呼び出されます。インターフェイスは 12 スレッドのみを占有し、他のワーカー スレッド リソースを占有しないため、サービス B にはカスケード障害が発生しません。スレッド プール分離の原理を図 4-2 に示します。
4.1.1.2. セマフォの分離
隔离信号量隔离是使⽤Semaphore来实现的，当拿不到信号量的时候直接拒接因此不会出现超时占⽤其他⼯作线程的情况。代码如下。
Semaphore semaphore = new Semaphore(10,true);
//获取信号量
semaphore.acquire();
//do something here
//释放信号量
semaphore.release();
4.1.1.3. スレッドプール分離とセマフォ分離の違い
线程池隔离针对不同的资源分别创建不同的线程池，不同服务调⽤都发⽣在不同的线程池中，在线程池排队、超时等阻塞情况时可以快速失败。线程池隔离的好处是隔离度⽐较⾼，可以针对某个资源的线程池去进⾏处理⽽不影响其它资源，但是代价就是线程上下⽂切换的 overhead ⽐较⼤，特别是对低延时的调⽤有⽐较⼤的影响。⽽信号量隔离⾮常轻量级，仅限制对某个资源调⽤的并发数，⽽不是显式地去创建线程池，所以 overhead ⽐较⼩，但是效果不错，也⽀持超时失败。
| カテゴリー | スレッドプールの分離 | セマフォの分離 |
| 糸 | 呼び出しスレッドとは異なり、スレッドプールによって作成されたスレッドが使用されます。 | スレッドの呼び出しと同じ |
| オーバーヘッド | キューイング、スイッチング、スケジューリング、その他のオーバーヘッド | スレッドレススイッチングのパフォーマンスが向上 |
| 非同期をサポートするかどうか | サポート | サポートしません |
| タイムアウトをサポートするかどうか | サポート | サポート |
| 同時実行のサポート | スレッドプールサイズによる制御をサポート | 最大セマフォによる制御をサポート |
4.1.2 ヒュージング
当下游的服务因为某种原因突然变得不可⽤或响应过慢，上游服务为了保证⾃⼰整体服务的可⽤性，不再继续调⽤⽬标服务，直接返回，快速释放资源。如果⽬标服务情况好转则恢复调⽤。熔断器模型，如图所示
ヒューズ モデルのステート マシンには 3 つの状態があります。
Closed：关闭状态（断路器关闭），所有请求都正常访问。
Open：打开状态（断路器打开），所有请求都会被降级。熔断器会对请求情况计数，当⼀定时间内失败请求百分⽐达到阈值，则触发熔断，断路器会完全打开。
Half Open：半开状态，不是永久的，断路器打开后会进⼊休眠时间。随后断路器会⾃动进⼊半开状态。此时会释放部分请求通过，若这些请求都是健康的，则会关闭断路器，否则继续保持打开，再次进⾏休眠计时。
4.1.3 ダウングレード
降级是指当⾃身服务压⼒增⼤时，系统将某些不重要的业务或接⼝的功能降低，可以只提供部分功能，也可以完全停⽌所有不重要的功能。⽐如，下线⾮核⼼服务以保证核⼼服务的稳定、降低实时性、降低数据⼀致性，降级的思想是丢⻋保帅。
举个例⼦，⽐如，⽬前很多⼈想要下订单，但是我的服务器除了处理下订单业务之外，还有⼀些其他的服务在运⾏，⽐如，搜索、定时任务、⽀付、商品详情、⽇志等等服务。然⽽这些不重要的服务占⽤了JVM的不少内存和CPU资源，为了应对很多⼈要下订单的需求，设计了⼀个动态开关，把这些不重要的服务直接在最外层拒绝掉。这样就有跟多的资源来处理下订单服务（下订单速度更快了）
4.1.4 電流制限
限流，就是限制最⼤流量。系统能提供的最⼤并发有限，同时来的请求⼜太多，就需要限流，⽐如商城秒杀业务，瞬时⼤量请求涌⼊，服务器服务不过来，就只好排队限流了，就跟去景点排队买票和去银⾏办理业务排队等号道理相同。下⾯介绍下四种常⻅的限流算法。
1. リーキーバケットアルゴリズム
2. トークンバケットアルゴリズム
3. 固定タイムウィンドウアルゴリズム
4. スライディングタイムウィンドウアルゴリズム
4.1.4.1.リーキーバケットアルゴリズム
リーキーバケツアルゴリズムの考え方は、固定容量のリーキーバケツが一定の一定速度で水滴を流出させるというものです。バケツが空の場合、水滴を流す必要はありません。漏れのあるバケツには、どのような場合でも水が流入する可能性があります。流入する水滴がバケツの容量を超えると、流入する水滴はオーバーフローします（廃棄されます）が、漏れのあるバケツの容量は変化しません。
4.1.4.2.トークンバケットアルゴリズム
トークン バケット アルゴリズム: 制限が 2r/s であると仮定すると、トークンは 500 ミリ秒の固定レートでバケットに追加されます。バケットには最大 b 個のトークンを保存でき、バケットがいっぱいになると、新しく追加されたトークンは破棄または拒否されます。サイズ n バイトのパケットが到着すると、バケットから n 個のトークンが削除され、パケットはネットワークに送信されます。バケット内のトークンが n 個未満の場合、トークンは削除されず、パケットはフロー制限されます (破棄されるかバッファリングされて待機します)。トークンバケットの電流制限原理は図に示すとおりです。
トークン バケット電流制限サーバーは、実際のサービス パフォーマンスと期間に基づいて、トークンの生成速度とバケットの容量を変更できます。レートを上げる必要がある場合は、必要に応じてバケットに配置されるトークンのレートを上げます。
生成令牌的速度是恒定的，⽽请求去拿令牌是没有速度限制的。这意味着当⾯对瞬时⼤流量，该算法可以在短时间内请求拿到⼤量令牌，⽽且拿令牌的过程并不是消耗很⼤。
4.1.4.3. 固定時間ウィンドウアルゴリズム
一定の時間枠内で、一定数のリクエストの入力を許可できます。数量を超過した場合は、拒否されるか、次の期間の入場を待つために列に並ぶことになります。カウンタ電流制限を実装するこの方法は、ある時間間隔内で制限されます。ユーザーが前の時間間隔が終了する前にリクエストし (ただし、制限を超えない)、同時に現在の時間間隔でリクエストを開始した場合 (また、各時間間隔内では、これらのリクエストは正常ですが、重要な期間内のリクエストはシステム制限を超え、システムが過負荷になる可能性があります。
カウンター アルゴリズムにはタイム クリティカル ポイントの欠陥があるため、タイム クリティカル ポイント付近の非常に短い期間の攻撃に対して脆弱です。たとえば、特定のインターフェイスは 1 分間に 100 回までリクエストできるように設定されており、たとえば、12:00:00 ～ 12:00:59 の時間帯にはデータ リクエストがありませんが、 12:00:59 ～ 12:01:00 の期間に突然 100 個の同時リクエストが発生し、次のカウント サイクルに入り、カウンタがクリアされ、12:01:00 ～ 12:01 の間に 100 個のリクエストがありました。 :01。つまり、タイムクリティカルポイントの前後では、同時にしきい値の 2 倍のリクエストが発生する可能性があり、その結果、バックグラウンド処理リクエストの過負荷が発生し、システムの操作能力が不十分になり、場合によってはシステムがクラッシュする可能性があります。
4.1.4.4. スライディングタイムウィンドウアルゴリズム
滑动窗⼝算法是把固定时间⽚进⾏划分，并且随着时间移动，移动⽅式为开始时间点变为时间列表中的第⼆时间点，结束时间点增加⼀个时间点，不断重复，通过这种⽅式可以巧妙的避开计数器的临界点的问题。
滑动窗⼝算法可以有效的规避计数器算法中时间临界点的问题，但是仍然存在时间⽚段的概念。同时滑动窗⼝算法计数运算也相对固定时间窗⼝算法⽐较耗时。
4.2 Resilience4j の概要
4.2.1 Resilience4j の概要
Netflix的Hystrix微服务容错库已经停⽌更新，官⽅推荐使⽤Resilience4j代替Hystrix，或者使⽤Spring Cloud Alibaba的Sentinel组件
コアモジュール:
resilience4j-circuitbreaker: 熔断
resilience4j-ratelimiter: 限流
resilience4j-bulkhead: 隔离
resilience4j-retry: ⾃动重试
resilience4j-cache: 结果缓存
resilience4j-timelimiter: 超时处理
Fallback 调用失败后异常处理