Nginx負荷分散、SpringBoot負荷分散インスタンス

関連コンテンツの元のリンク：

• 移民労働者：負荷分散を実現するためのNginx + Spring Boot
• Nginxを使用してMySQLデータベースの負荷分散を実現するにはどうすればよいですか？読んでわかりました！！

1.負荷分散の概要

Nginxは負荷分散を実現できますが、負荷分散とは何ですか？つまり、アプリケーションは異なるサーバーにデプロイされますが、統一されたドメイン名を介して、nginxはリクエストを分散し、処理のためにリクエストを異なるサーバーに分散します。これにより、単一のサーバーへのプレッシャーを効果的に減らすことができます。

Nginxロードバランシングの実装を紹介する前に、ロードバランシングの分類について簡単に説明しましょう。ロードバランシングは、主にハードウェアロードバランシングとソフトウェアロードバランシングに分けられます。

• ハードウェア負荷分散は、特殊なソフトウェアとハ​​ードウェア機器の組み合わせです。機器メーカーは、データの安定性とセキュリティの点で非常に信頼性の高いF5などの完全で成熟したソリューションを提供しますが、ソフトウェアよりも高価になります。
• ソフトウェアの負荷分散は、メッセージキュー分散メカニズムを実装するNginxなどのソフトウェアに基づいています。

簡単に言うと、いわゆる負荷分散とは、多くのリクエストを分割し、それらを異なるサーバーに分散して処理することです。たとえば、A、B、Cの3つのサーバーがあり、負荷分散とポーリング戦略にNginxを使用しています。この時点で9つのリクエストを受信すると、9つのリクエストがAとBに均等に分散されます。 Cサーバー。各サーバーは3つのリクエストを処理するため、複数のマシンクラスターの特性を使用して、単一サーバーの負荷を軽減できます。

負荷分散を実現するためのNginxの例図：

クロスドメインの問題を解決する

同一生成元：URLは、プロトコル、ドメイン名、ポート、およびパスで構成されます。2つのURLのプロトコル、ドメイン名、およびポートが同じである場合、それらは同じ発信元であることを意味します。

ブラウザの同一生成元ポリシー：ブラウザの同一生成元ポリシーは、異なるソースからの「ドキュメント」またはスクリプトが現在の「ドキュメント」の特定の属性を読み取ったり設定したりすることを制限します。あるドメインからロードされたスクリプトは、別のドメインのドキュメントプロパティにアクセスできません。

2、負荷分散戦略

nginxオープンソースは4つの負荷分散方法をサポートし、nginxPlusはさらに2つの方法を追加します。

2.1ラウンドロビン（ポーリング戦略）

すべてのリクエストをポーリングしてリクエストを送信します。これはデフォルトの配布方法です。

nginx.confの構成例：

# 1、轮询（默认）
# 每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉，能自动剔除。
upstream polling_strategy {
    server glmapper.net:8080; # 应用服务器1
    server glmapper.net:8081; # 应用服务器2
}

注：上記のドメイン名はIPに置き換えることもできます。

試験結果：

8081：hello
8080：hello
8081：hello
8080：hello

2.2最小の接続

アクティブな接続の数が最も少ないサーバーにリクエストを送信します。サーバーの重みも考慮する必要があります。

nginx.confの構成例：

upstream xuwujing {
    least_conn;
    server www.panchengming.com;
    server www.panchengming2.com;
}

2.3IPハッシュ戦略

要求を送信するサーバーは、クライアントのIPアドレスによって決定されます。この場合、IPv4アドレスの最初の3バイトまたはIPv6アドレス全体がハッシュ値の計算に使用されます。この方法では、サーバーが使用できない場合を除いて、同じアドレスからの要求が同じサーバーに確実に到着します。

#3、IP绑定 ip_hash
#每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，
#可以解决session的问题;在不考虑引入分布式session的情况下，
#原生HttpSession只对当前servlet容器的上下文环境有效
upstream ip_hash_strategy {
    
    
    ip_hash;
    server glmapper.net:8080; # 应用服务器1
    server glmapper.net:8081; # 应用服务器2
}

