門戶網站負載均衡技術的六大新挑戰
記得上大學時，我和好友老郭討論最多的話題便是：“像新浪這樣的網站是如何支撐如此巨大的訪問量？”也曾通過各種手段，猜測新浪服務器的數量、操作系統和應用軟件的版本……一切都是那么神秘。畢業那年，有幸加入新浪，終于一點點地揭開了這層神秘的面紗。2004年某廠商設備介紹會上，我初次接觸到了負載均衡技術。之后的幾年時間，可以說是負載均衡設備在網站推廣的黃金爆發期。
發展到今天，一方面硬件設備依然保持了強勁的實力，另一方面以LVS、Haproxy為代表的軟件負載均衡也異軍突起，被人們所認可。在新浪，軟、硬件負載均衡并存的格局已有三年多的歷史了，除了既往積累的經驗外，近一年來，我們也看到了負載均衡所面臨的一些新挑戰，在此跟大家分享。
挑戰一：Web應用對七層交換的依賴度越來越大，顯著增加了負載均衡器的壓力。
七層交換技術的引入，極大地解放了架構師和程序開發人員，同時也使我們越來越習慣依賴于它，甚至直呼上癮。很難想象，如果沒有負載均衡器的話，現有Web架構中的大量需求應該如何實現? 在充分享受其便利性的同時，我們也看到了一些隱憂。一方面越來越多的流量正從四層交換轉為七層交換；另一方面七層交換的規則也越來越趨于復雜。在雙重作用下，負載均衡器的壓力急劇上升。對于任何一臺負載均衡器來說：支撐相同的請求量，七層交換所消耗的CPU要遠遠高于四層交換。特別是在瞬間高并發連接的突發流量面前，負載均衡器面臨著嚴峻的挑戰。
挑戰二：微博等互聯網新興產品的出現，對負載均衡器的運維工作提出了更高的要求。
微博不僅改變著億萬網民的生活，而且也正悄然推動著運維體系的建設。
首先，與傳統的新聞、博客相比，微博用戶對服務質量的敏感度更高，而且這種敏感度會伴隨著一次次的“@”和“轉發”傳播擴散。在過去，當用戶訪問新浪服務感到慢時，反映的渠道多是打客戶電話。而現在只需要在微博上一個簡單的“@” 就可以與新浪的客服和技術人員直接溝通。作為流量進出的一個關卡，當微博等線上關鍵業務出現訪問異常或故障時，工程師們都迫切地想知道：是負載均衡器的問題嗎？此時故障診斷的效率顯得至關重要。在實際工作中我們發現：單純依靠負載均衡器提供的CPU、內存、連接數等統計信息，還不足以發現一些隱蔽問題。傳統的抓包分析耗時耗力且效果不佳，再加上有些故障現象與客戶端、后臺服務器上的某些特殊設置有著千絲萬縷的聯系，所有這些交織在一起，給我們故障診斷帶來了不小的挑戰。例如有次我們發現：負載均衡器偶爾會給客戶端返回HTTP 5xx的響應，當時特想快速地知道究竟是什么樣的HTTP請求會觸發這樣的現象。但可惜的是，負載均衡器上僅有統計數字而沒有請求的完整記錄。在花了很大力氣抓包分析后，最終定位到是由于后臺一個PHP程序不小心給頁面設置了一個錯誤的HTTP Header，導致Web Server的HTTP響應不能被負載均衡器所接受，最終給客戶端返回5xx。因此在故障診斷方面，我們需要有更先進的理念和手段。
其次，微博在國內正處于快速成長期，會隨時根據訪問量來靈活調整服務器的數量和系統架構。在這種快速靈活的變化面前，負載均衡器相關的配置調整工作也隨之增加：頻繁的上下線服務器、變更七層規則等。面對這種情況，我們需要思考：如何能更加快速安全地完成好這些變更、如何能避免工程師每天被動地陷入這些重復煩瑣的工作中等。目前一些硬件設備提供了API接口，像增刪Server、調整Server 權重等這類風險性極低的操作可通過API接口操作，以達到提高效率的目的。而Haproxy、LVS則缺乏這樣的 API接口，需要單獨開發。
除此之外，關鍵應用對負載均衡器的監控也有越來越多的新需求。比如：有些應用希望當負載均衡器檢測到服務器池中活躍的服務器數量少于一定比例后，便提前給系統管理員作出預警；及時發現服務器池中權重等設置不合理的問題等。
挑戰三：多核處理器時代下，Haproxy等用戶態的軟件負載均衡正面臨新的性能瓶頸。
近幾年來CPU發展進入了多核時代，CPU由過去的單核發展到四核、六核、八核、十二核，甚至更多，而主頻則變化不大。在這種趨勢下，充分利用多核特性顯得尤為重要。但在我們研究中發現，像Haproxy這類基于用戶態的軟件負載均衡，其對CPU主頻的依賴度要遠遠高于CPU核數。換言之，在高主頻、核數少CPU下的性能很有可能要優于低主頻、核數多的CPU。這一點，在Haproxy服務器選型時尤為重要。據我們分析，這主要是由于操作系統對多核（多CPU）下的并發支持度還不夠好。
挑戰四：軟件負載均衡發展路上的“雞蛋-籃子”理論的艱難選擇。
硬件負載均衡器往往以單臺高性能著稱，而Haproxy、LVS為代表的軟件負載均衡的優勢則在于成本低廉、可靈活定制，其性能與服務器CPU、網卡等硬件直接相關（當然特殊的優化也很重要）。正如前面提到的，當七層交換流量越來越大時，我們究竟是該投入成本讓單臺LVS、Haproxy足以支撐如此大的流量，還是讓更多中等性能的服務器共同分擔這些流量呢？這就是所謂的經典的“雞蛋－籃子”理論：究竟該不該將雞蛋放到一個籃子里呢？
其實不同的選擇各有利弊。2~3年前，我比較贊同將流量分攤到多臺軟件負載均衡器上，當時主要考慮到風險的分散。而現在，我更傾向于將流量集中于一臺上。之所以這樣，是從以下四個角度考慮的。
第一，目前國內IDC內每個機架所放服務器數量跟電力配額直接相關。而負載均衡由于其特殊性，往往是兩臺為一組，這樣每增加一組都會增加額外的電力開銷，特別是在電力資源緊張的IDC內，提高單臺軟件負載均衡器的承載能力可以為關鍵業務騰出更多的機架來。
第二，從服務穩定角度考慮，我們通常會將LVS、Haproxy直連核心交換機，如此一來，每增加一組，就意味著會占用更多的核心交換機端口資源。
第三，是基于管理成本的考慮。LVS、Haproxy之所以能在新浪得到廣泛應用，較低的管理成本是重要原因之一。在新浪我們通過一套集中管理平臺和快速初始化的辦法實現了運維成本的非線性增加。但不可否認的是，每新增一組，運維成本或多或少總會增加一些。之前也曾設計過一套“同機房內負載均衡器的集群池方案”，即：在一個機房內主備機的數量比不再固定為1:1， 虛擬IP（VIP）會根據集群池中每臺Haproxy/LVS的負載狀況，動態地“漂”在其中某臺上。但后來發現這個“聽起來很美”的方案，在實際運行中遇到了種種問題，運維成本不降反升。最終我們又回歸了傳統的1臺Active+1臺Standby的模式，正所謂簡單即是美。
第四，目前硬件負載均衡器正朝著“更高的性價比”方向發展，換句話來講，如果我們不提升軟件負載均衡器的單機支撐能力，則終有一天，其與硬件設備相比的成本優勢將會淡去。
挑戰五：在新時期下，如何找到負載均衡的最佳軟硬結合之道？
朋友、同行聚會時，常有人問我：“你們有了Haproxy、LVS后，會不會不買硬件設備了？”、“你最近又在山寨什么？”每次聽到這些，我都會微微一笑。如前文所述，Haproxy、LVS這類的軟件負載均衡和硬件設備各有優勢，在我看來，負載均衡的“軟”、“硬”解決方案并非水火不容，只要找到最佳的軟硬結合之道，魚和熊掌還是可以兼得的。下面是我們在長期摸索中，總結出來的一些經驗。
軟件負載均衡可優先承擔四層交換流量，讓硬件設備更專注于七層交換：由于工作方式和原理的不同，專注于四層交換的LVS在穩定性、單機支撐能力、易維護性、管理成本等多方面均要大大優于Haproxy。特別是在DR模式（即單臂）下， 單臺LVS足以應對絕大多數業務的訪問量。
優先保障“明星”產品占用寶貴的硬件設備資源：這里指的“明星產品”是指那些用戶群正處于快速增長，并被廣泛追捧的熱點互聯網產品，例如微博。考慮到負載均衡器一旦發生異常或宕機后，將對產品的美譽度和用戶體驗產生一定程度的影響，這屬于無形成本的損失。正所謂“好鋼要用在刀刃上”，我們可以優先將這類流量放到硬件負載均衡器上。
對于必須采用七層交換的重點服務來說，盡量避免同一重點服務的流量全部放在軟件負載均衡器上。例如某重點服務分布于四個IDC內，則可考慮兩個IDC內使用Haproxy，另外兩個IDC使用硬件設備。這樣一方面可以在一定程度上規避使用Haproxy可能帶來的風險，另一方面也方便對軟、硬件負載均衡器的穩定性、響應時間等進行長期對比觀察。
要充分利用好同一IDC內的軟、硬件負載均衡器，當一方負載高時，另一方可協助其分擔流量，緩解燃眉之急。
總而言之，在負載均衡方面的支出正所謂該花則花、該省則省，合理使用可以讓你在保障服務穩定的前提下，獲得最佳的投入產出比。
挑戰六：軟件負載均衡器的資源復用，在降低成本的同時，同時也面臨著一定的運維風險。
目前我們的軟件負載均衡器分布于全國各地，其中一些中小規模IDC內的軟件負載均衡器的負載并不是特別高，而這些機房普遍又需要VPN、自動安裝等服務，單獨為這些服務再放1~2組服務器顯得很不劃算。因此我們想到對軟件負載均衡器進行資源的復用，即：在軟件負載均衡器上同時運行VPN等服務。在實際中發現，這種資源復用面臨兩方面的風險：一是VPN、自動安裝、負載均衡可能分屬于不同的管理員，這樣大家對同臺服務器進行操作會增大因配置沖突、操作不當等導致的服務間互相影響的概率；二是非負載均衡的服務可能會突發占用過多的CPU或網絡資源，對正常的負載均衡服務造成了一定的影響。由于LVS、Haproxy服務的特殊性，像Xen這類通過虛擬化來實現資源隔離的辦法又不太適用；對服務器流量進行QOS設置，雖然可以起到一定的效果，但配置方面還是有些煩瑣。還有更好的辦法嗎？這確實值得我們思考。
當然除了以上六方面挑戰外，負載均衡領域還有很多值得研究之處。不同網站有不同的實際情況，希望本文能對大家起到拋磚引玉的作用。
作者簡介：
李曉棟，新浪網研發中心基礎架構部技術經理、集團金牌講師。在新浪有6年多的系統、網絡、安全相關工作經驗，現負責新浪網絡設備和操作系統相關研發工作。自2007年9月以來帶領團隊研發了新浪DDOS防火墻、廣域網加速器、軟件負載均衡管理系統、網頁掛馬檢測系統等重要產品, 為公司節約成本上千萬元。
（本文來自《程序員》雜志10年11期）
【編輯推薦】
