大型網站——負載均衡架構
負載均衡 （Load Balancing） 負載均衡建立在現有網絡結構之上，它提供了一種廉價有效透明的方法擴展網絡設備和服務器的帶寬、增加吞吐量、加強網絡數據處理能力、提高網絡的靈活性和可用性。
大型網站負載均衡的利器
- 全局負載均衡系統（GSLB）
- 內容緩存系統（CDN）
- 服務器負載均衡系統（SLB）
DNS域名解析的基本過程
最初的負載均衡解決方案（DNS輪詢）
優點
- 基本上無成本，因爲往往域名註冊商的這種解析都是免費的；
- 部署方便，除了網絡拓撲的簡單擴增，新增的Web服務器只要增加一個公網IP即可。
缺點
- 健康檢查，如果某臺服務器宕機，DNS服務器是無法知曉的，仍舊會將訪問分配到此服務器。修改DNS記錄全部生效起碼要3-4小時，甚至更久；
- 分配不均，如果幾臺Web服務器之間的配置不同，能夠承受的壓力也就不同，但是DNS解析分配的訪問卻是均勻分配的。用戶羣的分配不均衡導致DNS解析的不均衡。
- 會話保持，如果是需要身份驗證的網站，在不修改軟件構架的情況下，這點是比較致命的，因爲DNS解析無法將驗證用戶的訪問持久分配到同一服務器。雖然有一定的本地DNS緩存，但是很難保證在用戶訪問期間，本地DNS不過期，而重新查詢服務器並指向新的服務器，那麼原服務器保存的用戶信息是無法被帶到新服務器的，而且可能要求被重新認證身份，來回切換時間長了各臺服務器都保存有用戶不同的信息，對服務器資源也是一種浪費。
全局負載均衡系統（GSLB）
優勢
- 數據中心冗餘備份
- 多站點流量優化
- 確保用戶體驗
全局負載均衡系統（GSLB）的原理
DNS檢查工具網上有很多，感興趣的可以搜索一下。
內容緩存系統（CDN）
- 內容緩存系統（CDN）之靜態加速
- 內容緩存系統（CDN）之動態加速
動態加速的特點
- 智能路由
- 傳輸控制協議（TCP）優化
- HTTP預載
服務器負載均衡系統
應用背景
- 訪問流量快速增長
- 業務量不斷提高
用戶需求
- 希望獲得7×24的不間斷可用性及較快的系統反應時間
負載均衡必須滿足性能、擴展、可靠性
服務器負載均衡系統三種接入方式
服務器負載均衡系統的常見調度算法
- 輪詢（Round Robin）
- 加權輪詢（Weighted Round Robin）
- 最少連接（Least Connections）
- 加權最少連接（Weighted Least Connections）
健康性檢查
健康性檢查算法的目的：通過某種探針機制，檢查服務器羣中真實服務器的健康情況，避免把客戶端的請求分發給出現故障的服務器，以提高業務的HA能力。
目前常用的健康性檢查算法：
- Ping（ICMP）
- TCP
- HTTP
- FTP
系統加速
優化功能-SSL加速
優化功能-HTTP壓縮
HTTP壓縮是在Web服務器和瀏覽器間傳輸壓縮文本內容的方法。F5 HTTP壓縮技術通過具有智能壓縮能力的 BIG-IP 系統可縮短應用交付時間並優化帶寬。HTTP壓縮採用通用的壓縮算法壓縮HTML、JavaScript或CSS文件。壓縮的最大好處就是降低了網絡傳輸的數據量，從而提高客戶端瀏覽器的訪問速度。
優化功能-連接複用
優化功能-TCP緩存
會話保持
會話保持-客戶端源IP會話保持
源IP地址會話保持就是將同一個源IP地址的連接或者請求認爲是同一個用戶，根據會話保持策略，在會話保持有效期內，將這些發自同一個源IP地址的連接/請求都轉發到同一臺服務器。
會話保持-Cookie會話保持
當採用基於源地址的會話保持無法做到負載均分時，例如客戶端發起連接請求的源IP地址相對固定，發生此類問題通常可採用基於應用層的會話保持方式，Cookie通常是存在於HTTP頭中，現如今基於HTTP的應用被廣泛使用，因此基於Cookie的會話保持越來越多的出現在服務器負載均衡解決方案中。
侷限性：
- 對於非HTTP協議，或者客戶端禁用Cookie，無效。
會話保持-URL哈希（Hash）會話保持
哈希會話保持的一個基本概念就是按照某個Hash因子，根據此因子以及後臺存在多少臺服務器計算得到的結果來選擇將請求分配到那臺服務器。哈希會話保持的特點是在後臺服務器的健康狀態不發生改變的時候，每個特定的Hash因子被分配到的服務器是固定的。其最大的優勢是哈希會話保持可以沒有會話保持表，而僅僅是根據計算的結果來確定被分配到那臺服務器，尤其在一些會話保持表查詢的開銷已經遠遠大於Hash計算開銷的情況下，採用Hash會話保持可以提高系統的處理能力和響應速度。
URL哈希會話保持通常針對後臺採用Cache服務器的應用場景，針對URL進行Hash計算，將同一個URL的請求分配到同一臺Cache服務器，這樣，對後臺的Cache服務器羣來說，每臺Cache服務器上存放的內容都是不一樣的，提高Cache服務器的利用率。
故障案例分析
Q&A案例分析（1）-循環跳轉
故障現象：
Web服務端對用戶訪問的URL進行判斷，對於非https的請求，重定向到http站點，結果導致用戶一直302跳轉。
原因分析：
採用了負載均衡SSL加速功能，在服務端看到所有的用戶請求都來自於http。
解決方案：
全站啓用SSL加速。
Q&A案例分析（2）-用戶Session丟失
故障現象：
用戶在http站點上提交數據到同域名的https站點，web程序拋出session丟失的異常，用戶提交數據失敗。
原因分析：
http和https在負載均衡設備上被認爲是2個獨立的服務，產生2個獨立的TCP鏈接，會命中不同的真實服務器，導致session丟失。
解決方案：
在負載均衡設備上啓用基於真實服務器的會話保持。
Q&A案例分析（3）-客戶端源IP取不到
故障現象：
服務端獲取不到用戶外網的IP地址，看到的都是大量來自於內網特定網段的IP地址。
原因分析：
負載均衡設備啓用了用戶源地址轉換（SNAT）模式，修改了TCP報文中的用戶源IP。
解決方案：
負載均衡設備會用用戶的外網IP改寫x-forwarded-for值，服務端通過獲取http協議中request header頭的x-forwarded-for值作爲用戶源IP。IIS日誌通過安裝插件形式顯示用戶源IP。
服務器負載均衡設備選型
1.價格因素
- 硬件設備：F5、 Citrix 、Redware 、A10
- 軟件：LVS、Nginx、Haproxy、zen loadbalance
2.性能
- 4/7層吞吐量(單位bps)
- 4/7層新建連接數（單位CPS）
- 併發連接數
- 功能模塊性能指標（ssl加速、 HTTP壓縮、內存Cache）
3.滿足真實和未來需求
1）如果確認負載均衡設備對所有應用的處理都是最簡單的4層處理，那麼理論上選擇的負載均衡設備的4層性能稍高於實際性能需求即可。
2）如果確認負載均衡設備對所有應用的處理都是簡單的7層處理，那麼理論上選擇的負載均衡設備的7層性能稍高於實際性能需求即可。
3）如果負載均衡設備處理的應用既有4層的也有7層的，建議按照7層應用的性能來考慮負載均衡設備。
4）如果確認自己的應用經過負載均衡處理時，需要複雜的4層或者7層處理，例如需要根據客戶端的地址做策略性分發，需要根據tcp的內容做處理，需要根據HTTP頭或者HTTP報文做處理，那麼建議選擇的負載均衡設備4/7層性能爲真實性能需求的兩倍。
5）如果負載均衡設備有混合的複雜流量處理並且還開啓了一些功能模塊，那麼建議選擇的負載均衡設備4/7層性能爲真實性能需求的3倍。
6）考慮到設備需要輕載運行才能更加穩定，所以有可能的話在以上基礎上再增加30%的性能。
7）如果還要滿足未來幾年的發展需求，在以上基礎上還要留出未來發展所需要增加的性能。
8）不同負載均衡設備廠家由於不同的架構，使得某些設備在複雜環境下可能也表現的比較優秀，這個客戶可以對比判斷，但總體來說，以上建議適合於所有廠家的設備。
來源：https://www.cnblogs.com/and/p/3366400.html