Iphashアルゴリズム：ipは基本的なドット付き10進法であり、ipの最初の3つの端がパラメーターとしてハッシュ関数に追加されます。これの目的は、同じIPアドレスを持つ最初の3人のユーザーが、ハッシュ計算後に同じバックエンドサーバーに割り当てられるようにすることです。著者の検討は非常に望ましいため、IPアドレスの最初の3桁が同じであるということは、通常、それらが同じローカルエリアネットワークまたは隣接エリアからのものであることを意味し、同じバックエンドサービスを使用すると、nginxの一貫性がある程度向上します。 。

2.4汎用ハッシュ

リクエストの送信先となるサーバーは、テキスト文字列、変数、または組み合わせのユーザー定義キーによって決定されます。

upstream xuwujing {
     hash $request_uri consistent;
     server www.panchengming.com;
     server www.panchengming2.com;
 }

2.5最小時間（NGINX Plusのみ）

NGINX Plusは、リクエストごとに、平均遅延が最小でアクティブな接続の数が最小のサーバーを選択します。平均遅延が最小のサーバーは、least_timeディレクティブを含む次のパラメーターに基づいて計算されます。

• ヘッダー：サーバーから最初のバイトを受信した時刻。

• last_byte：サーバーから完全な応答を受信する時間。

• last_byte inflight：サーバーから完全な応答を受信する時間。

  アップストリームxuwujing {least_timeヘッダー; サーバーwww.panchengming.com; サーバーwww.panchengming2.com; }

2.6ランダム

各リクエストは、ランダムに選択されたサーバーに配信されます。2つのパラメーターが指定されている場合、最初にNGINXはサーバーの重みに基づいて2つのサーバーをランダムに選択し、次に指定された方法を使用してそのうちの1つを選択します。

• less_conn：アクティブな接続の最小数

• less_time = header（NGINX Plus）：サーバーから応答ヘッダーを受信するための最短の平均時間（$ upload_header_time）。

• less_time = last_byte（NGINX Plus）：サーバーから完全な応答を受信するための最短の平均時間（$ upload_response_time）。

  upstream xuwujing {
  	random two least_time=last_byte;
  	server www.panchengming.com;
  	server www.panchengming2.com;
  }
  

2.7リダイレクトの書き換え

location / {
    
    
    #重定向
    #rewrite ^ http://localhost:8080;
}

検証のアイデア：nginxの構成に従って、アクセスにlocalhost：80ポートをローカルで使用します。リダイレクトが有効にならない場合、リダイレクトは現在のlocalhost：80パスに留まり、ブラウザーのアドレスバーアドレスは変更されません。動作する場合アドレスバーのアドレスはlocalhost：8080になります。

2.8その他の負荷分散戦略

サードパーティのプラグインをインストールする必要があるため、確認する時間はありません。

#4、fair（第三方）
#按后端服务器的响应时间来分配请求，响应时间短的优先分配。
upstream fair_strategy {
    
    
    server glmapper.net:8080; # 应用服务器1
    server glmapper.net:8081; # 应用服务器2
    fair;
}

#5、url_hash（第三方）
#按访问url的hash结果来分配请求，使每个url定向到同一个后端服务器，
#后端服务器为缓存时比较有效。
upstream url_hash_strategy {
    
    
    server glmapper.net:8080; # 应用服务器1
    server glmapper.net:8081; # 应用服务器2
    hash $request_uri;
    hash_method crc32;
}

3つ目は、Nginx + SpringBootが負荷分散を実現することです。

環境への備え

• JDK1.8以降に依存します。
• Nginx環境に依存します。

ここでのプロジェクトは、以前のSpringbootプロジェクトであるSpringBootのプロジェクトアドレスを使用しています：https：//github.com/xuwujing/s ...

