SpringCloud マイクロサービス テクノロジー スタック ダーク ホースのフォローアップ (8)

今日の目標

1. Sentinel を理解する

1.1. 雪崩の問題と解決策

1.1.1. なだれ問題

マイクロサービスでは、サービス間の呼び出し関係は複雑であり、マイクロサービスは多くの場合、他の複数のマイクロサービスに依存しています。

図に示すように、サービス提供者 I が破綻すると、現在のアプリケーションの業務の一部もサービス I に依存しているため、ブロックされます。現時点では、Service I に依存しない他のサービスは影響を受けないようです。

ただし、サービス I に依存するビジネス リクエストはブロックされ、ユーザーは応答を取得しないため、Tomcat のスレッドは解放されず、ますます多くのユーザー リクエストが到着し、ますます多くのスレッドがブロックされます。

サーバーがサポートするスレッド数と同時実行数には制限があります. リクエストが常にブロックされると、サーバーのリソースが枯渇し、他のすべてのサービスが利用できなくなるため、現在のサービスも利用できなくなります.

その後、現在のサービスに依存する他のサービスは最終的に時間の経過とともに利用できなくなり、カスケード障害が形成され、雪崩が発生します: 雪崩: マイクロサービス呼び出しリンクで
サービス障害が発生し、チェーン全体を引き起こします、雪崩です。

1.1.2. タイムアウト処理

なだれ問題を解決する一般的な方法は 4 つあります
。

1.1.3. ウォールモード

オプション 2: 倉庫の壁モード

倉庫の壁のパターンは、キャビンのデザインから来ています。

キャビンはパーティションで複数の独立した空間に仕切られ、船体が損傷した場合、その空間の一部のみが入り込み、船体全体が水没することを防ぐために、損傷を一定の範囲内に制御します。

これと同様に、Tomcat 全体のリソースを使い果たすことを避けるために、各ビジネスで使用できるスレッドの数を制限できるため、スレッド分離とも呼ばれます。

1.1.4. サーキットブレーカー

サーキット ブレーカー モード:サーキット ブレーカーによって業務実行の異常な割合がカウントされ、しきい値を超えると業務が融合され、業務へのアクセス要求がすべて遮断されます。

サーキット ブレーカーは、サービスにアクセスするための要求の数、異常な比率をカウントします。

サービス D へのアクセス リクエストの異常な比率が高すぎることが判明した場合、サービス D には雪崩が発生する危険性があると見なされ、サービス D へのアクセス リクエストはすべて傍受され、サーキット ブレーカーが形成されます。

1.1.5. 電流制限

フロー制御: トラフィックの急激な増加によるサービス障害を回避するためにビジネス アクセスを制限する QPS。

1.1.6. まとめ

雪崩問題とは？

• マイクロサービスは相互に呼び出します。これは、呼び出しチェーンでサービスが失敗すると、リンク全体にアクセスできなくなるためです。

それは考えることができます：

現在の制限はサービスの保護であり、瞬間的な大量の同時トラフィックによって引き起こされるサービス障害を回避し、雪崩を回避します。予防措置です。

タイムアウト処理、スレッド分離、およびダウングレード ヒューズを使用して、特定の範囲内で障害を制御し、一部のサービスが失敗した場合のなだれを回避します。は対処法です。

1.2. サービス保護技術の比較

Spring Cloud では、複数のサービス保護テクノロジーがサポートされています。

• Netfix ハイストリックス
• センチネル
• レジリエンス4J

初期には Hystrix フレームワークの方が人気がありましたが、現在中国で最も広く使用されているのは Alibaba の Sentinel フレームワークです。

	センチネル	ハイストリックス
分離ポリシー	セマフォ分離	スレッドプール分離/セマフォ分離
サーキット ブレーカーのダウングレード戦略	スローコール率または異常率に基づく	故障率に基づく
リアルタイムインジケーターの実装	スライドウィンドウ	スライディング ウィンドウ (RxJava ベース)
ルール構成	複数のデータソースをサポート	複数のデータソースをサポート
スケーラビリティ	複数の拡張ポイント	プラグインフォーム
注釈ベースのサポート	サポート	サポート
制限する	QPS に基づいて、呼び出し関係に基づいて現在の制限をサポート	限定的なサポート
トラフィックシェーピング	スロースタート、均一キューイングモードをサポート	サポートしません
システム適応保護	サポート	サポートしません
コンソール	すぐに、ルールの構成、第 2 レベルの監視の表示、マシンの検出などを行うことができます。	不完全
共通フレームワークへの適応	Servlet、Spring Cloud、Dubbo、gRPC など	サーブレット、Spring Cloud Netflix

1.3. Sentinel の紹介とインストール

1.3.1. Sentinel を理解する

Sentinel は、Alibaba がオープンソース化したマイクロサービス トラフィック制御コンポーネントです。公式サイトアドレス：千値練公式サイト

Sentinel には次の特徴があります。

•豊富なアプリケーション シナリオ: Sentinel は過去 10 年間、アリババの Double Eleven トラフィック プロモーションのコア シナリオに取り組んできました。谷埋め、クラスタ トラフィック制御、ダウンストリームの使用できないアプリケーションのリアルタイム フュージングなど。

•完全なリアルタイム監視: Sentinel はリアルタイム監視機能も提供します。コンソールでは、アプリケーションに接続された単一のマシンの第 2 レベルのデータ、または 500 未満のスケールのクラスターの集計された実行状態を確認できます。

•広範なオープン ソース エコシステム: Sentinel は、Spring Cloud、Dubbo、および gRPC との統合など、他のオープン ソース フレームワーク/ライブラリとのすぐに使える統合モジュールを提供します。対応する依存関係を導入し、簡単な構成を実行するだけで、Sentinel にすばやくアクセスできます。

•完全な SPI 拡張ポイント: Sentinel は、使いやすく完全な SPI 拡張インターフェイスを提供します。拡張インターフェイスを実装することで、ロジックをすばやくカスタマイズできます。たとえば、カスタム ルール管理、動的データ ソースの適応などです。

1.3.2. Sentinel のインストール

1) ダウンロード

Sentinel は公式に UI コンソールを提供しています。これは、システムの現在の制限を設定するのに便利です。GitHubでダウンロードできます。

授業前の資料には、ダウンロードした jar パッケージも含まれています。

2) 走る

中国語以外のディレクトリにjarパッケージを配置します

注文の実行:

java -jar sentinel-dashboard-1.8.1.jar

