發(fā)展到今天，一方面硬件設備依然保持了強勁的實力，另一方面以LVS、Haproxy為代表的軟件負載均衡也異軍突起，被人們所認可。在新浪，軟、硬件負載均衡并存的格局已有三年多的歷史了，除了既往積累的經驗外，近一年來，我們也看到了負載均衡所面臨的一些新挑戰(zhàn)，在此跟大家分享。

　　挑戰(zhàn)一：Web應用對七層交換的依賴度越來越大，顯著增加了負載均衡器的壓力。

　　七層交換技術的引入，極大地解放了架構師和程序開發(fā)人員，同時也使我們越來越習慣依賴于它，甚至直呼上癮。很難想象，如果沒有負載均衡器的話，現有Web架構中的大量需求應該如何實現? 在充分享受其便利性的同時，我們也看到了一些隱憂。一方面越來越多的流量正從四層交換轉為七層交換；另一方面七層交換的規(guī)則也越來越趨于復雜。在雙重作用下，負載均衡器的壓力急劇上升。對于任何一臺負載均衡器來說：支撐相同的請求量，七層交換所消耗的CPU要遠遠高于四層交換。特別是在瞬間高并發(fā)連接的突發(fā)流量面前，負載均衡器面臨著嚴峻的挑戰(zhàn)。

　　挑戰(zhàn)二：微博等互聯網新興產品的出現，對負載均衡器的運維工作提出了更高的要求。

　　微博不僅改變著億萬網民的生活，而且也正悄然推動著運維體系的建設。

　　首先，與傳統的新聞、博客相比，微博用戶對服務質量的敏感度更高，而且這種敏感度會伴隨著一次次的“@”和“轉發(fā)”傳播擴散。在過去，當用戶訪問新浪服務感到慢時，反映的渠道多是打客戶電話。而現在只需要在微博上一個簡單的“@” 就可以與新浪的客服和技術人員直接溝通。作為流量進出的一個關卡，當微博等線上關鍵業(yè)務出現訪問異常或故障時，工程師們都迫切地想知道：是負載均衡器的問題嗎？此時故障診斷的效率顯得至關重要。在實際工作中我們發(fā)現：單純依靠負載均衡器提供的CPU、內存、連接數等統計信息，還不足以發(fā)現一些隱蔽問題。傳統的抓包分析耗時耗力且效果不佳，再加上有些故障現象與客戶端、后臺服務器上的某些特殊設置有著千絲萬縷的聯系，所有這些交織在一起，給我們故障診斷帶來了不小的挑戰(zhàn)。例如有次我們發(fā)現：負載均衡器偶爾會給客戶端返回HTTP  5xx的響應，當時特想快速地知道究竟是什么樣的HTTP請求會觸發(fā)這樣的現象。但可惜的是，負載均衡器上僅有統計數字而沒有請求的完整記錄。在花了很大力氣抓包分析后，終定位到是由于后臺一個PHP程序不小心給頁面設置了一個錯誤的HTTP Header，導致Web Server的HTTP響應不能被負載均衡器所接受，終給客戶端返回5xx。因此在故障診斷方面，我們需要有更先進的理念和手段。

　　其次，微博在國內正處于快速成長期，會隨時根據訪問量來靈活調整服務器的數量和系統架構。在這種快速靈活的變化面前，負載均衡器相關的配置調整工作也隨之增加：頻繁的上下線服務器、變更七層規(guī)則等。面對這種情況，我們需要思考：如何能更加快速安全地完成好這些變更、如何能避免工程師每天被動地陷入這些重復煩瑣的工作中等。目前一些硬件設備提供了API接口，像增刪Server、調整Server 權重等這類風險性極低的操作可通過API接口操作，以達到提高效率的目的。而Haproxy、LVS則缺乏這樣的 API接口，需要單獨開發(fā)。

　　除此之外，關鍵應用對負載均衡器的監(jiān)控也有越來越多的新需求。比如：有些應用希望當負載均衡器檢測到服務器池中活躍的服務器數量少于一定比例后，便提前給系統管理員作出預警；及時發(fā)現服務器池中權重等設置不合理的問題等。

　　挑戰(zhàn)三：多核處理器時代下，Haproxy等用戶態(tài)的軟件負載均衡正面臨新的性能瓶頸。

　　近幾年來CPU發(fā)展進入了多核時代，CPU由過去的單核發(fā)展到四核、六核、八核、十二核，甚至更多，而主頻則變化不大。在這種趨勢下，充分利用多核特性顯得尤為重要。但在我們研究中發(fā)現，像Haproxy這類基于用戶態(tài)的軟件負載均衡，其對CPU主頻的依賴度要遠遠高于CPU核數。換言之，在高主頻、核數少CPU下的性能很有可能要優(yōu)于低主頻、核數多的CPU。這一點，在Haproxy服務器選型時尤為重要。據我們分析，這主要是由于操作系統對多核（多CPU）下的并發(fā)支持度還不夠好。[Page]

　　挑戰(zhàn)四：軟件負載均衡發(fā)展路上的“雞蛋-籃子”理論的艱難選擇。

　　硬件負載均衡器往往以單臺高性能著稱，而Haproxy、LVS為代表的軟件負載均衡的優(yōu)勢則在于成本低廉、可靈活定制，其性能與服務器CPU、網卡等硬件直接相關（當然特殊的優(yōu)化也很重要）。正如前面提到的，當七層交換流量越來越大時，我們究竟是該投入成本讓單臺LVS、Haproxy足以支撐如此大的流量，還是讓更多中等性能的服務器共同分擔這些流量呢？這就是所謂的經典的“雞蛋－籃子”理論：究竟該不該將雞蛋放到一個籃子里呢？

