淺黑科技 - 阿里巴巴的十三載計算力大突圍－鑽石舞台

淺友們好~我是史中，我的日常生活是開撩五湖四海的科技大牛，我會嘗試各種姿勢，把他們的無邊腦洞和溫情故事講給你聽。如果你想和我做朋友，不妨加微信（shizhongmax）。

阿里巴巴的十三載計算力大突圍

文 | 史中

2022年初，杭州雪大如席。

口罩隱蔽了孩子們興奮的臉，汽車排成鋼鐵鏈條在城市血脈里蔓延。

阿里巴巴星散的幾座園區悉數被皚皚鵝毛籠罩。落地窗前，不時有人駐足凝望。

江南大雪並不尋常，也許一生都難見幾次。不知他們有沒有回想起2008年，那時落雪如今天一樣瘋狂，停雪如此刻一樣靜美。

只是自己的面孔還年輕許多。

（一）計算力大突圍

2008年8月，一首《歌唱祖國》通過孩子的嗓音傳向世界，屏幕前人們眼含熱淚齊聲高歌。

可嘆如今回望，那場告慰並非故事「終結的開始」，而是「開始的終結」。

盛世炙熱，站在各行各業山頂的「先知們」卻已感到陣陣寒意。

「計算力」領域，首當其衝。

你不妨想象一艘軍艦：

承載船體的「大海」是芯片，我們的「芯片設計」和「芯片製造」都發展滯後，芯片是中國第一大進口門類。

向上看，操作系統就是「船體」，遑論閉源系統 Windows、MacOS ，開源系統 Linux 中國程序員的發言權也極為有限。

再往上看，應用軟件就是「艦炮」。雖然中國「消費軟件」有一些本土生態（遊戲、文字處理、即時通信），但重磅的「生產軟件」都來自世界老牌廠商。

例如「企業資源管理軟件」領導者是 SAP，「製造執行系統」領導者是西門子，金融領域的「數據庫」被甲骨文和IBM壟斷。還有「碰撞模擬軟件」、「流體力學模擬軟件」、「工業製圖軟件」、「集成電路設計軟件」，越精專，越沒戲。

想想看，三層自研技術全面落後，拼裝起來的軍艦必定「慘不忍睹」。

我們和國際領先水平的差距不亞於「木船舢板」對「堅船利炮」。。。

別人能搞出來，我們為啥搞不出來？

核心問題在於：培養計算力恰恰就像拉扯一個孩子，需要在一個相對緩和的商業環境裡蹣跚學步。

但現實是，我們永遠錯失了那個時代。如今的全球戰場已是「地獄」級別——中國計算力的萌新小船剛探頭進入開放的「商業公海」，就會立刻遭遇戰力先進N倍的對手重炮合圍，保命都難，還想操練技術，門兒都沒有。。。

即便勝算渺茫，無數中國的軟硬件開發者仍然前赴後繼，幾十年肉身搏殺，青絲白髮。可嘆實力過於懸殊，自研技術終究被壓制在「軍港」，難以突圍。

本來，故事極有可能就這樣暗淡地走到終章。但就在我們精疲力盡時，科技的汪洋陡然掀起巨浪，把「包圍圈」沖開一道裂縫，光芒從中奔涌。

這道裂縫就是「分布式計算」。

為什麼會如摩西分開紅海一樣，出現這道「天賜裂縫」呢？我交代一下背景：

新世紀初，互聯網帶動全世界經濟蓬勃發展，對計算力的需求史詩級爆炸——眼看像「搜索」、「大數據計算」、「數據庫」等等很多大規模任務用「單台計算機」已經撐不起來了。

這意味着，國際老牌公司最拿手的「傳統計算力結構」已經看到天花板，世界面臨幾十年一遇的「計算力範式轉移」。

兩條路擺在眼前：

第一條是「航母路線」：想辦法做出一台更厲害的「單體計算機」，就像一艘航空母艦，這就是「超算」。

第二條是「艦隊路線」：把一堆弱雞計算機串起來，拼出一台大計算機，就像聯合艦隊那樣，這就是「分布式計算」。

「航母路線」，世界主要大國很早就走通了，自上世紀60年代起，中美德日都研發了自己的超算。

可這玩意兒動一動就好多錢，只能緊着國防和科研來用——算衛星、測彈道——根本不是互聯網公司這個層次玩得起的。

沒辦法，互聯網公司被逼上梁山，只能走上生死未卜的「艦隊路線」。

就在這個背景下，計算領域迎來了「奇蹟年」。

2003年、2004年、2006年，谷歌重炮轟出三篇學術論文，從理論上論證了「分布式計算」是完全可行的。

這一瞬間，就如同愛因斯坦發表了相對論，轉身對大家攤攤手：「接下來最先把核彈造出來，就看各位的本事了！」

仿佛發令槍響，全世界互聯網公司的技術人們一起狂奔出去。

只不過，與以往「稍有不同」，這次狂奔的隊伍里，出現了中國人的面孔——在「分布式計算」這個新範式面前，我們第一次和全世界站在同一起跑線上。

從天空俯瞰，情勢緊急：

如果中國程序員沒能奪下「分布式計算」這片海域，那麼包圍圈將重新合攏，故事回到過去；

如果中國程序員能趁天賜良機建造出分布式計算這支「艦隊」，向上可以把控自主軟件的「艦炮」，向下可以翻湧芯片研發的「汪洋大海」，

鎖死的技術鎖鏈一旦被掙脫，幾十年的計算力突圍戰，將會迎來光輝的「斯大林格勒時刻」。

王堅，從某種意義上說，並沒有辦法選擇自己的命運——因為他恰好就是離這片海域最近的人。

彼時他在微軟亞洲研究院常務副院長的位置上，好巧不巧，帶隊研究的一個方向正是「分布式計算系統」。

他有兩個選擇：第一，繼續幫助老東家微軟造出「聯合艦隊」，忠人之事，無可指摘；第二，加入一家中國公司，從頭造出一支「挑着五星紅旗的艦隊」。

2008年，紛紛揚揚的大雪，高樓的落地窗背後，他看到敞開的歷史之門正在緩緩關閉，包圍圈隨時可能再度封死，留給他做決定的時間正在以秒計數。

