阿里集團(tuán)技術(shù)大牛，@正明，淘寶基礎(chǔ)核心軟件研發(fā)負(fù)責(zé)人、LVS創(chuàng)始人、阿里云首席科學(xué)家章文嵩博士從阿里離職，去追求技術(shù)人生另一段歷程，讓阿里像我一樣的很多熱愛技術(shù)的工程師都有一絲牽動和感觸。

我個人作為一個平凡的一線技術(shù)工程師，對章博士是很敬佩的(雖然他還不認(rèn)識我),國內(nèi)IT業(yè)界這么多年，在底層基石技術(shù)層面有所建樹，打到Linux標(biāo)準(zhǔn)內(nèi)核模塊層面的應(yīng)該就LVS了吧，而且就廣泛影響力方面，LVS在Linux逐漸取代IBM Aix, Sun Solaris,HPUX 這些Unix們的過程中，扮演了很重要一塊的角色，那就是LVS是Linux Cluster的標(biāo)準(zhǔn)解決方案的核心,在我個人看來，X86-64芯片對比Power,Itanium,PA-RISC的更高性價比和Lvs Linux Cluster的方案成熟是互聯(lián)網(wǎng)時代剛開始興起的那個時期，在技術(shù)準(zhǔn)備上，從Unix逐漸走向低端商用機(jī)+Linux方案的2把掘墓鋤頭，雖然不是唯二的2把，但是絕對是其中非常重要的2把,而很多中國人、美國人、歐洲人、日本人...的技術(shù)書籍里介紹Linux技術(shù)的書籍里，LVS必然會在里面占有一定的篇幅。另外章博士也是國內(nèi)開源文化的積極的倡導(dǎo)者和真正踐行者，我們阿里中間件之所以開源被業(yè)界廣泛使用的產(chǎn)品(Dubbo,MetaQ,Diamond...)，究其原因，也可以說是深受章博士的影響。

在阿里中間件，我所在的團(tuán)隊恰好是專注在”軟負(fù)載“（軟件負(fù)載網(wǎng)絡(luò)）方面，提供的產(chǎn)品和服務(wù)，跟負(fù)載均衡產(chǎn)品有很大一部分交集，在集團(tuán)內(nèi)，我們的產(chǎn)品VIPServer可以說跟LVS有一些直面的競爭，在集團(tuán)內(nèi)越來越多的業(yè)務(wù)逐漸從LVS遷往VIPServer上，但正因為如此，所以在負(fù)載均衡領(lǐng)域我們對于章博士的江湖地位和影響力才有更深刻的了解。在這個技術(shù)人目光再次聚焦在章博士身上的時候，我想借此機(jī)會將我們團(tuán)隊對于負(fù)載均衡產(chǎn)品這一塊的一些思考和實踐經(jīng)驗，總結(jié)分享給需要的人，希望幫助到正在思考這一塊的技術(shù)人。也許未來我們永遠(yuǎn)也不能像章博士這樣做出廣泛影響世界技術(shù)圈的產(chǎn)品，但是作為后輩，我們會看著前輩的身影，追尋著往這個方向一直努力下去。

下面讓我們以輕松一點的心情開始:

阿里 Load Balance 之旅

什么是負(fù)載均衡（Load Balance）

• “負(fù)載(load)”惹得禍

首先讓我們從原點出發(fā)。

某一天清晨起床，你突然有了一個美妙的想法，這個想法讓你興奮不已，因為你發(fā)現(xiàn)了一個具有廣闊市場前景的處女地，這個處女地還完全沒有被開墾，這是一項新業(yè)務(wù)，這項業(yè)務(wù)能滿足世界上大部分人的某個方面他們自己都不知道的潛在的需求，更妙的是，到目前為止，它還沒有被任何人發(fā)現(xiàn)。你簡直被自己的天才驚呆了，被自己的天才想法感動的內(nèi)牛滿面，你確信你的人生會因為這個想法而改變，宇宙也會因為你這個想法而變的大不相同，你確定這個想法的實現(xiàn)將能幫助你走上人生巔峰，上上個時代是比爾蓋子，上個時代是拉里配齊，下個時代毫無疑問將是你，你迫不及待的想要將這項業(yè)務(wù)通過一個系統(tǒng)來表達(dá)和實現(xiàn)，于是你奮戰(zhàn)了好幾個通宵，有了下面這個能支撐這項新業(yè)務(wù)的非常牛逼的系統(tǒng):

