目錄

　　一、什么是負載均衡，都是負載惹的禍

　　二、常用的負載均衡技術比較

　　三、健康檢測，負載均衡的伴侶

　　四、為什么我們要做VIPServer？

　　五、VIPServer簡介

　　六、為什么短短幾年VIPServer在阿里集團發展的這么快?

　　七、VIPServer并不完美

阿里 Load Balance 之旅

　　什么是負載均衡（Load Balance）

　　“負載(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的負載均衡，其大致原理很清楚，DNS系統本身支持同一個域名映射到多個ip (A記錄）,例如

　　niubility.com. IN A 172.168.1.101

　　IN A 172.168.1.102

　　IN A 172.168.1.103

　　IN A 172.168.1.104

　　這樣每次向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健康檢測方案的靈敏度，準確性，多層次等等都提出了非常高的要求，別看健康檢測這個功能貌似很簡單，但是實現過程中如果有很多地方沒有想到，很容易就造成系統的重大的故障，我們的一些系統在心跳檢測上栽的跟頭并不少，踩過很多的坑。

為什么我們要做VIPServer

　　在有@正明（章文嵩博士的花名）這樣的技術大牛，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簡介

　　VIPServer是阿里中間件團隊開發的一個中間層負載均衡(mid-tier load balancing)產品，VIPServer是基于P2P模式，是一個七層負載均衡產品。VIPServer提供動態域名解析和負載均衡服務，支持很多諸如多業務單元同單元優先、同機房優先、同區域優先等一系列流量智能調度和容災策略，支持多種健康監測協議，支持精細的權重控制，提供多級容災體系、具有對稱調用、健康閾值保護等保護功能的解決方案。是阿里負載均衡體系、域名服務體系的一個非常重要的組成部分。

　　目前阿里包括阿里媽媽、釘釘、搜索、AE、1688、阿里云、高德等幾乎所有的業務線均在使用VIPServer，在一些重大的項目例如歷年雙11，支付寶春晚紅包項目都發揮了重大的作用。

　　VIPServer的實現原理，限于篇幅，這里不做詳細介紹，具體可以參考我們發表的VIPServer的Paper:

　　VIPServer: A System for Dynamic Address Mapping and Environment Management

為什么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.

VIPServer并不完美

　　作為一個誕生剛幾年的家伙，雖然發展確實很快，但它還只是個孩子，我們想說的是不光是用戶這樣看，其實在我們自己的眼里，它還有很多很多的不足甚至缺陷，但有@正明這樣的前輩在前面的孜孜不倦、追求卓越的身影，我們這些后輩怎么可以懈怠，尸位素餐，怎么可以不持續改進自己的產品，在國內技術領域的技術積累貢獻自己一點微薄的力量呢！《漢書·程序猿傳》有云：“今我輩程序猿，上不能匡主，下不能益民，皆可以稱之為尸位素餐。”

轉載于:https://my.oschina.net/u/3361217/blog/869383

總結

以上是生活随笔為你收集整理的（转载自）章文嵩博士和他背后的负载均衡帝国的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。