此時鏡頭拉遠，喧囂人間霎時安靜。人們看到王堅改換旗幟，帶着一眾中國程序員赤膊游向深海。由此，他成為了中國計算歷史上一萬個先輩之後的第一萬零一個勇士。

王堅

「分布式計算系統」，在今天有了更朗朗上口的名字——雲計算。

而王堅帶領的這群人，就是如今的阿里雲眾將。

歷史的轉捩點前，王堅壯懷激烈，為起航的阿里雲計算鐫刻一行使命：為了無法計算的價值。

可嘆彼時，空有凌雲之志，周身尚無爪牙。

粗略來說，「無法計算的價值」要想實現，起碼包含兩個步驟：「造雲」和「上雲」。

造云：

就是把更多的艦船（計算機）連接在一起，穩定高效地運行。可想而知，連接的「船」越多，就越穩固，戰力就越強。（不要受《三國演義》「火燒連船」的影響，那是虛構的故事。）

上云：

就是讓士兵們（大小企業）抓緊時間把「艦炮」（各種業務）從原來的小船搬到這個「聯合艦隊」上，抓緊投入戰鬥。

穩妥的操作肯定是「兩步走」——先造雲、再上雲。

但是，前有狼後有虎，容不得繡花般細緻。事實上，從2009年成立伊始，阿里雲這幫人就兩步並作一步——一邊造船，一邊就想往船上拉客。。。

各大公司一看這架勢，都嚇得往後退：大哥，你的船體還在叮叮噹噹地施工，我哪敢上去啊？

阿里雲的人一想，也確實是這麼個理兒。。。但總得有人做先驅，上雲操練一下啊。。。

苦悶中，他們一回頭，突然瞥見了阿里巴巴集團大大的「淘」和「支」的招牌，一拍大腿：「對啊，別的公司不肯做先驅，就拿我們自己人做先驅唄！」

歷史的那一瞬間，頗有喜感：一邊是「磨刀霍霍向集團」的阿里雲技術宅，一邊是「傻白甜」的阿里巴巴各部門業務同學，還不知道等待自己的將會是怎樣的腥風血雨。。。

2009年，在歷史的猝不及防中，阿里巴巴的「上雲計劃」，就這樣轟然拉開了帷幕。

（二）尋找「小白鼠」

2009年，北京懷柔水庫西岸一家會議中心裡，一堆人圍着五福。

別誤會，這個五福不是過年「集」的「五福」，他是阿里巴巴搜索技術的負責人。

新晉「阿里巴巴首席架構師」王堅坐在五福對面，苦口婆心說服他要把搜索業務挪上阿里雲。周遭一圈，圍滿了年輕的阿里雲工程師，額頭青筋迸出，指節按得嘎巴亂響。

五福當時害怕極了。。。

不過，聽王堅慢慢闡述他的技術構想，五福心裡被猛地點燃了一團火：

團隊本來是搞搜索技術的，但三天兩頭就要鼓搗底層服務器，確實很煩。

趁現在登上阿里雲這個「聯合艦隊」，一來能降低成本，二來兄弟們省下精力，能專心研究搜索技術，一舉兩得，豈不美哉？

一拍即合，搜索作為集團第一個上雲的業務，派出技術精銳，和阿里雲聯合研發。

為了表示感謝，王堅送了搜索團隊每人一個鍵盤。

大家都很開心。

此時恐怕上帝要冷笑一聲——天真的五福本以為手裡的劇本是《倚天屠龍記》，可是故事才進行到第一章，他就發現，自己演的好像是《三毛流浪記》。。。

五福

故事是這樣的：

經過一年代碼海洋里埋頭苦練，2010年，初代阿里雲「閃亮登場」。

五福一看，腦袋嗡一下。。。

阿里雲很多模塊的性能，都比搜索需要的低了不止一個數量級。這也就意味着，本來在雲下只需要一台服務器搞定的事情，上了阿里雲，就需要幾十台服務器。。。

這。。。相當於路邊攤吃一個雞蛋灌餅要5塊，到了大飯店，服務員張口要100——一樣的東西，我憑什麼要來你這「黑店」買啊。。。

五福直接拍了桌子：「老大，說好了能降低成本，現在成本反而提高這麼多，你這不是坑人麼？？」

阿里雲的技術宅們心裡也發虛，安慰五福：「別。。。別急，後面我們慢慢優化，資源消耗估計還是能降下來的。。。」

五福雖然脾氣沖，但也深明大義。冷靜下來想，既然之前答應了王堅博士，要為中國計算力的突圍盡一份力，現在自己撂挑子，於情於理也很難說得過去。

他只好勸說同學們回到崗位，繼續耐心陪阿里雲一起研發。

站在今天，可以負責任地說，2010年的搜索上雲，其實是一場沒有任何勝算的戰役。

核心原因就是：

當時的阿里雲眾將大大大大低估了雲計算這個「分布式操作系統」的研發難度。

從頭寫一個操作系統，對於彼時的中國程序員來說，是「奧數」級別的操作。而當時除了幾個骨幹是王堅「微軟亞研」舊部，大多阿里雲的程序員都只是滿腔熱血的「應屆生」。

代碼越寫，坑越多。好容易走到了坑底，沒想到坑底還有下水道。。。

用後來一位阿里雲同學的話說，他要一早就知道雲計算有這麼這麼難，當時早都辭職不知多少次了。。。

但生意可不等人。2010年，淘寶的發展突飛猛進，「雙11」也逐漸勢起，用戶訪問量暴增。

第一屆「雙11」還沒有大屏幕顯示成交額，大家用數字和表組成「人肉大屏」。

面對「黑雲壓城」的用戶，五福都快「死」了：

用戶搜索的每一個商品關鍵詞，都如重炮般轟擊在搜索系統上。此時，本應趕緊調兵遣將，搶修戰場上的搜索系統；可回頭看，他的主力團隊卻悉數陷在和阿里雲聯合研發「新引擎」的大後方，一灘爛泥完全無法抽身。

情況越發危急，搜索的技術同學輪番拿着一浪高過一浪的訪問數據找到五福，泣血死諫：老闆，趕緊把主力部隊調回前線吧！搜索引擎眼看要超過「警戒水位」，我們擔不起這個責任啊！