是的，你的系統(tǒng)已經(jīng)有了第一個用戶，這個用戶就是你自己。接下來你將你的系統(tǒng)通過X信朋友圈、釘釘、各大論壇廣邀各路親朋好友試試這個系統(tǒng)，結(jié)果是，非常棒! 好評如潮，他們不停的拉自己的親朋好友開始訪問這個系統(tǒng)，因此注冊、活躍用戶越來越多，此時，你興奮不已，感覺自己馬上就要走上人生巔峰。

但等等，不知道哪里出了問題，你的這個新系統(tǒng)居然上了ccav財經(jīng)頻道，而且被各路媒體小報紛紛報導(dǎo)，瞬間所有人都想看看這個牛逼的系統(tǒng)，于是乎,悲劇發(fā)生了:

怎么辦？怎么辦？很快你想到了3個解決方案。

• 縱向擴(kuò)展（Scale Up)

沒啥好說的，也許只是服務(wù)器還不夠NB，買！買！買！宇宙最好的服務(wù)器來上一臺，可惜，創(chuàng)業(yè)剛開始，投資人的錢要花在刀刃上，比如廣告營銷上，比如路邊掃個碼啊，順便送個內(nèi)衣啊、牙刷啊什么的，服務(wù)器? 買不起! 而且看了一下宇宙上最好服務(wù)器的網(wǎng)卡配置，更泄氣，這就不是有錢買個NB服務(wù)器就能解決的事！

• 業(yè)務(wù)拆分

你仔細(xì)審視之后，發(fā)現(xiàn)其實你的系統(tǒng)的2個頁面是2個不同的業(yè)務(wù)，用來滿足不同的需求的，于是啊，你就想，是不是能把這2個業(yè)務(wù)分開到2個系統(tǒng)中去，這樣用戶們自然乖乖的被引導(dǎo)、分流到2個子系統(tǒng)去了，這樣每個系統(tǒng)的壓力就減少了啊。這就好比一個飯店，生意火爆，原先來吃火鍋和吃大餅卷牛排的都在一起，擠不下之后，現(xiàn)在分成了2個店，1個是火鍋店，1個是大餅卷牛排店。從某種角度來說，這種其實也是一種負(fù)載均衡，但怎么做業(yè)務(wù)拆分并且通過組織文化和人事架構(gòu)去保障和適應(yīng)這種業(yè)務(wù)拆分，是有很多的業(yè)務(wù)考量和業(yè)務(wù)屬性在里面的，每個老板和每個行業(yè)的答案可能都是不同的，此文討論的不在這個方向上。

• 橫向擴(kuò)展（Scale Out）和 副本(Replica)

做完上面的垂直拆分之后，可能你會發(fā)現(xiàn)還是不行啊，這世界上擁有獨特口味的人太多，吃大餅卷牛排的人還是太多了，怎么辦? 開分店吧，每個上檔次的商場都開一個大餅卷牛排店，這樣每個地域的人又被分流到了附近的店。這個提供一模一樣服務(wù)的“分店”就是系統(tǒng)的副本（Replica），分布式系統(tǒng)中的副本(Replica)除了滿足數(shù)據(jù)冗余，容災(zāi)的需要等之外，橫向擴(kuò)展，通過開多個分店（Replica)分流的行為,就是負(fù)載均衡,做到多副本之間分流是一個重要的目的。而這個正是本文討論的范圍所在，如下簡圖:

