LB 負載均衡的層次結構_ZenDei技術網路在線

作為後端應用的開發者，我們經常開發、調試、測試完我們的應用併發布到生產環境，用戶就可以直接訪問到我們的應用了。但對於互聯網應用，在你的應用和用戶之間還隔著一層低調的或厚或薄的負載均衡層軟體，它們不顯山不露水默默的發揮著重要的作用，以至於我們經常忽略了它們的存在。因為負載均衡層通常不在一般開發人員的問 ...

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

硬負載

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

在七、八年前那時我在做 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 負載均衡器。剛下了論文還沒看，回頭看了再來寫寫。