連續幾周輾轉反側，五福肩頭的壓力衝破極限。最終，他還是拉着幾個骨幹敲開了王堅辦公室的門。

「博士，快扛不住了，能不能讓我們先撤下阿里雲？」

王堅別無選擇。

一邊是聯合研發無限期停止，一邊是舊搜索引擎採用「保守技術」緊急加固，很快，大火被澆滅，硝煙如霾散去，前幾個月的血戰似未曾發生。

但無論是搜索團隊還是阿里雲的年輕人，心裡都壓着一塊石頭，小心翼翼，不敢回頭。

出師未捷，但中國計算力千載難逢的突圍機會正在一分一秒地流逝。

容不得顧影自憐，王堅和同事們一邊加緊升級技術，一邊馬不停蹄尋找下一位「先驅」。

（三）「登月」

挑來挑去，「大數據計算業務」成了新的「獵物」。

大數據計算業務當時主要支持「淘寶」（用來計算營銷數據）和「阿里金融」（用來計算貸款）。這回阿里雲學乖了，不敢猛地一下把「大數據業務」全搬上雲，先挪半隻小白鼠。。。

淘寶這邊體量大，技術體系複雜，硬骨頭可以往後放放；彼時剛成立的「阿里金融」體量小，沒歷史包袱，怎麼看怎麼可愛。

阿里金融的工程師前幾天還在看搜索團隊的熱鬧，一回頭，就看到阿里雲奔自己來了。。。

他們把刀架在自己脖子上：你們別過來啊！我死給你看！

阿里雲這群瘋子才不管這套，這次就算是死，咱們也要一起死。。。

當然，阿里雲也不是混不講理，他們是提前拿到了「尚方寶劍」的——為了挺王堅團隊，鐵血推動阿里雲發展，馬雲已經讓阿里金融的負責人胡曉明立了軍令狀，一定要把業務綁在阿里雲上開發，死都不能分開。

（這段故事可以參考《阿里雲的這群瘋子》）

胡曉明

只是可憐阿里金融的這幫人，雖然做足了思想準備，還是「低估」了阿里雲的水平。。。與其說當時的阿里雲是操作系統，不如說它就是行走的 Bug。

那段日子，在阿里雲上開發業務，就像在地震帶上蓋房。

阿里金融的工程師開發金融業務反倒成了「副業」，「主業」反而變成了處理各種底層 Bug，到了晚上睡覺前，都恨不得燒柱香，乞求系統不要半夜報警。

有一位奶爸工程師，把自己小孩的哭聲設置成報警鬧鈴，一聽到這個聲音，就「垂死夢中驚坐起」，到電腦前解問題。。。

王堅這幫人口口聲聲說阿里雲是「為了無法計算的價值」，可阿里金融一線同學看到的情景，根本就是「無法計算的損失」——他們見到阿里雲的人，不罵出聲就已經是很禮貌了。。。

事情搞成這樣，阿里雲的年輕人心中那個「計算力突圍」的宏偉夢想，像是一顆寶石被蒙上了千萬層灰塵，壓根都沒臉對別人提起。

兄弟團隊的白眼他們只能當沒看見，咬着牙一個一個解 Bug，一秒一秒，期待把艱難捱過去。

後來，阿里巴巴拍了一個短片，講的就是當時的窘境。

2010年，好容易這邊阿里金融的大數據業務穩定了一點，工程師不用再「起夜」了，大家已經謝天謝地。。。

可是，連氣都沒喘，阿里雲又「恬不知恥」地去找另外半隻小白鼠——淘寶網的大數據業務。

淘寶團隊心裡一萬隻草泥馬：

「大哥啊，你們搗的亂還不夠嗎？原來的大數據系統明明還能用，為啥逼我們上那個破雲？」「這個王堅到底是啥背景？會不會過很快就被撤了？」「都傳阿里雲要解散，難不成就是這幾天的事兒了吧。」

其實傳言並非空穴來風，阿里雲連續兩年拿到集團最低績效分，最初的阿里雲隊伍，已經「折損大半」，能夠「算得清價值利弊的」，早就不是轉崗就是辭職。

有人擔心，找到王堅問：「博士，你說實話，公司明年還做不做雲計算？」

王堅抬眼看他：「我不知道公司明年做不做雲計算，我只知道明年我還會在這裡！」

就這樣，阿里雲的工程師離職一批，他們就重新再找一批；一個工程方向失敗了，就換個方向再來。

這是王堅任阿里巴巴 CTO 之後，內網的「嘲諷帖」。

就在2012年，阿里雲最危險的時刻，「戲劇性轉折」終於出現了：

淘寶大數據業務暴漲，巨量數據如潮水般漫上來，而他們原本依賴的 Hadoop 大數據架構，竟然嘗試了所有方法都無法繼續擴容。環顧四周，目測只有趕快跳到「Bug 無數」的阿里雲上，才有生還機會！

可憐的阿里雲前幾個月還被嫌棄，這幾個月就成了「全村人的希望」，開始被淘寶大數據「奪命連環催」，等着盼着要「上船」。。。

淘寶大數據業務向阿里雲上遷徙的的計劃，被鄭重地命名為「登月計劃」。

第一次被這樣寄予厚望，阿里雲的年輕技術宅們又驚喜又緊張，恨不得長兩個腦袋四隻手，可無奈越急眼前的問題就越難，開發進度不如意。

2013年，眼看距離舊系統資源耗盡的時間只剩一個月，阿里雲仍不具備遷移條件，所有人都快急哭了。

危急時刻，最理解王堅的一位技術大牛，時任阿里巴巴核心系統部負責人章文嵩挺身而出，發出「英雄帖」，緊急徵召淘寶最強的技術大牛開赴阿里雲，使出畢生絕學幫助阿里雲解 Bug。

大力出奇蹟。幾十位中國最強的武林高手，就像一管強心針，直接把阿里雲從「癱瘓在床」搞成「舞池蹦迪」。

就這樣，2013年底，眼看舊系統快要撐不住的那一瞬間，大數據系統完成了驚險的遷移。

「登月」成功，所有人橫七豎八癱了一地——大半年了，總算他喵的能正常喘氣了。。。就在這一刻，他們驀然抬眼，看到阿里雲這一隊「連環戰艦」漂泊在洶湧的海上，遮天蔽日，氣象初成。

