インタビュアー: なぜ Feign は最初の電話でこんなにも遅いのですか?

序文
リボンのロード方法
リボンクライアント構成
ZoneAwareLoadBalancer
リボン負荷分散戦略
リボン・イーガー・ロード (ハングリー・ロード) モード
リボンハンガーロードを有効にする
要約する

序文

まず第一に、レジストリ、負荷分散、FeignClient 間の関係を含め、Feign がリモート呼び出しを行う方法を理解する必要があります。マイクロサービスは eureka または nacos を介してサーバーに登録できます。Feign は負荷のためにリボンに依存しています。そして、リボンは取得する必要があります登録センターのサービスリストを取得し、サービスの負荷をローカルにキャッシュしてから、FeignClient クライアントが呼び出す、おそらくそのようなプロセスです。

Spring Boot + MyBatis Plus + Vue 3.2 + Vite + Element Plus をベースとしたフロントエンドとバックエンドに分離されたブログ。記事、カテゴリ、タグ管理、ダッシュボードなどの機能をサポートするバックグラウンド管理システムが含まれています。

GitHub アドレス: https://github.com/weiwosuoai/WeBlog

Gitee アドレス: https://gitee.com/AllenJiang/WeBlog

リボンのロード方法

まず、リボンがどのようにロードされるか、つまり、nacos と eureka のサービスリストを取得する方法を知る必要があります。これは非常に重要です。

リボンのロード方法

リボンクライアント構成

ibbonClientConfiguration クラスの LoadBalancer を通じて、リボンが LoadBalancer に依存してロードを実行することがわかります。これは ILoadBalancer インターフェイスのメソッドにすぎず、その後、新しいサービスを追加し、ロードバランサーでサービスを選択し、ServerDown をマークします。サービスをオフラインにする、サービスリストを取得する、生存しているサーバーを取得する、すべてのサーバー (正常なサーバーと異常なサーバーの両方) を取得する

ILoadBalancer インターフェイス

ZoneAwareLoadBalancer

デフォルトのloadBalancerはZoneAwareLoadBalancerロードバランサーです。親クラスDynamicServerListLoadBalancerのrestOfInitメソッドを継承することにより、さらに2つの重要なメソッド、enableAndInitLearnNewServersFeatureと2つが追加されます。

updateListOfServers 方法

restOfInit 方法

EnableAndInitLearnNewServersFeature メソッド。

LOGGER.info("Using serverListUpdater {}", serverListUpdater.getClass().getSimpleName());
serverListUpdater.start(updateAction);

ServerListUpdater.start メソッドの実装を見て、サービスリストを取得するためのカスタムスレッドを通じてそれを取得してみましょう。

ServerListUpdater.start

リボン負荷分散戦略

サービスリストの取得について言及しましたが、もちろん、負荷分散戦略についても説明する必要があります。主に 7 つのタイプがあります。

RoundRobinRule (サービスの順序に従って順番に呼び出されるポーリング戦略)
WeightedResponseTimeRule (重み付け比率戦略。重み付け比率の高いサービス、つまり応答時間が短いサービスを優先します。応答時間が長いほど、重み付け比率は低くなります)
RandomRule (ランダム戦略、サービスプロバイダーリストからサービスをランダムに選択)
BestAvailableRule (最小接続数戦略、サービスリスト内の接続数が最も少ないサービスインスタンスを取得します)
RetryRule (再試行戦略、無効なサービスの取得を再試行、指定された時間が取得できない場合は NULL を返す)
AvailabilityFilteringRule (可用性重視のポリシー、異常なサービスインスタンスのフィルター、lianji の選択)
ZoneAvoidanceRule (ゾーンに依存するポリシー)

カスタム負荷分散戦略に関しては、この記事の範囲には属しません。興味があれば、以下を参照してくださいhttps://t.zsxq.com/0fPeLWdXo。

Spring Boot + MyBatis Plus + Vue 3.2 + Vite + Element Plus をベースとしたフロントエンドとバックエンドに分離されたブログ。記事、カテゴリ、タグ管理、ダッシュボードなどの機能をサポートするバックグラウンド管理システムが含まれています。

GitHub アドレス: https://github.com/weiwosuoai/WeBlog

Gitee アドレス: https://gitee.com/AllenJiang/WeBlog

リボン・イーガー・ロード (ハングリー・ロード) モード

負荷用のリボンサービスの開始後および呼び出しの発生時にクライアントが作成されます

クライアントでは、最初の http リクエスト呼び出しが発生したときに、http リクエスト時間だけでなくクライアントの作成時間もカウントする必要があるため、最初の呼び出しは非常に遅くなり、メソッド呼び出しを作成します。

System サービスは System2 サービスを呼び出します

@GetMapping("/requestSystem2Api")
public String requestSystem2Api(){
    long startTime = System.currentTimeMillis();
    R<String> stringR = iTestServiceClient.testRequestMethod();
    if (null !=stringR){
        log.info("接口返回："+stringR.getMsg());
    }
    long needTime = System.currentTimeMillis() - startTime;
    log.info("接口调用需要的时间："+needTime);
    return "";
}

通話ログから、System2 サービスが初めて呼び出されるとき、リボンの DynamicServerListLoadBalancer が偽のクライアントをロードしてから呼び出しを行うことがわかります。最初の呼び出しの時間は長くなり、2 番目の呼び出しは直接呼び出すことができます。通話時間が早いです。

1回目は遅く、2回目は速く

リボンハンガーロードを有効にする

ribbon:
nacos:
  enabled: true # 开启naocos轮询
eager-load:
 enabled: true  # 开启Ribbon的饥饿加载模式(防止第一次请求超时的问题)
 clients: Lxlxxx-system2 # 指定需要开启的服务(需要开启Ribbon的饥饿加载模式)
 ReadTimeout: 10000
 ConnectTimeout: 10000
 MaxAutoRetries: 0
 MaxAutoRetriesNextServer: 1
 OkToRetryOnAllOperations: false

プロジェクトが開始されると、Lxlxxx-system2 サービスがロードされ、最初のリクエストのタイムアウトが回避されたことがログからわかります。

リボンハンガーロードを有効にする

要約する

実際、このスターベーションロードモードは、「クライアントロードウォームアップ」の操作に似ています。データ量とビジネスロジック処理の複雑さによって、サービス間の呼び出しによってインターフェイスタイムアウトが発生するのを防ぐために、プロジェクトの開始時にロードされます。呼び出しの間にビジネス処理を呼び出すのは複雑で時間がかかるため、この解決策を試してみるとよいでしょう。