リボンは、Spring Cloud Netflixファミリーバケットでの負荷分散を担当するコンポーネントです。クラスライブラリのコレクションです。リボンを介して、プログラマーは、プロジェクトでロードバランシングを実装するにはあまりにも多くのコードを作成することなく、特定の実装の詳細を伴わずに「透過的に」ロードバランシングを使用できます。
たとえば、ユーレカとリボンを含むクラスターでは、サービス（JARパッケージとして理解できます）が複数のサーバーに展開されます。複数のサービスユーザーが同時にサービスを呼び出す場合、これらの同時リクエストは、合理的な戦略を使用して各サーバーに転送できます。
実際、スプリングクラウドの他のさまざまなコンポーネントを使用する場合、ユーレカをリボンと統合できるなど、リボンの痕跡を確認できます。また、ゲートウェイ関数を提供するZuulコンポーネントは、リクエストを転送するときにリボンと統合することもできます。
コードレベルから、リボンには次の3つの重要なインターフェイスがあります。
まず、Iloadbalancerはロードバランサーとも呼ばれます。それを通して、特定のルールに従ってプロジェクトのリクエストを合理的に転送することができます。一般的な実装クラスは、ベースロードバランサーです。
第二に、このインターフェイスには、RandomRuleやRoundrobinRuleなどの複数の実装クラスがあります。これらの実装クラスは、「ランダム」や「ポーリング」などの負荷分散戦略を明確に定義します。また、このインターフェイスのメソッドを書き換えて、ロードバランス戦略をカスタマイズすることもできます。
BaseloAdbalancerクラスでは、IRULE実装クラスを介してロードバランスポリシーを設定できるため、ロードバランサーはこれに基づいて合理的に転送できるようにします。
第三に、このインターフェイスを介してIPINGインターフェイスは、現在使用可能なサーバーを取得できます。また、このインターフェイスのメソッドを書き換えることでサーバーが利用可能かどうかを決定するルールをカスタマイズすることもできます。 BaseloAdbalancerクラスでは、iping実装クラスを通じてサーバーが利用可能かどうかを判断するポリシーを設定することもできます。
1 Iloadbalancer：Loadbalancerインターフェイス
リボンでは、Iloadbalancerインターフェイスを介して特定の負荷分散ポリシーに基づいてサーバーを選択することもできます。
以下のiloadbalancerdemo.javaを使用して、このインターフェイスの基本的な使用法を見てみましょう。このクラスは、パート4.2で作成されたRabbionbasicdemoプロジェクトに配置されており、コードは次のとおりです。
//必要なパッケージを省略してコードを輸入しますパブリッククラスiloadbalancerdemo {public static void main（string [] args）{// iloadbalancerオブジェクトiloadbalancer loadbalancer = new baseloadbalancer（）; //サーバーリスト<server> myservers = new ArrayList <Server>（）; // 2つのサーバーオブジェクトサーバーS1 = new Server（ "ekserver1"、8080）;サーバーS2 = new Server（ "ekserver2"、8080）; // 2つのサーバーオブジェクトをリストに入れてくださいMyServersオブジェクトMyServers.Add（S1）; myServers.Add（S2）; // MyServersをLoad Balancer LoadBalancer.AddServers（MyServers）に入れます。 //（int i = 0; i <10; i ++）{//デフォルトのロードバランシングルールを使用してサーバータイプオブジェクトサーバーs = loadbalancer.chooseServer（ "default"）; // IPアドレスとポート番号System.out.println（s.gethost（） + "：" + s.getport（））; }}}5行目では、ベースロードバランサーのタイプのロードバランサーオブジェクトを作成し、ベースロードバランサーはロードバランサーIloadbalancerインターフェイスの実装クラスです。
6〜13行目では、2つのサーバータイプのオブジェクトを作成し、MyServersに入れます。 15行目では、リストタイプのMyServersオブジェクトをロードバランサーに入れました。
17行目から22行目のforループでは、ロードバランサーを介してサーバーの選択を10回シミュレートしました。具体的には、19行目では、ロードバランサーの選択方式を介してデフォルトのロードバランシングルールを使用してサーバーを選択します。 21行目では、「印刷」アクションを使用して、実際の「サーバーオブジェクトを使用してリクエスト」アクションをシミュレートします。
上記のコードの実行結果は次のとおりです。 Loadbalancer Load Balancerが10のリクエストを2つのサーバーに配布していることがわかり、「ロードバランシング」の効果を実際に確認できます。
第二に、このインターフェイスには、RandomRuleやRoundrobinRuleなどの複数の実装クラスがあります。これらの実装クラスは、「ランダム」や「ポーリング」などの負荷分散戦略を明確に定義します。また、このインターフェイスのメソッドを書き換えて、ロードバランス戦略をカスタマイズすることもできます。
BaseloAdbalancerクラスでは、IRULE実装クラスを介してロードバランスポリシーを設定できるため、ロードバランサーはこれに基づいて合理的に転送できるようにします。
第三に、このインターフェイスを介してIPINGインターフェイスは、現在使用可能なサーバーを取得できます。また、このインターフェイスのメソッドを書き換えることでサーバーが利用可能かどうかを決定するルールをカスタマイズすることもできます。 BaseloAdbalancerクラスでは、iping実装クラスを通じてサーバーが利用可能かどうかを判断するポリシーを設定することもできます。
Ekserver2：8080 Ekserver1：8080 Ekserver2：8080 Ekserver1：8080 Ekserver2：8080 Ekserver2：8080 Ekserver2：8080 Ekserver2：8080 Ekserver1：8080 Ekserver1：8080
2 Irule：ロードバランスルールを定義するインターフェイス
リボンでは、iRuleインターフェイスの実装クラスを定義することにより、ロードバランサーに対応するルールを設定できます。次の表では、IRuleインターフェイスの一般的に使用される実装クラスをいくつか確認できます。
実装クラスの名前 | バランスルールをロードします |
ランダムルール | ランダムに選択された戦略を採用します |
roundrobinrule | ポーリング戦略を採用します |
retryrule | この戦略を使用する場合、再試行アクションが含まれています |
可用性filterrule | 複数の接続障害と過度の要求の並行性を備えたサーバーをフィルタリングします |
weightedResponsetimerule | 平均応答時間に従って各サーバーの重みを設定し、この重量値に基づいて平均応答時間が小さくなるサーバーを選択します。 |
Zoneavoidancerule | リクエストと同じゾーンでサーバーへのリクエストを割り当てることが優先されます |
次のIruledemo.javaプログラムでは、Iruleの基本的な使用法を見てみましょう。
//必要なパッケージを省略してコードコードを省略しますパブリッククラスiruledemo {public static void main（string [] args）{//これは、Iloadbalancerインターフェイスではなく、Baseloadbalancer loadbalancer = new Baseloadbalancer（）; //ポーリングに基づいてロードバランスポリシーを宣言しますiruleルール= new roundrobinrule（）; // Policy Loadbalancer.setRule（ルール）を設定します。 // 3つのサーバーを次のように定義し、リストタイプのコレクション<server> myservers = new ArrayList <server>（）に定義します。サーバーS1 = new Server（ "ekserver1"、8080）;サーバーS2 = new Server（ "ekserver2"、8080）;サーバーS3 = new Server（ "ekserver3"、8080）; myServers.Add（S1）; myServers.Add（S2）; myServers.Add（S3）; //サーバーのリストloadbalancer.addservers（myservers）を設定します。 //（int i = 0; i <10; i ++）{server s = loadbalancer.chooseserver（null）の負荷分散の結果を出力します。 System.out.println（s.gethost（） + "：" + s.getport（））; }}}このコードは、上記の記事ではiloadbalancerdemo.javaに非常に似ていますが、次の違いがあります。
1行5では、クラスにはsetRuleメソッドが含まれているため、インターフェイスの代わりにベースロードバランサークラスを通じてロードバランサーを定義します。
2行7のポーリングルールに基づいてルールオブジェクトを定義し、9行目のロードバランサーに設定します。
3行19では、前の2つではなく、3つのサーバーを含むリストオブジェクトをロードバランサーに配置します。デモンストレーションの目的でここに保存されているため、存在しない「ekserver3」サーバーに入れます。
プログラムを実行した後、10の出力があることがわかり、「ポーリング」ルールに従って3つのサーバーの名前を順番に出力していることがわかります。 7行目のコードを次のように変更すると、サーバー名「ランダムに」出力が表示されます。
irule rule = new RandomRule（）;
3 Iping：サーバーが利用可能かどうかを判断するインターフェイス
このプロジェクトでは、通常、iloadbalancerインターフェイスがサーバーが利用可能かどうかを自動的に決定させます（これらのサービスはリボンの基礎となるコードにカプセル化されています）。さらに、リボンコンポーネントのIPIPインターフェイスを使用して、この関数を実装することもできます。
以下のiruledemo.javaコードでは、ipingインターフェイスの一般的な使用法を実証します。
//必要なパッケージを省略し、コードクラスをインポートしますmyping iping {public boolean isalive（server server）{//サーバー名がekserver2の場合、false if（server.gethost（）。equals（ "ekserver2"））{return false; } trueを返します。 }}2行目で定義されているMYPINGクラスは、IPIPインターフェイスを実装し、3行目の等性法をオーバーライドします。
この方法では、サーバー名に基づいて判断します。具体的には、名前がekserver2の場合、falseを返します。つまり、サーバーは利用できないことを意味します。
public class iruledemo {public static void main（string [] args）{baseloadbalancer loadbalancer = new baseloadbalancer（）; // iping iping iping myping = new Myping（）のMypingオブジェクトを定義します。 // mypingオブジェクトLoadbalancer.setping（myping）を使用します。 // 3つのサーバーオブジェクトを作成し、ロードバランサーリスト<server> myservers = new arrayList <server>（）に配置します。サーバーS1 = new Server（ "ekserver1"、8080）;サーバーS2 = new Server（ "ekserver2"、8080）;サーバーS3 = new Server（ "ekserver3"、8080）; myServers.Add（S1）; myServers.Add（S2）; myServers.Add（S3）; loadbalancer.addservers（myservers）; //（int i = 0; i <10; i ++）{server s = loadbalancer.chooseserver（null）; System.out.println（s.gethost（） + "：" + s.getport（））; }}}12行目のメイン関数では、15行目にipingタイプMypingオブジェクトを作成し、このオブジェクトを17行目のロードバランサーに入れます。18行目から26行目のコードを介して、3つのサーバーを作成し、ロードバランサーにも入れます。
28行目のforループでは、サーバー名を要求して出力します。ここのロードバランサーにはiping型オブジェクトが含まれているため、ポリシーに従ってサーバーを取得した後、MYPINGのISACTIVEメソッドに基づいてサーバーが利用可能かどうかが判断されます。
この方法では、サーバーekserver2が使用できないことを定義しているため、ロードバランサーロードバランサーオブジェクトはリクエストをサーバーに送信することはありません。つまり、出力の結果では、「ekserver2：8080」の出力が表示されません。
これから、IPIPインターフェイスの一般的な使用法を確認できます。 ISALIVEメソッドを書き換えることにより、「サーバーが利用可能かどうかを判断する」というロジックを定義できます。実際のプロジェクトでは、判断の基礎は「サーバーが長すぎるかどうか」または「サーバーに送信されたリクエストの数が多すぎるかどうか」にすぎません。これらの判断方法は、IRULEインターフェイスとその実装クラスにカプセル化されているため、一般的にシナリオではIPIPインターフェイスを使用します。
上記はこの記事のすべての内容です。みんなの学習に役立つことを願っています。誰もがwulin.comをもっとサポートすることを願っています。