奇觀在前，人們終於願意相信王堅，願意直視他背負的那個沉重理想。

（四）血鑄「倚天劍」

自家大數據業務上了雲，阿里雲這群人終於一掃陰霾，不僅有了和兄弟團隊說話的底氣，還敢挑出幌子招攬外部客戶了。

當時，每一個客戶王堅都親自見，見人就把自己的名片留給人家，說有問題直接給我打電話，旁邊的人攔都攔不住。

為了打消客戶顧慮，王堅還拍胸脯，如果因為阿里雲的原因用戶遭受了經濟損失，阿里雲負責「百倍賠償」，這個規則都是寫到合同里的，旁邊的人還是攔不住。。。

可即便如此，95%的企業卻還是將信將疑。

有一次，阿里雲同學去一家銀行聊合作，對方的拷問直擊靈魂：你們的核心業務，淘寶、支付寶上雲了沒有？

阿里雲同學面露羞赧：目前只有大數據這一塊兒上了雲，核心系統嘛，我們有這個計劃。。。

對方直接打斷：那等你們核心系統上雲了再來找我們吧。吃螃蟹的事兒，我們不干。

阿里雲灰頭土臉地回來。搞了半天，光有「大數據系統」一個小白鼠上雲，還是不好使啊。。。

事實證明，客戶的謹慎是對的。

米哈游是最早吃阿里雲「螃蟹」的公司，那時他們還沒開發出《原神》，剛做出來《崩壞學園》。可是就在2014年，《崩壞學園2》最火時候，阿里雲先「崩壞」了：

一次誤操作引發意外重啟，把所有玩家踢下線。。。

米哈游創始團隊

米哈游怒火中燒，拿出王堅的名片，一個電話就打過來！

王堅和主要負責人開車去上海，給米哈游道歉。

在車上，王堅嘆氣：「當我們在地上，看客戶在飛機上的時候會有誤操作，當我們和客戶一起在飛機上的時候，就不會有誤操作了！」

這一切，劉振飛看在眼裡。

作為引薦王堅和馬雲認識的人，作為阿里巴巴新晉合伙人，作為阿里巴巴「去IOE」項目負責人，時任系統保障部負責人劉振飛在阿里內網上發帖，建議加速「集團雲化」——淘寶、支付核心系統要在三年之內跑在阿里雲上！

劉振飛

大家都明白，這是一次公開的「喊話」。

下面的評論立刻炸了鍋。。。

反對者以淘寶人居多。

如果說之前的「大數據系統」還是幾門輕型火炮，那十幾年積澱的淘寶的核心系統就像一組超級複雜的重炮，現在要一股腦砸到阿里雲的船上，你的船不會沉嗎？

答案很簡單：必沉。

其中一個核心的問題就是：「虛擬化損耗」太大。

這裡涉及到一個小知識：

雲計算之所以能做成「聯合艦隊」，是因為它必須先用「魔法」把軍艦的甲板（服務器）綁在一起，再用「魔法」分割成小塊的「虛擬甲板」（虛擬機）分配給各個業務來用。

但這一來一回兩次「施法」，就要額外消耗計算力。行話叫做「虛擬化損耗」。

舉個例子：

原本10台服務器，經過「虛擬化」之後，還沒跑什麼業務，就剩8台服務器的算力了；

裝載業務以後，計算力損失還會更誇張，比如「購物車」這個模塊，甚至可能10台服務器虛擬化之後只剩1台。。。

虛擬化損耗示意圖

淘寶業務體量這麼巨大，每年還要搞「雙11」這樣的大促，本來用到的服務器都是數以十萬計，成本沉重，一旦上雲，所需要的服務器數量還會直接翻幾倍，這。。。

不解決虛擬化損耗問題，核心系統上雲想都不要想。

時任淘寶總裁張建鋒經過慎重思考，決定給剛成為阿里雲 CTO 的章文嵩來一次「考試」：

明年，也就是2015年的「雙11」，核心電商會分出10%的業務，用阿里雲來扛，而到時候的阿里雲，總體虛擬化損耗不能超過10%。

面對張建鋒這麼嚴苛的要求，阿里雲瑟瑟發抖，大伙兒心裡有數，憑現有的技術力量，恐怕妥妥地要考砸。。。

他們急需一個「外援」。

章文嵩給全國的技術大牛撥了一圈電話，神奇的是，大家給他的建議幾乎一致：要挖就挖張獻濤。

張獻濤究竟是何方神聖？他是當時 Intel 中國區的技術大牛，論虛擬化技術，屬於公認的「獨孤求敗」級別。

章文嵩本來擔心外企待遇優厚，張獻濤不願來阿里吃苦受累。沒想到張獻濤早就心懷技術報國的理想，沒有任何推辭，臨危受命。

他就像空降的傘兵，直接被投在敵軍環伺的兇險戰場。

張獻濤

說「兇險」，其實不誇張。

阿里雲從成立以來，採用的就是傳統的「Xen」虛擬化架構，可是，在這個技術架構上修修補補，恐怕「全員戰死」也不可能把虛擬化損耗降到10%以內。

張獻濤跟章文嵩建議：如果信我，就趕快啟動一個全新項目——從頭開發基於新技術「KVM」的虛擬化架構。

章文嵩畢竟要對大局負責，很謹慎：「給你兩個同學，先寫一個驗證版本出來。」

張獻濤花了一個月，把驗證版本寫好，一測試，果然大幅提升性能。章文嵩拍板：「干！」

這就是「倚天劍」項目。

2015年3月，距離雙11還有半年多，新一代虛擬化架構研發完畢。但是，一測試，虛擬化損耗竟然在20%左右。這個結果出乎了很多人意料，阿里雲內部立刻喧譁四起。。。

抉擇的壓力突然轉到章文嵩身上，此刻他面臨兩個選擇：第一，回到大家更熟悉的 Xen 架構，祈禱用剩下的時間把虛擬化損耗能降多少降多少，起碼不會死得那麼難看；第二，繼續攻堅新架構，可這條路一旦走不通，那結局就是「丟人現大眼」，阿里雲這幾年好容易攢起來的技術信譽一夜歸零。。。

