目錄

一、Nginx概述

1.1 負載均衡概述

1.2 負載均衡的作用

1.3 四/七層負載均衡

1.3.1 網(wǎng)絡(luò)模型簡介

1.3.2 四層和七層負載均衡對比

1.3.3 Nginx七層負載均衡實現(xiàn)

1.4 Nginx負載均衡配置

1.5 Nginx負載均衡狀態(tài)

1.6 Nginx負載均衡策略

二、負載均衡實戰(zhàn)

2.1 測試服務(wù)器

2.2 普通輪詢

2.2.1 實現(xiàn)效果

2.2.2 準備工作

2.2.3 實現(xiàn)

2.3 weight加權(quán)（加權(quán)輪詢）

2.3.1 實現(xiàn)效果

2.3.2 準備工作

2.3.3 實現(xiàn)

2.4 ip_hash

2.5 url_hash

2.6 fair

三、阿里云傳統(tǒng)型負載均衡CLB

3.1 概述

3.2CLB組成

3.3 產(chǎn)品優(yōu)勢

3.4 阿里云控制臺配置SLB

Nginx系列之 一 入門安裝_開著拖拉機回家的博客-CSDN博客

Nginx系列之 一 反向代理_開著拖拉機回家的博客-CSDN博客

一、Nginx概述

隨著社會越來越快的發(fā)展，信息化和數(shù)字化建設(shè)蓬勃發(fā)展，用戶訪問服務(wù)的數(shù)量也隨之驟增，依靠單設(shè)備硬件愈發(fā)不能滿足高并發(fā)下的大量網(wǎng)絡(luò)請求，因此負載均衡（LB）應(yīng)用而生。

1.1 負載均衡概述

所謂負載均衡，就是 Nginx 把請求分攤給上游的應(yīng)用服務(wù)器，這樣即使某一個服務(wù)器宕機也不會影響請求的處理，或者當應(yīng)用服務(wù)器扛不住了，可以隨時進行擴容。

應(yīng)用集群：將同一應(yīng)用部署到多臺機器上，組成處理集群，接收負載均衡設(shè)備分發(fā)的請求，進行處理并返回響應(yīng)的數(shù)據(jù)。

負載均衡器: 將用戶訪問的請求根據(jù)對應(yīng)的負載均衡算法，分發(fā)到集群中的一臺服務(wù)器進行處理。

1.2 負載均衡的作用

1、解決服務(wù)器的高并發(fā)壓力，提高應(yīng)用程序的處理性能。

2、提供故障轉(zhuǎn)移，實現(xiàn)服務(wù)高可用和可靠性。

3、通過增加或減少服務(wù)器數(shù)量，增強網(wǎng)站的可擴展性。

4、在負載均衡器上進行過濾，可以提高系統(tǒng)的安全性。

1.3 四/七層負載均衡

1.3.1 網(wǎng)絡(luò)模型簡介

OSI（Open System Interconnection，開放式系統(tǒng)互聯(lián)模型）是由國際標準化組織ISO指定的一個不基于具體機型、操作系統(tǒng)或公司的網(wǎng)絡(luò)體系結(jié)構(gòu)。該模型將網(wǎng)絡(luò)通信的工作分為七層。

負載均衡主要分為四層和七層負載均衡，對應(yīng)osi七層模型的四層和七層。

四層負載均衡工作在OSI模型的第四層-傳輸層，由于在傳輸層，只有TCP/UDP協(xié)議，這兩種協(xié)議中除了包含源IP、目標IP以外，還包含源端口號及目的端口號。

四層負載均衡 服務(wù)器在接受到客戶端請求后，以后通過修改數(shù)據(jù)包的地址信息（IP+端口號）將流量轉(zhuǎn)發(fā)到應(yīng)用服務(wù)器。

七層負載均衡工作在OSI模型的應(yīng)用層，應(yīng)用層協(xié)議較多，常用http、radius、dns等。七層負載就可以基于這些協(xié)議來負載。這些應(yīng)用層協(xié)議中會包含很多有意義的內(nèi)容。比如同一個Web服務(wù)器的負載均衡，除了根據(jù)IP加端口進行負載外，還可根據(jù)七層的URL、瀏覽器類別、語言來決定是否要進行負載均衡。