Sentinel のデフォルトのポート、アカウント、およびパスワードを変更する場合は、次の構成を使用できます。

構成アイテム	デフォルト	例証する
サーバポート	8080	サービスポート
sentinel.dashboard.auth.username	センチネル	デフォルトのユーザー名
sentinel.dashboard.auth.password	センチネル	デフォルトのパスワード

たとえば、ポートを次のように変更します。
java -D 上記の 3 つの要求に対応するため
ここでポートを変更することをお勧めします

java -Dserver.port=8099 -jar sentinel-dashboard-1.8.1.jar

3) 訪問

http://localhost:8099 ページにアクセスすると、sentinel コンソールが表示されます。

アカウント番号とパスワードを入力する必要があります。デフォルトはsentinelです。

ログインした後、何も表示されませんでした。

これは、まだマイクロサービスと統合していないためです。

1.4. マイクロサービス統合 Sentinel

ナコスを始める

./startup.cmd -m standalone

起動後の効果画像は次のとおりです。

ブラウザにアドレスを入力するだけです。

http://127.0.0.1:8848/nacos

デフォルトのアカウントとパスワードはどちらも nacos です。入力するだけです。

application.yml 内のすべての構成ファイルをクラスター設定からローカル構成に変更する必要があることに注意してください。

サービスを開始します

。起動が成功したら、ゲートウェイ、注文、およびユーザーにアクセスし、それらがすべて正しいことを確認します。

http://localhost:8081/user/1
http://localhost:8080/order/101
http://localhost:10010/user/1?authorization=admin
http://localhost:10010/order/101?authorization=admin

注文サービスにセンチネルを統合し、センチネル コンソールに接続します。手順は次のとおりです。

1) センチネル依存を導入する

<!--sentinel-->
<dependency>
    <groupId>com.alibaba.cloud</groupId> 
    <artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
</dependency>

2) コンソールを構成する

application.yaml ファイルを変更し、次の内容を追加します。

server:
  port: 8080
spring:
  cloud: 
    sentinel:
      transport:
        dashboard: localhost:8099

設定後、order-service を再起動します

3) order-service の任意のエンドポイントにアクセスする
ブラウザを開き、http://localhost:8080/order/101 にアクセスして、sentinel の監視をトリガーします。
次に、sentinel コンソールにアクセスして効果を確認します。

2. フロー制御

なだれ問題には4つの解決策がありますが、現在の制限は、突然のトラフィックによるサービス障害を回避するためのものであり、マイクロサービスのなだれ問題を防ぐためのものです。まずはこのパターンを学びましょう。

2.1. クラスターリンク

リクエストがマイクロサービスに入ると、最初に DispatcherServlet にアクセスし、次に Controller、Service、および Mapper に入ります. このような呼び出しチェーンは、クラスター ポイント リンクと呼ばれます。クラスタ リンクで監視される各インターフェイスはリソースです。

デフォルトでは、sentinel は SpringMVC の各エンドポイント (コントローラー内のメソッドであるエンドポイント) を監視するため、SpringMVC の各エンドポイント (エンドポイント) は呼び出しリンク内のリソースです。

たとえば、先ほどアクセスした order-service の OrderController のエンドポイント: /order/{orderId}

フロー コントロール、ヒューズなどはすべてクラスター ポイント リンクのリソース用に設定されているため、ルールを設定するための対応するリソース:

• フロー制御: フロー制御
• ダウングレード: ダウングレード ヒューズ
• Hotspot: 電流制限の一種である hotspot パラメータの電流制限
• 承認: パーミッション コントロールの要求

2.1. クイックスタート

2.1.1. 例

resource/order/{orderId} の後ろにあるフロー コントロール ボタンをクリックして、フォームをポップアップします。

次のように、現在の制限ルールをフォームに入力できます。

意味は、リソース /order/{orderId} のスタンドアロン QPS を 1 に制限することです。つまり、1 秒あたり 1 つのリクエストのみが許可され、超過リクエストは傍受され、エラーが報告されます。

2.1.2. 練習:

要件: リソース /order/{orderId} のフロー制御ルールを設定します。QPS は 5 を超えることはできず、テストします。

1) まず、sentinel コンソールに現在の制限ルールを追加します

2) jmeter を使用してテストします
jmeter を使用したことがない場合は、ドキュメント「Jmeter クイック スタート
.

プレクラスの資料は、適切に記述された Jmeter テスト サンプルを提供します。jmeter

を開き、プレクラスの資料で提供されたテスト サンプルをインポートします。選択

: 20 ユーザー、2 秒以内に実行、QPS は10、5

以上です。実行するボタン:
流控入门，QPS<5

メニューの実行ボタンをクリックして実行しないでください。

ここで、ポートを order-service のポート 8080 に変更します

結果:

一度に 5 つの成功したリクエストしかないことがわかります.
失敗の理由:

次に、sentinel に移動して通話ステータスを確認します

2.2. フロー制御モード

フロー制限ルールを追加する場合は、[詳細オプション] をクリックして、次の 3 つのフロー制御モードから選択します。

• 直接: 現在のリソースの統計要求を行い、しきい値がトリガーされたときに現在のリソースのフローを直接制限します。これはデフォルト モードでもあります。
• 関連付け: 現在のリソースに関連する別のリソースをカウントし、しきい値がトリガーされたときに現在のリソースのフローを制限します
• リンク: 指定されたリンクからこのリソースにアクセスするリクエストをカウントし、しきい値がトリガーされたときに指定されたリンクのフローを制限します

クイックスタート テストは直接モードです。

2.2.1. アソシエーションモード

アソシエーションモード: 現在のリソースに関連する別のリソースをカウントし、しきい値がトリガーされた場合、現在のリソースのフローを制限します 構成規則 : 構文の説明 :
/ write

リソースのアクセス量がしきい値をトリガーすると、現在のリソースのフローが制限されます/read リソースは、/write リソースへの影響を避けるために制限されます。

使用シナリオ：たとえば、ユーザーは支払い時に注文ステータスを変更する必要があり、ユーザーは同時に注文を照会したいと考えています。クエリ操作と変更操作がデータベース ロックをめぐって競合し、競合が発生します。注文の支払いや更新の業務を優先することが業務要件であるため、注文業務のトリガー閾値を変更する際には、問い合わせ注文業務の流れを制限する必要がある。

要件の説明:

• OrderController に /order/query と /order/update の 2 つのエンドポイントを作成します。ビジネスを実装する必要はありません。

