【負載均衡】
大量使用者發起請求的情況下，伺服器負載過高，導致部分請求無法被響應或者及時響應。
負載均衡根據一定的演算法將請求分發到不同的後端，保證所有的請求都可以被正常的下發並返回。
【主流實現-LVS】
LVS 是 Linux Virtual Server 的簡稱，也就是 Linux 虛擬伺服器，已經是 Linux 標準核心的一部分。
採用IP負載均衡技術和基於內容請求分發。
排程器具有很好的吞吐率，將請求均衡得轉移到不同的伺服器上執行，且排程器可以自動遮蔽掉故障的伺服器，從而將一組伺服器構成一個高可用，高效能的伺服器叢集。
*負載均衡機制
1. LVS是四層負載均衡，也就是說在傳輸層上，LVS支援TCP/UDP。由於是四層負載均衡，所以相對於其他的高層負載均衡而言，對於DNS域名輪流解析，應用層負載的排程，客戶端的排程等，它的效率是相對較高的。
2. 四層負載均衡，主要通過報文的目標地址和埠。（七層負載均衡又稱為"內容交換"，主要是通過報文中真正有意義的應用層內容）
3. LVS的轉發主要通過修改IP地址（NAT模式，包括SNAT和DNAT），修改目標MAC（DR模式）來實現。
*負載均衡模式-NAT模式
NAT（Network Address Translation）是一種外網和內網地址對映的技術。
NAT模式下，網路資料包的進出都要經過LVS的處理。LVS需要作為RS（真實伺服器）的閘道器。
當包從Client到達LVS時，LVS做DNAT（目標地址轉換），將D-IP（目的地址）改變為RS的IP。
RS處理完成，將包返回的時候，S-IP（源地址）是RS，D-IP是Client的IP。
到達LVS做閘道器中轉時，LVS會做SNAT（源地址轉換），將包的S-IP改為VIP。
*負載均衡模式-DR模式
DR（直接路由）模式下需要LVS和RS繫結同一個叢集（RS通過將VIP繫結在loopback實現）。
請求由LVS接受，返回的時候由RS直接返回給Client。
當包到LVS的時候，LVS將網路幀的MAC地址修改為某臺RS的MAC，此包會被轉發到對應的RS上面進行處理。
此時S-IP和D-IP都沒有發生改變。
RS收到LVS轉發的包時，鏈路層發現MAC地址是自己的，網路層發現IP地址也是自己的，於是包被合法接受，RS不感知LVS。
當包返回時，RS直接返回給Client，不再經過LVS。
由於RS響應的資料包是直接返回給Client的，所以有效得避免了負載均衡伺服器的頻寬成為瓶頸。
*負載均衡模式-IP隧道模式
隧道模式有點類似與VPN，使用網路分層的原理，在從客戶端發來的資料包的基礎上，封裝一個新的IP頭標記（不完整，只有目的IP）傳送給RS。
RS收到後，先把DR發過來的資料包的頭解開，還原資料包。處理完成後，直接返回給Client。
*負載均衡模式-總結
綜上所述，DR模式具有更好的效能，也是目前大型網站比較通用的一種模式。
*LVS排程演算法
限於篇幅，只介紹部分演算法。
1. 輪詢排程
2. 加權輪詢排程
3. 最小連線數排程
4. 加權最小連線數排程
5. 基於區域性性的最少連線（LBLC）
該演算法主要用於Cache叢集系統。
該演算法根據請求的D-IP找出該D-IP地址最近使用的伺服器地址，如果此伺服器可用，則傳送給此伺服器。如果不可用，則使用最小連線數演算法選擇一個伺服器傳送報文。
6. 帶複製的基於區域性性的最少連線（LCLBR）
它與LBLC演算法的不同之處是它要維護從一個目標IP地址到一組伺服器的對映，而LBLC演算法維護從一個目標IP地址到一臺伺服器的對映。
在LBLC演算法裡面，某些熱門站點報文較多，可能伺服器很快會達到飽和，然後切換到第二臺又會很快達到飽和，然後後端伺服器就一直在切換，造成資源不必要的浪費。
LCLBR裡面，單個伺服器變成了一組伺服器，就會有效避免這種情況。
7. 目標地址雜湊
8. 源地址雜湊
*LVS的優點
1. 抗負載能力強，由於工作在傳輸層上，只做分發，無流量產生，所以它在所有的負載均衡裡面效能是最強的，對記憶體和CPU的消耗也比較低。
2. 配置性較低，減少人為出錯的概率，但是也相應減少了人為自主性。
3. 工作穩定，自身有完整的雙機熱備方案，如：LVS + Keepalived
4. 無流量，保證IO不會受到影響。
*LVS的缺點
1. 軟體本身不支援正規表示式處理，不能做動靜分離。
2. 網站應用比較龐大的時候，LVS/DR+Keepalive實施較為複雜。
【主流實現-Nginx】
Nginx是一個很強大的高效能Web和反向代理伺服器。
最大的優勢在於高負載情況下對記憶體和CPU的低消耗。
在高併發的情況下，Nginx是Apache伺服器不錯的替代品。
*傳統基於程式或執行緒的模型
傳統基於程式或執行緒的模型（如Apache）在處理併發時會為每一個連線建立一個單獨的程式或執行緒。這種方法會在網路傳輸或者I/O操作上阻塞。
對於應用來講，在記憶體和CPU的使用上效率都是非常低的。
而且，生成一個單獨的程式/執行緒還需要為其準備新的執行環境（主要包括分配堆疊記憶體），以及上下文執行環境。
建立這些都消耗額外的CPU時間，這最終也會因為執行緒上下文來回切換導致效能非常差。
*Nginx架構設計
Nginx的架構設計是採用模組化的，基於事件驅動，非同步，單執行緒且非阻塞。
Nginx大量使用多路複用和事件通知，nginx啟動之後，會在系統中以 daemon（守護程式） 的方式在後臺執行，包括一個master程式和多個worker程式。
所有的程式都是單執行緒的，程式間通訊主要通過共享記憶體的方式。
多個連線，是通過worker程式中高效迴環（run-loop）機制來處理的。對於每個worker程式來說，每秒鐘可以處理上千個請求和連線。
*Nginx負載均衡
Nginx 負載均衡主要針對七層的http和https，當然，四層Nginx後來也支援了（1.9.0版本增加stream模組，用來實現四層協議）。
Nginx主要是通過反向代理的方式進行負載均衡的，所謂反向代理（Reverse Proxy），指的是以代理伺服器來接收 Client 請求，然後將請求轉發到內部伺服器，並將內部伺服器處理完成的結果返回給 Client ，對外，代理伺服器就是真正的伺服器，內部伺服器外部不感知。
Nginx支援以下幾種策略：
輪詢·default
weight （權重）
ip_hash （可用於解決會話保持的問題）
fair·第三方 （按後端伺服器的響應時間來分配請求，響應時間短的優先分配）
url_hash·第三方 （相同的url定位到相同的伺服器）
*Nginx的優勢
1. 跨平臺，配置簡單
2. 非阻塞，高併發（官方測試可以支撐5萬併發數）
3. 事件驅動，通訊機制採用 epoll 模型，支援更大的併發連線
4. 記憶體消耗小。（3萬併發數下，10個Nginx程式只需要150M記憶體）
5. 內建的健康檢查功能。 （一臺後端伺服器當機了，不會影響前端訪問）
6. 節省頻寬。 （支援GZIP壓縮，可以新增瀏覽器快取的header）
7. 穩定性高。 （反向代理，當機的概率很小）
*Nginx的缺點
1. 對後端伺服器的健康檢查，只支援通過埠檢測，不支援url檢測。
2. 不支援Session的直接保持。（通過ip_hash可解決）
【主流實現-Haproxy】
Haproxy提供高可用性，負載均衡以及基於TCP和HTTP的代理。
特別適用於那些負載特大的Web站點，這些站點通常需要會話保持或七層處理。
Haproxy支援四層和七層兩種負載模式。
Haproxy有一些Nginx不具有的優點，比如支援Session的保持，Cookie的引導；同時支援通過獲取指定的URL來檢測後端伺服器的狀態。
Haproxy和LVS類似，本身就只是一款負載均衡軟體；單純從效率上來講，比Nginx有更好的負載均衡速度，在併發處理上也優於Nginx。
Haproxy支援的負載均衡策略也比較多：Round-robin（輪循）、Weight-round-robin（帶權輪循）、source（原地址保持）、RI（請求URL）、rdp-cookie（根據cookie）。
【三種負載均衡的比較】
|
比較 |
HAProxy |
Nginx |
LVS |
|
優點 |
支援session保持，Cookie引導。
可通過url檢測後端伺服器健康狀態。
也可做MySQL、Email等負載均衡。
支援通過指定的URL對後端伺服器健康檢查。 |
http、https、Emai協議功能較好，處理相應請求快。
Web能力強，配置簡單，支援快取功能、適用動靜分離，低記憶體消耗。
支援WebSocket協議。
支援強大的正則匹配規則 。 |
通過vrrp轉發（僅分發）效率高，流量通過核心處理，沒有流量產生。（理論）
相當穩定可靠。
|
|
缺點 |
一般不做Web伺服器的Cache。 |
不支援session直接保持，但可通過ip_hash解決。 只能通過埠對後端伺服器健康檢查。 |
不支援正則，不能做動靜分離，配置略複雜，需要IP略多。 沒有後端主機健康狀態檢查。 |
|
支援演算法 |
目標uri hash(uri) url引數 (url_params) 請求頭資訊排程(hdr(name)) cookie (rdp-cookie) |
最小響應時間 自定義hash內容(hash key [consistent]) url hash 最短時間和最少連線 |
最短期望延遲(Shortest Expected Delay) 不排隊(Never Queue) 基於區域性性的最少連線(LBLC) 帶複製的基於區域性性最少連結(LCLBR) |
|
官網 |
|
||
|
虛擬主機 |
支援 |
支援 |
不支援 |
|
適用性 |
四層，七層（常用） |
四層，七層（常用） |
四層 |
|
量級 |
七層重量級，四層輕量級 |
七層重量級，四層輕量級 |
四層重量級 |
|
常用熱備 |
Keepalived+其它 |
Keepalived+其它 |
Keepalived+其它 |
*補充區別
HAProxy對於後端伺服器會一直做健康檢測（就算請求沒過來的時候也會做健康檢查）
後端機器故障發生在請求還沒到來的時候，haproxy會將這臺故障機切掉，但如果後端機器故障發生在請求到達期間，那麼前端訪問會有異常。
也就是說HAProxy會把請求轉到後端的這臺故障機上，並經過多次探測後才會把這臺機器切掉，並把請求發給其他正常的後端機，這勢必會造成一小段時間內前端訪問失敗。
Nginx對於後端的伺服器不會一直做健康檢測
後端機器發生故障，在請求過來的時候，分發還是會正常進行分發，只是請求不到資料的時候，它會再轉向好的後端機器進行請求，直到請求正常為止。
也就是說Nginx請求轉到後端一臺不成功的機器的話，還會再轉向另外一臺伺服器，這對前端訪問沒有什麼影響。
因此，如果有用HAProxy做為前端負載均衡的話 ，如果後端伺服器要維護，在高併發的情況，肯定是會影響使用者的。
但如果是Nginx做為前端負載均衡的話，只要併發撐得住，後端切掉幾臺不會影響到使用者。
【Openstack LBaaS的現狀】
Neutron中的loadbalance服務lbaas，可以將來自公網或內部網路的訪問流量，分發到雲資源中的雲主機上，可以隨時新增或者減少後端雲主機的數量，而不影響業務。
lbaas在Grizzly版本整合到Neutron中。
現在社群最新的API版本為V2，在Kilo中釋出，包含以下概念：
Lbaas V1與V2的區別如下：
|
功能 |
lbaas |
lbaasV2 |
|
最大連線數 |
Y |
Y |
|
TCP負載均衡 |
Y |
Y |
|
HTTP負載均衡 |
Y |
Y |
|
HTTPS負載均衡 |
Y |
Y |
|
TERMINATED_HTTPS負載均衡 |
X |
Y |
|
基於hostname的url轉發 |
X |
Y |
|
基於path的url轉發 |
X |
Y |
|
基於filename的url轉發 |
X |
Y |
|
基於header的url轉發 |
X |
Y |
|
基於cookie的url轉發 |
X |
Y |
|
一個vip支援多種協議和埠 |
X |
Y |
【Octavia 介紹】
Octavia當前作為lbaasV2的一個driver存在，完全相容lbaasV2的介面，最終的發展趨勢會作為一個獨立的專案代替lbaasV2。
架構圖如下：
網路結構如下：
【參考】
octavia相關：https://docs.openstack.org/octavia/latest/
nginx相關：nginx.org