接下來, 關(guān)于如何讓你的系統(tǒng)實現(xiàn)負(fù)載均衡，做到Scale Out, 你開始走上選型之路，

常用的負(fù)載均衡技術(shù)比較

DNS 輪詢

DNS本身的機(jī)制不再贅述，這里主要看一看基于DNS的負(fù)載均衡，其大致原理很清楚，DNS系統(tǒng)本身支持同一個域名映射到多個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系統(tǒng)詢問該域名的ip地址時（Tell Me The IP Address of niubility.com.），DNS會輪詢(Round Robin)這個ip列表，每次給一個不同的ip，從而達(dá)到負(fù)載均衡的效果。

來看看這種負(fù)載均衡解決方案的優(yōu)缺點

優(yōu)點

• 易于實現(xiàn)

對于應(yīng)用系統(tǒng)本身幾乎沒有任何侵入，配置也很簡單，在某個文本里多加幾行A記錄就可以。尤其對于一個基于Web的系統(tǒng)來說更是如此，用戶在瀏覽器里輸入的URL host部分天然就是域名，所以在某個環(huán)節(jié)你必然有起碼一臺DNS服務(wù)器記錄著這個域名對應(yīng)的ip，所以可以說是基于已有域名系統(tǒng)(資產(chǎn))就做到了負(fù)載均衡。

缺點

• 會話粘連 (Session Sticky)

客戶端與目標(biāo)系統(tǒng)之間一般存在會話的概念（不止是web系統(tǒng)的http session）, 其本質(zhì)在于server端會或多或少的存一些客戶端整個會話期間交互的身份識別以及數(shù)據(jù)信息，為了防止server端每次都對同一個客戶端問一下，你是誰？系統(tǒng)會希望客戶端在一個會話期間粘連在某個特定的serer上，除非這個server失敗才failover到其它的server上，這種粘連特性對于server處理客戶端請求處理的性能和客戶端看到的數(shù)據(jù)一致性是有很大好處的。但是DNS負(fù)載均衡不能保證下一次請求會再次落在同一個server上。

• DNS解析緩存和TTL帶來的麻煩

dns記錄的緩存以及緩存失效時間都是個問題，在無線時代，通常來自手機(jī)的訪問會經(jīng)過稱為行業(yè)網(wǎng)關(guān)的代理服務(wù)器，由于代理服務(wù)器會將域名解析的結(jié)果緩存一段時間，所以所有經(jīng)由這個代理服務(wù)器的訪問請求就全被解析到同一臺服務(wù)器上去了，因此就可能無法實現(xiàn)均等分配需要處理的請求了。另外在后端集群的拓?fù)浣Y(jié)構(gòu)(副本數(shù)、部署位置、健康狀態(tài)等)發(fā)生變化之后，dns配置的變化要等到網(wǎng)絡(luò)上所有節(jié)點的緩存失效才能反饋出來，這帶來的問題起碼有2個，1是在等待失效過程中，完全不可控，沒有辦法加快這個進(jìn)程，中美切換要花10分鐘，因為要等網(wǎng)絡(luò)所有幾點對某些域名的TTL失效，2是滯后，有時候這種滯后是致命的，比如仍然有部分流量打到已經(jīng)掛掉的那部分服務(wù)器上。

• 容錯

一個大型數(shù)據(jù)中心，每天都有機(jī)器壞了是很正常的事情，尤其是在虛擬化大行其道的今天，更是如此，相信你對虛擬主機(jī)又崩潰了一個，或者總是被同宿主機(jī)的豬一樣的隊友“擠”死這種情況一定不陌生。dns負(fù)載均衡的一大問題就在于這種情況下的容災(zāi)很麻煩，一是需要人工干預(yù)或者其他軟件配合做健康監(jiān)測，從dns配置中將無響應(yīng)的機(jī)器或者崩潰的機(jī)器的相應(yīng)的A記錄刪掉。一是刪掉之后也要等到所有網(wǎng)絡(luò)節(jié)點上的dns解析緩存失效，在這端時間內(nèi)，很多訪問系統(tǒng)的客戶會受到影響。

