案首語: 阿裡集團技術大牛，@正明，淘寶基礎核心軟體研發負責人、lvs創始人、阿裡雲首席科學家章文嵩博士從阿裡離職，去追求技術人生另一段曆程，讓阿裡像我一樣的很多熱愛技術的工程師都有一絲牽動和感觸。 我個人作為一個平凡的一線技術工程師，對章博士是很敬佩的(雖然他還不認識我),國内it業界這麼多年，在底層基石技術層面有所建樹，打到linux标準核心子產品層面的應該就lvs了吧，而且就廣泛影響力方面，lvs在linux逐漸取代ibm aix, sun solaris,hpux 這些unix們的過程中，扮演了很重要一塊的角色，那就是lvs是linux cluster的标準解決方案的核心,在我個人看來，x86-64晶片對比power,itanium,pa-risc的更高成本效益和lvs linux cluster的方案成熟是網際網路時代剛開始興起的那個時期，在技術準備上，從unix逐漸走向低端商用機+linux方案的2把掘墓鋤頭，雖然不是唯二的2把，但是絕對是其中非常重要的2把,而很多中國人、美國人、歐洲人、日本人...的技術書籍裡介紹linux技術的書籍裡，lvs必然會在裡面占有一定的篇幅。另外章博士也是國内開源文化的積極的倡導者和真正踐行者，我們阿裡中間件之是以開源被業界廣泛使用的産品(dubbo,metaq,diamond...)，究其原因，也可以說是深受章博士的影響。 在阿裡中間件，我所在的團隊恰好是專注在”軟負載“（軟體負載網絡）方面，提供的産品和服務，跟負載均衡産品有很大一部分交集，在集團内，我們的産品vipserver，可以說跟lvs有一些直面的競争，在集團内越來越多的業務逐漸從lvs遷往vipserver上，但正因為如此，是以在負載均衡領域我們對于章博士的江湖地位和影響力才有更深刻的了解。在這個技術人目光再次聚焦在章博士身上的時候，我想借此機會将我們團隊對于負載均衡産品這一塊的一些思考和實踐經驗，總結分享給需要的人，希望幫助到正在思考這一塊的技術人。也許未來我們永遠也不能像章博士這樣做出廣泛影響世界技術圈的産品，但是作為後輩，我們會看着前輩的身影，追尋着往這個方向一直努力下去。 下面讓我們以輕松一點的心情開始:
“負載(load)”惹得禍
首先讓我們從原點出發。
某一天清晨起床，你突然有了一個美妙的想法，這個想法讓你興奮不已，因為你發現了一個具有廣闊市場前景的處女地，這個處女地還完全沒有被開墾，這是一項新業務，這項業務能滿足世界上大部分人的某個方面他們自己都不知道的潛在的需求，更妙的是，到目前為止，它還沒有被任何人發現。你簡直被自己的天才驚呆了，被自己的天才想法感動的内牛滿面，你确信你的人生會因為這個想法而改變，宇宙也會因為你這個想法而變的大不相同，你确定這個想法的實作将能幫助你走上人生巅峰，上上個時代是比爾蓋子，上個時代是拉裡配齊，下個時代毫無疑問将是你，你迫不及待的想要将這項業務通過一個系統來表達和實作，于是你奮戰了好幾個通宵，有了下面這個能支撐這項新業務的非常牛逼的系統:
是的，你的系統已經有了第一個使用者，這個使用者就是你自己。接下來你将你的系統通過x信朋友圈、釘釘、各大論壇廣邀各路親朋好友試試這個系統，結果是，非常棒! 好評如潮，他們不停的拉自己的親朋好友開始通路這個系統，是以注冊、活躍使用者越來越多，此時，你興奮不已，感覺自己馬上就要走上人生巅峰。
但等等，不知道哪裡出了問題，你的這個新系統居然上了ccav财經頻道，而且被各路媒體小報紛紛報導，瞬間所有人都想看看這個牛逼的系統，于是乎,悲劇發生了:
怎麼辦？怎麼辦？很快你想到了3個解決方案。
縱向擴充（scale up)
沒啥好說的，也許隻是伺服器還不夠nb，買！買！買！宇宙最好的伺服器來上一台，可惜，創業剛開始，投資人的錢要花在刀刃上，比如廣泛營銷上，比如路邊掃個碼啊，順便送個内衣啊、牙刷啊什麼的，伺服器? 買不起! 而且看了一下宇宙上最好伺服器的網卡配置，更洩氣，這就不是有錢買個nb伺服器就能解決的事！
業務拆分
你仔細審視之後，發現其實你的系統的2個頁面是2個不同的業務，用來滿足不同的需求的，于是啊，你就想，是不是能把這2個業務分開到2個系統中去，這樣使用者們自然乖乖的被引導、分流到2個子系統去了，這樣每個系統的壓力就減少了啊。這就好比一個飯店，生意火爆，原先來吃火鍋和吃大餅卷牛排的都在一起，擠不下之後，現在分成了2個店，1個是火鍋店，1個是大餅卷牛排店。從某種角度來說，這種其實也是一種負載均衡，但怎麼做業務拆分并且通過組織文化和人事架構去保障和适應這種業務拆分，是有很多的業務考量和業務屬性在裡面的，每個老闆和每個行業的答案可能都是不同的，此文讨論的不在這個方向上。
橫向擴充（scale out）和 副本(replica)
做完上面的垂直拆分之後，可能你會發現還是不行啊，這世界上擁有獨特口味的人太多，吃大餅卷牛排的人還是太多了，怎麼辦? 開分店吧，每個上檔次的商場都開一個大餅卷牛排店，這樣每個地域的人又被分流到了附近的店。這個提供一模一樣服務的“分店”就是系統的副本（replica），分布式系統中的副本(replica)除了滿足資料備援，容災的需要等之外，橫向擴充，通過開多個分店（replica)分流的行為,就是負載均衡,做到多副本之間分流是一個重要的目的。而這個正是本文讨論的範圍所在，如下簡圖:
接下來, 關于如何讓你的系統實作負載均衡，做到scale out, 你開始走上選型之路，
dns本身的機制不再贅述，這裡主要看一看基于dns的負載均衡，其大緻原理很清楚，dns系統本身支援同一個域名映射到多個ip (a記錄）,例如
這樣每次向dns系統詢問該域名的ip位址時（tell me the ip address of niubility.com.），dns會輪詢(round robin)這個ip清單，每次給一個不同的ip，進而達到負載均衡的效果。
來看看這種負載均衡解決方案的優缺點
易于實作
對于應用系統本身幾乎沒有任何侵入，配置也很簡單，在某個文本裡多加幾行a記錄就可以。尤其對于一個基于web的系統來說更是如此，使用者在浏覽器裡輸入的url host部分天然就是域名，是以在某個環節你必然有起碼一台dns伺服器記錄着這個域名對應的ip，是以可以說是基于已有域名系統(資産)就做到了負載均衡。
會話粘連 (session sticky)
用戶端與目标系統之間一般存在會話的概念（不止是web系統的http session）, 其本質在于server端會或多或少的存一些用戶端整個會話期間互動的身份識别以及資料資訊，為了防止server端每次都對同一個用戶端問一下，你是誰？系統會希望用戶端在一個會話期間粘連在某個特定的serer上，除非這個server失敗才failover到其它的server上，這種粘連特性對于server處理用戶端請求處理的性能和用戶端看到的資料一緻性是有很大好處的。但是dns負載均衡不能保證下一次請求會再次落在同一個server上。
dns解析緩存和ttl帶來的麻煩
dns記錄的緩存以及緩存失效時間都是個問題，在無線時代，通常來自手機的通路會經過稱為行業網關的代理伺服器，由于代理伺服器會将域名解析的結果緩存一段時間，是以所有經由這個代理伺服器的通路請求就全被解析到同一台伺服器上去了，是以就可能無法實作均等配置設定需要處理的請求了。另外在後端叢集的拓撲結構(副本數、部署位置、健康狀态等)發生變化之後，dns配置的變化要等到網絡上所有節點的緩存失效才能回報出來，這帶來的問題起碼有2個，1是在等待失效過程中，完全不可控，沒有辦法加快這個程序，中美切換要花10分鐘，因為要等網絡所有幾點對某些域名的ttl失效，2是滞後，有時候這種滞後是緻命的，比如仍然有部分流量打到已經挂掉的那部分伺服器上。
容錯
一個大型資料中心，每天都有機器壞了是很正常的事情，尤其是在虛拟化大行其道的今天，更是如此，相信你對虛拟主機又崩潰了一個，或者總是被同主控端的豬一樣的隊友“擠”死這種情況一定不陌生。dns負載均衡的一大問題就在于這種情況下的容災很麻煩，一是需要人工幹預或者其他軟體配合做健康監測，從dns配置中将無響應的機器或者崩潰的機器的相應的a記錄删掉。一是删掉之後也要等到所有網絡節點上的dns解析緩存失效，在這端時間内，很多通路系統的客戶會受到影響。
資料熱點
dns是在域名層面做負載均衡，如果從web系統的請求url角度講，不同的url對後端server的壓力強度不一樣，dns負載很可能會出現所有高強度的請求全都被打到小部分伺服器甚至同一台上去了的情況，這個問題的可怕性不在于風險，而在于風險完全不可控。
如圖: 用戶端 -> lb -> replica1,replica2,replica3
lb負責用戶端流量到後端服務叢集的分發，一般lb也會負責後端所有server的健康監測，關于健康監測這一塊我們在稍後一點再做具體分析。
可以在lb裡面做集中的分發邏輯，可以有多種分發方式，例如最常見的round robin, random robin, weight-based round robin等。
lb是單點, 這裡其實是有2個問題，下面具體分解一下。
問題1: 所有流量(請求流、響應流）都要經過lb，量太大，lb這小身闆扛不住啊，尤其是響應流，一般遠大于請求流，為什麼? 我們想想一般一個http請求封包大小和響應的封包大小的對比就明白了。
解決方案:
響應流不走lb了！
問題2: lb是單點啊，挂了，所有流量都損失了
解決方案之一(lb active-standby模式):
現在一些lb也會支援active-active模式，這裡不再介紹。
四層lb vs 七層lb
四層lb的特點一般是在網絡和網絡傳輸層(tcp/ip)做負載均衡，而七層則是指在應用層做負載均衡。2者的差別還是比較大的，各有優缺點，四層lb對于應用侵入比較小，這一層的lb對應用的感覺較少，同時應用接入基本不需要針對lb做任何的代碼改造。七層負載均衡一般對應用本身的感覺比較多，可以結合一些通用的業務流量負載邏輯和容災邏輯做成很細緻的負載均衡和流量導向方案，但是一般接入時，應用需要配合做相應的改造。
網際網路時代因為流量就是錢啊，是以對于流量的排程的細緻程度往往是四層lb難以滿足的，是以可以說七層負載均衡的解決方案現在是百花齊放，百家争鳴，中間層負載均衡(mid-tier load balancing)正當其時。
對于lb或者一個lb解決方案來說，健康檢測是lb固有需要一起實作的需求之一，lb要能幫助業務實作業務、伺服器、容器的優雅上、下線，幫助業務實作透明的擴容、縮容等一系列很現實的功能，如下簡圖:
在雲計算時代彈性計算(elastic compute service)，按需伸縮(on-demand allocation)大行其道的今天，對于lb健康檢測方案的靈敏度，準确性，多層次等等都提出了非常高的要求，别看健康檢測這個功能貌似很簡單，但是實作過程中如果有很多地方沒有想到，很容易就造成系統的重大的故障，我們的一些系統在心跳檢測上栽的跟頭并不少，踩過很多的坑。
在有@正明（章文嵩博士的花名）這樣的技術大牛，lvs的原作者本尊坐鎮的阿裡，為什麼阿裡會再做一個負載均衡産品?其實很簡單，為了解決實際的業務問題。在集團,阿裡技術團隊常常面臨的都是世界級難題，中間件團隊更是如此，我們不敢吹牛逼說對這些問題我們解得多好，但我們真的在踏實的認真的解這些問題，而且用我們自己特有的方式，而不是copy國外技術棧的方式在解這些難題，其實我們很多時候也很想copy啊，但是放眼全球相關領域确實是沒得抄。言歸正傳，上面我們過了一遍常見的負載均衡方案之後，我們可以發現傳統lb，如lvs的解決方案中并不是把所有的問題都已經解決了，我們檢視一下，起碼還遺留了6個問題:
如果過lb的請求量就大到把lb給打挂了怎麼辦?網際網路的流量，尤其是中國網際網路的流量，我們要有足夠的自信啊，而且參與過春節買票的，春晚修一修搶紅包的都能想象得到。
lb雖然可以有standby的方案或者有小規模叢集能力，但如果active/standby同時挂了怎麼辦? 1個蛋蛋很危險，但2個蛋蛋也未必就多安全。比如在active-standby方案中，既然active撐不住請求流量，那麼作為其clone的standby身上當然也不會出現任何奇迹，那麼是不是lb前面還應該再架一層lb呢?能不能lb叢集全挂了的情況下，不影響正常的業務?
請求方和目标機器之間總是要過一次lb,這在網絡鍊路上是多了1跳，我們都知道多一跳可不光是rt的損耗那麼簡單，鍊路上從1跳到2跳，鍊路和連接配接出故障的機率也翻了一倍,這要怎麼解？
多機房，多區域的異地多活與容災，國際化戰略的跨國流量的容災對于負載均衡提出的挑戰怎麼解，在阿裡集團内部，現在斷網、斷電、斷機房的演習如日常喝水、像辦公大樓消防演習一樣随意，據說要達到，馬老師半夜起來上個廁所，順便斷個電的能力，這些容災場景下業務流量的負載均衡怎麼解？
每次在一些如“秒殺”，“大促”等營銷熱點場景下，業務為了應對可以預期的流量洪峰，評估lb這一塊的容量夠不夠、要擴多少的痛點又如何解決?lb的彈性在哪裡?
成本。雖然lvs比一些傳統硬體lb的成本已經有很大的優勢，但是在一個大型網際網路系統級别的流量和業務發展面前,lvs的使用成本還是太高了一點。
vipserver就是為了解決這些實際問題而生，是以上面介紹的這些我們耳熟能詳的機制全都不是vipserver解決問題的思路。
vipserver是阿裡中間件團隊開發的一個中間層負載均衡(mid-tier load balancing)産品，vipserver是基于p2p模式，是一個七層負載均衡産品。vipserver提供動态域名解析和負載均衡服務，支援很多諸如多業務單元同單元優先、同機房優先、同區域優先等一系列流量智能排程和容災政策，支援多種健康監測協定，支援精細的權重控制，提供多級容災體系、具有對稱調用、健康門檻值保護等保護功能的解決方案。是阿裡負載均衡體系、域名服務體系的一個非常重要的組成部分。目前阿裡包括阿裡媽媽、釘釘、搜尋、ae、1688、阿裡雲、高德等幾乎所有的業務線均在使用vipserver，在一些重大的項目例如曆年雙11，支付寶春晚紅包項目都發揮了重大的作用。
vipserver的實作原理，限于篇幅，這裡不做詳細介紹。
講了這麼多平實的技術的東西，讓我們接着上面的故事往下叙述，幫助您了解vipserver為何在發揮越來越重要的作用。我們看看上面的故事中，随着業務的發展還會發生一些什麼事，遇到哪些挑戰。
現在你的公司已經各方面都已經走上正軌，馬上就要敲鐘上市了，在業内，世界範圍内已經有了廣泛的社會影響力，已經成為一個新興行業的風向标之一，很多人都盯着你，你這個公司有任何的風吹草動，新聞從業人員腎上腺激素都會往外狂飙，你的任何一個系統挂了都會影響幾億的使用者，産生千萬的資産損失，那麼問題來了，你的系統還敢随意的挂掉麼? 挂掉哪怕1分鐘都是給競争對手的一場狂歡，讓自己的公關團隊夙夜難眠！好，像這麼牛逼的公司你覺得你開始更多的需要考慮的是什麼?1個機房，全在h城?那怎麼可以?!!且不說地球這麼危險，地震、海嘯頻發，錯峰用電、火災時有發生，有時候周圍的化工廠還會爆個炸啥的，有時候就是工地上的鏟車看起來都那麼可怕，尤其是blueshi(r)t人開的鏟車尤其的可怕。好吧，看來你需要在多個城市，多個國家，多個地球上建設很多個機房。有了多個機房萬事就ok了麼？不，事情其實要比你想象的複雜的多，你的公司的已有應用都在一開始就支援異地容災能力了麼，做架構的都知道無狀态的應用可能好一點，但是那些有狀态的應用在這一塊絕對是重災區。
再從另一個視角來看這個問題，你的公司再過去的幾年發展過程中會有各種的新需求，貴公司會有越來越多的新業務來滿足這些新需求，而針對這些新業務當然會有更多的各種系統或者叫應用來滿足和服務這些客戶，但這些應用就像我們的手指頭，并不是均衡的，并不是都一樣長，這些系統，使用者數不均衡，流量不均衡，耗費的計算資源不均衡，資料重要性、特征分布，容災能力，跨地域部署能力等等全都不均衡。
某一天你好奇到底有多少個系統，調用鍊路是怎樣的，他們的機房分布是怎樣的?想評估一下a地的機房全挂了會影響多少系統，多少流量，産生多少資損? 于是梳理了一下，這下傻眼了，可能是這個樣子的:
如果更準确一點的話，這個圖其實應該是個動态的jpeg,因為每周都有系統在出生和消亡，有的應用版圖在擴大，有的應用版圖在縮小，而且從一定程度上來講，這個圖的變化的速度一定程度上反應了貴公司的整個系統跟随業務快速變化的能力和業務的活力，除了應用本身，資料中心每天都有實體機器在崩潰和修複，虛拟化之後更明顯。
如果有這麼一種負載均衡器，能在宏觀上，某個切面上讓所有的應用之間的調用滿足如下的智能排程政策，将是一個多麼美好的事情，而且最好是接入幾乎不用怎麼讓已有的業務做代碼的改造，這種改造是多麼蛋疼的事情，有經驗的平台架構師肯定身有體會，無需贅述。
同機房優先
a應用調用b應用，負載均衡器負責排程，如果b應用有跟a部署在同一個機房部署的話，就優先路由到同機房的b。
流量打散的容災需求
昨天同機房的a和b玩的還好好的，但同機房的b應用說沒有就沒有了，有時候是淩晨睡的正香的時候沒有了，手機上報警嘩嘩的，這時候你就想要是能流量自動打散到最近的機房就好了。
貴公司要的是千裡之外的容災，國際化的戰略，而使用者需要的是毫秒級的請求響應速度，跟随戰略，這網絡延遲蹭蹭的往上漲，網絡品質蹭蹭的往下降，但另一個方面，現在使用者的時間碎片化這麼嚴重，毫秒級的延遲就可能導緻使用者失去耐心全去你的競争對手的網站上去了，是以如何去彌合所有已有應用之間的跨機房、區域、國家的調用導緻這2個方向上的裂隙?
你作為老闆，想了一下，一個小小負載均衡器挂了，怎麼可以影響到所有的業務呢？而作為有夢想的程式猿啊，出來混，系統要”穩“字當頭，一個3天2頭當機的系統即使有價值也有限的很，而且很快會被更穩定的系統所替代，是以lb的server挂了還能保障業務繼續運作的lb才是好的lb.
作為一個誕生剛幾年的家夥，雖然發展确實很快，但它還隻是個孩子，我們想說的是不光是使用者這樣看，其實在我們自己的眼裡，它還有很多很多的不足甚至缺陷，但有@正明這樣的前輩在前面的孜孜不倦、追求卓越的身影，我們這些後輩怎麼可以懈怠，屍位素餐，怎麼可以不持續改進自己的産品，在國内技術領域的技術積累貢獻自己一點微薄的力量呢！《漢書·程式猿傳》有雲：“今我輩程式猿，上不能匡主，下不能益民，皆可以稱之為屍位素餐。“
最後歡迎通過各種方式聯系我們，吐槽和給我們提意見，雖然人之本性是不喜歡被吐槽，我們也是，但根據我們的觀察，對産品吐槽的厲害的兄弟恰恰是能給我們做産品新的靈感和有高含金量需求的人。