1.3.2 四層和七層負載對比

（1）智能性

七層負載均衡由于具備OIS七層的所有功能，所以在處理用戶需求上能更加靈活，從理論上講，七層模型能對用戶的所有跟服務(wù)端的請求進行修改。例如對文件header添加信息，根據(jù)不同的文件類型進行分類轉(zhuǎn)發(fā)。四層模型僅支持基于網(wǎng)絡(luò)層的需求轉(zhuǎn)發(fā)，不能修改用戶請求的內(nèi)容。

（2）安全性

七層負載均衡由于具有OSI模型的全部功能，能更容易抵御來自網(wǎng)絡(luò)的攻擊；四層模型從原理上講，會直接將用戶的請求轉(zhuǎn)發(fā)給后端節(jié)點，無法直接抵御網(wǎng)絡(luò)攻擊。

（3）復(fù)雜度

四層模型一般比較簡單的架構(gòu)，容易管理，容易定位問題；七層模型架構(gòu)比較復(fù)雜，通常也需要考慮結(jié)合四層模型的混用情況，出現(xiàn)問題定位比較復(fù)雜。

（4）效率比

四層模型基于更底層的設(shè)置，通常效率更高，但應(yīng)用范圍有限；七層模型需要更多的資源損耗，在理論上講比四層模型有更強的功能，現(xiàn)在的實現(xiàn)更多是基于http應(yīng)用。

實際環(huán)境采用的方式：四層負載（LVS）+七層負載（Nginx）。

1.3.3 Nginx七層負載均衡實現(xiàn)

Nginx要實現(xiàn)七層負載均衡需要用到proxy_pass代理模塊配置， Nginx的負載均衡是在Nginx的反向代理基礎(chǔ)上把用戶的請求根據(jù)指定的算法分發(fā)到一組【upstream虛擬服務(wù)池】。

1.4 Nginx負載均衡配置

nginx.conf

   upstream myserver{
          server 192.168.2.211:8082 max_fails=1 fail_timeout=10s weight=1;
          server 192.168.2.211:8083;
    }
    server {
        listen       9001;
        server_name  www.kangll.com;

        location /edu/ {
            proxy_pass http://myserver;
            root  html;
        }
    }

1.5 Nginx負載均衡狀態(tài)

代理服務(wù)器在負載均衡調(diào)度中的狀態(tài)有以下幾個：

1.6 Nginx負載均衡策略

二、負載均衡實戰(zhàn)

2.1 測試服務(wù)器

2.2 普通輪詢

2.2.1 實現(xiàn)效果

瀏覽器中訪問 kangll.com:9001/edu/a.html , 觀察請求負載均衡的實現(xiàn)效果，請求平均分擔(dān)到節(jié)點192.168.2.211:8082 和192.168.2.211:8083的兩個端口。

2.2.2 準備工作

兩個tomcat 里面webapps目錄 中8083 的 Tomcat 的 webapps 文件夾下新建 edu 文件夾和 a.html 文件，填寫內(nèi)容為 "hello, 8083-Tomcat!" ,對應(yīng)8082 的Tomcat a.html 文件，填寫內(nèi)容為 "hello, 8082-Tomcat!"

2.2.3 實現(xiàn)

nginx.conf 配置

   upstream myserver{
          server 192.168.2.211:8082;
          server 192.168.2.211:8083;
    }
    server {
        listen       80;
        server_name  www.kangll.com;

        location / {
            proxy_pass http://192.168.2.211:8080;
            index  index.html index.htm index.jsp;
        }
    }
    server {
        listen       9001;
        server_name  www.kangll.com;

        location /edu/ {
            proxy_pass http://myserver;
            root  html;
        }
    }

通過瀏覽器訪問： kangll.com:9001/edu/a.html， 刷新頁面 請求的兩次 結(jié)果不一樣。

2.3 weight加權(quán)（加權(quán)輪詢）

? ? ? ? weight=number：用來設(shè)置服務(wù)器的權(quán)重，默認為1，權(quán)重數(shù)字越大，被分配到請求的幾率越大。該權(quán)重值主要是針對實際工作環(huán)境中不同的后端服務(wù)器硬件配置進行調(diào)整的，所以此策略比較適合服務(wù)器的硬件配置差別比較大的情況。

