負載均衡層次結構：LVS Nginx DNS CDN

文章地址：http://blog.csdn.net/mindfloating/article/details/51020767

做爲後端應用的開發者，咱們常常開發、調試、測試完咱們的應用併發布到生產環境，用戶就能夠直接訪問到咱們的應用了。但對於互聯網應用，在你的應用和用戶之間還隔着一層低調的或厚或薄的負載均衡層軟件，它們不顯山不露水默默的發揮着重要的做用，以致於咱們常常忽略了它們的存在。由於負載均衡層一般不在通常開發人員的問題域內，並且它們通常都是現成且成熟的解決方案，以致於咱們習慣性的忽略和認爲乏善可陳。其實否則，本文就寫寫我對負載均衡層次結構的認知和理解。

硬負載

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

在7、八年前那時我在作 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 工做模式以及工做原理