• 數(shù)據(jù)熱點

dns是在域名層面做負(fù)載均衡，如果從web系統(tǒng)的請求URL角度講，不同的URL對后端server的壓力強(qiáng)度不一樣，dns負(fù)載很可能會出現(xiàn)所有高強(qiáng)度的請求全都被打到小部分服務(wù)器甚至同一臺上去了的情況，這個問題的可怕性不在于風(fēng)險，而在于風(fēng)險完全不可控。

引入負(fù)載均衡器

如圖: 客戶端 -> LB -> replica1,replica2,replica3

LB負(fù)責(zé)客戶端流量到后端服務(wù)集群的分發(fā)，一般LB也會負(fù)責(zé)后端所有server的健康監(jiān)測，關(guān)于健康監(jiān)測這一塊我們在稍后一點再做具體分析。

優(yōu)點

可以在LB里面做集中的分發(fā)邏輯，可以有多種分發(fā)方式，例如最常見的Round Robin, Random Robin, Weight-Based Round Robin等。

缺點

LB是單點, 這里其實是有2個問題，下面具體分解一下。

• 問題1: 所有流量(請求流、響應(yīng)流）都要經(jīng)過LB，量太大，LB這小身板扛不住啊，尤其是響應(yīng)流，一般遠(yuǎn)大于請求流，為什么? 我們想想一般一個http請求報文大小和響應(yīng)的報文大小的對比就明白了。

解決方案:

響應(yīng)流不走LB了！

• 問題2: LB是單點啊，掛了，所有流量都損失了

解決方案之一(LB Active-Standby模式):

現(xiàn)在一些LB也會支持Active-Active模式，這里不再介紹。

• 四層LB vs 七層LB

四層LB的特點一般是在網(wǎng)絡(luò)和網(wǎng)絡(luò)傳輸層(TCP/IP)做負(fù)載均衡，而七層則是指在應(yīng)用層做負(fù)載均衡。2者的區(qū)別還是比較大的，各有優(yōu)缺點，四層LB對于應(yīng)用侵入比較小，這一層的LB對應(yīng)用的感知較少，同時應(yīng)用接入基本不需要針對LB做任何的代碼改造。七層負(fù)載均衡一般對應(yīng)用本身的感知比較多，可以結(jié)合一些通用的業(yè)務(wù)流量負(fù)載邏輯和容災(zāi)邏輯做成很細(xì)致的負(fù)載均衡和流量導(dǎo)向方案，但是一般接入時，應(yīng)用需要配合做相應(yīng)的改造。

互聯(lián)網(wǎng)時代流量就是錢啊，對于流量的調(diào)度的細(xì)致程度往往是四層LB難以滿足的，可以說七層負(fù)載均衡的解決方案現(xiàn)在是百花齊放，百家爭鳴，中間層負(fù)載均衡(mid-tier load balancing)正當(dāng)其時。

健康檢測，負(fù)載均衡的伴侶

對于LB或者一個LB解決方案來說，健康檢測是LB固有需要一起實現(xiàn)的需求之一，LB要能幫助業(yè)務(wù)實現(xiàn)業(yè)務(wù)、服務(wù)器、容器的優(yōu)雅上、下線，幫助業(yè)務(wù)實現(xiàn)透明的擴(kuò)容、縮容等一系列很現(xiàn)實的功能，如下簡圖:

在云計算時代彈性計算(Elastic Compute Service)，按需伸縮(On-Demand Allocation)大行其道的今天，對于LB健康檢測方案的靈敏度，準(zhǔn)確性，多層次等等都提出了非常高的要求，別看健康檢測這個功能貌似很簡單，但是實現(xiàn)過程中如果有很多地方?jīng)]有想到，很容易就造成系統(tǒng)的重大的故障，我們的一些系統(tǒng)在心跳檢測上栽的跟頭并不少，踩過很多的坑。

為什么我們要做VIPServer？