章文嵩看向張獻濤。

張獻濤咬牙：回到 Xen 一定死，堅持新架構還有贏的可能，懇請各位再和我衝鋒一次！

第二天，張獻濤和團隊列出了幾百項優化計劃，然後像機關槍一樣挨個狂掃，在代碼的戰場殺得昏天黑地。

那時候早晨上班，經常能看到盯了一夜指標睡在工位上的同學。

人門還記得，在5月的一次技術評審會上，屏幕上的虛擬化損耗率經過幾秒波動，竟然穩定在了5%的水平，比張建鋒的要求高出一倍。

下一秒，人們爆發出近乎尖叫的歡呼，「倚天劍」成了！「倚天劍」成了！

然而，九九八十一難，還差一難。。。

就在「雙11」之前兩周，所有測試都沒問題，唯獨支付系統的一個子應用，虛擬化損耗硬是停留在30%。直覺上這個問題並不難解決，可是一群人圍着好幾天，愣是找不到原因。大家開始慌了，眼看逆襲就要成功，可千萬別陰溝翻船啊。。。

就在這時，一位運維同學指着屏幕弱弱地問了一句：這個數據庫應該配到深圳機房吧？怎麼連到了杭州？

花了三秒鐘，改了一個數字，一切恢復正常。

所有人捶胸頓足，一邊恨自己雲上經驗不足，一邊又感謝上蒼讓自己「逃出生天」。

終於等到「雙11」，大考降臨。10%的流量如約切到已經被測試了上百次的阿里雲上。阿里雲同學們憋了一肚子的火焰，此刻火力全開。

那一整天，阿里雲系統嘯叫着跑完全程，直到次日零點，任務結束，故障數量為「0」，連抖都沒抖一毫。

秋夜如水，有人把臉埋在手掌中。說不清為什麼，他們就是想用一次完美的戰役蕩滌心裡的委屈。

「雙11」剛過，阿里雲團隊突然收到了淘寶團隊發來的一封感謝信。

張獻濤抱着電腦把這封信讀了又讀。他當然知道，這封信不僅僅是表揚那麼簡單，這是阿里巴巴最核心的業務對阿里雲夢想的一次擁抱。

這種擁抱恆久而堅定，像烈酒，又像良藥，讓身上的每一道傷疤都不疼了。

（五）春天裡的「暫停鍵」

「如果有一天，我老無所依，請把我埋在，這春天裡。」

2016年，恐怕就是阿里雲眾將魂牽夢繞的那個「春天」。

那一年，新任總裁胡曉明攤開地圖，駕長車破陣，帶領阿里雲在廣袤的土地上攻城略地。仿佛九月的塞倫蓋蒂草原，無數中大型企業開始了向雲上狂奔遷徙的史詩進程。

而在集團內部，阿里雲又進行了一場「基操勿六」的華麗表演，用3%的極限虛擬化損耗扛下了「雙11」60%的流量，他們信心滿懷，兵臨城下，劍指整個集團，「全面上雲」箭在弦上。

然而，彼時已經成為集團 CTO 的張建鋒卻嗅到了一絲「山雨欲來」的氣息。

當時，阿里巴巴集團的核心技術已歸於四大中台：

在線業務、大數據計算業務、搜索業務、數據庫業務。

可是，掰着手指頭數數這四大中台，「大數據計算」付出慘烈代價已經被阿里雲支撐；「在線業務」只有雙11這一天才用到阿里雲；反觀「搜索」，自從2010年被「深深傷害」之後，五福就一直保持觀望，目前仍然不具備上雲條件；而「數據庫」對底層技術的要求更是變態，阿里雲目前的水平也無法承載。

簡單來說，雲計算的基礎技術分為三方面：「計算」、「存儲」、「網絡」。

要想扛住四大中台，阿里雲這三個基礎技術必須全部登峰造極。可現實是：當時的阿里雲，在這三方面都不夠極致。

全集團上雲的過程，被張建鋒冷靜地按下了暫停鍵。

在2016年「雙11」復盤會上，張建鋒提出了一個「不近人情」的要求：

阿里雲的虛擬化損耗，能不能降到0？

張獻濤一口老血噴出來，大哥你這玩意兒不科學呀。。。

但張建鋒一臉認真，他沒有想開玩笑：「只有把虛擬化降到「0」，阿里雲才會具備和物理機持平、甚至更好的性能，這樣，阿里巴巴集團的所有業務才願意「全面上雲」！只有阿里巴巴全面上雲，千行百業的各種計算任務才有機會完全上雲！」

張建鋒

亂世須用重典，奇效需要猛藥。其實，領到這個「不可能的任務」那一刻，張獻濤心裡已經有數了。

他的計劃就是：必須造出一顆宇宙中從未存在過的芯片，擔負起所有的虛擬化職責。

也正是從這一刻起，阿里雲的使命第一次從打造「操作系統」這個艦體，下潛到了「芯片」這片汪洋深海中。

回首看，之前「從戰艦到海洋」的設想，正在緩慢成真。

浩大的芯片戰役，召喚最兇猛的戰士。

那一年，張獻濤大開殺戒，連續招攬了各路芯片大牛，負責核心芯片設計的漸名前一天剛剛入職，後一天就帶着行軍床進駐了辦公室，沒日沒夜用兩個月得時間把芯片設計完成。

而負責芯片板卡設計的芳志回憶：「好歹我在這個行業里也摸爬滾打十五年了，這是我見過最複雜的板卡，沒有之一。當時哪怕只有一根線路設計出現錯誤，都會導致板卡點不亮。」

一個寒暑過去，2017年10月12日，阿里雲副總裁，集團上雲總指揮李津在雲棲大會上毫無預警突然宣布：阿里雲已經用一顆神秘的芯片把虛擬化損耗降到了「0」。

李津

消息之炸裂，以至於很多人第一反應是：這是個假新聞。。。

當然，所有人的努力都是無比真實的，這顆芯片就是後來被業界競相效仿的 DPU，而裝載了 DPU 的服務器，就是名聲大噪的「神龍雲服務器」。

神龍核心芯片板卡（MOC卡）

剛才說過，雲計算的基礎技術分為三方面：「計算」、「存儲」、「網絡」。