• /order/ 更新リソースによってアクセスされる QPS が 5 を超えると、フロー制御ルールを構成し、/order/query リクエストのフローを制限します

1) /order/query エンドポイントを定義して、注文クエリをシミュレートします。

@GetMapping("/query")
public String queryOrder() {
    
    
    return "查询订单成功";
}

2) /order/update エンドポイントを定義して、注文の更新をシミュレートする

@GetMapping("/update")
public String updateOrder() {
    
    
    return "更新订单成功";
}

サービスを再起動して、新しく追加されたアドレスにアクセスします

http://localhost:8080/order/query
http://localhost:8080/order/update

Sentinel コンソールのクラスター ポイント リンクを表示します。

3) フロー制御ルールを構成する

== どのエンドポイントの電流を制限するには、そのエンドポイントの後ろにあるボタンをクリックします。==注文クエリ/注文/クエリを制限しているので、その後ろのボタンをクリックして、

フォームにフロー制御ルールを入力してください:

4) Jmeter でのテスト

「Flow Control Mode-Association」を選択します。同様に、ポート番号が 8080 に変更された場合

、1000 人のユーザーが 100 秒間表示されるため、QPS は 10 であり、設定したしきい値を超えています: 5

http 要求を見てください。

要求のターゲットは /order/update であるため、このブレークポイントがしきい値をトリガーします。

しかし、現在の制限の対象は /order/query です。ブラウザでアクセスすると、現在の制限が実際に制限されていることがわかります

。

5) まとめ

2.2.2. リンクモード

リンクモード: 指定したリンクからこのリソースへのアクセス要求のみを統計し、閾値を超えているかどうかを判定します。
構成例：

たとえば、2 つのリクエスト リンクがあります。

• /test1 --> /共通
• /test2 --> /共通

/test2 から /common へのリクエストのみをカウントする場合は、次のように構成できます

。

要件: 注文照会サービスと注文作成サービスがあり、どちらも製品を照会する必要があります。注文の照会から製品の照会、現在の制限の設定までの要求の統計のため。

ステップ：

1. ビジネスを実装せずに OrderService に queryGoods メソッドを追加する
2. OrderController で、/order/query エンドポイントを変更し、OrderService で queryGoods メソッドを呼び出します。
3. /order/save エンドポイントを OrderController に追加し、OrderService の queryGoods メソッドを呼び出します
4. queryGoods の現在の制限ルールを設定します。/order/query から queryGoods を入力する方法の QPS 制限は 2 未満でなければなりません

達成：

1) クエリ プロダクト メソッドを追加する

order-service サービスで、queryGoods メソッドを OrderService クラスに追加します。

public void queryGoods(){
    
    
    System.err.println("查询商品");
}

２）ご注文に関するお問い合わせの際は、商品についてお問い合わせください

order-service の OrderController で、 /order/query エンドポイントのビジネス ロジックを変更します。

@GetMapping("/query")
public String queryOrder() {
    
    
    // 查询商品
    orderService.queryGoods();
    // 查询订单
    System.out.println("查询订单");
    return "查询订单成功";
}

3) 新しい注文を追加して製品を照会する

order-service の OrderController で、 /order/save エンドポイントを変更して新しい注文をシミュレートします。

@GetMapping("/save")
public String saveOrder() {
    
    
    // 查询商品
    orderService.queryGoods();
    // 查询订单
    System.err.println("新增订单");
    return "新增订单成功";
}

4) クエリ プロダクトにリソース タグを追加する

デフォルトでは、OrderService のメソッドは Sentinel によって監視されないため、アノテーションを使用して監視するメソッドをマークする必要があります。
**@SentinelResource** アノテーションを OrderService の queryGoods メソッドに追加します。

@SentinelResource("goods")
public void queryGoods(){
    
    
    System.err.println("查询商品");
}

リンク モードでは、異なるソースからの 2 つのリンクが監視されます。ただし、sentinel はデフォルトで SpringMVC に入るすべてのリクエストに対して同じルート リソースを設定するため、リンク モードが失敗します。

SpringMVC のこのリソース アグリゲーションをオフにして、order-service サービスの application.yml ファイルを変更する必要があります。

spring:
  cloud:
    sentinel:
      web-context-unify: false # 关闭context整合

サービスを再起動し、/order/query と /order/save にアクセスし、

Sentinel のクラスター ポイント リンク ルールに新しいリソースが表示されていることがわかります。

5) フロー制御ルールを追加する

商品リソースの後ろにあるフロー制御ボタンをクリックし、ポップアップ フォームに次の情報を入力します:

/order/query から /goods を入力するリソースのみをカウントし、QPS しきい値は 2 です。制限を超えた場合、流れが制限されます。

6) Jメーターテスト

「Flow Control Mode-Link」を選択:

ここには 200 人のユーザーがいて、送信は 50 秒以内に完了し、QPS は 4 であり、設定したしきい値を超えていることがわかります.http リクエストは /order/ にアクセスすることです
.保存:

操作の結果:

まったく影響を受けません。
もう 1 つは /order/query:

run results にアクセスすることです:

毎回 2 パスのみです。

2.2.3. まとめ

フロー制御モードとは何ですか?

• 直接: 現在のリソースを制限する

• 関連付け: 優先度の高いリソースはしきい値をトリガーし、優先度の低いリソースは制限されます。

• リンク: しきい値をカウントする場合、指定されたリソースから現在のリソースに入るリクエストのみがカウントされます。これは、リクエストのソースに対する現在の制限です。

2.3. フロー制御効果

フロー制御の詳細オプションには、フロー制御効果オプションもあります。

フロー制御効果とは、要求がフロー制御のしきい値に達したときに実行する必要がある措置を指し、次の 3 つのタイプが含まれます。

• フェイル ファスト: しきい値に達すると、新しいリクエストはすぐに拒否され、FlowException がスローされます。デフォルトの処理方法です。

• ウォームアップ: ウォームアップ モード。しきい値を超える要求も拒否され、例外がスローされます。ただし、このモードのしきい値は動的に変化し、小さな値から最大しきい値まで徐々に増加します。

• キューで待機: すべてのリクエストをキューで順番に実行し、2 つのリクエスト間の間隔を指定された時間より短くすることはできません

2.3.1.ウォーミングアップ

通常、しきい値は、マイクロサービスが引き受けることができる最大 QPS です. ただし、サービスが開始されたばかりの場合、すべてのリソースは初期化されていません (コールド スタート). QPS が直接最大値まで実行されると、サービスが停止する可能性がありますすぐに降りる。