2.3.1 實現(xiàn)效果

瀏覽器中訪問 kangll.com:9001/edu/a.html , 觀察請求負載均衡的實現(xiàn)效果，請求平均分擔(dān)到節(jié)點192.168.2.211:8082 和192.168.2.211:8083的兩個端口。

2.3.2 準備工作

準備三個tomcat 里面webapps目錄 中8083 的 Tomcat 的 webapps 文件夾下新建 edu 文件夾和 a.html 文件，填寫內(nèi)容為 "hello, 8083-Tomcat!" ,對應(yīng)8082 的Tomcat a.html 文件，填寫內(nèi)容為 "hello, 8082-Tomcat!"，對應(yīng)8081 的Tomcat a.html 文件，填寫內(nèi)容為 "hello, 8081-Tomcat!"

2.3.3 實現(xiàn)

配置文件 nginx.conf

http {
   ...
    upstream myserver{
          server 192.168.2.211:8081 weight=10;
          server 192.168.2.211:8082 weight=5;
          server 192.168.2.211:8083 weight=5;
    }
 
    server {
        listen      9888;
        server_name www.kangll.com;

        location ~ / {
           # 被代理服務(wù)器的地址, 可以配置主機、ip 或者地址加端口
            proxy_pass http://myserver;
            index a.html;
            proxy_set_header Host $host;
            proxy_set_header X-real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }
    }

}

通過瀏覽器訪問：http://www.kangll.com:9888/edu/a.html 頁面刷新 10次， 訪問到的 比例為：4：3: 3 。

2.4 ip_hash

? ? ? ?對后端的多臺動態(tài)應(yīng)用服務(wù)器做負載均衡時，ip_hash指令能夠?qū)⒛硞€客戶端IP的請求通過哈希算法定位到同一臺后端服務(wù)器上。當來自某一個IP的用戶在后端Web服務(wù)器A上登錄后，再訪問該站點的其他URL，能保證其訪問的還是后端web服務(wù)器A，可以解決session共享問題。

典型例子：用戶首次訪問一個系統(tǒng)是需要進行登錄身份驗證的，首先將請求跳轉(zhuǎn)到Tomcat1服務(wù)器進行處理，登錄信息是保存在Tomcat1 上的，這時候進行別的操作，那么可能會將請求輪詢到第二個Tomcat2上，那么由于Tomcat2 沒有保存會話信息，會以為該用戶沒有登錄，然后繼續(xù)登錄一次，如果有多個服務(wù)器，每次第一次訪問都要進行登錄，這顯然是很影響用戶體驗的。

? ? ? nginx 基于 IP 路由負載，每次都將同一個 IP 地址發(fā)送的請求都分發(fā)到同一個 Tomcat 服務(wù)器，那么也不會存在 session 共享的問題。

配置文件 nginx.conf

http {
   ...
    upstream myserver{
          ip_hash;
          server 192.168.2.211:8081;
          server 192.168.2.211:8082;
          server 192.168.2.211:8083;
    }
 
    server {
        listen      9888;
        server_name www.kangll.com;

        location ~ / {
           # 被代理服務(wù)器的地址, 可以配置主機、ip 或者地址加端口
            proxy_pass http://myserver;
            index a.html;
            proxy_set_header Host $host;
            proxy_set_header X-real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }
    }

}

注意：使用ip_hash指令無法保證后端服務(wù)器的負載均衡，可能導(dǎo)致有些后端服務(wù)器接收到的請求多，有些后端服務(wù)器接受的請求少，而且設(shè)置后端服務(wù)器權(quán)重等方法將不起作用。

2.5 url_hash

按訪問url的hash結(jié)果來分配請求，使每個 url 定向到同一個后端服務(wù)器，要配合緩存命中來使用。同一個資源多次請求，可能會到達不同的服務(wù)器上，導(dǎo)致不必要的多次下載，緩存命中率不高，以及一些資源時間的浪費。而使用url_hash，可以使得同一個url（也就是同一個資源請求）會到達同一臺服務(wù)器，一旦緩存住了資源，再次收到請求，就可以從緩存中讀取。

