SpringCloud プロジェクトの構築方法を教える (11) Hystrix のサービスヒューズの統合

これからも更新していきますので、いいねやフォロー大歓迎です！
この記事では、サービスヒューズについて学ぶために、まずいくつかの概念を理解します。(概要の一部、クリックして表示)

サーキットブレーカーとは何ですか?

「サーキットブレーカー」自体はスイッチングデバイスであり、サービスユニットが監視に失敗した場合 (ヒューズが切れた場合と同様)、長時間待機する代わりに、予期された処理可能な代替応答 (FallBack) を呼び出したメソッドに返します。呼び出し側メソッドでは処理できない例外。これにより、サービス呼び出し側のスレッドが長時間不必要に占有されなくなり、分散システムでの障害の拡大が回避されます。雪崩さえも。

ヒューズの仕組みは何ですか?

ヒューズメカニズムは、アバランシェ効果に対処するためのマイクロサービスリンク保護メカニズムであり、ファンアウトリンクのマイクロサービスに障害が発生したり、応答時間が長すぎる場合、サービスがダウングレードされ、ノードマイクロサービスの呼び出しが中断されます。誤った応答情報を迅速に返し、ノードのマイクロサービス呼び出し応答が正常であることを検出すると、呼び出しリンクを復元します。

Spring Cloud フレームワークでは、ヒューズメカニズムは Hystrix を通じて実装されます。Hystrix はマイクロサービスコールのステータスを監視し、失敗したコールが特定のしきい値に達すると、デフォルトでは 5 秒以内に 20 回のコール失敗が発生し、ヒューズメカニズムがアクティブになります。ヒューズメカニズムのアノテーションは @HystrixCommand です。

1. コード実装例

前回の記事で新しく作成したプロデューサーcloud-provider-hystrix-payment8001のサービスにあるビジネスクラスPaymentServiceを変更します。このpaymentCircuitBreakerメソッドのロジックは、パラメータidを渡すことです。id<0の場合、ランタイム例外がスローされます。それ以外の場合は条件が満たされ、uuid が出力されます。具体的に設定します。以下に示すように:

@HystrixCommand(fallbackMethod = "paymentCircuitBreaker_fallback",commandProperties = {
    
    
            @HystrixProperty(name = "circuitBreaker.enabled",value = "true"),// 是否开启断路器
            @HystrixProperty(name = "circuitBreaker.requestVolumeThreshold",value = "10"),// 请求次数
            @HystrixProperty(name = "circuitBreaker.sleepWindowInMilliseconds",value = "10000"), // 时间窗口期
            @HystrixProperty(name = "circuitBreaker.errorThresholdPercentage",value = "60"),// 失败率达到多少后跳闸
    })
    public String paymentCircuitBreaker( Integer id)
    {
    
    
        if(id < 0)
        {
    
    
            throw new RuntimeException("******id 不能负数");
        }
        String serialNumber = IdUtil.simpleUUID();
        return Thread.currentThread().getName()+"\t"+"调用成功，流水号: " + serialNumber;
    }
//兜底降级的方法
 
    public String paymentCircuitBreaker_fallback(Integer id)
    {
    
    
        return "id 不能负数，请稍后再试，/(ㄒoㄒ)/~~   id: " +id;
    }

Hystrix サーキットブレーカーを使用する際に最も一般的に使用される 3 つの重要なインジケーターパラメーター

Hystrix をマイクロサービスのサーキットブレーカーとして使用する場合、通常は次の 3 つの重要なインジケーターパラメーターが含まれます (ここでは @HystrixProperties アノテーションに記述されています。もちろん、実際のプロジェクトは yml またはプロパティでグローバルに構成できます)。

1、circuitBreaker.sleepWindowInミリ秒

サーキットブレーカーのスナップショット時間ウィンドウは、ウィンドウ期間とも呼ばれます。これはサーキットブレーカーをトリガーするサイクルタイム値として理解でき、デフォルトは 10 秒 (10000) です。

2、circuitBreaker.requestVolumeThreshold

サーキットブレーカーのウィンドウ期間内にサーキットブレーカーをトリガーするための要求しきい値。デフォルトは 20 です。つまり、特定のウィンドウ期間内のリクエストの合計数が設定値よりも少ない場合、サーキットブレーカーは発生する資格さえありません。この期間中はサーキットブレーカーは開かれません。

3、circuitBreaker.errorThresholdPercentage

サーキットブレーカーのウィンドウ期間中に許容できるエラーパーセンテージのしきい値。デフォルトは 50 です (つまり、デフォルトでは 50% のエラーレートが許容されます)。たとえば、ウィンドウ期間中に 100 件のサービスリクエストがあった場合、そのうち 50 件にエラーが発生します。この場合、サーキットブレーカーが開きます。ウィンドウ期間の終了前に、51 番目のリクエストで例外が発生しなくても、フォールバックロジックが実行されます。

要約すると、上記の 3 つのパラメーターがデフォルトに設定されている場合、Hystrix サーキットブレーカーによってトリガーされるデフォルトの戦略は次のとおりです。