ウォームアップはウォームアップ モード とも呼ばれ、サービスのコールド スタートの解決策です。リクエストのしきい値の初期値は maxThreshold / coldFactor で、指定された期間が経過すると maxThreshold 値まで徐々に増加します。コールドファクターのデフォルト値は 3 です。

たとえば、QPS の maxThreshold を 10 に設定し、ウォームアップ時間が 5 秒の場合、最初のしきい値は 10 / 3、つまり 3 で、5 秒後に徐々に 10 に増加し

ます
。

http://localhost:8080/order/101

要件: リソース /order/{orderId} の現在の制限を設定します。最大 QPS は 10 で、ウォームアップ効果を使用し、ウォームアップ時間は 5 秒です

1) フロー制御ルールを構成します。

2) Jメーターテスト

「フロー制御効果、ウォームアップ」を選択:

QPS は 10 です。

開始直後はほとんどのリクエストが失敗し、成功したのは 3 つだけでした。これは、QPS が 3 に制限されていたことを示しています: 時間が経つにつれて、

成功率はどんどん高くなりました:

Sentinel コンソールでリアルタイムの監視を確認してください:

一定期間後:

2.3.2. 順番待ち

リクエストが QPS のしきい値を超えると、フェイル ファストとウォームアップで新しいリクエストを拒否し、例外をスローします。
キューイングと待機とは、すべてのリクエストをキューに入れ、しきい値で許可された時間間隔に従って順番に実行することです。後続のリクエストは、前の実行が完了するまで待機する必要があり、リクエストの予想待機時間が最大期間を超える場合は拒否されます。

動作原理
例: QPS = 5 は、キュー内のリクエストが 200 ミリ秒ごとに処理されることを意味し、タイムアウト = 2000 は、予想される待機時間が 2000 ミリ秒を超えるリクエストが拒否され、例外がスローされることを意味します。

では、予想される待ち時間は？

たとえば、200 ミリ秒ごとに 1 つのリクエストが実行されるため、一度に 12 のリクエストが来ると、次のようになります。

• 6 番目のリクエストの予想待機時間= 200 * (6 - 1) = 1000 ミリ秒
• 12 番目のリクエストの予想待機時間 = 200 * (12-1) = 2200ms

ここで、最初の 1 秒間に 10 個のリクエストが同時に受信されますが、2 番目の 1 秒間に受信されるリクエストは 1 つだけです。このとき、QPS 曲線は次のようになります。

フロー制御にキュー モードを使用する場合、すべての着信要求をキューに入れ、200 ミリ秒の固定間隔で実行する必要があり、QPS は非常にスムーズになります。

滑らかな QPS 曲線は、サーバーにとってより友好的です。

ケース

要件: リソース /order/{orderId} の現在の制限を設定します。最大 QPS は 10 です。キューイングのフロー制御効果を使用し、タイムアウト期間を 5 秒に設定します。

1) フロー制御ルールを追加する

2) Jメーターテスト

「フロー制御効果、キュー」を選択します。QPS

は 15 で、設定した 10 を超えています。

以前の高速障害およびウォームアップ モードである場合、過剰な要求はエラーを直接報告する必要があります。

しかし、キュー モードの結果を見てみましょう。

すべて合格です。

次に、sentinel に移動して、リアルタイム モニタリングの QPS 曲線を表示します。

QPS は非常にスムーズで、常に 10 に維持されていますが、超過したリクエストは拒否されず、キューに入れられます。そのため、応答時間（待ち時間）はますます長くなります。
キューがいっぱいになると、一部のリクエストは失敗します。

2.3.3. まとめ

フロー制御効果とは？

• フェイル ファスト: QPS がしきい値を超えると、新しいリクエストを拒否します
• ウォームアップ: QPS がしきい値を超えると、新しい要求は拒否されます。QPS しきい値は徐々に増加します。これにより、コールド スタート中の高い同時実行性によって引き起こされるサービスのダウンタイムを回避できます。
• キューで待機中: リクエストはキューに入り、しきい値で許可された時間間隔に従ってリクエストが順次実行されます; リクエストの予想待機時間がタイムアウト時間よりも長い場合、リクエストは直接拒否されます

2.4. ホットスポットパラメータの現在の制限

これまでの電流制限は、特定のリソースへのアクセス要求をすべてカウントし、QPS しきい値を超えているかどうかを判断するものでした。hotspot パラメータの現在の制限は、同じパラメータ値のリクエストを個別にカウントし、QPS しきい値を超えているかどうかを判断することです。

2.4.1. グローバルパラメータ電流制限

たとえば、id に基づいて製品をクエリするためのインターフェース:

/goods/{id} にアクセスするためのリクエストでは、id パラメータの値が変更され、hotspot パラメータの現在の制限は、パラメータに従ってそれぞれ QPS をカウントします。統計結果:

id=1 のリクエストがトリガーされた場合 しきい値が制限されている場合、1 以外の id 値を持つリクエストは影響を受けません。

構成例:代表の意味: ホット リソースのパラメーター 0 (最初のパラメーター) で統計を作成し、

1 秒あたりの同じパラメーター値に対する要求の数が5 を超えることはできません

2.4.2. ホットスポットパラメータの現在の制限

先ほどの構成では、製品を照会するためのインターフェイスのすべての製品が同等に扱われ、QPS は 5 に制限されています。

実際の開発では、一部の製品はフラッシュセール製品などのホットな製品である可能性があります.これらの製品の QPS 制限は、他の製品とは異なり、より高いことが望まれます. 次に、ホットスポット パラメーターの現在の制限の高度なオプションを構成する必要があります。

前の構成と組み合わせると、ここでの意味は、0 番の long 型パラメーターの電流を制限することであり、1 秒あたりの同じパラメーターの QPS は 5 を超えることはできません。ただし、次の 2 つの例外があります。

• パラメータ値が 100 の場合、1 秒あたりの許容 QPS は 10 です
• パラメータ値が 101 の場合、1 秒あたりの許容 QPS は 15 です

2.4.4. ケース

ケースの要件: リソース /order/{orderId} にホットスポット パラメータの現在の制限を追加します。ルールは次のとおりです。

• デフォルトのホットスポット パラメータ ルールは、1 秒あたりのリクエスト数が 2 を超えないことです
• パラメータ 102 の例外を設定します: 1 秒あたりのリクエスト数は 4 を超えません
• パラメータ 103 の例外を設定します: リクエスト数1 秒あたり 10 を超えない