nginx.conf

upstream myserver{
          hash $request_uri;
          server 192.168.2.211:8081;
          server 192.168.2.211:8082;
          server 192.168.2.211:8083;
    }
 
    server {
        listen      9888;
        server_name www.kangll.com;

        location ~ / {
           # 被代理服務(wù)器的地址, 可以配置主機、ip 或者地址加端口
            proxy_pass http://myserver;
            index a.html;
            proxy_set_header Host $host;
            proxy_set_header X-real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }
    }

2.6 fair

fair采用的不是內(nèi)建負載均衡使用的均衡算法，而是可以根據(jù)頁面大小、加載時間長短智能地進行負載均衡。

nginx.conf

upstream myserver{
          fair;
          server 192.168.2.211:8081;
          server 192.168.2.211:8082;
          server 192.168.2.211:8083;
    }
 
    server {
        listen      9888;
        server_name www.kangll.com;

        location ~ / {
           # 被代理服務(wù)器的地址, 可以配置主機、ip 或者地址加端口
            proxy_pass http://myserver;
            index a.html;
            proxy_set_header Host $host;
            proxy_set_header X-real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }
    }

三、阿里云傳統(tǒng)型負載均衡CLB

傳統(tǒng)型負載均衡CLB（Classic Load Balancer）是將訪問流量根據(jù)轉(zhuǎn)發(fā)策略分發(fā)到后端多臺云服務(wù)器的流量分發(fā)控制服務(wù)。CLB擴展了應(yīng)用的服務(wù)能力，增強了應(yīng)用的可用性。什么是傳統(tǒng)型負載均衡CLB - 負載均衡 - 阿里云

3.1 概述

CLB通過設(shè)置虛擬服務(wù)地址，將添加的同一地域的多臺云服務(wù)器虛擬成一個高性能和高可用的后端服務(wù)池，并根據(jù)轉(zhuǎn)發(fā)規(guī)則，將來自客戶端的請求分發(fā)給后端服務(wù)器池中的云服務(wù)器。

CLB默認檢查云服務(wù)器池中的云服務(wù)器的健康狀態(tài)，自動隔離異常狀態(tài)的云服務(wù)器，消除了單臺云服務(wù)器的單點故障，提高了應(yīng)用的整體服務(wù)能力。此外，CLB還具備抗DDoS攻擊的能力，增強了應(yīng)用服務(wù)的防護能力。

3.2 CLB組成

說明 上圖中灰色的云服務(wù)器代表該云服務(wù)器健康檢查失敗，流量不會轉(zhuǎn)發(fā)到該云服務(wù)器上。

CLB由以下三個部分組成：

3.3 產(chǎn)品優(yōu)勢

• 高可用采用全冗余設(shè)計，無單點，支持同城容災(zāi)。根據(jù)流量負載進行彈性擴容，在流量波動情況下不中斷對外服務(wù)。
• 可擴展您可以根據(jù)業(yè)務(wù)的需要，隨時增加或減少后端服務(wù)器的數(shù)量，擴展應(yīng)用的服務(wù)能力。
• 低成本與傳統(tǒng)硬件負載均衡系統(tǒng)高投入相比，成本可下降60%。
• 安全結(jié)合云盾，可提供5 Gbps的防DDoS攻擊能力。
• 高并發(fā)集群支持億級并發(fā)連接，單實例最大支持100萬并發(fā)。

3.4 阿里云控制臺配置SLB

創(chuàng)建好的 SLB實例 服務(wù)地址是我們的公網(wǎng)IP

監(jiān)控的是服務(wù)器組

可以看到 第一臺 和第三臺服務(wù)器我們給了相同的權(quán)重 100

總結(jié)：負載均衡之四層與七層_四層負載均衡_小魏的博客的博客-CSDN博客

nginx的七層和四層負載均衡_nginx七層和四層_小魚兒&的博客-CSDN博客

Nginx——Nginx負載均衡_啊噢1231的博客-CSDN博客文章來源地址http://www.zghlxwxcb.cn/news/detail-613099.html

到了這里，關(guān)于Nginx系列之 一 負載均衡的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！