1、haproxy 能同時配置兩個ssl證書嗎
Apache 2.4
WINDOWS 2012 IIS8
以上環境才支持2個SSL證書，如果不支持的，需要淘一個多域名SSL證書。
2、阿里雲ip的地址能不能從http改成https
如果你的應用使用SSL證書，則需要決定如何在負載均衡器上使用它們。
單伺服器的簡單配置通常是考慮客戶端SSL連接如何被接收請求的伺服器解碼。由於負載均衡器處在客戶端和更多伺服器之間，SSL連接解碼就成了需要關注的焦點。
2、有兩種主要的策略
第一種是我們選擇的模式，在haproxy這里設定SSL，這樣我們可以繼續使用七層負載均衡。SSL連接終止在負載均衡器haproxy ----->解碼SSL連接並發送非加密連接到後端應用tomcat，這意味著負載均衡器負責解碼SSL連接，這與SSL穿透相反，它是直接向代理伺服器發送SSL連接的。
第二種使用SSL穿透，SSL連接在每個tomcat伺服器終止，將CPU負載都分散到tomcat伺服器。然而，這樣做會讓你失去增加或修改HTTP報頭的能力，因為連接只是簡單地從負載均衡器路由到tomcat伺服器，這意味著應用伺服器會失去獲取 X-Forwarded-* 報頭的能力，這個報頭包含了客戶端IP地址、埠和使用的協議。
有兩種策略的組合做法，那就是第三種，SSL連接在負載均衡器處終止，按需求調整，然後作為新的SSL連接代理到後台伺服器。這可能會提供最大的安全性和發送客戶端信息的能力。這樣做的代價是更多的CPU能耗和稍復雜一點的配置。
3、haproxy 負載均衡有沒有辦法在日誌中看到客戶端做訪問的域名？後端是squid緩存伺服器。
HAProxy提供高可用性、負載均衡以及基於TCP和HTTP應用的代理，支持虛擬主機，它是免費、快速並且可靠的一種解決方案。根據官方數據，其最高極限支持10G的並發。
HAProxy特別適用於那些負載特大的web站點， 這些站點通常又需要會話保持或七層處理。HAProxy運行在當前的硬體上，完全可以支持數以萬計的並發連接。並且它的運行模式使得它可以很簡單安全的整合進您當前的架構中， 同時可以保護你的web伺服器不被暴露到網路上。
4、怎麼把http請求變成https
這個暫時沒有好的辦法解決，因為https的頁面存在http的鏈接，瀏覽器認為是版不安全的，有可能會阻止權內容，只能是百度地圖的js改為https的才能完美兼容——沃通（wosign）專業的數字證書ca機構
5、haproxy 後斷伺服器可以寫域名嗎
HAProxy提供高可用性、負載均衡以及基於TCP和HTTP應用的代理，支持虛擬主機，它是免費、快速並且可靠的一種解決方案。根據官方數據，其最高極限支持10G的並發。
HAProxy特別適用於那些負載特大的web站點， 這些站點通常又需要會話保持或七層處理。HAProxy運行在當前的硬體上，完全可以支持數以萬計的並發連接。並且它的運行模式使得它可以很簡單安全的整合進您當前的架構中， 同時可以保護你的web伺服器不被暴露到網路上。
6、HAProxy 可以基於請求的 SNI 域名配置 server 嗎
HAProxy提供高可用性、負載均衡以及基於TCP和HTTP應用的代理，支持虛擬主機，它是免費、快速並且可靠的一種解決方案。根據官方數據，其最高極限支持10G的並發。
HAProxy特別適用於那些負載特大的web站點， 這些站點通常又需要會話保持或七層處理。HAProxy運行在當前的硬體上，完全可以支持數以萬計的並發連接。並且它的運行模式使得它可以很簡單安全的整合進您當前的架構中， 同時可以保護你的web伺服器不被暴露到網路上。
7、如何在haproxy配置可以正向代理https
第一種方式：haproxy伺服器本身提供ssl證書
第二種方式：haproxy伺服器本身只提供代理，沒有ssl證書 （一般我們常用的就是這種方式）
8、haproxy怎麼負載nginx的https協議
依賴客戶端來實現分布式讀寫；主從復制時，每次從節點重新連接主節點都要依賴整個快照,無增量復制，因性能和效率問題，
所以單點問題比較復雜；不支持自動sharding,需要依賴程序設定一致hash 機制。
9、如何把一個web集群由HTTP轉換為HTTPS
1、概述
如果你的應用使用SSL證書，則需要決定如何在負載均衡器上使用它們。
單伺服器的簡單配置通常是考慮客戶端SSL連接如何被接收請求的伺服器解碼。由於負載均衡器處在客戶端和更多伺服器之間，SSL連接解碼就成了需要關注的焦點。
2、有兩種主要的策略
第一種是我們選擇的模式，在haproxy這里設定SSL，這樣我們可以繼續使用七層負載均衡。SSL連接終止在負載均衡器haproxy ----->解碼SSL連接並發送非加密連接到後端應用tomcat，這意味著負載均衡器負責解碼SSL連接，這與SSL穿透相反，它是直接向代理伺服器發送SSL連接的。
第二種使用SSL穿透，SSL連接在每個tomcat伺服器終止，將CPU負載都分散到tomcat伺服器。然而，這樣做會讓你失去增加或修改HTTP報頭的能力，因為連接只是簡單地從負載均衡器路由到tomcat伺服器，這意味著應用伺服器會失去獲取 X-Forwarded-* 報頭的能力，這個報頭包含了客戶端IP地址、埠和使用的協議。
有兩種策略的組合做法，那就是第三種，SSL連接在負載均衡器處終止，按需求調整，然後作為新的SSL連接代理到後台伺服器。這可能會提供最大的安全性和發送客戶端信息的能力。這樣做的代價是更多的CPU能耗和稍復雜一點的配置。
選擇哪個策略取決於你及應用的需求。SSL終端為我所見過最典型的策略，但SSL穿透可能會更安全。
3、使用HAProxy作為SSL終端
首先，我們將介紹最典型的解決方案 - SSL 終端。正如前面提到的，我們需要讓負載均衡器處理SSL連接。這就意味著要將SSL證書放在負載均衡伺服器上。
記住，在生產環境里使用（而不是自簽名）的SSL證書，是不會需要你自己來生成或簽名 - 你只需要創建證書簽名請求 (csr) 並把它交給那個你向它購買證書的機構即可。
首先， 我們創建一份自簽名的證書作為示範，並在本地使用同一份證書。
openssl genrsa -out /etc/haproxy/wzlinux.key 2048
openssl req -new -key /etc/haproxy/wzlinux.key -out /etc/haproxy/wzlinux.csr
> Country Name (2 letter code) [AU]:CN
> State or Province Name (full name) [Some-State]:Shanghai
> Locality Name (eg, city) []:Shanghai
> Organization Name (eg, company) [Internet Widgits Pty Ltd]:wzlinux
> Organizational Unit Name (eg, section) []:
> Common Name (e.g. server FQDN or YOUR name) []:www.wzlinux.com
> Email Address []:
> Please enter the following 'extra' attributes to be sent with your certificate request
> A challenge password []:
> An optional company name []:
cd /etc/haproxy
openssl x509 -req -days 3655 -in wzlinux.csr -signkey wzlinux.key -out wzlinux.crt
這就生成了wzlinux.csr，wzlinux.key和wzlinux.crt文件了。
接著，在創建了證書之後，我們需要創建pem文件。pem文件本質上只是將證書、密鑰及證書認證中心證書（可有可無）拼接成一個文件。在我們的例子中，我們只是簡單地將證書及密鑰文件並以這個順序拼接在一樣來創建wzlinux.pem 文件。這是HAProxy讀取SSL證書首選的方式。
cat wzlinux.crt wzlinux.key | tee wzlinux.pem
當購買真正的證書 時，你不一定會獲取拼接後的文件。你可以要自己拼接它們。然而，很多機構也會提供一份拼接好的文件給你。如果你沒有獲取到拼接後的文件，則它可能不是一個 pem 文件，而是 bundle、cert、cert、key文件或一些相同概念但名稱類似的文件。
無論如何，只要我們得到了HAProxy使用的pem文件，我們只需經過簡單配置就是可以處理SSL連接了。
下面我們將要配置haproxy來安裝SSL證書，配置文件如下
#---------------------------------------------------------------------
# Example configuration for a possible web application. See the
# full configuration options online.
#
# http://haproxy.1wt.eu/download/1.4/doc/configuration.txt
#
#---------------------------------------------------------------------
#---------------------------------------------------------------------
# Global settings
#---------------------------------------------------------------------
global
# to have these messages end up in /var/log/haproxy.log you will
# need to:
#
# 1) configure syslog to accept network log events. This is done
# by adding the '-r' option to the SYSLOGD_OPTIONS in
# /etc/sysconfig/syslog
#
# 2) configure local2 events to go to the /var/log/haproxy.log
# file. A line like the following can be added to
# /etc/sysconfig/syslog
#
# local2.* /var/log/haproxy.log
#
log 127.0.0.1 local2 warning
chroot /var/lib/haproxy
pidfile /var/run/haproxy.pid
maxconn 400000
user haproxy
group haproxy
daemon
tune.ssl.default-dh-param 2048
# nbproc 3
# turn on stats unix socket
stats socket /var/lib/haproxy/stats
#---------------------------------------------------------------------
# common defaults that all the 'listen' and 'backend' sections will
# use if not designated in their block
#---------------------------------------------------------------------
defaults
mode http
log global
option httplog
option dontlognull
option http-server-close
option forwardfor except 127.0.0.0/8
option redispatch
option httpclose
retries 3
timeout http-request 10s
timeout queue 1m
timeout connect 10s
timeout client 1m
timeout server 1m
timeout http-keep-alive 10s
timeout check 10s
stats enable
stats hide-version
stats uri /haproxy?status
stats realm Haproxy\ Statistics
stats auth admin:asd870719
# stats admin if TRUE
#---------------------------------------------------------------------
# main frontend which proxys to the backends
#---------------------------------------------------------------------
#frontend main *:5000
# acl url_static path_beg -i /static /images /javascript /stylesheets
# acl url_static path_end -i .jpg .gif .png .css .js
# use_backend static if url_static
# default_backend app
frontend wzlinux_ssl
bind *:80
bind *:443 ssl crt /etc/haproxy/wzlinux.pem
mode http
default_backend wzlinux
#---------------------------------------------------------------------
# static backend for serving up images, stylesheets and such
#---------------------------------------------------------------------
#backend static
# balance roundrobin
# server static 127.0.0.1:4331 check
backend wzlinux
mode http
balance roundrobin
option forwardfor
# option httpchk HEAD / HTTP/1.1\r\nHost:localhost
server wzlinux01 10.0.0.9:8080 check inter 15000 rise 2 fall 4
server wzlinux02 10.0.0.9:8081 check inter 15000 rise 2 fall 4
server wzlinux03 10.0.0.9:8082 check inter 15000 rise 2 fall 4
server wzlinux04 10.0.0.9:8083 check inter 15000 rise 2 fall 4
server wzlinux05 10.0.0.9:8084 check inter 15000 rise 2 fall 4
server wzlinux06 10.0.0.9:8085 check inter 15000 rise 2 fall 4
server wzlinux07 10.0.0.9:8086 check inter 15000 rise 2 fall 4
# http-request set-header X-Forwarded-Port %[dst_port]
# http-request add-header X-Forwarded-Proto https if { ssl_fc }
因為 SSL 連接在負載均衡器上終止了，我們依然來發送正常的 HTTP 請求到後台伺服器。
只接受SSL連接
如果你想讓網站只接受SSL連接，你可以添加向前端配置加上redirect導向：
frontend wzlinux_ssl
bind *:80
bind *:443 ssl crt /etc/haproxy/wzlinux.pem
redirect scheme https if !{ ssl_fc }
mode http
default_backend wzlinux
上面，我們添加了 redirect 導向，如果連接不是通過SSL連接的，它將http重定向到https。
4、使用HAProxy實現SSL穿透
使用SSL穿透，我們將讓後台伺服器處理SSL連接，而非負載均衡器來處理。
負載均衡器的工作就只是簡單地將請求轉發到配置好的後台伺服器。因為連接還保持加密狀態,HAProxy只能將它轉發給其他伺服器，其他事情就沒法做了。
在這個配置中，我們需要在前端和後台配置中同時使用TCP模式而不是HTTP模式。HAProxy只會把連接當作信息流來轉發到其他伺服器，而不會使用在HTTP請求上才能使用的功能。
首先，我們調整一下前端配置：
frontend wzlinux_ssl
bind *:80
bind *:443
option tcplog
mode tcp
default_backend wzlinux
這里依然同時綁定80和443埠，以保證正常的HTTP連接和SSL連接都能工作。
正如上述提到的，轉發一個安全連接而伺服器而不作任何解碼，我們需要使用TCP模式(mode tcp)。這也意味著我們需要設置tcp日誌而不是默認的http日誌（option tcplog）。
接著，我們要調整後台end配置。注意，我們還要將這個更改成TCP模式，並刪除一些directives以避免因為修改/增加HTTP報頭功能所帶來的沖突：
backend wzlinux
mode tcp
balance roundrobin
option ssl-hello-chk
server wzlinux01 10.0.0.9:8080 check inter 15000 rise 2 fall 4
server wzlinux02 10.0.0.9:8081 check inter 15000 rise 2 fall 4
server wzlinux03 10.0.0.9:8082 check inter 15000 rise 2 fall 4
server wzlinux04 10.0.0.9:8083 check inter 15000 rise 2 fall 4
server wzlinux05 10.0.0.9:8084 check inter 15000 rise 2 fall 4
server wzlinux06 10.0.0.9:8085 check inter 15000 rise 2 fall 4
server wzlinux07 10.0.0.9:8086 check inter 15000 rise 2 fall 4
正如你所看到的，這里設置成了mode tcp - 前端和後台配置都需要設置成這個模式。
我們還刪除了option forwardfor和http-request選項 - 這些不能用於TCP模式，而且我們也不能向已加密的請求添加報頭，還有一些前面的默認配置也刪去關於http的配置，這里不再演示。
為了檢查正確與否，我們可以使用ssl-hello-chk來檢查連接及它處理SSL（特別是SSLv3）連接的能力。
在這個例子中，我虛構了兩個接受SSL證書的後台伺服器。如果你有閱讀過 edition SSL certificates ，你會看到如何將它們集成到 Apache 或 Nginx 來創建一個網路伺服器後台，以處理SSL通信。使用SSL 穿越，不需要給HAProxy創建或使用SSL證書。後台伺服器都能夠處理SSL連接，如同只有一台伺服器且沒有使用負載均衡器那樣。
10、nginx lvs haproxy哪個用的多
一、lvs的優勢：
1、抗負載能力強，因為lvs工作方式的邏輯是非常之簡單，而且工作在網路4層僅做請求分發之用，沒有流量，所以在效率上基本不需要太過考慮。在我手裡的 lvs，僅僅出過一次問題：在並發最高的一小段時間內均衡器出現丟包現象，據分析為網路問題，即網卡或linux2.4內核的承載能力已到上限，內存和 cpu方面基本無消耗。
2、配置性低，這通常是一大劣勢，但同時也是一大優勢，因為沒有太多可配置的選項，所以除了增減伺服器，並不需要經常去觸碰它，大大減少了人為出錯的幾率。
3、工作穩定，因為其本身抗負載能力很強，所以穩定性高也是順理成章，另外各種lvs都有完整的雙機熱備方案，所以一點不用擔心均衡器本身會出什麼問題，節點出現故障的話，lvs會自動判別，所以系統整體是非常穩定的。
4、無流量，上面已經有所提及了。lvs僅僅分發請求，而流量並不從它本身出去，所以可以利用它這點來做一些線路分流之用。沒有流量同時也保住了均衡器的IO性能不會受到大流量的影響。
5、基本上能支持所有應用，因為lvs工作在4層，所以它可以對幾乎所有應用做負載均衡，包括http、資料庫、聊天室等等。
另：lvs也不是完全能判別節點故障的，譬如在wlc分配方式下，集群里有一個節點沒有配置VIP，會使整個集群不能使用，這時使用wrr分配方式則會丟掉一台機。目前這個問題還在進一步測試中。所以，用lvs也得多多當心為妙。
二、nginx和lvs作對比的結果
1、nginx工作在網路的7層，所以它可以針對http應用本身來做分流策略，比如針對域名、目錄結構等，相比之下lvs並不具備這樣的功能，所以 nginx單憑這點可利用的場合就遠多於lvs了；但nginx有用的這些功能使其可調整度要高於lvs，所以經常要去觸碰觸碰，由lvs的第2條優點 看，觸碰多了，人為出問題的幾率也就會大。
2、nginx對網路的依賴較小，理論上只要ping得通，網頁訪問正常，nginx就能連得通，nginx同時還能區分內外網，如果是同時擁有內外網的 節點，就相當於單機擁有了備份線路；lvs就比較依賴於網路環境，目前來看伺服器在同一網段內並且lvs使用direct方式分流，效果較能得到保證。另 外注意，lvs需要向託管商至少申請多一個ip來做Visual IP，貌似是不能用本身的IP來做VIP的。要做好LVS管理員，確實得跟進學習很多有關網路通信方面的知識，就不再是一個HTTP那麼簡單了。
3、nginx安裝和配置比較簡單，測試起來也很方便，因為它基本能把錯誤用日誌列印出來。lvs的安裝和配置、測試就要花比較長的時間了，因為同上所述，lvs對網路依賴比較大，很多時候不能配置成功都是因為網路問題而不是配置問題，出了問題要解決也相應的會麻煩得多。
4、nginx也同樣能承受很高負載且穩定，但負載度和穩定度差lvs還有幾個等級：nginx處理所有流量所以受限於機器IO和配置；本身的bug也還是難以避免的；nginx沒有現成的雙機熱備方案，所以跑在單機上還是風險較大，單機上的事情全都很難說。
5、nginx可以檢測到伺服器內部的故障，比如根據伺服器處理網頁返回的狀態碼、超時等等，並且會把返回錯誤的請求重新提交到另一個節點。目前lvs中 ldirectd也能支持針對伺服器內部的情況來監控，但lvs的原理使其不能重發請求。重發請求這點，譬如用戶正在上傳一個文件，而處理該上傳的節點剛 好在上傳過程中出現故障，nginx會把上傳切到另一台伺服器重新處理，而lvs就直接斷掉了，如果是上傳一個很大的文件或者很重要的文件的話，用戶可能 會因此而惱火。
6、nginx對請求的非同步處理可以幫助節點伺服器減輕負載，假如使用apache直接對外服務，那麼出現很多的窄帶鏈接時apache伺服器將會佔用大 量內存而不能釋放，使用多一個nginx做apache代理的話，這些窄帶鏈接會被nginx擋住，apache上就不會堆積過多的請求，這樣就減少了相 當多的內存佔用。這點使用squid也有相同的作用，即使squid本身配置為不緩存，對apache還是有很大幫助的。lvs沒有這些功能，也就無法能 比較。
7、nginx能支持http和email（email的功能估計比較少人用），lvs所支持的應用在這點上會比nginx更多。
在使用上，一般最前端所採取的策略應是lvs，也就是DNS的指向應為lvs均衡器，lvs的優點令它非常適合做這個任務。
重要的ip地址，最好交由lvs託管，比如資料庫的ip、webservice伺服器的ip等等，這些ip地址隨著時間推移，使用面會越來越大，如果更換ip則故障會接踵而至。所以將這些重要ip交給lvs託管是最為穩妥的，這樣做的唯一缺點是需要的VIP數量會比較多。
nginx可作為lvs節點機器使用，一是可以利用nginx的功能，二是可以利用nginx的性能。當然這一層面也可以直接使用squid，squid的功能方面就比nginx弱不少了，性能上也有所遜色於nginx。
nginx也可作為中層代理使用，這一層面nginx基本上無對手，唯一可以撼動nginx的就只有lighttpd了，不過lighttpd目前還沒有 能做到nginx完全的功能，配置也不那麼清晰易讀。另外，中層代理的IP也是重要的，所以中層代理也擁有一個VIP和lvs是最完美的方案了。
nginx也可作為網頁靜態伺服器，不過超出了本文討論的范疇，簡單提一下。
具體的應用還得具體分析，如果是比較小的網站（日PV<1000萬），用nginx就完全可以了，如果機器也不少，可以用DNS輪詢，lvs所耗費的機器還是比較多的；大型網站或者重要的服務，機器不發愁的時候，要多多考慮利用lvs。
****************************************************************************************************************
Nginx的優點:
性能好，可以負載超過1萬的並發。
功能多，除了負載均衡，還能作Web伺服器，而且可以通過Geo模塊來實現流量分配。
社區活躍，第三方補丁和模塊很多
支持gzip proxy
缺點:
不支持session保持。
對後端realserver的健康檢查功能效果不好。而且只支持通過埠來檢測，不支持通過url來檢測。
nginx對big request header的支持不是很好，如果client_header_buffer_size設置的比較小，就會返回400bad request頁面。
Haproxy的優點:
它的優點正好可以補充nginx的缺點。支持session保持，同時支持通過獲取指定的url來檢測後端伺服器的狀態。
支持tcp模式的負載均衡。比如可以給mysql的從伺服器集群和郵件伺服器做負載均衡。
缺點：
不支持虛擬主機(這個很傻啊)
目前沒有nagios和cacti的性能監控模板
LVS的優點:
性能好，接近硬體設備的網路吞吐和連接負載能力。
LVS的DR模式，支持通過廣域網進行負載均衡。這個其他任何負載均衡軟體目前都不具備。
缺點：
比較重型。另外社區不如nginx活躍。
*************************************************************************************
現在網路中常見的的負載均衡主要分為兩種：一種是通過硬體來進行進行，常見的硬體有比較昂貴的NetScaler、F5、Radware和Array等商用的負載均衡器，也有類似於LVS、Nginx、HAproxy的基於Linux的開源的負載均衡策略,
商用負載均衡裡面NetScaler從效果上比F5的效率上更高。對於負載均衡器來說，不過商用負載均衡由於可以建立在四~七層協議之上，因此適用 面更廣所以有其不可替代性，他的優點就是有專業的維護團隊來對這些服務進行維護、缺點就是花銷太大，所以對於規模較小的網路服務來說暫時還沒有需要使用。
另一種負載均衡的方式是通過軟體：比較常見的有LVS、Nginx、HAproxy等，其中LVS是建立在四層協議上面的，而另外Nginx和HAproxy是建立在七層協議之上的，下面分別介紹關於
LVS：使用集群技術和Linux操作系統實現一個高性能、高可用的伺服器，它具有很好的可伸縮性（Scalability）、可靠性（Reliability）和可管理性（Manageability）。
LVS的特點是：
1、抗負載能力強、是工作在網路4層之上僅作分發之用，沒有流量的產生；
2、配置性比較低，這是一個缺點也是一個優點，因為沒有可太多配置的東西，所以並不需要太多接觸，大大減少了人為出錯的幾率；
3、工作穩定，自身有完整的雙機熱備方案；
4、無流量，保證了均衡器IO的性能不會收到大流量的影響；
5、應用范圍比較廣，可以對所有應用做負載均衡；
6、LVS需要向IDC多申請一個IP來做Visual IP，因此需要一定的網路知識，所以對操作人的要求比較高。
Nginx的特點是：
1、工作在網路的7層之上，可以針對http應用做一些分流的策略，比如針對域名、目錄結構；
2、Nginx對網路的依賴比較小；
3、Nginx安裝和配置比較簡單，測試起來比較方便；
4、也可以承擔高的負載壓力且穩定，一般能支撐超過1萬次的並發；
5、Nginx可以通過埠檢測到伺服器內部的故障，比如根據伺服器處理網頁返回的狀態碼、超時等等，並且會把返回錯誤的請求重新提交到另一個節點，不過其中缺點就是不支持url來檢測；
6、Nginx對請求的非同步處理可以幫助節點伺服器減輕負載；
7、Nginx能支持http和Email，這樣就在適用范圍上面小很多；
8、不支持Session的保持、對Big request header的支持不是很好，另外默認的只有Round-robin和IP-hash兩種負載均衡演算法。
HAProxy的特點是：
1、HAProxy是工作在網路7層之上。
2、能夠補充Nginx的一些缺點比如Session的保持，Cookie的引導等工作
3、支持url檢測後端的伺服器出問題的檢測會有很好的幫助。
4、更多的負載均衡策略比如：動態加權輪循(Dynamic Round Robin)，加權源地址哈希(Weighted Source Hash)，加權URL哈希和加權參數哈希(Weighted Parameter Hash)已經實現
5、單純從效率上來講HAProxy更會比Nginx有更出色的負載均衡速度。
6、HAProxy可以對Mysql進行負載均衡，對後端的DB節點進行檢測和負載均衡。
***********************************************************************************************
現在網站發展的趨勢對網路負載均衡的使用是隨著網站規模的提升根據不同的階段來使用不同的技術：
第一階段：利用Nginx或者HAProxy進行單點的負載均衡，這一階段伺服器規模剛脫離開單伺服器、單資料庫的模式，需要一定的負載均衡，但是 仍然規模較小沒有專業的維護團隊來進行維護，也沒有需要進行大規模的網站部署。這樣利用Nginx或者HAproxy就是第一選擇，此時這些東西上手快， 配置容易，在七層之上利用HTTP協議就可以。這時是第一選擇
第二階段：隨著網路服務進一步擴大，這時單點的Nginx已經不能滿足，這時使用LVS或者商用F5就是首要選擇，Nginx此時就作為LVS或者 F5的節點來使用，具體LVS或者F5的是選擇是根據公司規模，人才以及資金能力來選擇的，這里也不做詳談，但是一般來說這階段相關人才跟不上業務的提 升，所以購買商業負載均衡已經成為了必經之路。
第三階段：這時網路服務已經成為主流產品，此時隨著公司知名度也進一步擴展，相關人才的能力以及數量也隨之提升，這時無論從開發適合自身產品的定製，以及降低成本來講開源的LVS，已經成為首選，這時LVS會成為主流。
最終形成比較理想的狀態為：F5/LVS<—>Haproxy<—>Squid/Varnish<—>AppServer。