注: hotspot パラメーターの現在の制限は、デフォルトの SpringMVC リソースでは無効です。リソースをマークするには、@SentinelResource アノテーションを使用する必要があります。

1) タグリソース

order-service の OrderController の /order/{orderId} リソースにアノテーションを追加します。

変更後、order-service サービスを再起動することを忘れないでください。

2) ホットスポットパラメータの電流制限ルール

このインターフェイスにアクセスすると、マークしたホット リソースが表示されていることがわかります。

ここでホットの後ろにあるボタンをクリックしないでください。ページにはバグがあります。

左側のメニューで[ホットスポット ルール]メニューをクリックします。

[追加] をクリックして、フォームに入力します。

3) Jメーターテスト

「Hotspot parameter current limit QPS1」を選択します。

ここでは、リクエストの QPS は 5 です。

3 つの http リクエストが含まれています。

共通パラメータ、QPS しきい値は 2

実行結果:

例外項目、QPS しきい値は 4

操作結果:

例外、QPS のしきい値は 10 です

操作結果:

3. 隔離とエスカレーション解除

現在の制限は予防策です.現在の制限は、高い同時実行性によって引き起こされるサービス障害を回避しようとすることができますが、他の理由でサービスが失敗することもあります.

これらの障害を特定の範囲内に制御し、なだれを回避するには、スレッド分離(バルクウォール モード) とヒューズ ダウングレードメソッドに依存する必要があります。

スレッドの分離については前に説明しました: 呼び出し元がサービス プロバイダーを呼び出すと、呼び出し要求ごとに独立したスレッド プールが割り当てられます. 障害が発生した場合、呼び出し元のすべてのリソースを使い果たすことを避けるために、このスレッド プール内のリソースが最大でも消費されます. .

ヒューズ ダウングレード: 発信者側にサーキット ブレーカーを追加して、サービス プロバイダーへの呼び出しをカウントすることです. 呼び出しの失敗率が高すぎる場合、サービスが切断され、サービス プロバイダーへのアクセスが許可されなくなります.

スレッドの分離であろうとヒューズのダウングレードであろうと、クライアント(呼び出し元) の保護であることがわかります。呼び出し元がリモート呼び出しを開始するときに、スレッドの分離またはサービスの融合を実行する必要があります。

また、マイクロサービスのリモート呼び出しはすべて Feign に基づいているため、Feign と Sentinel を統合し、Feign にスレッド分離とサービス ヒューズを実装する必要があります。

3.1.FeignClient は Sentinel を統合します

Spring Cloud では、マイクロサービス呼び出しはすべて Feign を介して実装されるため、クライアント保護のために Feign と Sentinel を統合する必要があります。

3.1.1. 設定を変更してセンチネル機能を有効にする

OrderService の application.yml ファイルを変更して、Feign の Sentinel 機能を有効にします。

feign:
  sentinel:
    enabled: true # 开启feign对sentinel的支持

3.1.2. 障害ダウングレードロジックの記述

ビジネスの失敗の後、エラーを直接報告することはできませんが、わかりやすいプロンプトまたは既定の結果をユーザーに返す必要があります。これが失敗のダウングレード ロジックです。
失敗後の FeignClient のダウングレードロジックを書く
① 方法 1: リモート呼び出しの例外を処理できない FallbackClass
② 方法 2: リモート呼び出しの例外を処理できる FallbackFactory 、これを選択

ここでは、2 番目の方法の障害ダウングレード処理を示します。
ステップ 1 : feed-api プロジェクトでクラスを定義して、FallbackFactory を実装します。

コード:

package cn.itcast.feign.clients.fallback;

import cn.itcast.feign.clients.UserClient;
import cn.itcast.feign.pojo.User;
import feign.hystrix.FallbackFactory;
import lombok.extern.slf4j.Slf4j;

@Slf4j
public class UserClientFallbackFactory implements FallbackFactory<UserClient> {
    
    
    @Override
    public UserClient create(Throwable throwable) {
    
    
        return new UserClient() {
    
    
            @Override
            public User findById(Long id) {
    
    
                log.error("查询用户异常", throwable);
                // 根据业务需求返回默认的数据，例如这里返回了空用户
                return new User();
            }
        };
    }
}

ステップ 2 : feed-api プロジェクトの DefaultFeignConfiguration クラスに UserClientFallbackFactory を Bean として登録します。

@Bean
public UserClientFallbackFactory userClientFallbackFactory(){
    
    
    return new UserClientFallbackFactory();
}

ステップ 3 : feed-api プロジェクトの UserClient インターフェイスで UserClientFallbackFactory を使用します。

import cn.itcast.feign.clients.fallback.UserClientFallbackFactory;
import cn.itcast.feign.pojo.User;
import org.springframework.cloud.openfeign.FeignClient;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;

@FeignClient(value = "userservice", fallbackFactory = UserClientFallbackFactory.class)
public interface UserClient {
    
    

    @GetMapping("/user/{id}")
    User findById(@PathVariable("id") Long id);
}

サービスを再起動した後、注文クエリ サービスに 1 回アクセスし、sentinel コンソールを確認すると、新しいクラスター ポイントのリンクが表示されます。

3.1.3. まとめ

Sentinel がサポートする雪崩ソリューション:

• スレッドの分離 (サイロ ウォール モード)
• サーキットブレーカーの格下げ

Feign が Sentinel を統合するための手順:

• application.yml で設定: feign.sentienl.enable=true
• FeignClient の FallbackFactory を記述して Bean として登録する
• FallbackFactory を FeignClient に構成する

3.2. スレッド分離 (バルクウォールモード)

3.2.1. スレッド分離の実装

スレッドの分離は、次の 2 つの方法で実現できます。

• スレッド プールの分離

• セマフォ分離 (Sentinel はデフォルトで使用)

図に示すように:

スレッド プール分離: 各サービス呼び出し業務にスレッド プールを割り当て、スレッド プール自体を使用して分離効果を実現します。

セマフォ分離: スレッドプールを作成する代わりに、カウンタモードを使用して、業務で使用されるスレッドの数を記録し、セマフォの上限に達すると、新しいリクエストが禁止されます。

両方の長所と短所:

3.2.2. センチネルのスレッド分離

使用説明書:

スロットリング ルールを追加するときは、次の 2 つのしきい値の種類を選択できます。

• QPS: クイック スタートで示されている、1 秒あたりのリクエスト数です。

