目次
Sentinel は、サービス フロー制限、ヒューズのダウングレードなどのシステム保護を実行できるトラフィック管理コンポーネントです。同時実行性とアクセス性が高い一部のサービスでは、システムの安定性を確保するために必須のコンポーネントです。一般に、ゲートウェイやフェインなどのコンポーネントとともに使用されます。ゲートウェイとの組み合わせについては、以降のゲートウェイ関連の記事で説明します。この記事では、センチネルの使い方と、センチネルとフェイグの組み合わせを紹介します。
センチネルの基本的な使い方
Sentinel の使用を導入する前に、準備作業を行う必要があります。Sentinel コンソール サービスをダウンロードして開始します。コンソールは jar パッケージであり、ダウンロード後すぐに使用できます。ダウンロード アドレスは次のとおりです。 Releases · alibaba/Sentinel · GitHubで、必要なバージョンの jar パッケージをダウンロードし、起動します。Sentinel コンソールのデフォルト ポートは 8080 です。アドレスにアクセスすると、ログイン インターフェイスが表示されます。ユーザー名/パスワードは: Sentinel/sentinel です。ログイン後、次のページが表示されます:
上記のページが表示された後、sentinel コンソールが起動されます。永続的な設定がない場合、sentinel は遅延読み込みモードに属することに注意してください。関連するサービスとリソースが表示されます。次のステップは、Spring Boot プロジェクトへの Sentinel の統合、および Sentinel の具体的な操作と使用です。
新しい Spring Boot プロジェクトを作成し、基本的な依存関係を追加した後、次の依存関係を追加します。
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
</dependency>次に、次の構成をプロジェクト構成ファイルに追加します。
spring:
cloud:
sentinel:
transport:
# sentinel控制台地址，
dashboard: 127.0.0.1:8080
# 默认使用8719端口，如果端口被占用会以1为长度递增，直到找到未被占用的端口
port: 8719
# 针对限流中的链路规则，如果要使用链路限流，则需配置为，值为false，默认为true
web-context-unify: false上記の構成で Spring Boot プロジェクトに単純なコントローラーを追加し、インターフェイスを作成してプロジェクトを開始し、インターフェイス アドレスにアクセスすると、Sentinel コンソールでプロジェクトが見つかります。
電流制限ルール
まず、電流制限について見てみましょう。電流制限の目的は、現在のサービスが短期間に大量のアクセスを行い、サービスの収容能力を超えてサービスがクラッシュすることを防ぐことです。 。
上記の準備作業が完了したら、次の場所、つまり電流制限ルール構成の場所を見つけてみましょう。
フロー制御をクリックすると、次のポップアップ ボックスが表示されます。
リソース名: 特別な処理を行わない場合、これはアクセス パスであり、カスタムの名前付けに @SentinelResource(value="xxx") アノテーションを使用することもできます。
ソースの場合: デフォルトはデフォルトであり、通常は変更されません。
しきい値の種類: qps (1 秒あたりのインターフェイス アクセス データ) および同時スレッドの数、つまり電流制限の種類。
スタンドアロンしきい値: 組み合わせて使用するしきい値タイプを構成します。たとえば、しきい値タイプとして qps を選択し、単一マシンのしきい値として 10 を構成します。これは、単一マシンの qps が 10 を超えると、現在の制限ルールが次のようになります。引き金になった。
詳細オプション構成が実行されない場合、デフォルトの電流制限ポリシーは直接拒否します。最初に 1 に設定して電流制限の効果を確認し、その後インターフェイスに継続的にアクセスして電流制限をトリガーすると、次のリターン情報が表示されます。これは Sentinel のデフォルトのリターン情報です。Sentinel のカスタム リターンについては後ほど紹介します。
基本的な電流制限構成を理解した後、高度なオプションを見てみましょう。
フロー制御モードは次のように分類されます。
直接: アクセスされたアドレスが現在の制限ルールに達すると、現在の制限ルールが直接トリガーされます。
関連付け: 関連付けを選択すると、関連付けられたリソースの入力ボックスが表示されます。/testA と testB という 2 つのインターフェイスがあり、/testA という名前のリソースのフロー制御ルールで関連付けとして構成され、関連付けられたリソースが /testB であるとします。/testB が構成されたフロー制御制限に達すると、/testA はブロックされます。制限されます。/testB のルールを個別に設定する必要はなく、現在の基本的なフロー制御ルールは /testB 用であることに注意してください。
リンク: リンクを選択すると、エントリリソースの入力ボックスが表示されます。Sentinel の上位バージョンの場合は、web-context-unify: false を設定する必要はありません。バージョン 2.2.5.RELEASE 程度である必要があります。リンクを使用する場合、@SentinelResource アノテーションとともに使用されます。たとえば、/testA と testB の両方のインターフェイスは、base() メソッドにアクセスします。アクセスするには、base() メソッドに @SentinelResource("base") アノテーションを追加します。 / testA (/testB) の後、ベース リンクがクラスタ ポイント リンクに表示されます。リンクを使用するときは、インターフェイスの場所ではなくベースで設定します。たとえば、現在のエントリ リソース設定は /testA で、その後、 /testB インターフェイスは、電流制限ルールが満たされていても電流を制限しません。
フロー制御効果, フロー制御効果は、しきい値タイプが qps の場合にのみ表示されることに注意してください。しきい値タイプが同時スレッド数の場合、フロー制御効果はデフォルトで高速障害、つまりフロー制御効果になります。次の qps に設定されています:
Fail fast : 処理を行わずに直接失敗します。
wam up (予熱) : wam upを選択すると、予熱時間の入力ボックスが表示され、指定した予熱時間が実行時間となり、サービスのqpsリチャージ開始値が設定値まで増加します。開始値の式はスタンドアロンのしきい値/codeFactor です。codeFactor のデフォルト値は 3 です。たとえば、現在のスタンドアロンしきい値設定が 20 で、ウォームアップ時間が 6 秒である場合、スタンドアロンしきい値は最初は 7 で、6 秒後にスタンドアロンしきい値は 20 に上昇します。
この設定のウォームアップ効果については、フロー制御ルールを設定し、関連する操作を実行した後、センチネル コンソールのリアルタイム モニタリングを通じて確認できます。
列に並んで待つ: 列に並んで待つことを選択すると、タイムアウト時間の出力ボックスが表示されます。キューイングとは、リクエストが 1 回限りではなく均等に通過できるようにすることを指します。たとえば、設定された qps が 2 の場合、リクエストが 500 ミリ秒ごとに渡されることを意味します (現在、キューイングと待機は qps > 1000 の状況をサポートしていないことに注意してください)。では、タイムアウト期間は何を表すのでしょうか? これには計算上の問題があり、例えばタイムアウト設定が10000msで、qps設定の値が2、つまりインターバル時間は500msのままですが、この時点でリクエストが来ると、まだ 5 つのリクエストがその前にあり、キューに入れられています。これは最初の 6 つのリクエストが実行されるまでに 3000 ミリ秒待機する必要がありますが、3000 ミリ秒<10000 ミリ秒の場合は、順番に待機します。ただし、前に 30 のリクエストがある場合は、キューに入れられます。キューでは、15500 ミリ秒待つ必要があります。この時点で 15500 ミリ秒 > 10000 ミリ秒の場合、現在の制限ルールがトリガーされ、拒否されます。
上記は電流制限ルールの紹介であり、それぞれの状況に応じてシミュレーションすることができます。同時スレッドは jemeter でシミュレートできます。アソシエーションまたはリンクは、郵便配達員の自動リクエスト メソッドによってシミュレートできますが、ここではケースごとに例を作成およびシミュレートすることはしません。
2 つのヒューズのルール
ヒューズは実際にはサービスの雪崩が危険になるのを防ぐためのものです。現在のサービスは基本的にマイクロサービスの形式でデプロイされているため、サービス間で呼び出しが発生します。ヒューズの制限がない場合、サービスがサービス間を呼び出すときに、呼び出されたサービスが失敗して長時間応答しない場合、IO リソースが占有されていて解放できません。そのようなリクエストが多すぎる場合、サービスの呼び出し側には問題ありませんが、サービスの呼び出し元には問題がありません。サービスを呼び出すと、サービス全体が利用できなくなります。この種の危険を防ぐために、センチネルのサーキット ブレーカー ルールを使用して対処できます。
ヒューズ ルールの設定場所:
サーキットブレーカーのルールには、低速通話の割合、異常の割合、異常の数の3種類があり、以下ではこれら3つのサーキットブレーカーのルールを紹介します。導入の前に、理解すべきもう 1 つの知識ポイントがあります。それは、センチネル ヒューズの 3 つの状態です。
OPEN : オープン状態をヒューズし、すべてのリクエストを拒否します。
HALF_OPEN : リカバリステータスを検出するために、次のリクエストが正常にアクセスでき、ヒューズルールがトリガーされない場合はヒューズを終了し、そうでない場合はヒューズを継続します。
CLOSE : ヒューズが閉じられており、リクエストは正常に処理されます。
上記の 3 つの状態を紹介した後、融合の 3 つの戦略を見てみましょう。
1 遅いコール率
低速コール率のヒューズ ルールをクリックすると、次の関連入力情報が表示されます。
リソース名: これは、サーキット ブレーク ルールのリクエスト パスを追加するか、@SentinelResource アノテーションを使用してカスタマイズできます。
サーキットブレーカー戦略: サーキットブレーカー戦略には、スローコール率、異常率、異常数の 3 種類があります。
最大 RT : 通話で許可される最大応答時間。つまり、実際のリクエスト消費時間がこの時間を超える場合、この通話は低速通話として分類されます。
比率のしきい値: ここでは、低速通話の許容比率を指し、値の範囲は 0 ～ 1 です。たとえば、値が 0.1 に設定されている場合、低速通話の比率は 10 分の 1 を超えることはできません。
ヒューズ期間: ヒューズ ルールがトリガーされると、サービスは指定された時間内にサービス拒否状態になります。これは、前述の OPEN 状態です。
最小リクエスト数: リクエスト数がこの値より大きい場合にのみ、ヒューズ ルールの検証がトリガーされます。この値より小さい場合、サーキット ブレーカーの検証は実行されません。
統計期間: 指定された時間範囲内の統計リクエスト データ。
上記はサーキット ブレーカー ルールの各フィールドの紹介ですが、サーキット ブレーカー ストラテジーが異なれば、ほとんどのパラメーターは同じ意味を持ち、サーキット ブレーカー ストラテジーによって一意に所有されるのは一部のパラメーターのみです。低速通話率については、最大RTと比率閾値が低速通話情報を設定するための設定項目である。
一連の特定の設定を使用して、その意味を説明します。最大 RT は 500、比率しきい値は 0.4、ヒューズ時間は 1、リクエストの最小数は 5、統計時間は 1000 です。これは、カウントすることを意味します。 1 秒以内のリクエスト この場合、1 秒以内のリクエストの数が 5 未満の場合、ヒューズ状態は CLOSE になります。リクエストの数が 5 を超える場合、たとえばリクエストが 10 件ある場合は、リクエストの数をカウントします。これら 10 件のリクエストのうち、応答時間が 0.5 秒を超え、リクエストの数が 0.5 秒を超える場合 リクエストの数が 4 (0.4*10) 未満の場合、融合状態は CLOSE になり、それ以外の場合は OPEN 状態になります, OPEN 状態は 1 秒間続きます。溶断時間が 1 秒に達すると、溶断状態は HALF_OPEN 状態になります。次のリクエストの応答時間が 0.5 秒未満の場合、ヒューズ状態は CLOSE 状態に戻り、そうでない場合は継続します。上記の状態変化を繰り返します。つまり、ヒューズは 1 秒間 OPEN 状態になり、その後 HALF_OPEN 状態に変化します。
この状況をシミュレートするときは、sleep メソッドを使用してシミュレートし、スレッド スリープによる遅い応答をシミュレートできます。
2 異常な比率
異常比率: リクエスト全体に対する異常リクエストの比率。
または、具体的な例で説明します。割合のしきい値は 0.4、ヒューズ期間は 1、リクエストの最小数は 5、統計期間は 1000 です。つまり、リクエストの数が 1 秒以内のリクエストの統計は、 1s 以内が 5 未満の場合、ヒューズ状態は CLOSE です。リクエストの数が 5 より大きい場合、たとえばリクエストが 10 件ある場合は、10 リクエストのうち異常なリクエストの数をカウントします。が 4 (0.4*10) 未満の場合、ヒューズ状態は CLOSE、それ以外の場合は OPEN 状態になり、OPEN 状態は 1 秒間続きます。溶断時間が 1 秒に達すると、溶断状態は HALF_OPEN 状態になります次のリクエストの応答時間が 0.5 秒未満の場合、溶断状態は CLOSE 状態に戻り、それ以外の場合は繰り返し上記の状態が変化します。つまり、ヒューズは 1 秒間 OPEN 状態になり、その後変化します。 HALF_OPEN状態になります。
3 つ の外れ値
例外: 例外のあるリクエストの数。
または、具体的な例で説明すると、例外の数は 4、ヒューズ期間は 1、リクエストの最小数は 5、統計期間は 1000 です。これは、数が 1 秒以内のリクエストの統計が 1 秒以内であることを意味します。 1 秒以内のリクエストの数が 5 未満の場合、ヒューズ状態は CLOSE です。リクエストの数が 5 を超える場合、たとえばリクエストが 10 件ある場合は、10 リクエストのうち異常なリクエストの数をカウントします。リクエストが 4 未満の場合、ヒューズ状態は CLOSE、それ以外の場合は OPEN 状態、OPEN 状態は 1 秒間続きます。溶断時間が 1 秒に達すると、溶断状態は HALF_OPEN 状態になります。次のリクエストの応答時間が0.5 秒未満の場合、ヒューズ状態は CLOSE 状態に戻ります。それ以外の場合は、上記の状態変化を繰り返し続けます。つまり、ヒューズは 1 秒間 OPEN 状態になり、その後 HALF_OPEN 状態に変化します。
3 つのセンチネル電流制限ルールのその他の紹介
1 ホットスポット ルール
前編で紹介した電流制限ルールでは、要求されたリソースに対する全体的な電流制限ルールのみを実装していますが、より細かく電流を制限したい場合は、ホットスポット ルールを使用する必要があります。たとえば、特定の売れ筋商品の一定期間内の購入数を制限したいとします。ホットスポットルールはリクエストパスを指し、リクエストパラメータにはホットスポットデータの流入制限ルールが含まれ、ホットスポットデータを含まないリクエストはホットスポットデータに流入しません。次の図を使って説明します。
次に、設定方法を見てみましょう。
リソース名: リクエストパスアドレス;
電流制限モード: 現在は qps のみをサポートしており、変更できません。
パラメータ インデックス: インターフェイス内のパラメータ インデックスを指します。インデックスは 0 から始まります。
パラメータ例外にはパラメータのセットもあります。
パラメータ タイプ: 現在、8 つのパラメータ タイプがサポートされています: byte、short、int、long、float、double、String。
パラメータ値: ホットスポット データを設定します。
電流制限しきい値: このホットスポット データの電流制限 qps 値。
上記はホットスポット ルールの設定の概要です。興味のある学生は自分で試してみてください。
2 認可ルール
認可ルールは、現在のリソースによってどのリソースへのアクセスが許可され、どのリソースへのアクセスが許可されないかを参照します。これはブラック リストとホワイト リストのメカニズムであり、その構成エントリは次のとおりです。
3 システムルール
上記で紹介したルールは、実際には API レベルの現在の制限とみなすことができる細かい現在の制限ですが、システム ルールはサービス全体に対する粗い制限です。その構成エントリは次のとおりです。
LOAD : 適応型システム保護のヒューリスティック指標として、1 分間のシステムの平均負荷を使用します。システムの 1 分間の平均負荷が設定されたしきい値を超え、システムの現在の同時スレッド数が推定システム容量 (システム容量 = maxQps (最大 qps) * minRt によって推定される) を超えると、システム保護がトリガーされます。 (最小応答時間)。設定基準値：カップコア（CPUコア数）×2.5。
RT : 応答時間
スレッド数、エントリ QPS、CPU 使用率は文字通り
センチネルの 2 つの高度な使用法
カスタム応答メッセージ
電流制限やヒューズに Sentinel を使用する場合、設定を行わない場合は、Sentinel のデフォルトの制限情報が使用されます。たとえば、「Sentinel によってブロックされました (フロー制限)」という情報が表示されます。この表示方法は、お客様に適しています。運用環境では非常に不親切ですが、 @SentinelResouce アノテーションを使用してカスタム データを返すことができます。
次の簡単なコードを例として説明してみましょう。
新しい例外処理クラスを作成します。これには 2 つのメソッドが含まれます。1 つは現在の制限ルールがトリガーされたときのプロンプトで、もう 1 つは例外が発生したときのプロンプトです。
// 自定义异常处理类
public class SelfSentinelHandler {
// 当资源触发限流或者熔断规则的时候，返回的错误提示信息
public static String limite(BlockException e){
return "sentinel limite";
}
// 当调用资源发生异常时，返回的错误提示信息
public static String systemError(BlockException e){
return "system error";
}
}上記のカスタム エラー メッセージ クラスの開発が完了したら、次のステップはリソースで構成を呼び出すことです。
@GetMapping("/test")
@SentinelResource(blockHandlerClass = SelfSentinelHandler.class, blockHandler = "limite"
, fallbackClass = SelfSentinelHandler.class, fallback = "systemError"
, exceptionsToIgnore = {IOException.class, InterruptedException.class})
public String test(){
return "hello sentinelC";
}ここでは @SentinelResource アノテーションを使用し、アノテーション内の各属性について次の説明を示します。
blockHandlerClass : 現在の制限ルールまたはヒューズ ルールがトリガーされたときにプロンプト情報を処理するクラス。
blockHandler : 電流制限またはサーキット ブレーカー ルールがトリガーされたときに呼び出されるメソッド。
fallbackClass : 呼び出しインターフェイスで例外が発生したときにプロンプト情報を処理するクラス。
fallback : 呼び出し側インターフェイスで例外が発生したときに呼び出すメソッド。
ExceptionsToIgnore : 呼び出しインターフェースで例外が発生した場合、例外情報を無視し、これらの例外を直接返すことができます。
関連する例外処理メソッドを他のクラスで定義するため、これらのメソッドを変更するには static を使用する必要があることに注意してください。もちろん、blockHandlerClass、fallbackClass を構成せず、blockHandler と fallback のみを構成する場合、これらのメソッドは次の場所で開発されます。現在のインターフェイスと同じ時間 クラスでは、装飾に static を使用する必要はありません。
2 つの構成の永続性 (nacos)
Sentinel は遅延読み込みを使用します。対応するリンク情報は、対応する API にアクセスし、電流制限ヒューズ ルールを設定した後にのみ表示されます。プロジェクトが再起動されると、設定した電流制限ヒューズ ルールは消えます。本番環境では、電流制限やサーキットブレーカーの設定を永続化する必要があるため、この設定方法は不適切であるため、永続化に関しては nacos と協力しています。
nacos による永続性の構成を紹介する前に、永続性について全体的に理解しておきましょう。現在、sentinel でサポートされている永続化モードは 2 つあります。
1. プル モード、つまり、クライアントがスケジュールされたタスクを通じてフロー制御ルールをアクティブにプルしますが、この方法には、フロー制御ルールが変更されると、クライアントがフロー制御ルールを取得するのに 1 分の遅れが生じるという致命的な欠点があります。この構成方法を使用すると、現在、eurake、動的データ ソースなどが使用されます。
2. プッシュ モードでは、クライアントはイベントを登録してリッスンすることで、フロー制御ルールの変更をリアルタイムで監視します。現在、sentinel でサポートされているプッシュ モードのデータ ソースには、zookeeper、apollo、nacos、redis などが含まれます。
この記事では nacos の使い方を紹介していますが、他のモードについて知りたい場合は、sential の公式ドキュメント: Persistence of flow control rulesを参照してください。
まず、永続的なフロー制御ルール (nacos の場合) の原理を見てみましょう。
通常の状況では、nacos コンソールとセンチネル コンソールは相互に対話する必要があります。つまり、nacos コンソールのフロー制御ルールを変更する必要があり、センチネル コンソールのフロー制御ルールは現在実装されている同期的に変更されます。フロー制御ルールの変更は nacos でも同期的に変更される必要がありますが、これは現在実装されていません。使用する場合は注意が必要です。フロー制御ルールを永続的に変更したい場合は、nacos で変更する必要があります。
まず、依存関係を導入する必要があります。
<dependency>
<groupId>com.alibaba.csp</groupId>
<artifactId>sentinel-datasource-nacos</artifactId>
<version>1.8.1</version>
</dependency>次に、構成ファイルに次の構成を追加します。
spring:
cloud:
nacos:
discovery:
server-addr: 172.30.10.103:8848
sentinel:
web-context-unify: false
# sentinel控制台的访问信息
transport:
dashboard: 172.30.10.103:8080
port: 8719
# sentinel持久化的相关配置
datasource:
nacos:
nacos:
# nacos服务端地址
serverAddr: 172.30.10.103:8848
# naocs命名空间
namespace: 4b57e563-2039-42f4-86b1-9c4c7cf58bfc
# nacos组信息
groupId: DEFAULT_GROUP
# 在nacos中存放持久化配置的文件名称
dataId: sentinel-config.json
# 持久化的流控规则类型，目前支持flow，degrade，param-flow，system，authority，gw-flow,gw-api-group这几种，他们具体代表什么，我们后续再源码章节会进行介绍
ruleType: flow上記の構成が完了したら、次のステップは、nacos の指定された場所に移動し、永続ファイルを構成することです。
プロジェクトで構成したruleTypeはflowであるため、ここでの構成情報は次のようになります。
[
{
"resource": "/sentinel/config/demo",
"limitType": "default",
"grade": "1",
"count": "1",
"strategy": "0",
"controlBehavior": "0",
"clusterMode": false
}
]resource: API のアクセス アドレスに対応するリソース名 (@SentinelResource アノテーションで指定された名前)。
limitType: ソース アプリケーション、デフォルトはデフォルトです。
グレード: しきい値タイプ、0-スレッド数、1-qps;
カウント: スタンドアロンのしきい値。
戦略: フロー制御モード、0-ダイレクト、1-アソシエーション、2-リンク。
controlBehavior: フロー制御効果、0-フェイルファスト、1-ウォームアップ、2-キュー待機。
クラスタモード: クラスタ化するかどうか、true/false
設定ファイルのruleTypeが異なる場合、nacos設定ファイルのフィールドも異なり、実際の状況に応じて設定されることに注意してください。
上記の設定が完了したら、Spring Boot サービスを開始し、対応する API にアクセスすると、センチネル コンソールに、対応するフロー制御ルールの設定があることがわかります。
3つのOpenFeignの使い方紹介
なぜここで OpenFeign を紹介するのでしょうか? 1 つの理由は、OpenFeign がサービス呼び出しコンポーネントとしては比較的単純であり、別の記事で紹介する必要がないこと、もう 1 つの理由は、ヒューズ メカニズムを紹介したときに述べたように、主にサービス間の呼び出しを目的としているためです。マイクロサービス アーキテクチャでは、サービス間で一般的に使用される呼び出しの 1 つが OpenFeign です。OpenFeign を使用するには、Spring クラウドのコンポーネントである登録センターで使用する必要があることに注意してください。ここで使用するレジストリ コンポーネントは nacos です。
OpenFeign の基礎となる層はサービス呼び出しに HttpClient を使用します。前回の記事から、nacos 自体が負荷分散のためのリボンを継承しており、ここでのクラスター呼び出しに追加の構成は必要ないことがわかります。次に、OpenFeign の使用方法を紹介します。OpenFeign を使用するには、サービス プロバイダーとサービス コンシューマの両方が必要です。サービス プロバイダーの場合は、特別な処理を行う必要はなく、基本的な Spring Boot プロジェクトを作成し、nacos に登録するだけで済みます。この記事では、sentinel の使用方法を紹介し、次に Sentinel の関連設定を追加してヒューズ ルールを設定します。次に、サービスコンシューマの処理を紹介しますが、構成センターとしての nacos をベースに、登録センターの関連依存関係として nacos を追加する必要があります。
まず、OpenFeign の関連する依存関係を追加します。
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-openfeign</artifactId>
</dependency>次に、スタートアップ クラスで OpenFeign を開始するためのアノテーションを追加するか、スタートアップ タイプで OpenFeign ログを出力する Bean オブジェクトを追加します。
@SpringBootApplication
@EnableDiscoveryClient
// 使用openFeign，如果不添加该注解，无法使用
@EnableFeignClients
public class FeignConsumer9003Application {
public static void main(String[] args) {
SpringApplication.run(FeignConsumer9003Application.class, args);
}
// 打印openFeign的注解
@Bean
Logger.Level feignLoggerLevel(){
//开启详细日志，这里的日志级别有四种，默认为NONE-不打印任何日志
// BASIC：记录请求方法，URL，响应状态码以及执行时间
// HEADERS：除了BASIC中定义的信息之外，还有请求和响应的头信息
// FULL：除了HEADERS级别的信息以外，还有请求和响应的正文以及元数据
return Logger.Level.FULL;
}
}次に、関連する設定を設定ファイルに追加します。nacos の設定は必要ですが、OpenFeign の設定は必要ありません。これは一部のパラメータの特別な設定です。
// 因为openFeign在调用时通过ribbon作为负载均衡，因此OpenFeign的超时时间也就是ribbon的超时时间
ribbon:
# 指的是建立连接后从服务器读取到可用资源所用的时间
ReadTimeout: 5000
#指的是建立连接所用的时间，适用于网络状况正常的情况下,两端连接所用的时间
ConnectTimeout: 5000
// openFeign的日志打印级别以及对应的类型信息
logging:
level:
org.springframework.stereotype.Service.OpenfeignService: debug最後にコードの作成ですが、まずインターフェイスを作成する必要があり、サービス コンシューマはこのインターフェイスの関連メソッドを呼び出すことでサービス コンシューマを呼び出します。
@Service
// 该注解为OpenFeign的相关注解，注解里面的值为服务提供者注册到nacos中的服务名
@FeignClient("provider-service")
public interface OpenfeignService {
// 服务提供者提供的请求地址以及请求方式
@GetMapping("/provider/product/{id}")
// 方法签名，方法入参以及返回值一定要与服务提供者中对应接口完全一致
String getProduct(@PathVariable("id") Integer id);
}次に、Bean インジェクションを介して呼び出すことができ、サービス コンシューマでは、ローカル メソッドの呼び出しを通じてリモート呼び出しが実現され、サービス プロバイダとサービス コンシューマが起動され、サービス コンシューマ内の関連インターフェイスが起動されます。サービス プロバイダーに電話すると、対応するサービスがセンチネル コンソールに表示され、対応するサーキット ブレーカー ルールを構成できます。