㈠ 國內應用負載均衡比較成熟的技術有哪些
一、應用負載均衡技術：
1）輪循調度(Round-Robin) 它將請求依次分配不同的RS，也就是在RS中均攤請求。這種演算法簡單，但是只適合於伺服器處理性能相差不大的情況。
2）加權輪循調度(Weighted Round-Robin) 它將依據不同伺服器的權值分配任務。權值較高的伺服器將優先獲得任務，並且分配到的連接數將比權值較低的伺服器更多。相同權值的伺服器得到相同數目的連接數。
3）目的地址哈希調度 (Destination Hashing) 以目的地址為關鍵字查找一個靜態hash表來獲得需要的伺服器。
4）源地址哈希調度(Source Hashing) 以源地址為關鍵字查找一個靜態hash表來獲得需要的伺服器。
5）最小連接數調度(Least-Connection)，把新的連接請求發送到當前連接數最小的伺服器。
6）加權最小連接數調度(Weighted Least-Connection) 假設各台伺服器的權值依次為Wi（I = 1..n），當前的TCP連接數依次為Ti（I＝1..n），依次選取Ti/Wi為最小的伺服器作為下一個分配的伺服器。
7）基於地址的最小連接數調度(Locality-Based Least-Connection) 當上一次分配的伺服器不忙（此時權重就是最大連接數）時，將當前來自同一目的地址的請求分配給同一台伺服器，否則採用加權最小連接數調度演算法分配伺服器，並以它為下一次分配的首先考慮。
8）基於地址的帶重復最小連接數調度(Locality-Based Least-Connection with Replication) 對於某一目的地址，對應有一個伺服器子集。對此地址的請求，為它分配子集中連接數最小的伺服器；如果子集中所有的伺服器均已滿負荷，則從集群中選擇一個連接數較小的伺服器，將它加入到此子集並分配連接；若一定時間內，這個子集未被做任何修改，則將子集中負載最大的節點從子集刪除。
9）最短預期延遲調度(Shortest Expected Delay Scheling)（最短延遲調度） 將網路連接分配給具有最短預期延遲的伺服器。
計算方式:當前每台伺服器的當前連接數Ci，權重為Wi，取(Ci+1)/Wi最小的伺服器
10）不排隊調度（Never Queue Scheling）（最快調度）當集群中有一台伺服器空閑時，就將當前的請求發送給此伺服器；否則採用演算法9）最短預期延遲演算法。
二、鏈路負載均衡技術：
採用包括策略路由（基於源地址或者目的地址）、Round Robin（輪詢）、Weighted Round Robin（加權輪詢）、擁塞均衡、備份均衡等演算法，充分滿足用戶差異化需求，最佳利用網路現有帶寬資源，實現流出與流入(Inbound & Outbound)流量的多鏈路負載均衡，為用戶建立最佳質量最佳服務的網路環境。
1）流出流量的負載均衡。對於流出流量進行智能的管理，實現多鏈路下的流出流量均衡，還可以按企業特定的策略選擇出站鏈路，提高鏈路利用率，節約企業對通信鏈路的投資。
目的地址策略路由：根據目的IP地址智能選擇流出路徑，即當目的地址處於某一個ISP的IP地址范圍內時，自動選擇此ISP提供的鏈路。
Round Robin（輪詢）演算法：按照順序選擇多個鏈路出口作為每個數據流的流出路徑
Weighted Round Robin（加權輪詢演算法）：為每條鏈路設置一個權重值，按照權重順序選擇多個鏈路出口作為每個數據流的流出路徑。在多條不同帶寬的鏈路上，設置不同的權重，可以保證每條鏈路利用的均衡。
擁塞均衡演算法：可以為每條鏈路設置擁塞閾值，當鏈路利用率超過閾值時，可以選擇其它利用率較低的鏈路。
備份均衡演算法：當兩條或多條鏈路屬於同一運營商時，可以將某一條鏈路設置為備份鏈路，備份鏈路在主鏈路沒有擁塞時，一直處於閑置狀態，當主鏈路擁塞後，流量才會進入備份鏈路。
2）流入流量負載均衡。採用智能DNS均衡演算法實現企業入站流量在不同ISP鏈路上的流量均衡。
源地址策略路由：根據源IP所處的ISP，來進行智能DNS解析，返回屬於此ISP的IP地址。
Round Robin演算法：順序將多個ISP的地址作為每次用戶解析請求的返回地址。
Weighted Round Robin演算法：為每個ISP提供的鏈路設置權重值，按照權重值順序選擇多個ISP的IP地址返回。
擁塞均衡演算法：為每條鏈路設置擁塞閾值，當鏈路利用率超過閾值時，返回利用率較低的鏈路對應的ISP的IP地址。
㈡ 常見的負載均衡技術
四層負責均衡：主要是指通過判斷報文的IP地址和埠並通過一定的負載均衡演算法來決定轉發到哪個指定目標，主要工作在OSI模型的第四層。四層負載均衡對數據包只是起一個數據轉發的作用，並不會干預客戶端與伺服器之間應用層的通信（如：三次握手等）。所以能對數據所進行的操作也就很少，但相對於七層負載均衡來講效率會高上很多
七層負載均衡：也被稱為「內容交換」，指的是負載均衡設備通過報文中的應用層信息(URL、HTTP頭部等信息)和負載均衡演算法，選擇到達目的的內部伺服器。七層負載均衡可以「智能化」地篩選報文中 應用層信息，然後根據不同的信息進行特定的負載均衡調度。這種方式提升了應用系統在網路層上的靈活性，另外也在一定程度上提升了後端系統的安全性。因為像網路常見的DoS攻擊，這些攻擊在七層負載均衡的環境下通常都在負載均衡設備上就截止了，不會影響到後台伺服器的正常運行。
前網路中常見的負載均衡主要分為硬體負載均衡和軟體負載均衡。硬體負載均衡比較知名的產品有F5 Big-IP、Cirtix Netscaler等等。而軟體負載均衡就有著眾多的開源項目，常見的有Haproxy、nginx、lvs等。
Haproxy：
lvs:
nginx:
Haproxy可以做代理服務相對於nginx而言有很多相同之處，統一可以基於mode tcp進行四層代理也可以基於mode http進行七層代理，但不同的是其無法使用location和if等進行匹配判斷。突出優勢在於有會話綁定，web管理界面，狀態統計非常詳細。官方推薦只啟用一個進程，相對於nginx多進程架構工作並不理想，更多的線程可能會受到系統內存的一些限制。
程序環境：
主程序：/usr/sbin/haproxy
主配置文件：/etc/haproxy/haproxy.cfg
Unit file：/usr/lib/systemd/system/haproxy.service
查看配置文件
重要的幾個參數，及性能調優，多數無需修改
發現日誌發送給本機rsyslog的local2的facility，而本機的rsyslog里並沒有定義，需要我們自己去配置
所以vim /etc/rsyslog.conf添加一段將local2的所有信息記錄在對應日誌文件中
由於HAProxy可以工作在七層模型下，因此，要實現HAProxy的強大功能，一定要使用強大靈活的ACL規則，通過ACL規則可以實現基於HAProxy的智能負載均衡系統。HAProxy通過ACL規則完成兩銀汪種主要的功能，分別是：
1）通過設置的ACL規則檢查客戶端請求是否合法。如果符合ACL規則要求，那鋒賀仔么將放行；如果不符合規則，則直接中斷請求。
2）符合ACL規則要求的請求將被提交到後端的backend伺服器集群，進而實現基於ACL規則的負載均衡。HAProxy中的ACL規則經常使用在frontend段中，使用方法如下：
acl 自定義的acl 名稱 acl 方法 -i [ 匹配的路徑或文件] 其中：
·acl：是一個關鍵字，表示定義ACL規則的開始。後面需要跟上自定義的ACL名稱。
·acl方法：這個欄位用來定義實現ACL的方法，HAProxy定義了很多ACL方法，經常使用的方法有hdr_reg（host）、hdr_dom（host）、hdr_beg（host）、url_sub、url_dir、path_beg、path_end等。
·-i：表示不區分大小寫，後面需要跟上匹配的路徑或文件或正則表達式。與ACL規則一起使用的HAProxy參數還有use_backend，use_backend後面需要跟上一個backend實例名，表示在滿足ACL規拍禪則後去請求哪個backend實例，與use_backend對應的還有default_backend參數，它表示在沒有滿足ACL條件的時候默認使用哪個後端
這些例子定義了www_policy、bbs_policy、url_policy三個ACL規則，第一條規則表示如果客戶端以 www.z.cn 或 z.cn 開頭的域名發送請求時，則此規則返回true，同理第二條規則表示如果客戶端通過 bbs.z.cn 域名發送請求時，則此規則返回true，而第三條規則表示如果客戶端在請求的URL中包含「buy_sid=」字元串時，則此規則返回true。
第四、第五、第六條規則定義了當www_policy、bbs_policy、url_policy三個ACL規則返回true時要調度到哪個後端backend，例如，當用戶的請求滿足www_policy規則時，那麼HAProxy會將用戶的請求直接發往名為server_www的後端backend，其他以此類推。而當用戶的請求不滿足任何一個ACL規則時，HAProxy就會把請求發往由default_backend選項指定的server_cache這個後端backend。
與上面的例子類似，本例中也定義了url_static、host_www和host_static三個ACL規則，其中，第一條規則通過path_end參數定義了如果客戶端在請求的URL中以.gif、.png、.jpg、.css或.js結尾時返回true，第二條規則通過hdr_beg（host）參數定義了如果客戶端以www開頭的域名發送請求時則返回true，同理，第三條規則也是通過hdr_beg（host）參數定義了如果客戶端以img.、video.、download.或ftp.開頭的域名發送請求時則返回true。
第四、第五條規則定義了當滿足ACL規則後要調度到哪個後端backend，例如，當用戶的請求同時滿足host_static規則與url_static規則，或同時滿足host_www和url_static規則時，那麼會將用戶請求直接發往名為static的後端backend，如果用戶請求滿足host_www規則，那麼請求將被調度到名為www的後端backend，如果不滿足所有規則，那麼將用戶請求默認調度到名為server_cache的這個後端backend。
log：全局的日誌配置，local0是日誌設備，info表示日誌級別。其中日誌級別有err、warning、info、debug4種可選。這個配置表示使用127.0.0.1上的rsyslog服務中的local0日誌設備，記錄日誌等級為info。
maxconn：設定每個HAProxy進程可接受的最大並發連接數，此選項等同於Linux命令行選項「ulimit -n」。
user/group：設置運行HAProxy進程的用戶和組，也可使用用戶和組的uid和gid值來替代。
daemon：設置HAProxy進程進入後台運行。這是推薦的運行模式。
nbproc：設置HAProxy啟動時可創建的進程數，此參數要求將HAProxy運行模式設置為daemon，默認只啟動一個進程。該值的設置應該小於伺服器的CPU核數。創建多個進程，能夠減少每個進程的任務隊列，但是過多的進程可能會導致進程崩潰。
pidfile：指定HAProxy進程的pid文件。啟動進程的用戶必須有訪問此文件的許可權。
mode：設置HAProxy實例默認的運行模式，有tcp、http、health三個可選值。
retries：設置連接後端伺服器的失敗重試次數，如果連接失敗的次數超過這里設置的值，HAProxy會將對應的後端伺服器標記為不可用。此參數也可在後面部分進行設置。
timeout connect：設置成功連接到一台伺服器的最長等待時間，默認單位是毫秒，但也可以使用其他的時間單位後綴。
timeout client：設置連接客戶端發送數據時最長等待時間，默認單位是毫秒，也可以使用其他的時間單位後綴。
timeout server：設置伺服器端回應客戶端數據發送的最長等待時間，默認單位是毫秒，也可以使用其他的時間單位後綴。
timeout check：設置對後端伺服器的檢測超時時間，默認單位是毫秒，也可以使用其他的時間單位後綴。
bind：此選項只能在frontend和listen部分進行定義，用於定義一個或幾個監聽的套接字。bind的使用格式為： bind [<address>:<port_range>] interface <interface>其可以為主機名或IP地址，如果將其設置為「*」或「0.0.0.0」，將監聽當前系統的所有IPv4地址。port_range可以是一個特定的TCP埠，也可是一個埠范圍，小於1024的埠需要有特定許可權的用戶才能使用。interface為可選選項，用來指定網路介面的名稱，只能在Linux系統上使用。
option httplog：在默認情況下，HAProxy日誌是不記錄HTTP請求的，這樣很不方便HAProxy問題的排查與監控。通過此選項可以啟用日誌記錄HTTP請求。
option forwardfor：如果後端伺服器需要獲得客戶端的真實IP，就需要配置此參數。由於HAProxy工作於反向代理模式，因此發往後端真實伺服器的請求中的客戶端IP均為HAProxy主機的IP，而非真正訪問客戶端的地址，這就導致真實伺服器端無法記錄客戶端真正請求來源的IP，而X-Forwarded-For則可用於解決此問題。通過使用forwardfor選項，HAProxy就可以向每個發往後端真實伺服器的請求添加X-Forwarded-For記錄，這樣後端真實伺服器日誌可以通過「X-Forwarded-For」信息來記錄客戶端來源IP。
option httpclose：此選項表示在客戶端和伺服器端完成一次連接請求後，HAProxy將主動關閉此TCP連接。這是對性能非常有幫助的一個參數。
log global：表示使用全局的日誌配置，這里的global表示引用在HAProxy配置文件global部分中定義的log選項配置格式。
default_backend：指定默認的後端伺服器池，也就是指定一組後端真實伺服器，而這些真實伺服器組將在backend段進行定義。這里的htmpool就是一個後端伺服器組。
option redispatch：此參數用於cookie保持的環境中。在默認情況下，HAProxy會將其請求的後端伺服器的serverID插入cookie中，以保證會話的session持久性。而如果後端的伺服器出現故障，客戶端的cookie是不會刷新的，這就會出現問題。此時，如果設置此參數，就會將客戶的請求強制定向到另外一台健康的後端伺服器上，以保證服務正常。
option abortonclose：如果設置了此參數，可以在伺服器負載很高的情況下，自動結束當前隊列中處理時間比較長的連接。
-balance：此關鍵字用來定義負載均衡演算法。目前HAProxy支持多種負載均衡演算法，常用的有如下幾種：
cookie：表示允許向cookie插入SERVERID，每台伺服器的SERVERID可在下面的server關鍵字中使用cookie關鍵字定義。
option httpchk：此選項表示啟用HTTP的服務狀態檢測功能。HAProxy作為一個專業的負載均衡器，它支持對backend部分指定的後端服務節點的健康檢查，以保證在後端backend中某個節點不能服務時，把從frotend端進來的客戶端請求分配至backend中其他健康節點上，從而保證整體服務的可用性。
option httpchk的用法如下： option httpchk <method> <uri> <version> 其中，各個參數的含義如下：
check：表示啟用對此後端伺服器執行健康狀態檢查。
inter：設置健康狀態檢查的時間間隔，單位為毫秒。
rise：設置從故障狀態轉換至正常狀態需要成功檢查的次數，例如，「rise 2」表示2次檢查正確就認為此伺服器可用。
fall：設置後端伺服器從正常狀態轉換為不可用狀態需要檢查的次數，例如，「fall 3」表示3次檢查失敗就認為此伺服器不可用。
cookie：為指定的後端伺服器設定cookie值，此處指定的值將在請求入站時被檢查，第一次為此值挑選的後端伺服器將在後續的請求中一直被選中，其目的在於實現持久連接的功能。上面的「cookie server1」表示web1的serverid為server1。同理，「cookie server2」表示web2的serverid為server2。
weight：設置後端真實伺服器的權重，默認為1，最大值為256。設置為0表示不參與負載均衡。
backup：設置後端真實伺服器的備份伺服器，僅僅在後端所有真實伺服器均不可用的情況下才啟用。
用nginx反代後端的兩台tomcat主機，做動靜分離，如果是jsp結尾的就發往後端，否則就交給nginx處理。
在兩台tomcat主機上創建應用
nginx配置
則動靜分離就實現了，並且我們還基於uri實現了會話粘性