• スレッド数: このリソースで使用できる tomcat スレッドの最大数です。つまり、スレッドの数を制限することで、スレッドの分離(バルクウォール モード) が実現されます。

ケースの要件: 注文サービス サービスで UserClient のクエリ ユーザー インターフェイスのフロー制御ルールを設定し、スレッド数が 2 を超えることはできません。次に、jemeter を使用してテストします。

1) 分離ルールを構成する

偽装インターフェイスの背後にあるフロー制御ボタンを選択します。

フォームに記入する：

2) Jメーターテスト

「しきい値タイプ - スレッド数 < 2」を選択します。

一度に 10 件のリクエストが発生し、同時スレッド数が 2 を超える可能性が高く、超過したリクエストは、以前に定義された障害低下ロジックに従います。

実行結果を確認します。

結果はすべて渡されますが、一部の要求に対する応答は、ダウングレードによって返される null 情報であることがわかります。

3.2.3. まとめ

スレッド分離の 2 つの手段は何ですか?

• セマフォ分離

• スレッド プールの分離

セマフォ分離の特徴は何ですか?

• カウンターモードをベースに、シンプルで低オーバーヘッド

スレッド プール分離の特徴は何ですか?

• スレッド プール モードに基づいて、追加のオーバーヘッドがありますが、分離制御はより強力です

3.3. ヒューズのダウングレード

ヒューズのダウングレードは、雪崩問題を解決するための重要な手段です。サーキット ブレーカーが異常なサービス コールの割合と遅いリクエストの割合をカウントし、しきい値を超えるとサービスが中断されるという考え方です。つまり、サービスへのアクセス要求はすべて傍受され、サービスが復元されると、サーキット ブレーカーはサービスへのアクセス要求を解放します。

サーキット ブレーカーのヒューズとリリースの制御は、ステート マシンによって実行されます。

ステート マシンには、次の 3 つの状態があります。

• クローズ: クローズ状態。サーキット ブレーカーはすべての要求を解放し、例外と遅い要求の割合のカウントを開始します。閾値を超えるとオープン状態に移行
• オープン: オープン状態では、サービス呼び出しが中断され、中断されたサービスへのアクセス要求は拒否され、すぐに失敗し、ダウングレード ロジックに直接進みます。オープン状態で5秒経過後、半開状態になります
• ハーフオープン：ハーフオープン状態では、要求が解除され、実行結果によって次の動作が判断されます。
  • リクエストが成功しました: クローズ状態に切り替えます
  • リクエストに失敗しました: オープン状態に切り替えます

サーキットブレーカーの融合戦略には、スローコール、異常比率、異常数の 3 種類があります。

3.3.1. スローコール

スロー コール: サービスの応答時間 (RT) が指定された時間よりも長いリクエストは、スロー コール リクエストと見なされます。指定された時間内に、リクエストの数が設定された最小数を超え、スロー コールの割合が設定されたしきい値を超えると、サーキット ブレーカーがトリガーされます。

例えば：

解釈: RT が 500 ミリ秒を超える呼び出しは遅い呼び出しです. 最後の 10,000 ミリ秒以内の要求を数えます. 要求の数が 10 を超え、遅い呼び出しの割合が 0.5 以上の場合、サーキット ブレーカーがトリガーされます。サーキット ブレーカーは 5 秒間続きます。その後、ハーフオープン状態に入り、テスト要求を解除します。

ケースの
要件: UserClient のクエリ ユーザー インターフェイスのダウングレード ルールを設定します。スロー コールの RT しきい値は 50 ミリ秒、統計時間は 1 秒、要求の最小数は 5、障害しきい値比率は 0.4、ヒューズ持続時間は5

1) スローコールを設定する

user-service の /user/{id} インターフェイスのサービスを変更します。休眠による遅延時間のシミュレーション:

このとき、orderId=101 の注文は ID 1 のユーザーに関連付けられ、呼び出し時間は 60ms、orderId

=102 の注文は ID 2 のユーザーに関連付けられ、呼び出し時間は 60ms です。通話時間は非常に短いです。

2) ヒューズのルールを設定する

最初に以前のフロー制御ルールを削除して影響を防ぎます.

次に、偽装インターフェイスのダウングレード ルールを設定します:

ルール:

50 ミリ秒を超えるリクエストは遅いリクエストと見なされます

3) テスト

ブラウザーにアクセスします: http://localhost:8088/order/101、すばやく 5 回更新すると、サーキット ブレーカーがトリガーされ、要求期間が 5 ミリ秒に短縮され、すぐに失敗し、劣化が進行することがわかります。ロジック、null を返す

ブラウザでアクセス: http://localhost:8088/order/102、それも吹き飛ばされました:

3.3.2. 異常比率、異常数

異常率または異常数: 指定時間内の呼び出しをカウントし、呼び出し数が指定した要求数を超え、異常の割合が設定した比率のしきい値に達する (または指定した異常数を超える) 場合、サーキット ブレーカーが作動します。引き金になった。

たとえば、異常なスケール設定:

解釈: 最後の 1000ms 内のリクエストをカウントし、リクエスト数が 10 を超え、異常率が 0.4 以上の場合、サーキット ブレーカーがトリガーされます。

例外数の設定:

解釈: 最後の 1000 ミリ秒内の要求をカウントします. 要求数が 10 を超え、例外の割合が 2 以上の場合、サーキット ブレーカーがトリガーされます.

ケース

要件: UserClient のクエリ ユーザー インターフェースのダウングレード ルールを設定します。統計時間は 1 秒、要求の最小数は 5、障害しきい値比率は 0.4、ヒューズ持続時間は 5 秒です。

1) 例外要求の設定

まず、user-service のインターフェイス /user/{id} のビジネスを変更します。手動で例外をスローして、異常な比率のヒューズをトリガーします。

つまり、id が 2 の場合、例外がトリガーされます
。

http://localhost:8080/order/102

例外をスローする

2) ヒューズのルールを設定する

以前のサーキット ブレーカー ルールを削除する

次に、feign インターフェイスのダウングレード ルールを設定します。

ルール:

5 つのリクエストで、例外比率が 0.4 を超える限り、つまり、2 つ以上の例外がある限り、サーキット ブレーカーがトリガーされます。

3) テスト

ブラウザーですばやくアクセスします: http://localhost:8088/order/102、すばやく 5 回更新し、サーキット ブレーカーをトリガーします: この時点で、正常なはずの

103 にアクセスします

