SpringCloudプロジェクトの構築方法を教えます (8)リボンロードバランサの統合

これからも更新していきますので、いいねやフォロー大歓迎です！

1. リボンの概要

リボンは Neflix によってリリースされたオープンソースプロジェクトで、後に Spring Cloud 開発チームによって Spring Cloud にカプセル化され、サービス指向の REST テンプレートリクエストをクライアント側の負荷分散サービス呼び出しに簡単に変換できます。この機能は、クライアントソフトウェアの負荷分散アルゴリズムとサービスコールを提供することです。リボンは HTTP と CP に基づくクライアント負荷分散ツールです。Spring Cloud リボンは単なるツールフレームワークですが、サービスレジストリ、構成センター、API ゲートウェイなどの独立したデプロイメントは必要ありませんが、ほぼすべての Spring Cloud に存在します。マイクロサービスとインフラストラクチャが構築されました。マイクロサービス間の呼び出しやAPIゲートウェイのリクエスト転送などは、後ほど紹介するFeignも含め、実際にはRibbonをベースとしたツールであるRibbonを通じて実装されているためです。したがって、Spring Cloud を使用してマイクロサービスを構築するには、Spring Cloud リボンを理解して使用することが非常に重要です。リボンクライアントは、接続タイムアウト、再試行などの一連の包括的な構成項目を提供します。簡単に言うと、ロードバランサー (略して LB) の背後にあるすべてのマシンが構成ファイルにリストされており、リボンは特定のルール (単純なポーリング、ランダムなど) に基づいてこれらのマシンに接続するのを自動的に支援します。私たちはリボンを使用してカスタムの負荷分散アルゴリズムを実装するまさにコンテナーです。

ロードバランサーとは何ですか?

簡単に言えば、システムの HA (高可用性) を実現するために、ユーザーのリクエストを複数のサービスに均等に分散することです。一般的な負荷分散ソフトウェアには、Nginx、LVS、ハードウェア F5 などが含まれます。

リボンのローカル負荷分散と Nginx サーバーの負荷分散の違いは何ですか?

Nginx はサーバーのロードバランサーであり、クライアントからのリクエストはすべて Nginx に渡され、Nginx がリクエストを転送します。つまり、ロードバランサーはサーバーによって実装されます。
リボンローカルロードバランシングは、サービスインターフェイスを呼び出すときに、登録センターから登録情報サービスリストを取得し、それを JVM にローカルにバッファリングして、RPC リモートサービス呼び出しテクノロジをローカルで実現します。

2 種類の LB ロードバランシングとは何ですか?

集中型 LB、つまり、サービスコンシューマとプロバイダーの間に独立した LB 機能があり (F5 などのハードウェアまたは Nginx などのソフトウェア)、この機能は特定の戦略を通じてアクセスリクエストをサービスのプロバイダー。

インプロセス LB は LB ロジックをコンシューマと統合し、コンシューマは登録センターから利用可能なアドレスを学習し、これらのアドレスから適切なサーバーを選択します。リボンはインプロセス LB であり、コンシューマプロセスに統合された単なるクラスライブラリであり、コンシューマはそれを通じてサービスプロバイダのアドレスを取得します。

前回の記事では、プロデューサークラスターにアクセスするコンシューマーのラウンドロビン割り当てバランスを実現しました。リボンはサーバーの負荷分散とRestTemplateの呼び出しを実現するためのものです。これはソフトロードバランシングのクライアントコンポーネントであり、リクエストを必要とする他のクライアントと組み合わせて使用できます (Eureka との組み合わせは一例にすぎません)。

2. コード例

spring-cloud-starter-netflix-eureka-client には spring-cloud-starter-ribbon リファレンスが付属しているため、以下に示すように、リボンパッケージを導入する必要はありません。

ここに画像の説明を挿入

リボンのアーキテクチャ図は次のとおりです。

ここに画像の説明を挿入

リボンは作業時に 2 つのステップに分かれています。

最初のステップは、同じエリア内で負荷の少ないサーバーを優先する EurekaServer を選択することです。
2 番目のステップでは、ユーザーが指定したポリシーに従って、サーバーから取得したサービス登録リスト内のアドレスを選択します。
その中で、リボンは、ポーリング、ランダム、時間応答時間に応じた重み付けなど、さまざまな戦略を提供します。

リボンのコアコンポーネント IRule

IRule アルゴリズムのノット図:
ここに画像の説明を挿入

IRule の 7 つのロードアルゴリズム

ここに画像の説明を挿入

ロードアルゴリズムをポーリングメソッドからランダムアルゴリズムに変更するには、構成クラスをカスタマイズする必要があります。注意: このカスタムクラスは、@ComponentScan によってスキャンされた現在のパッケージまたはパッケージの下に配置することはできません。それ以外の場合は、この構成クラスをカスタマイズしますすべてのリボンクライアントで共有されるため、特別なカスタマイズの目的は達成できません。以下に示すように:

ここに画像の説明を挿入

次の図に示すように、新しい MyselfRule 構成クラスを作成し、それをランダムに変更します。

package com.buba.springclould.myrule;
 
import com.netflix.loadbalancer.IRule;
import com.netflix.loadbalancer.RoundRobinRule;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
//自定义负载均衡路由规则类
@Configuration
public class MyselfRule {
    
    
    @Bean
    public IRule myRule() {
    
    
        // 定义为随机
        return new RoundRobinRule();
    }   
}

以下の図に示すように、メインの起動クラスに @RibbonClient アノテーションを追加して構成します。

package com.buba.springclould.order;
 
import com.buba.springclould.myrule.MyselfRule;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.netflix.eureka.EnableEurekaClient;
import org.springframework.cloud.netflix.ribbon.RibbonClient;
 
@SpringBootApplication
@EnableEurekaClient
//name为生产者服务的服务名称  configuration为配置类的类名
@RibbonClient(name = "mcroservice-payment",configuration = MyselfRule.class)
public class OrderMain {
    
    
    public static void main(String[] args) {
    
    
        SpringApplication.run(OrderMain.class,args);
    }
}

次に、eureka7001 と 7002 を今すぐ起動し、次にサーバーサービス 8001 と 8002 を起動し、プロデューサーサービス 80 を起動し、パス http://localhost/consumer/payment/get/1 にアクセスして、元のポーリング 8001 サービス間を切り替えます。と 8002 サービスは、8001 サービスと 8002 サービスのランダムアクセスになります。

リボンの負荷分散の原理:

ここに画像の説明を挿入

リボンの読み込みアルゴリズムを統合するだけで完了です。とても簡単！
ここに画像の説明を挿入

次の記事では、OpenFeign サービスインターフェイスを呼び出す方法を学び、常に注意を払い、それを気に入ってください。引き続き更新していきます。