2017年出發的敢死隊中，張獻濤「零虛擬化損耗」的「神龍」只代表了「計算方面軍」；而在「網絡方面軍」，江鶴帶領大家研發出了搭載自研芯片的大型交換設備「洛神雲網關」，把可以同時連接的虛擬機數量推上了「100萬」大關；在「存儲方面軍」，Jason 帶着存儲團隊開發了「盤古存儲2.0」，把百億級別的讀寫操作從毫秒時代推進到微秒時代。

洛神雲網關

有了這些「重器」墊底，張建鋒才終於「鬆口」，放阿里雲過了自己的「技術關」。

現在回望，2017年阿里巴巴成立前沿科技研究部門「達摩院」，2018年組建芯片公司「平頭哥」，其實背後的精神都可以匯入那同一道奔涌的大河：中國的計算力突圍。

而阿里巴巴的全面上雲，正是這場漫長突圍戰的關鍵一役。

2018年，在那個無數人懷戀的「春天裡」，已被擱置太久的「全面上雲」的戰役終於打響。

（六）「巨炮」挪移

張建鋒宣布：從這一年開始，集團所有部門（除了阿里雲），將不允許購買任何服務器，要用計算力，就必須上阿里雲。有趣的是，與此呼應，阿里雲也把對外部客戶的核心口號改成「上雲就上阿里雲」。

當時業內流傳一句詩：洛陽親友如相問，上雲就上阿里雲。洗腦程度，可見一斑。。。

終於到了「核心系統」搬家的那一刻，之前死命推動這件事的阿里雲總裁胡曉明不知為何，突然有點心虛。想了半天，他明白了問題所在：電商那邊「拆」系統肯定成功，他擔心的是雲這邊萬一「裝」不好，可怎麼辦？

胡曉明的決定是：要從電商部門「挖」來一個對核心系統熟悉到「倒背如流」，做夢都能把代碼背出來的大神。

這樣的大神還真有。。。電商有一個低調神秘的「中間件」團隊，日常的工作職責恰恰是開發一些精巧組件，粘合電商所有子系統之間錯綜複雜的運作。

「中間件」的負責人小邪，就在這樣的背景下，一臉懵逼地被揪到了阿里雲，扣上帥帽，統領阿里雲的所有技術產品。

似乎胡曉明也並不關心，2014年劉振飛的帖子下面，小邪的意見是明顯的「對集團上雲持保留態度」。。。。

小邪當年的帖子原話，我謄抄了下來。

「我是個聽話的人，反正領導讓我做什麼，我就做好！」

回憶當年，小邪說得很誠懇。

事實也證明，聽話的小邪對崗位無比忠誠——了解了雲的夢想和戰略，立刻調轉槍頭，成了鼓搗核心系統上雲的「急先鋒」。

小邪

就這樣，從天空俯瞰，「電商核心系統」這門重炮，被從原來的軍艦上拔起來，緩慢地往阿里雲上吊裝。

阿里雲的這群人驚呆了，他們第一次親眼看到到這門重炮的細節結構有多複雜——管線穿梭，環環相扣，精密非凡，巍峨壯麗。

這一瞬間，他們才真正明白「定海神針」張建鋒當年的良苦用心。若不是張建鋒逼着阿里雲搞出了「零損耗」的神龍，這門炮強行放在原本的阿里雲船體上，將是災難般的存在。

這邊核心電商系統剛剛遷移完成，放眼阿里雲這支艦隊，四周已經圍滿了小船：

各個系統的「上雲」工作像春天的花一樣四處開放。

數據庫也打響了上雲的第一槍。

陳錦賦，就是當時數據庫遷移的主力技術人。

陳錦賦

數據庫上雲有多難呢？

還拿戰艦舉例子。

數據庫的「艦炮」形狀是很特殊的，只能放在特殊的戰艦上。過去，這個戰艦都是數據庫團隊用物理機自己搭建的特殊型號。

現在要搬上雲，雲的戰艦是統一的標準品，原來的艦炮就裝不上去。

這個過程中，就必須用雲上提供的標準原材料重新造出一個艦炮，也就是說，四捨五入要重做一個數據庫。

而且，之前說到，數據庫對計算性能的要求極其變態。

有些雲的性能達不到原來服務器的標準，就只能自研很多黑科技，例如「I/O 合併」、「自研文件系統」等等。

況且，數據庫還不只有一種。為了適合不同業務場景，陳錦賦他們搞出了雲原生數據庫PolarDB、雲原生數據倉庫AnalyticDB、雲數據庫 RDS、雲原生內存數據庫Tair等等很多種類。

作為艦炮設計師，陳錦賦他們足足花了幾年的時間才完成這些複雜系統的設計和交付。

就這樣，數據庫這門巨炮，也慢慢被這幫人搬上了雲的「艦隊」。

雖然你我並沒感覺，但從這一刻開始，自2003年以來下單買過的每一件商品記錄，都已被騰挪寫入了阿里雲。

那段日子，阿里雲上不僅迎來了電商核心、數據庫等等重磅系統，還迎來了一個重磅的人，他就是張建鋒本人。

為阿里雲的夢想金剛怒目保駕護航了十年後，他終究成為了新一代阿里雲的掌門人。

而另一位為同樣阿里技術貢獻了十幾年的技術人魯肅接過 CTO 的沉重火把，繼續帶隊前行。

魯肅

2019年，就在「集團上雲」如火如荼的時候，張建鋒和魯肅幾乎同時發現了一個大問題，那就是：

大家上雲的「姿勢」很可能不對！

（七）「可以計算」的價值

阿里巴巴內部有很多系統，它們都誕生「上雲」之前。

這意味着一個重要的事實：這些系統原本就不是為雲而設計的。

硬要搬到雲上，雖然也不是不行，但有兩個繞不開的問題：

一來、這樣做最好的效果也就是雲上和雲下達到同樣的性能，跑在雲上絕不會比跑在雲下更好。

二來、雲本身的優勢，例如大規模調度能力，這些老系統反而享受得不充分。

舉個生活中的例子你就明白了：

這就像把實體算盤搬進了電腦里，做成了一個「虛擬算盤」，結果你的使用方法就從「手動撥算盤」變成了「用鼠標撥算盤」。這就很雞肋了，因為你想要的是把數字更快地算出來。