:
Sentinel circuit breaker downgrade の戦略?
● スロー コール率: 指定された時間を超えるコールはスロー コールであり、統計単位時間内の
スロー
コールの割合がしきい値を超えると遮断されます. 異常率: 異常なコールの割合統計単位期間内は、しきい値を超えると切断されます
. 異常な呼び出しの数, しきい値を超えると、それは吹き飛ばされます.

4. 認可規則

認可ルールは、リクエスタの送信元を判断および制御できます。

4.1. 承認規則

4.1.1. 基本ルール

認可規則は呼び出し元のソースを制御でき、ホワイト リストとブラック リストの 2 つの方法があります。

• ホワイトリスト: オリジンがホワイトリストにある発信者はアクセスが許可されます

• ブラックリスト：発信元がブラックリストにある発信者はアクセスできません

左側のメニューで [承認] をクリックして、承認規則を表示します。

• リソース名: /order/{orderId} などの保護されたリソースです。

• フロー制御アプリケーション: ソースのリストです。

  • ホワイト リストがチェックされている場合、リスト内のソースへのアクセスが許可されます。
  • ブラックリストがチェックされている場合、リスト内のソースへのアクセスが禁止されます。

例えば：

ゲートウェイから order-service へのリクエストを許可し、ブラウザーが order-service にアクセスすることを許可しないため、ゲートウェイのソース名 (オリジン) をホワイト リストに入力する必要があります。

4.1.2. オリジンの取得方法

Sentinel は、RequestOriginParser インターフェイスの parseOrigin を通じてリクエストのソースを取得します。

public interface RequestOriginParser {
    
    
    /**
     * 从请求request对象中获取origin，获取方式自定义
     */
    String parseOrigin(HttpServletRequest request);
}

このメソッドの機能は、リクエスト オブジェクトからリクエスタのオリジン値を取得して返すことです。

デフォルトでは、リクエスタがどこから来たかに関係なく、sentinel は常に値 default を返します。これは、すべてのリクエストのソースが同じ値 default であると見なされることを意味します。

したがって、このインターフェースの実装をカスタマイズして、異なるリクエストが異なるオリジンを返すことができるようにする必要があります。

たとえば、注文サービス サービスでは、RequestOriginParser の実装クラスを定義します。

package cn.itcast.order.sentinel;

import com.alibaba.csp.sentinel.adapter.spring.webmvc.callback.RequestOriginParser;
import org.springframework.stereotype.Component;
import org.springframework.util.StringUtils;

import javax.servlet.http.HttpServletRequest;

@Component
public class HeaderOriginParser implements RequestOriginParser {
    
    
    @Override
    public String parseOrigin(HttpServletRequest request) {
    
    
        // 1.获取请求头
        String origin = request.getHeader("origin");
        // 2.非空判断
        if (StringUtils.isEmpty(origin)) {
    
    
            origin = "blank";
        }
        return origin;
    }
}

request-header から origin の値を取得しようとします。

4.1.3. ゲートウェイにリクエストヘッダーを追加する

リクエストのオリジンを取得する方法は、リクエスト ヘッダーからオリジンの値を取得することであるため、ゲートウェイからマイクロサービスにルーティングされるすべてのリクエストにオリジン ヘッダーを持たせる必要があります。

これは、前に学習した GatewayFilter AddRequestHeaderGatewayFilter を使用して実現する必要があります。

ゲートウェイ サービスの application.yml を変更し、defaultFilter を追加します。

spring:
  cloud:
    gateway:
      default-filters:
        - AddRequestHeader=origin,gateway
      routes:
       # ...略

このようにして、ゲートウェイからルーティングされたすべてのリクエストは、値ゲートウェイを含むオリジン ヘッダーを運びます。他の場所からマイクロサービスに到着するリクエストには、このヘッダーがありません。

設定後、Gateway と OrderService への
アクセスを再開します

http://localhost:8080/order/103

4.1.4. 承認ルールの設定

次に、オリジン値がゲートウェイであるリクエストを許可する認可ルールを追加します。

構成は次のとおりです。

ここで、ゲートウェイを直接スキップして、注文サービス サービスにアクセスします。
ゲートウェイを介してアクセスします。

私たちは訪ねる

http://localhost:8080/order/102

エラーが直接報告されていることがわかり

、ゲートウェイにアクセスしました

http://localhost:10010/order/101?authorization=admin

アクセスが正しいことがわかりました

4.2. カスタム例外の結果

デフォルトでは、現在の制限、ダウングレード、または認証傍受が発生すると、呼び出し元に例外がスローされます。異常な結果はフロー制限 (電流制限) です。これは友好的とは言えず、現在の制限、ダウングレード、または許可された傍受のいずれであるかを知ることは不可能です。

4.2.1. 例外の種類

また、例外が発生したときに返される結果をカスタマイズする場合は、BlockExceptionHandler インターフェイスを実装する必要があります。

public interface BlockExceptionHandler {
    
    
    /**
     * 处理请求被限流、降级、授权拦截时抛出的异常：BlockException
     */
    void handle(HttpServletRequest request, HttpServletResponse response, BlockException e) throws Exception;
}

このメソッドには 3 つのパラメーターがあります。

• HttpServletRequest request：リクエスト対象
• HttpServletResponse 応答：応答対象
• BlockException e: センチネルによってインターセプトされたときにスローされる例外

ここでの BlockException には、いくつかの異なるサブクラスが含まれています。

異常な	例証する
フロー例外	電流制限例外
ParamFlowException	hotspot パラメータの電流制限の異常
DegradeException	ダウングレードの例外
AuthorityException	承認規則の例外
SystemBlockException	システム ルールの例外

4.2.2. カスタム例外処理

次に、order-service でカスタム例外処理クラスを定義します。

package cn.itcast.order.sentinel;

import com.alibaba.csp.sentinel.adapter.spring.webmvc.callback.BlockExceptionHandler;
import com.alibaba.csp.sentinel.slots.block.BlockException;
import com.alibaba.csp.sentinel.slots.block.authority.AuthorityException;
import com.alibaba.csp.sentinel.slots.block.degrade.DegradeException;
import com.alibaba.csp.sentinel.slots.block.flow.FlowException;
import com.alibaba.csp.sentinel.slots.block.flow.param.ParamFlowException;
import org.springframework.stereotype.Component;

import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