在有@正明（章文嵩博士的花名）這樣的技術(shù)大牛，LVS的原作者本尊坐鎮(zhèn)的阿里，為什么阿里會再做一個負(fù)載均衡產(chǎn)品?其實很簡單，為了解決實際的業(yè)務(wù)問題。在集團(tuán),阿里技術(shù)團(tuán)隊常常面臨的都是世界級難題，中間件團(tuán)隊更是如此，我們不敢吹牛逼說對這些問題我們解得多好，但我們真的在踏實的認(rèn)真的解這些問題，而且用我們自己特有的方式，而不是COPY國外技術(shù)棧的方式在解這些難題，其實我們很多時候也很想COPY啊，但是放眼全球相關(guān)領(lǐng)域確實是沒得抄。言歸正傳，上面我們過了一遍常見的負(fù)載均衡方案之后，我們可以發(fā)現(xiàn)傳統(tǒng)LB，如LVS的解決方案中并不是把所有的問題都已經(jīng)解決了，我們檢視一下，起碼還遺留了6個問題:

1. 如果過LB的請求量就大到把LB給打掛了怎么辦?互聯(lián)網(wǎng)的流量，尤其是中國互聯(lián)網(wǎng)的流量，我們要有足夠的自信啊，而且參與過春節(jié)買票的，春晚修一修搶紅包的都能想象得到。
2. LB雖然可以有standby的方案或者有小規(guī)模集群能力，但如果active/standby同時掛了怎么辦? 1個蛋蛋很危險，但2個蛋蛋也未必就多安全。比如在active-standby方案中，既然active撐不住請求流量，那么作為其clone的standby身上當(dāng)然也不會出現(xiàn)任何奇跡，那么是不是LB前面還應(yīng)該再架一層LB呢?能不能LB集群全掛了的情況下，不影響正常的業(yè)務(wù)?
3. 請求方和目標(biāo)機(jī)器之間總是要過一次LB,這在網(wǎng)絡(luò)鏈路上是多了1跳，我們都知道多一跳可不光是rt的損耗那么簡單，鏈路上從1跳到2跳，鏈路和連接出故障的概率也翻了一倍,這要怎么解？
4. 多機(jī)房，多區(qū)域的異地多活與容災(zāi)，國際化戰(zhàn)略的跨國流量的容災(zāi)對于負(fù)載均衡提出的挑戰(zhàn)怎么解，在阿里集團(tuán)內(nèi)部，現(xiàn)在斷網(wǎng)、斷電、斷機(jī)房的演習(xí)如日常喝水、像辦公大樓消防演習(xí)一樣隨意，據(jù)說要達(dá)到，馬老師半夜起來上個廁所，順便斷個電的能力，這些容災(zāi)場景下業(yè)務(wù)流量的負(fù)載均衡怎么解？
5. 每次在一些如“秒殺”，“大促”等營銷熱點場景下，業(yè)務(wù)為了應(yīng)對可以預(yù)期的流量洪峰，評估LB這一塊的容量夠不夠、要擴(kuò)多少的痛點又如何解決?LB的彈性在哪里?
6. 成本。雖然LVS比一些傳統(tǒng)硬件LB的成本已經(jīng)有很大的優(yōu)勢，但是在一個大型互聯(lián)網(wǎng)系統(tǒng)級別的流量和業(yè)務(wù)發(fā)展面前,LVS的使用成本還是太高了一點。

VIPServer就是為了解決這些實際問題而生，所以上面介紹的這些我們耳熟能詳?shù)臋C(jī)制全都不是VIPServer解決問題的思路。

VIPServer簡介