你不需要「虛擬算盤」，你需要「計算器」！

所以，與其費盡心思「搬家」，為啥不把原來的系統直接廢棄，在雲上用「第一性原理」重構一套系統呢？

這個思路，就叫做「雲原生」。

雲原生的技術路線很多，現在最主流的路線是：容器化。

啥是容器化？

簡單來說，就是把過去巨大的程序拆成小模塊，然後把小模塊放進類似「玻璃瓶」的容器里，容器和容器之間通過「接口」相互連接、調用——完成和過去巨型程序同樣的功能。

你可能直覺上覺得：把大程序拆小，不是更難管理了嗎？

其實不然。

在容器界，有一個叫做 K8S 的開源神器，專門負責海量程序調度，由於容器很小很輕，恰恰可以需要的時候，一秒鐘就建立好，不需要的時候，一秒鐘就關掉。

如果說原來的程序是「巨炮」，經過容器化重構的程序就變成了「機槍」，隨時可以騰挪，萬彈齊發如螞蟻吞象——反而靈活了許多。

而且，容器化帶來了兩個明顯的好處：

其一，是標準。

之前在雲下，各個業務都會自己設計「槍炮」，用料獨特，手法個性。就像大廚一樣，換個調料味道都不對。而現在上雲，必須調用雲上提供的組件來組裝自己的武器，就像麥當勞，全國各地吃到的都是同樣的味道。

其二，是靈活。

剛才我們講過，一個虛擬機里只能跑一種程序，要麼是「數據庫」，要麼是「大數據系統」，要麼是「在線電商」；現在，各種程序都被「大卸八塊」塞在容器里，一個虛擬機里可以跑幾十上百個容器，至於容器里放的是「胳膊」還是「腿」，放的是「數據庫」還是「大數據系統」，根本沒區別！

這種特性，就使得一台虛擬機里可以對各種程序進行「混部」。

舉個例子：白天，阿里雲上可以主要跑「電商」，到了晚上，買東西的人少了，同樣的計算力就可以主要跑「大數據」。

這麼一來，本來需要開兩個「單間」分別跑的任務，現在可以通過容器技術搞「合租」塞進一個房間裡，直接節省50%的成本。

不過，容器技術也不是千般好：畢竟是把「單間」改成「合租」，一個屋檐之下，程序之間難免抬槓拌嘴，爭搶資源。

越是把容器塞得密集，越是會出現這種情況。

這時，K8S 的核心模塊「容器調度器」身上的壓力陡然變大——一旦調度得不好，讓程序打起架來，效率不升反降，得不償失。。。

懿川，就是被挖來專門解決這問題的大牛。

懿川是花名，如果提到他的真名，那是「雲原生界」人盡皆知的大牛。但他特別囑咐我，別多說他的過去，他不想要光環，只想在阿里做成一點事情。

調度器的難題，其實是業內老大難的問題，說到底，是因為系統里原本存在好多調度器。

調度「大數據計算」的是一個調度器，調度「在線計算」的又是一個調度器，這兩個調度器各自調度，就像一個公司有兩個總經理，肯定會打架。

於是，只好再在他們中間放一個「仲裁器」，他倆發生爭執，就去「仲裁一下」。

可是。。。每次發生爭執，都要打一場「官司」，這事情就耽誤了呀。。。

解決方案其實很明確：開發出一個能夠調度所有類型「統一調度器」！

「統一調度器」說起來容易，但之前不乏技術大牛挑戰過，都沒能成功。就連谷歌也沒有實現基於 k8s 的統一調度並大規模應用。

但懿川不一樣，面孔年輕但頂着一頭白髮的他已經把容器技術玩到「純熟」了，這次來阿里，就是奔着獨孤求敗來的。

2020年，還在試用期的懿川面不改色跟大家立下軍令狀：三個月，我要做出「統一調度器」，如果做不出來，正好，也不用轉正了，我走人！

他這個「自殺式軍令狀」，反而炸出一群大神。

來自「大數據」、「搜索」、「數據庫」、「電商」里的各路容器大牛，拍拍他的肩膀，決定跟他一起「獨孤求敗」——組成聯合研發小組，開始瘋魔一樣研發調度器。

就這樣，當年8月，統一調度器如約發布。

同事們驚為天人。

「獨孤求敗」的大神中，就有林偉一個。

他是阿里雲「大數據+AI 工程化」領域的技術大牛。

2008年，林偉也在微軟亞洲研究院，那時他就有機會來阿里雲，但他卻拒絕了邀請，選擇去微軟美國前線工作了幾年。

美國的前線戰鬥，讓他在軟件工程化能力上爐火純青。2015年，覺得時機成熟，林偉鄭重接受了再次發來的邀請，加盟阿里雲。

他加盟的時間點，恰是「登月計劃」之後不久。

在「登月」的時代，今天常見的雲原生工具還不健全，阿里雲建設了自己的一套雲原生系統核心雛形。

林偉面臨的難題，就是如何讓「自有雲原生體系」和「開源雲原生體系」協同進化。

這時候，他的工程化絕活就派上了用場。當時，他使出畢生絕學，對大數據系統進行了一次巨大重構，才使得這個系統平滑運轉至今。

林偉

林偉和懿川合作那幾個月，簡直是高手過招，只見刀光，不見人影。

2020年，林偉帶隊不僅把大數據計算平台 MaxCompute 搬進了容器，還把計算平台「三劍客」的另外兩個——人工智能計算平台 PAI 和大數據治理平台 DataWorks——統統適配了容器。

至此，數據平台完成了雲原生化。

四大中台里，在線業務、數據庫、大數據三大中台均已上雲。

雲原生和容器技術給雲上的產品帶來了「標準化」，而標準化意味着「平等」。

阿里雲上的這些「機槍大炮」，不僅給阿里巴巴用，同樣可以提供給雲上的「非阿里」客戶使用。至此，阿里巴巴集團成為了阿里雲的「標準」客戶，阿里雲並不會對「阿里巴巴集團」有偏袒的支持，而是和「其他客戶」一視同仁。

遙想2014年，阿里雲說要和客戶「坐同一架飛機」。此時，幾番寒暑過去，這群人終於可以驕傲地說：我們自己上飛機了！