@Component
public class SentinelExceptionHandler implements BlockExceptionHandler {
    
    
    @Override
    public void handle(HttpServletRequest request, HttpServletResponse response, BlockException e) throws Exception {
    
    
        String msg = "未知异常";
        int status = 429;

        if (e instanceof FlowException) {
    
    
            msg = "请求被限流了";
        } else if (e instanceof ParamFlowException) {
    
    
            msg = "请求被热点参数限流";
        } else if (e instanceof DegradeException) {
    
    
            msg = "请求被降级了";
        } else if (e instanceof AuthorityException) {
    
    
            msg = "没有权限访问";
            status = 401;
        }

        response.setContentType("application/json;charset=utf-8");
        response.setStatus(status);
        response.getWriter().println("{\"msg\": " + msg + ", \"status\": " + status + "}");
    }
}

テストを再開します。異なるシナリオでは、異なる例外メッセージが返されます。
最初にフロー制御ルールを追加し、QPS = 1 を設定し

、アイデアを再起動してキャッシュをクリアします
。 にアクセスしてください。

http://localhost:8080/order/103

制限:

テスト後に上記のルールを忘れずに削除してから、承認ルールを構成してください。

承認が傍受された場合:
ここに再度アクセスしてください

http://localhost:8080/order/103

5. ルールの永続性

これで、sentinel のすべてのルールがメモリに保存され、再起動後にすべてのルールが失われます。運用環境では、損失を避けるためにこれらのルールの永続性を確保する必要があります。

5.1. ルール管理モード

ルールを永続化できるかどうかは、ルール管理モードによって異なります. Sentinel は、3 つのルール管理モードをサポートしています:

• オリジナル モード: Sentinel のデフォルト モードで、ルールはメモリに保存され、サービスを再起動するとサービスは失われます。
• プルモード
• プッシュモード

5.1.1. プルモード

プル モード: コンソールは構成されたルールを Sentinel クライアントにプッシュし、クライアントは構成されたルールをローカル ファイルまたはデータベースに保存します。将来的には、定期的にローカル ファイルまたはデータベースにクエリを実行して、ローカル ルールを更新します。
短所：適時性の問題とデータの不一致があります

5.1.2. プッシュモード

プッシュ モード: コンソールは、構成ルールを Nacos などのリモート構成センターにプッシュします。Sentinel クライアントは Nacos を監視し、構成変更のプッシュ メッセージを取得して、ローカル構成の更新を完了します。

5.2. プッシュモードの実現

詳細な手順については、クラス前の資料の「Sentinel ルールの永続性」を参照してください。

Sentinel ルールの持続性

1. 注文サービス サービスを変更する

OrderService を変更して、Nacos のセンチネル ルール構成をリッスンします。
具体的な手順は次のとおりです。

1.依存関係を導入する

order-service で nacos の依存関係を監視するセンチネルを導入します。

<dependency>
    <groupId>com.alibaba.csp</groupId>
    <artifactId>sentinel-datasource-nacos</artifactId>
</dependency>

2. nacos アドレスの設定

order-service の application.yml ファイルで、nacos アドレスとモニター構成情報を構成します。

spring:
  cloud:
    sentinel:
      datasource:
        flow:
          nacos:
            server-addr: localhost:8848 # nacos地址
            dataId: orderservice-flow-rules
            groupId: SENTINEL_GROUP
            rule-type: flow # 还可以是：degrade、authority、param-flow

変更後に注文サービス プロジェクトを再開する

2.sentinel-dashboardのソースコードを修正

SentinelDashboard はデフォルトで nacos 永続性をサポートしていないため、ソース コードを変更する必要があります。

1.解凍する

事前授業資料のセンチネル ソース パッケージを解凍します。

次に、このプロジェクトを IDEA で開きます。構造は次のとおりです。

2. nacos の依存関係を変更する

Sentinel-dashboard ソース コードの pom ファイルでは、nacos はデフォルトのテスト スコープに依存しており、これはテスト中にのみ使用できます

。

<dependency>
    <groupId>com.alibaba.csp</groupId>
    <artifactId>sentinel-datasource-nacos</artifactId>
</dependency>

3. nacos サポートを追加する

Sentinel-dashboard のテスト パッケージの下に、nacos のサポートが記述されているので、それを main にコピーする必要があります。

4. nacos アドレスを変更する

次に、テスト コードの NacosConfig クラスも変更する必要があります。

nacos アドレスを変更し、application.properties の構成を読み取らせます。sentinel

-dashboard の application.properties に nacos アドレス構成を追加します。

nacos.addr=localhost:8848

5. nacos データ ソースの構成

さらに、com.alibaba.csp.sentinel.dashboard.controller.v2 パッケージの下にある FlowControllerV2 クラスを変更する必要もあります。

追加した Nacos データ ソースを有効にします。

6. フロントエンド ページを変更する

次に、フロントエンド ページを変更し、nacos をサポートするメニューを追加します。

src/main/webapp/resources/app/scripts/directives/sidebar/ ディレクトリにある sidebar.html ファイルを変更します。

コメントのこの部分をオンにします。

その中のテキストを変更します。

7. プロジェクトを再コンパイルしてパッケージ化する

IDEA で maven プラグインを実行し、変更した Sentinel-Dashboard をコンパイルしてパッケージ化します。

8.スタート

起動方法は公式と同じです。

java -jar sentinel-dashboard.jar

nacos アドレスを変更する場合は、パラメーターを追加する必要があります。
ここでは、プロジェクト情報で教師によってパッケージ化されたポートを使用して、

order-service 構成ファイルのポートを変更します。教師の jar パッケージはポート 8080 であるためです。

次に、jar パッケージを開始します。

java -jar -Dnacos.addr=localhost:8848 sentinel-dashboard.jar

ブラウザを開いて Sentinel にログインします

http://localhost:8080/#/login

最初にアクセスして、クラスター ポイント リンクを読み込みます

http://localhost:8088/order/103

センチネルの更新 (ここで IDEA を再起動できます)
アクセス

http://localhost:8080/#/dashboard

クリア後​​、sentinel に再度ログインすると、他にもフロー制御ルールがあることがわかります。

クリックしてフロー制御ルールを追加します。

リソース名

/order/{orderId}

アクセス

http://localhost:8848/nacos/

追加の構成リストがあることがわかりました。これが現在の制限ルールです

2 回アクセスしてください

http://localhost:8088/order/101

IDEA を再起動して、現在の制限ルールが消えるかどうかを確認し

、もう一度アクセスしてみましょう

http://localhost:8088/order/101

電流制限ルールが消えていないことがわかり、持続​​性が実現されました