まず、このプロジェクトをダウンロードし、次のように入力しmvn clean packageます。プロジェクトをjarファイルにパッケージ化しapplication.properties、jarプロジェクトをフォルダーに入れてから、フォルダーをコピーします（ここでは、わかりやすくするために、コピーします。実際にはコピーせず、ポートを変更します）。再起動します。）、コピーしたフォルダのapplication.propertiesポートを変更します。たとえば、8086に変更します。

Nginx構成

nginx / conf / nginx.confディレクトリにあるnginx構成ファイルnginx.confを見つけ、構成を変更して次の構成を追加します。

upstream pancm{
   server 127.0.0.1:8085;
   server 127.0.0.1:8086;
}

• アップストリームpancm：好きな名前を定義します。
• サーバー+ IP：ポートまたはドメイン名。

ラウンドロビン戦略を使用したくない場合は、別の戦略に切り替えることもできます。

次に、サーバーで次の構成を追加/変更します。

server {
    
    
        listen       80;
        server_name  127.0.0.1;
        location / {
    
    
            root   html;
            proxy_pass http://pancm;
            proxy_connect_timeout 3s;
            proxy_read_timeout 5s;
            proxy_send_timeout 3s;
            index  index.html index.htm;
        }
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
    
    
            root   html;
        }
    }

構成手順：

• サーバー：仮想ホストの名前。1つのhttpで複数のサーバーを構成できます。
• リッスン：Nginxのデフォルトポート。
• server_name：Nginxサービスのアドレス。ドメイン名を使用でき、複数のスペースを区切ります。
• proxy_pass：プロキシパス。通常、負荷分散を実現するためにアップストリームの背後にある名前を構成します。ジャンプするようにipを直接構成できます。

nginx.confの完全な構成：

events {
    
    
    worker_connections  1024;
}
error_log nginx-error.log info;
http {
    
    
    include       mime.types;
    default_type  application/octet-stream;
    sendfile        on;
    keepalive_timeout  65;
      upstream pancm{
    
    
       server 127.0.0.1:8085;
       server 127.0.0.1:8086;
    }
    
    server {
    
    
        listen       80;
        server_name  127.0.0.1;
        location / {
    
    
            root   html;
            proxy_pass http://pancm;
            proxy_connect_timeout 3s;
            proxy_read_timeout 5s;
            proxy_send_timeout 3s;
            index  index.html index.htm;
        }
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
    
    
            root   html;
        }
    }
}

負荷分散テスト

Nginxの構成が完了したら、Nginxを起動します。Linuxの入力/usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/nginx.confすでに使用して開始した場合、/usr/local/nginx/sbin/nginx -s reloadコマンドの熱負荷の設定ファイルを、Windowsが単にnginxのディレクトリの下クリックnginx.exeまたはcmd実行中のstart nginxブートがまだ使用できる場合は、スタートnginx -s reload熱負荷を。

Nginxの起動が完了したら、ダウンロードしたSpringbootを起動し、ポートを変更するプロジェクトをコピーして、次のように入力します：java -jar springboot-jsp-thymeleaf.jarstart。

起動が成功したら、ブラウザにサービスのIPを入力してサービスにアクセスできます。

サンプルグラフ：

注：ここでは、テストにWindowsシステムを使用していますが、実際のLinuxは同じです。

次に、コンソールログを確認します。

上記の例の図から、4つのインターフェイス更新要求を行い、最終的にそれらを2つのサービスに均等に分散しました。上記のテスト結果から、負荷分散を実現しました。

ここでは、Nginxを使用する際の注意事項について説明します。学習とテストを行う場合、負荷分散を実現するためにnginxのデフォルトのポートを使用しても問題はありませんが、プロジェクトで使用する場合は、ログインインターフェイスとポートがあります。が80でない場合、リダイレクトできないログインインターフェイスがあります。デバッグ中の場合、net :: ERR_NAME_NOT_RESOLVEDのようなエラーが表示されます。これは、nginxのデフォルトポートが80であるため、デフォルトのジャンプはまた、これ、つまりこれこの場合、locationの下にproxy_set_header Host $ host：port構成を追加する必要があり、ポートとリッスンポートは同じである必要があります。