【負載均衡】
大量用戶發起請求的情況下，服務器負載過高，導致部分請求無法被響應或者及時響應。
負載均衡根據一定的算法將請求分發到不同的后端，保證所有的請求都可以被正常的下發並返回。
【主流實現-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