1. Sentinelサービス保護フレームワークの紹介
インターフェースが頻繁にクラッシュする理由
QPS = 1は1秒あたり1回しかアクセスできません。
スレッド数=セマフォ分離、これはインターフェースが使用するスレッドの最大数です
ダッシュボード？
速く失敗する
Sentinelのデフォルトでは、現在の制限ルールは永続的ではありません。永続化するには、zk、nacos、Apolloを使用してください
ゲートウェイの電流を制限するには、ゲートウェイを統合する必要があります
2.サービスインターフェイス保護のオプションは何ですか？
ブラックリストおよびホワイトリスト
IP
サービスの低下に対する電流制限/ヒューズメカニズムの実現
サービス分離メカニズム
サービスの現在の制限：目的はサービスを保護することです。同時実行性が高い場合、クライアントがサーバーに特定の制限（設定されたしきい値）に到達するように要求すると、要求の数は設定されたしきい値を超え、自己保護メカニズムを開き、直接実行しますサービスダウングレードメソッド。ビジネスロジックを実行せず、ローカルフォールバックメソッドを使用します
サービスの低下：同時実行性が高い場合、ユーザーが待機するのを防ぐために、現在の制限またはヒューズメカニズムを使用してサービスを保護し、ビジネスロジックを実行せず、ローカルフォールバックメソッドを使用します
サービス雪崩：デフォルトでは、tomcat / jettyサーバーには、すべてのインターフェース要求を処理するスレッドプールが1つだけあります。同時実行性が高い場合、同じインターフェイスへのアクセスがすべてのスレッドプール接続を占有し、他のインターフェイスにアクセスできなくなります
サービス雪崩ソリューション：
サービス分離メカニズム：スレッドプール分離またはセマフォ分離メカニズム
スレッドプール分離：各インターフェイスには、要求を維持するための独自の独立したスレッドプールがあり、各スレッドプールは互いに影響しません。つまり、各インターフェイスは独立していますスレッドプールを使用することの欠点は、非常に
大量のサーバーメモリを占有することです。セマフォの分離：設定により、インターフェイスの1つに、スレッドを処理するためのしきい値のスレッド数を設定できます。スレッドの数を超えると、アクセスが拒否されます。
3. Sentinelとhytrixの違いは何ですか？
4、電流制限構成2スキーム
1.手動コード構成を使用
2. Sentinelコンソール構成
3.デフォルトでは、Sentinelはデータを永続化せず、個別に永続化する必要があります
達成するためのステップ：
1.フロー制御（制限）ルールを作成する
5つのsprngboot統合コンソール
コンソール構成
対応するSentinel-Dashboard
https://github.com/alibaba/Sentinel/releases/tag/1.7.1をダウンロードして実行します。
実行コマンドを実行します
java -Dserver.port = 8718 -Dcsp.sentinel.dashboard.server = localhost：8718 -Dproject.name = sentinel-dashboard -Dcsp.sentinel.api.port = 8719 -jar
アカウントパスワードは、センチネル
ログインアドレス127.0.0.1:8718です。
springboot構成
1、yml構成センチネル
2、デフォルトのリソース名は/ xxxなどのインターフェースアドレス
3、インターフェースには注釈が付けられ、現在の制限に優しいプロンプトblockHandler
6。
7.サービスヒューズとサービス劣化
サービスヒューズ：インターフェース呼び出し時間（サービス応答時間）が指定された時間を超えている
サービスの低下：
一定時間内にインターフェースに再度アクセスできない
8.センチネルルールデータの永続化のための4つのスキーム
1. Nacos分散構成センター：インターフェース、サーバーを再起動する必要なし、推奨
2. Ctrip Apollo：インターフェース、サーバーを再起動する必要なし、推奨
3. ZK、インターフェースなし、推奨
されない4.ローカルファイルに保存：簡単一貫性のないデータ、推奨されませんか？
サーバーの再起動後に、構成された現在の制限がクリアされます
Sentinelは、起動時にnaocのフロー制御ルールをメモリに読み込みます
nacosの統合は、ymlが構成されている限り継続されます。ルールはnacosに記述されます。統合後、コードでフロー制御ルールを構成することはできません。それ以外の場合、nacosのルールは上書きされます。
電流制限を実現する9つのSentinel統合ゲートウェイ
アクセスするとき、それらはすべてゲートウェイを介してアクセスされるため
1. Yml構成
2. 2つの構成クラスを追加し、1つは統合構成、1つはルール構成
3.統合された依存関係を導入する
4.ゲートウェイWeb依存パッケージの競合を排除する4.
デフォルトのプロンプトメソッドを書き換える
10、サービスの動的ヒューズ劣化を実現する
しきい値に達し、サービスダウングレードフォールバックメソッドを実行しても、実際にはビジネスロジックは実行されません
サービス低下の3つの戦略：
1. rt（平均応答時間）：インターフェースのアクセス応答時間が指定されたしきい値を1秒以内に超えると、サービスヒューズがトリガーされ、サービス低下メソッドが呼び出されます。指定された時間（時間ウィンドウ秒）以内は、再度アクセスできません。インターフェース、1秒間に5回アクセス、5回の平均応答時間はしきい値を超え、最大しきい値は4.9秒です。構成
2 を変更するには、最大しきい値を変更する必要があります。異常率：1秒あたりの異常リクエストの比率が、指定されたしきい値を超えています。サービスダウングレード、時間枠（秒）
-3。異常な時間：1分間の異常なリクエストの数が、指定されたしきい値、サービスの低下、時間枠（分）を超えています-
複数の戦略を同時に使用できます
11。
12。
XIII。
14。
15。
16。
17。
18。
19。
20、
21、
22。
二十三
24。
25。
26。
27。
28。
29。
30、
