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