然而，此時此刻，追光之外的孤島上，還站着一個人，他背負着無人能解的遺憾默默前行了十年。

他就是五福。

（八）孤島回歸

2018年底，張獻濤、Jason 帶着一群人坐在五福對面。

五福恍然想起2009年的那個下午。只不過，對面的人不再是王堅。

九年過去了，世界變了許多。唯一沒變的是搜索的「逆天」難度。

講2009年的故事時，我們只提到搜索對底層資源要求高，但沒具體解釋，這裡不妨科普兩句：

搜索的靈魂是「快」。

如果你在淘寶搜索框查了一個「連衣裙」，搜索引擎現場是沒功夫翻遍所有商品詳情的。他們必須在平時就做好一個「索引」，把帶有「連衣裙」的書提前整理在一起。

這個過程叫離線搜索，對「存儲性能」有很高的要求。

但別忘了，淘寶上每分每秒都有新的商品上架，索引庫做不到實時更新。所以你搜「連衣裙」的時候，搜索引擎其實還要再在「新上架」的商品里翻一遍，用豹的速度幫你把「連衣裙」找出來補到搜索結果里。

這個過程叫「在線搜索」，可想而知，這會對「計算性能」和「網絡性能」產生超高的壓力。

一邊是：自從2010年「下雲」之後，搜索一直在沿用當時的「保守方案」，此時舊的技術路線已經接近天花板——這台「大炮」的很多組件都年久失修了。

另一邊是：阿里巴巴的商品數量已增加到將近10億，每一個商品，都是搜索引擎肩上的「一根稻草」。

搜索作為最後一個「孤島」，上雲迫在眉睫。

就是這個搜索框，背後有無數技術大坑。

但五福還是「留了個心眼」。

他讓技術大牛喜得去給阿里雲做一個「體檢」——只有通過各種嚴苛的性能測試，才能開始遷移。

幾天後的會上，喜得表情凝重：按照最嚴苛的標準，阿里雲的計算、網絡、存儲性能都還不夠完美。

但與2009年不同的是，這次阿里雲離及格線非常非常近。

五福內心非常糾結：如果強上，未必不成功。但萬一上雲之後頂不住，又要第二次撤下來，那。。。。

討論再三，五福決定：搜索暫時不上雲！但只要阿里雲的性能達標，第二天搜索就可以啟動上雲。

說實話，這個決定還是出乎了阿里雲的意料——畢竟全集團都上了雲，為什麼搜索就是死活上不去？

阿里雲的計算、存儲、網絡幾大團隊受了不小的「刺激」。

2019年初，他們決定組成「攻堅小組」，就在搜索團隊的樓下辦公，你搜索要什麼性能，我就研發什麼性能，發誓要用一年時間把搜索搬上雲！

存儲團隊負責人Jason（左）和網絡團隊負責人祝江鶴（右）

深入搜索內部，阿里雲才發現，原來搜索團隊真的不是「矯情」，而是搜索對計算力的用法就是和別的業務有巨大區別。

現在給搜索準備的阿里雲，就像是給西餐大廚準備了四川辣子，怎麼用都不順手。。。

沒關係，你有多大的腳，我就有多大的鞋——當時正在研發最終階段的神龍二代服務器，專門添加了適合搜索場景的特性；洛神雲網關也從上一代芯片 XGW 進化到了新一代芯片 HGW，極限轉發性能提升十倍；盤古2.0專門針對搜索對「速度」的要求研發了「超高速 POV 鏈路」。

2019年底，一個超大的會議室，所有大咖齊聚一堂。

這邊是搜索計算平台總負責人周靖人、搜索負責人五福、還有一眾技術骨幹；那邊是阿里雲神龍服務器、彈性計算、盤古存儲、洛神網絡，技術的骨幹悉數到齊。

阿里雲拍着胸脯，向搜索正式發出「上雲邀請函」。

周靖人回憶：「雖然當時還沒有一個完善的上雲方案，但看到阿里雲幾乎所有負責人都來了，給了我非常大的信心。」

當時，搜索團隊就決定，2020年雙11，搜索要全面上雲。

這一年，雖然疫情來襲，整個世界都為之冰凍，但是技術的火焰卻越燒越旺，相比2009年，阿里雲的網絡吞吐性能從5萬 PPS 做到了2500萬PPS，磁盤存儲I/O性能從500次每秒變成了100萬次每秒。

在這樣的變態性能加持下，搜索引擎一鼓作氣順利完成「雲上重構」。

昔日一別，苦等12年，阿里雲的技術發展終於追上了搜索的需要。這個孤島終於回歸雲的懷抱。

只是搜索團隊，恐怕已沒人用王堅12年前曾經送給他們的鍵盤敲代碼了。

2021年1月，小邪提議，為搜索上雲舉辦了慶祝儀式。

那一天，阿里雲總裁張建鋒來了，阿里巴巴 CTO 魯肅來了，五福來了。

王堅也來了。

五福不再是那個嫩小伙，王堅的兩鬢也長了白頭髮。

五福對王堅說：博士，12年了，我在你面前沒有遺憾了。

王堅

（九）無法計算的價值

王堅曾經說，有些問題十年才能求出解。

他說少了。上雲這個問題，求解了十多年。

2021年「雙11」，被魯肅稱為集團100%上雲，也就是阿里巴巴的大大小小的業務，已經完全跑在了阿里雲上。

阿里巴巴集團完成全面上雲的壯舉。而這件事，其他國際雲計算的領導者，亞馬遜、谷歌、微軟，都尚未對外宣布完成。

在魯肅看來，數字是最誠實的情報官，每一行代碼的價值都可以被測算。依靠資源共享和混部，CPU資源利用率提升了30%，而所有業務基於雲原生統一開發，開發效能也提升了20%。

2021年底，世界最權威的技術評測機構 Gartner 發布了最新一年的雲計算評測報告《Gartner Solution Scorecard 2021》，通過嚴格實驗為國際主流雲廠商的「計算」「存儲」「網絡」「安全」「韌性」「運營與治理」等9項水平打分，阿里雲橫掃「計算」、「存儲」、「網絡」、「安全」4個第一。在核心技術指標上完全超越亞馬遜 AWS、微軟 Azure 這些頂尖玩家。