　　其實不同的選擇各有利弊。2~3年前，我比較贊同將流量分攤到多臺軟件負載均衡器上，當時主要考慮到風險的分散。而現在，我更傾向于將流量集中于一臺上。之所以這樣，是從以下四個角度考慮的。

　　第一，目前國內IDC內每個機架所放服務器數量跟電力配額直接相關。而負載均衡由于其特殊性，往往是兩臺為一組，這樣每增加一組都會增加額外的電力開銷，特別是在電力資源緊張的IDC內，提高單臺軟件負載均衡器的承載能力可以為關鍵業(yè)務騰出更多的機架來。

　　第二，從服務穩(wěn)定角度考慮，我們通常會將LVS、Haproxy直連核心交換機，如此一來，每增加一組，就意味著會占用更多的核心交換機端口資源。

　　第三，是基于管理成本的考慮。LVS、Haproxy之所以能在新浪得到廣泛應用，較低的管理成本是重要原因之一。在新浪我們通過一套集中管理平臺和快速初始化的辦法實現了運維成本的非線性增加。但不可否認的是，每新增一組，運維成本或多或少總會增加一些。之前也曾設計過一套“同機房內負載均衡器的集群池方案”，即：在一個機房內主備機的數量比不再固定為1:1， 虛擬IP（VIP）會根據集群池中每臺Haproxy/LVS的負載狀況，動態(tài)地“漂”在其中某臺上。但后來發(fā)現這個“聽起來很美”的方案，在實際運行中遇到了種種問題，運維成本不降反升。終我們又回歸了傳統的1臺Active+1臺Standby的模式，正所謂簡單即是美。

　　第四，目前硬件負載均衡器正朝著“更高的性價比”方向發(fā)展，換句話來講，如果我們不提升軟件負載均衡器的單機支撐能力，則終有一天，其與硬件設備相比的成本優(yōu)勢將會淡去。

　　挑戰(zhàn)五：在新時期下，如何找到負載均衡的佳軟硬結合之道？

　　朋友、同行聚會時，常有人問我：“你們有了Haproxy、LVS后，會不會不買硬件設備了？”、“你近又在山寨什么？”每次聽到這些，我都會微微一笑。如前文所述，Haproxy、LVS這類的軟件負載均衡和硬件設備各有優(yōu)勢，在我看來，負載均衡的“軟”、“硬”解決方案并非水火不容，只要找到佳的軟硬結合之道，魚和熊掌還是可以兼得的。下面是我們在長期摸索中，總結出來的一些經驗。

　　軟件負載均衡可優(yōu)先承擔四層交換流量，讓硬件設備更專注于七層交換：由于工作方式和原理的不同，專注于四層交換的LVS在穩(wěn)定性、單機支撐能力、易維護性、管理成本等多方面均要大大優(yōu)于Haproxy。特別是在DR模式（即單臂）下， 單臺LVS足以應對絕大多數業(yè)務的訪問量。

　　優(yōu)先保障“明星”產品占用寶貴的硬件設備資源：這里指的“明星產品”是指那些用戶群正處于快速增長，并被廣泛追捧的熱點互聯網產品，例如微博。考慮到負載均衡器一旦發(fā)生異常或宕機后，將對產品的美譽度和用戶體驗產生一定程度的影響，這屬于無形成本的損失。正所謂“好鋼要用在刀刃上”，我們可以優(yōu)先將這類流量放到硬件負載均衡器上。

　　對于必須采用七層交換的重點服務來說，盡量避免同一重點服務的流量全部放在軟件負載均衡器上。例如某重點服務分布于四個IDC內，則可考慮兩個IDC內使用Haproxy，另外兩個IDC使用硬件設備。這樣一方面可以在一定程度上規(guī)避使用Haproxy可能帶來的風險，另一方面也方便對軟、硬件負載均衡器的穩(wěn)定性、響應時間等進行長期對比觀察。[Page]

　　要充分利用好同一IDC內的軟、硬件負載均衡器，當一方負載高時，另一方可協助其分擔流量，緩解燃眉之急。

　　總而言之，在負載均衡方面的支出正所謂該花則花、該省則省，合理使用可以讓你在保障服務穩(wěn)定的前提下，獲得佳的投入產出比。

　　挑戰(zhàn)六：軟件負載均衡器的資源復用，在降低成本的同時，同時也面臨著一定的運維風險。

　　目前我們的軟件負載均衡器分布于全國各地，其中一些中小規(guī)模IDC內的軟件負載均衡器的負載并不是特別高，而這些機房普遍又需要VPN、自動安裝等服務，單獨為這些服務再放1~2組服務器顯得很不劃算。因此我們想到對軟件負載均衡器進行資源的復用，即：在軟件負載均衡器上同時運行VPN等服務。在實際中發(fā)現，這種資源復用面臨兩方面的風險：一是VPN、自動安裝、負載均衡可能分屬于不同的管理員，這樣大家對同臺服務器進行操作會增大因配置沖突、操作不當等導致的服務間互相影響的概率；二是非負載均衡的服務可能會突發(fā)占用過多的CPU或網絡資源，對正常的負載均衡服務造成了一定的影響。

    由于LVS、Haproxy服務的特殊性，像Xen這類通過虛擬化來實現資源隔離的辦法又不太適用；對服務器流量進行QOS設置，雖然可以起到一定的效果，但配置方面還是有些煩瑣。還有更好的辦法嗎？這確實值得我們思考。

　　當然除了以上六方面挑戰(zhàn)外，負載均衡領域還有很多值得研究之處。不同網站有不同的實際情況，希望本文能對大家起到拋磚引玉的作用。