VIPServer是阿里中間件團(tuán)隊開發(fā)的一個中間層負(fù)載均衡(mid-tier load balancing)產(chǎn)品，VIPServer是基于P2P模式，是一個七層負(fù)載均衡產(chǎn)品。VIPServer提供動態(tài)域名解析和負(fù)載均衡服務(wù)，支持很多諸如多業(yè)務(wù)單元同單元優(yōu)先、同機(jī)房優(yōu)先、同區(qū)域優(yōu)先等一系列流量智能調(diào)度和容災(zāi)策略，支持多種健康監(jiān)測協(xié)議，支持精細(xì)的權(quán)重控制，提供多級容災(zāi)體系、具有對稱調(diào)用、健康閾值保護(hù)等保護(hù)功能的解決方案。是阿里負(fù)載均衡體系、域名服務(wù)體系的一個非常重要的組成部分。目前包括阿里媽媽、釘釘、搜索、AE、1688、阿里云、高德等幾乎所有的業(yè)務(wù)線均在使用VIPServer，在一些重大的項目例如歷年雙11，支付寶春晚紅包項目都發(fā)揮了重大的作用。

VIPServer的實現(xiàn)原理，限于篇幅，這里不做詳細(xì)介紹。

為什么短短幾年VIPServer在阿里集團(tuán)發(fā)展的這么快?

講了這么多平實的技術(shù)的東西，讓我們接著上面的故事往下敘述，幫助您理解VIPServer為何在發(fā)揮越來越重要的作用。我們看看上面的故事中，隨著業(yè)務(wù)的發(fā)展還會發(fā)生一些什么事，遇到哪些挑戰(zhàn)。

現(xiàn)在你的公司已經(jīng)各方面都已經(jīng)走上正軌，馬上就要敲鐘上市了，在業(yè)內(nèi)，世界范圍內(nèi)已經(jīng)有了廣泛的社會影響力，已經(jīng)成為一個新興行業(yè)的風(fēng)向標(biāo)之一，很多人都盯著你，你這個公司有任何的風(fēng)吹草動，新聞從業(yè)人員腎上腺激素都會往外狂飆，你的任何一個系統(tǒng)掛了都會影響幾億的用戶，產(chǎn)生千萬的資產(chǎn)損失，那么問題來了，你的系統(tǒng)還敢隨意的掛掉么? 掛掉哪怕1分鐘都是給競爭對手的一場狂歡，讓自己的公關(guān)團(tuán)隊夙夜難眠！好，像這么牛逼的公司你覺得你開始更多的需要考慮的是什么?1個機(jī)房，全在H城?那怎么可以?!!且不說地球這么危險，地震、海嘯頻發(fā)，錯峰用電、火災(zāi)時有發(fā)生，有時候周圍的化工廠還會爆個炸啥的，有時候就是工地上的鏟車看起來都那么可怕，尤其是blueshi(r)t人開的鏟車尤其的可怕。好吧，看來你需要在多個城市，多個國家，多個地球上建設(shè)很多個機(jī)房。有了多個機(jī)房萬事就OK了么？不，事情其實要比你想象的復(fù)雜的多，你的公司的已有應(yīng)用都在一開始就支持異地容災(zāi)能力了么，做架構(gòu)的都知道無狀態(tài)的應(yīng)用可能好一點，但是那些有狀態(tài)的應(yīng)用在這一塊絕對是重災(zāi)區(qū)。

再從另一個視角來看這個問題，你的公司再過去的幾年發(fā)展過程中會有各種的新需求，貴公司會有越來越多的新業(yè)務(wù)來滿足這些新需求，而針對這些新業(yè)務(wù)當(dāng)然會有更多的各種系統(tǒng)或者叫應(yīng)用來滿足和服務(wù)這些客戶，但這些應(yīng)用就像我們的手指頭，并不是均衡的，并不是都一樣長，這些系統(tǒng)，用戶數(shù)不均衡，流量不均衡，耗費的計算資源不均衡，數(shù)據(jù)重要性、特征分布，容災(zāi)能力，跨地域部署能力等等全都不均衡。

某一天你好奇到底有多少個系統(tǒng)，調(diào)用鏈路是怎樣的，他們的機(jī)房分布是怎樣的?想評估一下A地的機(jī)房全掛了會影響多少系統(tǒng)，多少流量，產(chǎn)生多少資損? 于是梳理了一下，這下傻眼了，可能是這個樣子的:

如果更準(zhǔn)確一點的話，這個圖其實應(yīng)該是個動態(tài)的jpeg,因為每周都有系統(tǒng)在出生和消亡，有的應(yīng)用版圖在擴(kuò)大，有的應(yīng)用版圖在縮小，而且從一定程度上來講，這個圖的變化的速度一定程度上反應(yīng)了貴公司的整個系統(tǒng)跟隨業(yè)務(wù)快速變化的能力和業(yè)務(wù)的活力，除了應(yīng)用本身，數(shù)據(jù)中心每天都有物理機(jī)器在崩潰和修復(fù)，虛擬化之后更明顯。

• 如果有這么一種負(fù)載均衡器，能在宏觀上，某個切面上讓所有的應(yīng)用之間的調(diào)用滿足如下的智能調(diào)度策略，將是一個多么美好的事情，而且最好是接入幾乎不用怎么讓已有的業(yè)務(wù)做代碼的改造，這種改造是多么蛋疼的事情，有經(jīng)驗的平臺架構(gòu)師肯定身有體會，無需贅述。

  • 同機(jī)房優(yōu)先 A應(yīng)用調(diào)用B應(yīng)用，負(fù)載均衡器負(fù)責(zé)調(diào)度，如果B應(yīng)用有跟A部署在同一個機(jī)房部署的話，就優(yōu)先路由到同機(jī)房的B。
  • 流量打散的容災(zāi)需求 昨天同機(jī)房的A和B玩的還好好的，但同機(jī)房的B應(yīng)用說沒有就沒有了，有時候是凌晨睡的正香的時候沒有了，手機(jī)上報警嘩嘩的，這時候你就想要是能流量自動打散到最近的機(jī)房就好了。
  • 貴公司要的是千里之外的容災(zāi)，國際化的戰(zhàn)略，而用戶需要的是毫秒級的請求響應(yīng)速度，跟隨戰(zhàn)略，這網(wǎng)絡(luò)延遲蹭蹭的往上漲，網(wǎng)絡(luò)質(zhì)量蹭蹭的往下降，但另一個方面，現(xiàn)在用戶的時間碎片化這么嚴(yán)重，毫秒級的延遲就可能導(dǎo)致用戶失去耐心全去你的競爭對手的網(wǎng)站上去了，所以如何去彌合所有已有應(yīng)用之間的跨機(jī)房、區(qū)域、國家的調(diào)用導(dǎo)致這2個方向上的裂隙?
  • 你作為老板，想了一下，一個小小負(fù)載均衡器掛了，怎么可以影響到所有的業(yè)務(wù)呢？而作為有夢想的程序猿啊，出來混，系統(tǒng)要”穩(wěn)“字當(dāng)頭，一個3天2頭宕機(jī)的系統(tǒng)即使有價值也有限的很，而且很快會被更穩(wěn)定的系統(tǒng)所替代，所以LB的server掛了還能保障業(yè)務(wù)繼續(xù)運行的LB才是好的LB.

用戶故事 (Use Case)

這中間故事太多，不好攫取，這里取集團(tuán)阿里媽媽廣告業(yè)務(wù)線從LVS+內(nèi)部域名的解決方案全線遷往VIPServer的案例?？聪聢D:

在阿里媽媽廣告業(yè)務(wù)線全線遷往VIPServer之后，整體業(yè)務(wù)調(diào)用rt從平均50多ms，下降到40多ms,下降了12毫秒，12毫秒是什么概念呢,是杭州機(jī)房到上海機(jī)房的rt的double!要知道這是在幾乎沒有什么改造成本的情況下取得的，什么樣的代碼優(yōu)化能在很少侵入業(yè)務(wù)代碼的情況下，讓一個BU所有的業(yè)務(wù)應(yīng)用都受惠12ms? 而且收獲的還不僅僅是這些。

VIPServer并不完美。

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