10 秒以内に 20 を超えるリクエストが発生し、エラー率が 50% を超えると、サーキットブレーカーが開きます。(ウィンドウ期間が経過するとサーキットブレーカーは半開(HALF-OPEN)状態となり、この時に発生するリクエストが正常であればクローズされ、そうでない場合は再度オープンされます)

次に、以下の図に示すように、制御層でそれを呼び出します。

 @GetMapping("/payment/circuit/{id}")
    public String paymentCircuitBreaker(@PathVariable("id") Integer id)
    {
    
    
        String result = paymentService.paymentCircuitBreaker(id);
        log.info("****result: "+result);
        return result;
    }

Eureka7001 サービスと 8001 サービスを開始し、http://localhost:8001/payment/circuit/1 にアクセスすると、渡されたパラメーター ID は 0 より大きい 1 であるため、シリアル番号 uuid が返されます。以下に示すように:
ここに画像の説明を挿入

次に、パラメータ ID に負の数を渡して http://localhost:8001/payment/circuit/-1 にアクセスすると、実行時に例外のプロンプトが返されます。以下に示すように:

ここに画像の説明を挿入

次にテストします。上記の設定は 10 秒以内に 10 回アクセスされるため、6 つ以上のエラーがある場合、サーキットブレーカーが開きます。サーキットブレーカーを開くということは、正しいパラメーターを渡し、問題があればフローを返すことを意味しますuuid 番号が失敗します。以下に示すように:
ここに画像の説明を挿入

これは、サーキットブレーカーがオンになり、時間が経つにつれて正しいアクセスが行われると、フォールトトレランス率が低下し、ゆっくりと回復し、サーキットブレーカーの状態が半開状態になり、正しいレートになることを意味します。増加すると、自動的に閉じます。次の図に示すように、正しくアクセスできます。
ここに画像の説明を挿入

3 種類の融着:

熔断打开：请求不再调用当前服务，内部设置一般为MTTR（平均故障处理时间），当打开时长达到所设时钟则进入半熔断状态。

熔断关闭：熔断关闭不会对服务进行熔断。

熔断半开：部分请求根据规则调用当前服务，如果请求成功且符合规则认为当前服务恢复正常，关闭熔断。

ここに画像の説明を挿入

サーキットブレーカーが開閉する条件は何ですか?

1. 特定のしきい値に達したとき (デフォルトは 10 秒間に 20 リクエストを超えています)
2. 失敗率が特定のレベルに達したとき (デフォルトは 10 秒間にリクエストの 50% を超えています)
3. 上記の場合しきい値に達すると、サーキットブレーカーがオンになります
。 4. オンになると、すべてのリクエストは転送されません。
5. 一定時間 (デフォルトは 5 秒) が経過すると、この時点でサーキットブレーカーは半分開いた状態になります。 6.成功し
た場合は、サーキットブレーカーがデバイスを閉じます。失敗した場合は、引き続き開き、ステップ 4 と 5 を繰り返します。

サーキットブレーカーが開いた後はどうなりますか?

1. 再度呼び出し要求がある場合、メインロジックは呼び出されず、ダウングレードフォールバックが直接呼び出され、サーキットブレーカーを介してエラーが自動的に検出され、ダウングレードロジックがメインロジックに切り替えられ、エラーが発生します。応答遅延の影響。
2. 元のメインロジックを復元するにはどうすればよいですか?
この問題に対して、Hystrix は自動復旧機能も実装しています。サーキットブレーカーが開いてメインロジックが融合すると、Hystrix はスリープタイムウィンドウを開始します。この時間ウィンドウの間、劣化したロジックが一時的にメインロジックになります。スリープタイムウィンドウが終了すると、サーキットブレーカーは半開状態になり、元のメインロジックへのリクエストを解放します。リクエストが正常に戻ると、サーキットブレーカーは閉じ続け、メインロジックが再開されます。このリクエストには依然として問題があり、サーキットブレーカーは引き続きオープン状態になり、スリープタイムウィンドウが再開されます。

Hystrix ワークフロー

ここに画像の説明を挿入

公式 Web サイトのフローチャートでは、Hystrix のワークフローが説明されています。

1、每次调用都会创建一个HystrixCommand
2、执行execute或queue做同步\异步调用
3、判断熔断器是否打开,如果打开跳到步骤8，否则进入步骤4
4、判断线程池/信号量是否跑满，如果跑满进入步骤8,否则进入步骤5
5、调用HystrixCommand的run方法，如果调用超时进入步骤8
6、判断是否调用成功，返回成功调用结果，如果失败进入步骤8
7、计算熔断器状态,所有的运行状态(成功, 失败, 拒绝,超时)上报给熔断器，用于统计从而判断熔断器状态
8、降级处理逻辑，根据上方的步骤可以得出以下四种情况会进入降级处理：熔断器打开、线程池/信号量跑满、调用超时、调用失、
9、返回执行成功结果

Hystrix のサービスヒューズはおそらくここで学べますが、とても簡単です。

ここに画像の説明を挿入

次の記事では、Hystrix のグラフィカルダッシュボードのリアルタイムモニタリングについて学習し続けます。記事は引き続き更新されます。注目してください。