LB 負載均衡的層次結構

硬負載

所謂「硬負載」就是採用硬件設備來提供負載均衡。

在七、八年前那時我在做 Java 的企業軟件開發，開發出來的企業級 Java 應用程序就部署在像 Weblogic 之類的應用容器中。而這類應用容器軟件又跑在 Unix 的小型機上。把硬件和軟件一體打包作爲企業應用解決方案賣給客戶。這類應用部署的方案十分簡單，層級也比較淺。爲了保證可靠性，使用兩套小型機上各部署一個 Weblogic Server，在應用服務前面使用像 F5 之類的硬件負載均衡器，如下圖所示。

由於小型機和前面的 F5 負載均衡硬件都比較貴，所以出於可靠性、可維護性和成本的綜合考慮，一般應用部署兩套跑在兩臺小型機上，在前面共享一個 F5 做負載均衡。而一般 F5 和小型機這類硬件設備都至少是 5 個 9 的可靠性保障，所以整體的系統可靠性基本有保障。

進入互聯網時代後，應用開發擁抱開源，部署使用更廉價的 PC Server 和免費開源的應用容器。負載均衡也逐步從硬負載向軟負載變遷，由於互聯網應用的海量特性和部署規模的急劇膨脹，前端負載均衡也開始變得豐富起來。

軟負載

進入互聯網公司後，我們剛開始開發應用時，業務規模小用戶量還不大，機器數量也少（<10）。所以一開始的負載均衡的結構也是很簡單的，類似硬負載只是把硬件換成了免費的開源軟件並跑在可用性是有 3 個 9 的廉價 PC Server 上。

前面一個 LVS 後面跟着幾個應用服務，後來爲了方便做按域名的分流和適配切流量上線，中間又加了一層 Nginx。

這樣就變成了兩層軟負載結構了，LVS 負責 4 層，Nginx 負責 7 層。 但 Nginx 只負責了單機內多實例的負載均衡，這裏主要是因爲當時 PC Server 是物理機，CPU 16/32 core，內存 32/64G 不等，爲了更充分的利用資源，一臺物理機上都部署了多個應用服務實例，而考慮到 Nginx 工作在 7 層的開銷遠高於 LVS/DR 模式，所以一般在一個 Nginx 後面掛的實例數也不會超過 10 個。

但隨着業務發展和用戶流量上升，機器規模也在不斷擴張，導致一個網段內的 IP 都不夠用了，這套負載結構又遇到了橫向擴展的瓶頸，因爲 LVS/DR 模式下跨不了網段。所以後來又在 LVS 和 Nginx 之間加了一層 HAProxy，負載結構就變成了下面這樣。

其實加了 HAProxy 之後，它也是工作在 7 層，這樣 Nginx 這層看起來就不是很有必要。但三層的負載結構能支撐更大規模的集羣，而原本在 Nginx 層做了一套方便研發切流量上線的運維管理系統，所以犧牲一點性能換取現在的可維護性和將來擴展性，Nginx 這層就一直保留下來了。而且 Nginx 相比 HAProxy 不是純粹的負載均衡器，它還能提供 cache 功能，對於某些 HTTP 請求實際只走到 Nginx 這層就可以通過緩存命中而返回。

DNS負載

隨着業務發展，公司開始了多個 IDC 的建設，考慮到 IDC 級別的容災，集羣開始部署到多個 IDC。跨 IDC 的負載均衡方案可以簡單通過 DNS 輪詢來實現，但可控性不好。所以我們沒有采用這種，而是採用一主加多子域名的方式來基於業務場景實現動態域名調度和負載。主域名下實際是一個動態流量調度器，跨多個 IDC 部署，對於 HTTP 請求基於重定向方式跳子域名，對於 TCP 方式每次建立長連接前請求分配實際連接的子域名，如下圖所示。

CDN負載

最後再加上互聯網應用必不可少的 CDN 將靜態資源請求的負載分流，那麼整個負載的層次結構就完整了。

SSL 帶來的負載結構變化

隨着互聯網的普及，安全問題益發嚴重，原本早期只有銀行網銀等使用 HTTPS 方式訪問，現在電商類網站也開始啓用全站 HTTPS 了。引入 SSL 後對負載結構帶來了什麼影響麼？SSL 屬於應用層的協議，所以只能在 7 層上來做，而 HAProxy 也是支持 SSL 協議的，所以一種方式是隻需簡單的讓 HAProxy 開啓 SSL 支持完成對內解密對外加密的處理。

但 HAProxy 的作者不太贊同這種方案，因爲引入 SSL 處理是有額外的性能開銷的。那麼在承擔確定流量的情況下，假設原本需要 M 臺 HAProxy，在開啓了 SSL 後可能需要 M + N 臺 HAProxy。隨着流量增長，這種方式的橫向擴展成本較高（畢竟 SSL 證書按服務器數量來收費的）。他給出的解決方案是再獨立一層 SSL 代理緩存層，像下面這樣。

L4 和 L7 之間獨立的 SSL 代理緩存層只負責 SSL 協議的處理，把 HTTPS 轉換成 HTTP，並檢查本地緩存是否命中。若未命中再轉發請求到後端的 L7 層應用負載均衡層。這樣的好處是每個層次都可以根據流量來獨立伸縮，而且 SSL 層顯然可以跨多個應用共享，更節省成本。如果按這個思路來重新調整我們前面的負載均衡結構層次，將會演變成下面這樣。

其實，這時我覺得應用前面的那層 Nginx 可能就顯得多餘了點，不是必需的。但如果現實這麼演進下來很可能就會有這麼一層冗餘的東西存在很長一段時間，這就是理想和現實之間的差距吧。

總結

好了，本文到此爲止。作爲一名後臺開發我其實對上面提及的各類開源軟件如何配置、調優和管理並不熟悉，這屬於運維開發的問題域範疇。但這並不妨礙我去了解我所開發的應用所處的整個環境是怎樣的，多瞭解些你工作領域範圍邊界外的 What 和 Why，有時也能幫助我們更好的設計和解決自身問題域內的問題，別爲自己設限而最終畫地爲牢。

本來以爲負載均衡這個古老的課題已經定型了，在寫本文時又看到新聞，在近日舉辦的第十三屆網絡系統設計與實現 USENIX 研討會上，來自 Google 的工程師又分享了其自研的 Maglev 負載均衡器。剛下了論文還沒看，回頭看了再來寫寫。

參考

[1] HAProxy Documentation. HAProxy Management Guide
[2] HAProxy Documentation. HAProxy Starter Guide
[3] Willy Tarreau. Making applications scalable with Load Balancing
[4] LVS wiki. Load balancing
[5] Wikipedia. Virtual Router Redundancy Protocol
[6] shuming. LVS 工作模式以及工作原理

轉載自: http://www.cnblogs.com/mindwind/p/5339657.html?ref=myread