技術(shù)解讀阿里去IOE后的系統(tǒng)架構(gòu)

從Hadoop到自主研發(fā)，技術(shù)解讀阿里去IOE后的系統(tǒng)架構(gòu)瀏覽次數(shù)：437次

CSDN

2014年11月02日

字號:

大

中

小分享到：QQ空間新浪微博騰訊微博人人網(wǎng)豆瓣網(wǎng)開心網(wǎng)更多0【導(dǎo)讀】互聯(lián)網(wǎng)的普及，智能終端的增加，大數(shù)據(jù)時代悄然而至。在這個數(shù)據(jù)為王的時代，數(shù)十倍、數(shù)百倍的數(shù)據(jù)給各個機(jī)構(gòu)帶來了無盡的機(jī)遇；然而，無可否認(rèn)的是，數(shù)據(jù)體積的暴增同樣前所未有的挑戰(zhàn)著企業(yè)的根底設(shè)施。在這個大背景下，各個機(jī)構(gòu)不得不在控制好本錢支出的同時，不停摸索著時刻激增用戶數(shù)據(jù)的解決之道，其中阿里的成績無疑令人艷羨——單集群規(guī)模5000+的飛天，以及多集群跨機(jī)房計算的支持。本次我們將以飛天為例，為大家分享大規(guī)模分布式系統(tǒng)打造過程中的艱難坎坷及應(yīng)對之道。本次分享共分為視點、技術(shù)專題、應(yīng)用實踐三大板塊：“視點”從人物著手細(xì)分阿里當(dāng)時所面臨的形勢及各個據(jù)測制定的依據(jù)；“技術(shù)專題”主要從實踐出發(fā)剖析飛天5000節(jié)點擴(kuò)展時所遭遇的艱難險阻及應(yīng)對之道，涉及架構(gòu)調(diào)整、性能優(yōu)化、系統(tǒng)運維等多個領(lǐng)域；“應(yīng)用實踐”那么更注重于云實踐經(jīng)驗及用例分享。目錄視點阿里云觀察2014阿里技術(shù)保障部：阿里云的幕后英雄不期而遇的飛天之路技術(shù)專題探索5K巔峰，云梯架設(shè)的飛天之夢。在3個月deadline的情況下，阿里卻選擇投入更多人力物力及時間的云梯1〔以Hadoop為底層的集群〕和云梯2〔以飛天為底層的集群〕并行擴(kuò)容，阿里人選擇背水一戰(zhàn)的原因究竟是什么？在這個過程中，他們又會遭遇哪些挑戰(zhàn)？目標(biāo)實現(xiàn)后的驚喜又是什么？優(yōu)化無極限：盤古Master優(yōu)化實踐。盤古，飛天的分布式文件系統(tǒng)，在內(nèi)部架構(gòu)上盤古采用Master/ChunkServer結(jié)構(gòu)，Master管理元數(shù)據(jù)，ChunkServer負(fù)責(zé)實際數(shù)據(jù)讀寫，通過Client對外提供類POSIX的專有API。在集群擴(kuò)展到5K規(guī)模后，相關(guān)問題紛至沓來，主要可分為兩個局部：首先，盤古MasterIOPS問題；其次，盤古Master冷啟動速度。那么究竟是什么造成了這些問題？阿里工程師又該如何應(yīng)對？走近伏羲，談5000節(jié)點集群調(diào)度與性能優(yōu)化。伏羲，飛天平臺的分布式調(diào)度系統(tǒng)。在5K攻堅中，從設(shè)計到實現(xiàn)每一步都可能存在性能“陷阱”，原因主要在三個方面：規(guī)模放大效應(yīng)；木桶效應(yīng)；長路徑模塊依賴。5000節(jié)點后這些方面究竟存在什么樣的問題？阿里人又通過了什么方法保證了效勞的性能與穩(wěn)定性？走近華佗，解析自動化故障處理系統(tǒng)背后的秘密。5K后的運維模式究竟會產(chǎn)生什么樣的變化？阿里人究竟為什么會開發(fā)華佗？上通飛天系統(tǒng)，下達(dá)運維各種系統(tǒng)，華佗健壯、簡單和開放的架構(gòu)究竟表現(xiàn)在什么方面？系統(tǒng)又是如何實現(xiàn)了自動化的運維？ODPS技術(shù)架構(gòu)及應(yīng)用實踐。ODPS采用抽象的作業(yè)處理框架將不同場景的各種計算任務(wù)統(tǒng)一在同一個平臺之上，共享平安、存儲、數(shù)據(jù)管理和資源調(diào)度，為來自不同用戶需求的各種數(shù)據(jù)處理任務(wù)提供統(tǒng)一的編程接口和界面。那么，在DT時代，不斷擴(kuò)大的數(shù)據(jù)規(guī)模又會給ODPS帶來什么樣的挑戰(zhàn)？網(wǎng)站日志分析又該如何進(jìn)行？ODPS跨集群遷移與數(shù)據(jù)同步經(jīng)驗分享。阿里各業(yè)務(wù)部門如淘寶、天貓、一淘、B2B等每天都會產(chǎn)生大量的數(shù)據(jù)，日均增量數(shù)百TB。2013年初，阿里內(nèi)部的生產(chǎn)集群PA所在機(jī)房的存儲量最多可擴(kuò)容到數(shù)十PB，而當(dāng)時已使用75%的存儲量。存儲容量告急，迫切需要將生產(chǎn)集群PA上的大量數(shù)據(jù)遷移到其他集群。那么阿里人該如何平安地跨集群遷移幾十PB的數(shù)據(jù)和其上相關(guān)業(yè)務(wù)？數(shù)據(jù)遷移之后，兩個集群間存在大量的數(shù)據(jù)依賴，需要互相訪問最新的數(shù)據(jù)，如何平安快速地實現(xiàn)跨集群數(shù)據(jù)同步？飛天5K實戰(zhàn)經(jīng)驗：大規(guī)模分布式系統(tǒng)運維實踐。但短時間大規(guī)?？焖倥蛎浀默F(xiàn)狀，給運維帶來了巨大挑戰(zhàn)，其中云梯2單集群規(guī)模更是從1500臺升級到5000臺。為此，運維需要做多個方向的調(diào)整，比方：提升全局掌控能力、實現(xiàn)系統(tǒng)的自我保護(hù)和自動化修復(fù)、大規(guī)模與精細(xì)化的平衡。那么，阿里又是通過什么途徑完成這些工作的？應(yīng)用實踐數(shù)據(jù)生意背后的云計算登月1號：支付寶演繹空中升級絕技御膳房：構(gòu)建大數(shù)據(jù)的美食廚房節(jié)選《不期而遇的飛天之路》——去IOE，飛天勢在必行翻開歷史，淘寶曾啟用全亞洲最大的OracleRAC集群，阿里更是購置過3年無限制的許可，阿里在IBM小型機(jī)以及EMCSAN存儲上的投入也曾成為媒體爭相報道的事件。但隨著互聯(lián)網(wǎng)爆發(fā)式開展，淘寶、支付寶和阿里巴巴B2B的注冊用戶數(shù)激增，阿里只能不停地通過水平和垂直擴(kuò)展架構(gòu)來應(yīng)對新增用戶生成的海量數(shù)據(jù)。而這種集中式數(shù)據(jù)庫的架構(gòu)，使得數(shù)據(jù)庫成為了整個系統(tǒng)的瓶頸，越來越不適應(yīng)海量數(shù)據(jù)對計算能力的巨大需求，更不用說越來越難以承受的高昂投入。阿里的“去IOE”已經(jīng)勢在必行：通過自主研發(fā)的分布式系統(tǒng)取代集中式數(shù)據(jù)庫架構(gòu)，使用MySQL+HBase取代Oracle，商用機(jī)取代小型機(jī)+SAN。選擇自主研發(fā)，這也是阿里云在步入云計算之路上做出的最重要的抉擇：堅持追求擁有自有的最有競爭力的核心技術(shù)。在唐洪看來，云計算是一門高技術(shù)門檻的生意，具備核心技術(shù)競爭力等于具備了在戰(zhàn)場上可以正面抗衡競爭對手的實力，盡管這個技術(shù)攻關(guān)的歷程非常之艱難。選擇自主研發(fā)而非采用開源Hadoop優(yōu)化，也是基于一定的考慮，盡管Hadoop在離線大數(shù)據(jù)處理上具備優(yōu)勢，但無法完全提供阿里云要求的大規(guī)模分布式計算與處理的能力，而目前基于飛天上線的云效勞，已遠(yuǎn)遠(yuǎn)超出Hadoop的能力。開源可以說是一條先易后難的路，盡管一開始可以走一些捷徑，但事后在版本升級、研發(fā)上都會受頗多限制；從核心知識產(chǎn)權(quán)角度來看，今天無論是微軟、Amazon或者Google的云計算平臺，都沒有采用Hadoop且不開放代碼開源，本質(zhì)上都是在追求自有的核心競爭力。開源軟件無法徹底成為一個云計算底層平臺的根底，采用開源軟件并非解決做分布式系統(tǒng)這個問題的一劑良方。開展自有技術(shù)，堅持底層自主研發(fā)，如今能夠構(gòu)建超級計算機(jī)的飛天已成為阿里擁抱云計算，以及對外提供云計算效勞的堅實根底。結(jié)語已經(jīng)實現(xiàn)5000節(jié)點單集群的飛天5K擁有驚人的規(guī)模：10萬核的計算能力；100PB存儲空間；可處理15萬并發(fā)任務(wù)數(shù)；可承載億級別文件數(shù)目；100TB排序30分鐘完成，遠(yuǎn)超今年7月1日Yahoo!在SortBenchmark排序測試DaytonaGraySort所創(chuàng)造的世界紀(jì)錄——100TB排序完成時間約71分鐘。優(yōu)秀的產(chǎn)品背后，必定有優(yōu)秀的根底設(shè)施支撐。在此，我們期望越來越多的團(tuán)隊打造出更加穩(wěn)定、更具性能的底層平臺，不管是自主研發(fā)，亦或是基于開源。阿里云觀察2014發(fā)表于2014-10-1013:28|

11899次閱讀|來源《程序員》|

38

條評論|作者劉江《程序員》雜志2014年10月刊阿里云《凌云》云計算摘要：Amazon云計算對整個新興產(chǎn)業(yè)的開展無疑舉足輕重，而國內(nèi)，阿里云的成敗也有類似的分量。2013~2014年，阿里云幾乎一直主導(dǎo)著云計算方面的業(yè)界話題。2011年和2012年，我先后兩次對話阿里云的負(fù)責(zé)人王堅博士，并在《凌云》雜志發(fā)表了《追尋凌云夢》和《阿里云觀察》兩篇文章，記錄了阿里云和王堅本人不同開展階段的酸甜苦辣。在后一篇文章的結(jié)尾，我這樣寫道：“全球范圍內(nèi)，Amazon云計算對整個新興產(chǎn)業(yè)的開展無疑舉足輕重。對于中國來說，阿里云的成敗也有類似的分量。”我沒有想到的是，此后一年多，國內(nèi)外云計算的形勢很快就發(fā)生了較大變化。最引人矚目的故事，是Amazon在2013年3月獲得美國中情局6億美元的大單，強(qiáng)力攻入企業(yè)級市場的核心地帶——政府。更有戲劇性的是，IBM為此不惜把中情局告上法庭，仍然未能挽回局面。而在總體格局上，微軟和Google先后放棄只做PaaS的戰(zhàn)略，開始在IaaS市場發(fā)力，引發(fā)一系列連鎖反響。2012年6月6日，微軟首次公開自己的IaaS效勞的時候，還用混合云的名義來遮掩。而同月Google在I/O大會上發(fā)布IaaS平臺GCE〔GoogleComputeEngine〕那么高調(diào)多了，劍鋒毫不客氣地直指AWS。等兩家IaaS正式上線開放效勞，已經(jīng)到了差不多一年后2013年的4月和5月。總體上，它們比Amazon要晚了5年以上。以至于去年8月Gartner的數(shù)據(jù)估計，AWS的計算容量是后面14家競爭對手總和的5倍。但是，兩大巨頭畢竟實力雄厚〔技術(shù)實力毋庸置疑，又握有數(shù)以百億計美元的現(xiàn)金〕，只要公司頂層下了決心〔解決了我所說的“一把手工程”問題〕，無論產(chǎn)品還是市場上都追得很猛。2014年1月，Google負(fù)責(zé)根底設(shè)施的高級副總裁UrsH?lzle給全公司發(fā)出一份令人震驚的備忘錄，表示自己的團(tuán)隊將對公司內(nèi)部包括搜索和Gmail這樣的“客戶”減少關(guān)注，將大局部精力轉(zhuǎn)向公司以外的新客戶，大力打造公共云計算。2014年2月，微軟原來負(fù)責(zé)云業(yè)務(wù)的SatyaNadella成為新的CEO，他很自然地將云定為公司的兩大核心戰(zhàn)略之一，Azure無論在產(chǎn)品還是市場力度上陡然加大。巨頭競爭最大的利器，是大把在固定資產(chǎn)上投錢〔每年投入在數(shù)十億美元〕，然后展開血肉橫飛的價格戰(zhàn)。2014年3月，Google首先發(fā)起一輪大規(guī)模的降價，各項效勞降幅達(dá)32%～85%，Amazon第二天就馬上跟進(jìn)，微軟的降價通知也不過再等了幾天，但后兩家的降幅比Google都要小一些。價格戰(zhàn)的直接結(jié)果是“神仙打架，百姓遭殃”，RackSpace這樣的獨立云廠商首先撐不下去了：他們拒絕跟進(jìn)降價，繼而在一片收購和私有化傳聞中，幾個月內(nèi)的股價跌去一半，不得不在今年5月宣布退出純IaaS市場，主推綁定效勞的托管云。即使是Amazon也開始感到吃力，第二季度的財報發(fā)布時，他們的CFO公開成認(rèn)價格戰(zhàn)影響了公司的財務(wù)表現(xiàn)，股價也應(yīng)聲而落。到7月份，一些國外的分析機(jī)構(gòu)和媒體已經(jīng)在討論：如果把SaaS加進(jìn)來，到年底微軟的云業(yè)務(wù)收入會不會超過Amazon？形勢現(xiàn)在很清楚了，在美國，公共云計算市場已經(jīng)成為巨頭的角斗場所。只有既有資源、又有技術(shù)實力的公司才能繼續(xù)生存。Amazon雖然一開始戰(zhàn)略對頭，選對了從IaaS開始，成為長期的領(lǐng)跑者，至今仍然有較大優(yōu)勢，但Google和微軟一旦發(fā)力，這場長途征戰(zhàn)，鹿死誰手，還很難預(yù)料。三巨頭之外，還有哪些公司能拿到所剩無幾的船票？Apple、IBM、Facebook、Oracle、Intel、Cisco、EMC/VMware……候選人的名單很長，但勝出的概率卻很小了。國內(nèi)的情況呢？從某些方面看，與前幾年的美國Amazon一馬領(lǐng)先，微軟和Google還在猶豫，但AWS之上的云生態(tài)已經(jīng)方興未艾確實非常類似。中國市場上，阿里云的行業(yè)領(lǐng)導(dǎo)地位已經(jīng)根本確立，騰訊云雖然也有比擬完整的產(chǎn)品線，但對外似乎并不急于發(fā)力，百度云更是一直戰(zhàn)略方向都沒有定下來，電信運營商和其他較大的IT公司也同樣心不在焉。而各類創(chuàng)業(yè)公司那么一派欣欣向榮的景象。某種程度上，正是在阿里云不斷地通過雙十一、余額寶和去IOE等大動作震撼業(yè)界、教育市場的東風(fēng)下，中國云計算生態(tài)確實有了很大起色。越來越多的移動游戲、互聯(lián)網(wǎng)、電商、金融、在線教育、企業(yè)軟件效勞規(guī)模性轉(zhuǎn)向云計算。與之相對應(yīng)的，從2013年1月開始，國內(nèi)連續(xù)出現(xiàn)多起云計算領(lǐng)域投資案例，一掃之前的陰郁，包括IaaS層面的七牛、又拍、QingCloud、UCloud、UnitedStack、道里云、群核、監(jiān)控寶、云杉網(wǎng)絡(luò)、多備份、VisualOps、華云數(shù)據(jù)、刻通云、巨杉等，SaaS層面的Tower、Worktile、明道、紛享、Teambition……以至于常參與討論的云計算行業(yè)微信群里，在我的持續(xù)觀察之下，除我之外的其他人在一年多的時間里幾乎都拿到投資，成了土豪。有些IaaS公司融資高達(dá)數(shù)千萬美元，意味著他們的收入很可能可以到達(dá)數(shù)千萬乃至過億人民幣的水平。在《阿里云觀察》一文中，我曾經(jīng)說過：“阿里云在國內(nèi)目前沒有真正的對手，2013年將繼續(xù)享受較長時間的機(jī)遇窗口?！笔聦嵣?，阿里云確實很好地抓住了這個機(jī)遇，打了好幾個漂亮仗，幾乎一直主導(dǎo)著云計算方面的業(yè)界話題。2013年5月17日，阿里集團(tuán)最后一臺IBM小機(jī)在支付寶下線，7月10日，淘寶最后一個Oracle數(shù)據(jù)庫在廣告系統(tǒng)中下線，“去IOE”取得關(guān)鍵性成功。與此同時，“去IOE”也引起IT界熱議和思考，技術(shù)重新選型蔚然成風(fēng)。2013年6月13日，余額寶在阿里云的支撐下推出，一年后用戶過億，規(guī)模到達(dá)近6千億，使背后原本默默無聞的天弘基金成為業(yè)界領(lǐng)導(dǎo)者，震撼了中國基金業(yè)乃至整個金融業(yè)，互聯(lián)網(wǎng)金融成為社會熱點。2013年11月11日，雙十一再創(chuàng)紀(jì)錄，單日成交額到達(dá)362億，而建構(gòu)在阿里云之上的聚石塔處理了75%的訂單量，無一故障。而雙十一巨大的成交量，讓零售業(yè)感受到了前所未有的變革壓力。2013年11月27日，代號“聚寶盆”的金融云效勞推出，阿里云成為金融行業(yè)IT架構(gòu)的一個新選擇。次年5月媒體報道，使用阿里云效勞的金融機(jī)構(gòu)超過100家。2014年2月27日，阿里與海南簽訂規(guī)劃總投資50億元的“未來城市”方案。此后，阿里云在政務(wù)與民生領(lǐng)域的新聞不斷地見諸報端：中國氣象局、廣西、貴州、寧夏、河南、河北……2014年3月4日從CDN正式商用起，新的產(chǎn)品和效勞也在密集推出，僅在6、7月就連續(xù)開放大數(shù)據(jù)處理效勞ODPS、日志效勞SLS、搜索OpenSearch、BI效勞DPC〔采云間〕和可用區(qū)。2014年3月31日，聯(lián)合高德等推出代號“聚無線”的移動云平臺。2014年4月29日，北京數(shù)據(jù)中心開放。5月和9月香港和深圳數(shù)據(jù)中心又陸續(xù)開放，節(jié)點總數(shù)到達(dá)5個。2014年7月15日，開始免費試用四款入門產(chǎn)品的活動。2014年8月19日，發(fā)布“云合方案”，要以2:8分成的政策招募1萬家云效勞商，與之前成立的云棲小鎮(zhèn)聯(lián)盟，組成完整的生態(tài)系統(tǒng)?！?014年5月，阿里巴巴集團(tuán)的上市招股書中，Cloud一詞出現(xiàn)達(dá)80屢次，顯示云計算成為集團(tuán)非常重要的組成局部。另外，業(yè)界也從中得知，阿里云計算等互聯(lián)網(wǎng)根底設(shè)施收入2013年超過1億美元。雖然量級與美國仍有差距，但也打破了云計算的泡沫之論。近百萬用戶數(shù)量，更是令人鼓舞。而對阿里而言，這一年多最重要的突破和轉(zhuǎn)折點，卻是不太為外界注意的飛天5K工程的成功。飛天是阿里云的核心系統(tǒng)，它本來的設(shè)計目的就是將成千上萬臺效勞器組成一臺超級計算機(jī)，對外提供通用計算效勞。早在2012年初，王堅就表示，“從戰(zhàn)略上來說，他們〔阿里云〕想做的事情實際上可以解讀為Amazon+Google并有所超越”。將單一集群做到數(shù)千乃至更高，技術(shù)上是國家和企業(yè)競爭力的標(biāo)志。阿里云必須攻克這道難關(guān)。只不過，2009年才起步的飛天，一直沒有時機(jī)沖擊這一目標(biāo)。2013年，這個時機(jī)來了。一季度做預(yù)算的時候，大家發(fā)現(xiàn)，阿里集團(tuán)內(nèi)部數(shù)據(jù)處理的兩套系統(tǒng)——基于Hadoop的云梯1和基于飛天的ODPS〔云梯2〕隨著單集群規(guī)模不斷擴(kuò)大，都到了幾千，面臨5000集群規(guī)模和跨機(jī)房的門檻。如果分別繼續(xù)投入、重復(fù)建設(shè)，開發(fā)和維護(hù)本錢很高，浪費巨大，必須舍棄一個。怎么辦？當(dāng)時技術(shù)團(tuán)隊內(nèi)部的爭論非常厲害，甚至當(dāng)著馬云的面也不掩飾。Hadoop作為大數(shù)據(jù)的標(biāo)志性開源工程，本身更加成熟，在技術(shù)人員心目中地位很高，感情很深，而且Hadoop集群的規(guī)模本身更大。但是可控性、平安性的問題可能更會在長期成為過不去的坎兒。阿里技術(shù)保障部負(fù)責(zé)人劉振飛的一句話透出了這場爭論背后的本質(zhì)：“Hadoop的定位就是陪太子讀書，而太子就是ODPS。”飛天5K工程因此啟動，一方面ODPS往5K規(guī)模升級，另一方面Hadoop不再開展，處理負(fù)荷向ODPS遷移。以唐洪為首的飛天核心研發(fā)團(tuán)隊歷經(jīng)4個月艱苦努力，對盤古、伏羲等組件進(jìn)行了深入優(yōu)化，并全新開發(fā)了自動故障處理模塊華佗〔細(xì)節(jié)可以參考本期凌云的相應(yīng)的文章〕。到2013年8月15日，這個任務(wù)勝利完成，新的基于飛天5K的ODPS生產(chǎn)集群規(guī)模到達(dá)5000，而且實現(xiàn)了跨機(jī)房，并經(jīng)受了整機(jī)房斷電的嚴(yán)苛考驗。平臺計算100TB排序只需30分鐘，遠(yuǎn)超Yahoo!在7月剛剛創(chuàng)造的71分鐘世界紀(jì)錄。阿里成為世界上屈指可數(shù)的具備這一能力的公司之一，也是第一個對外提供這種能力的公司。多年來，中國在前沿性的關(guān)鍵技術(shù)上少有地站到了世界領(lǐng)獎臺上。從各方面看，飛天5K都是阿里云乃至阿里巴巴歷史上重要的里程碑。到今天，支付寶的所有數(shù)據(jù)處理、淘寶的數(shù)據(jù)倉庫、阿里小貸的貸款業(yè)務(wù)等越來越多的集團(tuán)關(guān)鍵應(yīng)用，都已經(jīng)由ODPS和飛天5K支撐。據(jù)劉振飛透露，阿里云終于借此在集團(tuán)內(nèi)部證明了自己。在此之后，阿里內(nèi)部關(guān)于做不做云計算、到底用Hadoop還是用ODPS，甚至王堅和阿里云靠譜不靠譜的爭論都結(jié)束了。飛天5K工程為此畫上了一個休止符。此后，阿里云作為集團(tuán)的統(tǒng)一技術(shù)平臺，已經(jīng)成為上上下下的共識。最近，幾千臺的HBase集群也在往OTS上遷移。淘寶、天貓、支付寶的負(fù)責(zé)人，現(xiàn)在已經(jīng)主動提出，要將核心系統(tǒng)遷移到阿里云提上日程。在這背后，集團(tuán)副總裁王文彬〔花名菲青〕在2014年初接任阿里云總裁，他原在淘寶天貓負(fù)責(zé)開放平臺與商家業(yè)務(wù)，技術(shù)和生態(tài)建設(shè)背景均很資深，而且他領(lǐng)軍的聚石塔是之前淘寶系基于阿里云所做的最重要的工程之一，對阿里云也有比擬深的了解。同時，以集團(tuán)副總裁章文嵩、傳奇技術(shù)專家蔡景現(xiàn)〔花名多隆的他剛剛成為阿里集團(tuán)的合伙人〕等為代表的許多原淘寶系技術(shù)精英也進(jìn)入阿里云，負(fù)責(zé)主要產(chǎn)品的研發(fā)，大大增強(qiáng)了阿里云的技術(shù)實力。2014年9月原Oracle全球副總裁喻思成加盟，以集團(tuán)副總裁出任阿里云技術(shù)業(yè)務(wù)總經(jīng)理。再加上以劉振飛為首的猛將如云的阿里技術(shù)保障部在根底設(shè)施和運維的全力支持〔參見本期文章《阿里技術(shù)保障部：阿里云的幕后英雄》〕。至此，阿里云的陣容空前強(qiáng)大。2013年9月，在王堅卸任阿里云總裁的消息發(fā)布之后，媒體有各種不明內(nèi)情的解讀。10月阿里云開發(fā)者大會，在會場附近的綠地上，我和其他云棲小鎮(zhèn)聯(lián)盟的成員一起見證了飛天5K紀(jì)念碑的揭幕儀式，王堅非常動情地張羅著眾多還在阿里云或者已經(jīng)離開的同事一起與刻著大家名字的紀(jì)念碑合影。我知道，這個紀(jì)念碑其實主要是王堅自己與小伙伴們幾年在云計算核心技術(shù)自主研發(fā)上篳路藍(lán)縷的階段性總結(jié)，他的云計算之路遠(yuǎn)沒有結(jié)束。此后，由于有了更多強(qiáng)有力的幫手，他得以從具體業(yè)務(wù)抽身，更多地將精力轉(zhuǎn)到云計算和大數(shù)據(jù)戰(zhàn)略思考、客戶溝通與布道上，在更大的范圍內(nèi)發(fā)揮自己的影響。事實上，王堅自己一直認(rèn)為，阿里自己的業(yè)務(wù)用不用阿里云，對阿里云而言并不是最重要的事情。阿里云要成為全社會的通用計算平臺，這個難度無論從技術(shù)還是效勞上，比支撐阿里內(nèi)部要大得多。只不過阿里云如果做得好，阿里內(nèi)部也會用，這是一個附帶的成果。這一年來，他與各種類型的客戶交流，感觸很深。他說，無論是政府、金融還是中小企業(yè)，一旦轉(zhuǎn)到云計算，所能釋放出來的創(chuàng)新能力，遠(yuǎn)遠(yuǎn)超出了他的想象，經(jīng)常令他心潮澎湃。而客戶對云計算的態(tài)度很大程度上已經(jīng)轉(zhuǎn)變，越來越多人對云計算是樂于接受的。反過來，云平臺的挑戰(zhàn)也越來越大。這么多客戶要用，你的能力夠不夠，你接不接得?。烤湍描F道部網(wǎng)站的問題來說，這其實不完全是政府相關(guān)部門的問題，更多的是圍繞鐵道部的那些企業(yè)的問題。很多事情解決不好，中國的企業(yè)不能老是賴政府，企業(yè)也有自己的責(zé)任。云計算企業(yè)要盡快提升自己的能力，否那么很多客戶會不得不去做一些不正確的事情，比方大規(guī)模地自行建設(shè)數(shù)據(jù)中心，用非常傳統(tǒng)的技術(shù)架構(gòu)?！白钆碌氖虑槭牵迥旰髮＜覀儾粩嗪粲跻龀謬a(chǎn)云計算。”王堅說自己經(jīng)常有時不我待的緊迫感。與此照應(yīng)，王文彬在介紹阿里云工作重點時說，今年的主要目標(biāo)是在提升既有產(chǎn)品穩(wěn)定性和體驗、推出更為豐富的新產(chǎn)品的根底上，擴(kuò)大阿里云的影響和市場份額，提升阿里云的口碑。產(chǎn)品和效勞都是重中之重。他希望與更多合作伙伴一起提升用戶體驗。云計算本身似乎存在一個悖論，就是為了競爭和擴(kuò)大規(guī)模，必須不斷降價，而這又會最后使平臺自身無利可圖。Amazon最近的財務(wù)表現(xiàn)似乎證明了這一點。微軟的云負(fù)責(zé)人在說明自己優(yōu)勢時，說的是除了云平臺本身的收入之外，微軟還有其他軟件授權(quán)收入，言下之意也是云計算本身不太掙錢。這也是許多其他巨頭尤其是主營業(yè)務(wù)利潤率比擬高對此看不清楚，而遲遲沒有真正投入的重要原因之一。對此王堅表示，現(xiàn)在關(guān)于云計算還是有很多似是而非的認(rèn)識。一方面，阿里、淘寶平臺還有公共電力行業(yè)的開展歷史，都證明了平臺本身最后能夠成為大生意，而且并不困難。由于杰文斯效應(yīng)〔Jevonseffect〕，技術(shù)的進(jìn)步會增加對技術(shù)的消費量，只要到了一定的規(guī)模，盈利是遲早的事情。另一方面，我們實際上已經(jīng)從IT〔信息技術(shù)〕進(jìn)入到DT〔數(shù)據(jù)技術(shù)〕時代，互聯(lián)網(wǎng)+數(shù)據(jù)取代了計算機(jī)+軟件，云計算是將更多行業(yè)乃至全社會數(shù)據(jù)化的平臺和前提，它的價值不只是平臺本身的盈利，而更在于作為根底設(shè)施，將數(shù)據(jù)的價值釋放出來。這個意義要大得多。最近的幾次談話中，他舉了非常多讓自己感動和驚訝的云計算用戶案例?！坝脩粲冒⒗镌圃谧龅氖虑?，才是阿里云的價值所在?！彼e例說，美國電力科學(xué)研究院〔EPRI〕的數(shù)據(jù)說明，一部iPad如果每天完全充電一次，一年所消耗的電費只有1.5美元，而用戶拿它去干的事情那么不知道會多么偉大。王文彬也非常強(qiáng)調(diào)阿里云上推出ODPS這種大數(shù)據(jù)效勞的意義，這也是阿里云目前的重要特色之一。從很多方面來看，中國的云計算開展有可能超越美國。由于阿里等互聯(lián)網(wǎng)公司積極向各行業(yè)滲透，具有比美國同行更大的影響力，加上國內(nèi)許多公司的IT系統(tǒng)并不成熟，全社會又具有改革慣性，完全有可能直接跨越一個階段，基于云計算平臺構(gòu)建新的核心IT系統(tǒng)。這既是阿里云及其同行的機(jī)遇，也是重重的責(zé)任。阿里技術(shù)保障部：阿里云的幕后英雄發(fā)表于2014-09-2710:48|

8365次閱讀|來源未知|

0

條評論|作者劉江阿里云摘要：阿里集團(tuán)上市前夕公布的最新27名合伙人名單中，出現(xiàn)了公司副總裁、技術(shù)保障部負(fù)責(zé)人劉振飛的名字。這當(dāng)然既是對他個人的認(rèn)可，也是對阿里技術(shù)保障部這一幕后英雄團(tuán)隊奉獻(xiàn)的肯定。阿里集團(tuán)包括阿里云、天貓、淘寶、支付寶、小貸在內(nèi)的各項業(yè)務(wù)，以及近幾年雙十一、飛天5K等諸多奇跡的背后，這...阿里集團(tuán)上市前夕公布的最新27名合伙人名單中，出現(xiàn)了公司副總裁、技術(shù)保障部負(fù)責(zé)人劉振飛的名字。這當(dāng)然既是對他個人的認(rèn)可，也是對阿里技術(shù)保障部這一幕后英雄團(tuán)隊奉獻(xiàn)的肯定。阿里集團(tuán)包括阿里云、天貓、淘寶、支付寶、小貸在內(nèi)的各項業(yè)務(wù)，以及近幾年雙十一、飛天5K等諸多奇跡的背后，這個團(tuán)隊都發(fā)揮了關(guān)鍵性的根底支撐作用。然而，不僅外界聽說過阿里技術(shù)保障部的人不多，就連我雖然與劉振飛已經(jīng)相識多年，對他們團(tuán)隊的具體情況以及與阿里云的淵源也只是一知半解。近日我終于找到一個時機(jī)，在杭州和他好好聊了一上午。阿里技術(shù)保障部的故事，要從2009年8月說起。今天的用戶可能難以想象，當(dāng)時淘寶網(wǎng)非常不穩(wěn)定，動不動就訪問不了，或者要停機(jī)維護(hù)，搞得領(lǐng)導(dǎo)們很生氣很無奈。以至于當(dāng)時淘寶的總裁陸兆禧感慨，淘寶2008年全年成交額是999.6億，要是少宕幾次機(jī)，就過千億了啊。劉振飛說：“你想，當(dāng)一個公司的CEO天天在琢磨這種事，就說明技術(shù)平臺上真是出大問題了?！?月25日，為了解決淘寶系統(tǒng)的問題，成立淘寶技術(shù)保障部，將阿里媽媽和淘寶的運維、數(shù)據(jù)庫等工作和團(tuán)隊合并，當(dāng)時正在北京負(fù)責(zé)淘寶廣告〔阿里媽媽〕技術(shù)團(tuán)隊的劉振飛被領(lǐng)導(dǎo)點將，負(fù)責(zé)組建這支團(tuán)隊。阿里集團(tuán)副總裁、技術(shù)保障部負(fù)責(zé)人劉振飛劉振飛搬到杭州真正進(jìn)入角色，已經(jīng)到了2009年的11月2日，此后很長時間內(nèi)，他和團(tuán)隊都處于救火隊的狀態(tài)，幾乎每天大概都要處理幾十起緊急情況。但更大的挑戰(zhàn)卻是阿里媽媽和淘寶兩個運維團(tuán)隊的合并并不那么順利。“你要知道是兩套體系，兩套人合起來，人的觀念不一樣，大家經(jīng)歷不一樣，習(xí)慣不一樣，工具不一樣，什么都不一樣。合起來真是非常痛苦的過程?！眲⒄耧w甚至夸張地說這一經(jīng)歷給自己留下了不小的心理陰影。而每年的雙十一對劉振飛團(tuán)隊的成長幫助巨大。2009年第一個雙十一銷售額只有5000萬，對系統(tǒng)影響不大，連劉振飛也是在活動要結(jié)束前半小時收到淘寶商城負(fù)責(zé)人逍遙子〔張勇〕的郵件才知道的。一年后的第二個雙十一卻是淘寶技術(shù)保障部經(jīng)歷的一次大挑戰(zhàn)。由于業(yè)務(wù)部門事先估算的成交量2.5億偏低〔實際到達(dá)了9.36億〕，系統(tǒng)準(zhǔn)備缺乏，整個活動期間都如履薄冰，走在崩潰的邊緣，曾經(jīng)一度就要實施降級方案，限制局部寶貝圖片的顯示了。所幸，最后系統(tǒng)經(jīng)受住了考驗。2011年劉振飛決定不再盲從業(yè)務(wù)部門的預(yù)估，而是從技術(shù)角度做足準(zhǔn)備。這一年還創(chuàng)立了由各部門技術(shù)骨干組成技術(shù)保障總指揮部、預(yù)先大規(guī)模壓力測試、大量演習(xí)和詳細(xì)的應(yīng)急預(yù)案等流程和機(jī)制，很好地保證了總銷售額從不到10億到52億、191億和362億的逐年飛躍。2011年還有兩件事兒至關(guān)重要。一是6月淘寶一分為四，除淘寶網(wǎng)、淘寶商城〔后改名天貓〕、一淘三個業(yè)務(wù)部門外，還有一個不太為外界注意到的阿里技術(shù)與公共效勞共享平臺。對此，劉振飛分析，當(dāng)時的拆分可能是馬云和王堅等集團(tuán)高層想將公司技術(shù)底層統(tǒng)一起來，貫徹OneCompany戰(zhàn)略的開始。后來，這個共享平臺的技術(shù)局部改名為阿里集團(tuán)技術(shù)保障部。另一件事是劉振飛團(tuán)隊與阿里云運維的合并。由于上次合并的痛苦回憶，加上當(dāng)時公司內(nèi)外對阿里云有很多爭議，劉振飛對這事起初并不積極，拖過了雙十一之后，又有雙十二，眼見著就往春節(jié)后拖了。可是阿里云的運維負(fù)責(zé)人道夫很主動，而且提出了很具體的方案，他的那句“這方案你聽完以后，你愛怎么合怎么合”感動了劉振飛。雙方很快達(dá)成了一致，合并總體也非常順利。技術(shù)保障部開展到今天，涵蓋業(yè)務(wù)運營〔包括合作創(chuàng)新、標(biāo)準(zhǔn)化和知識產(chǎn)權(quán)〕，性能與容量〔架構(gòu)、性能、容量、優(yōu)化〕，系統(tǒng)研發(fā)〔網(wǎng)絡(luò)平臺、網(wǎng)絡(luò)產(chǎn)品、SDN、效勞器研發(fā)、無線技術(shù)、數(shù)據(jù)引擎、算法平臺等〕，供給鏈管理〔ODM管理〕，數(shù)據(jù)庫〔MySQL、OceanBase、SQLServer和RDS〕，平臺與工具〔工具、流程、監(jiān)控、自動化、配置、研發(fā)協(xié)同平臺、硬件管理平臺〕，平安生產(chǎn)，系統(tǒng)運營和云PE等多個方面，猛將如云，而且同時具有運維的經(jīng)驗和自主研發(fā)的實力。劉振飛還透露了一個鮮為人知的細(xì)節(jié)，因為對阿里云心里沒底，在接手前他私下直接問過馬云本人對阿里云到底是什么態(tài)度，我是全力去干，還是說應(yīng)付應(yīng)付就完了。當(dāng)時馬云是這么答復(fù)的：在王堅參加阿里之前，我跟教授〔指曾鳴〕討論公司的未來，覺得云計算和大數(shù)據(jù)代表未來，對國家、民族、社會的開展有長遠(yuǎn)的意義，所以我們要干，這是第一點。但是怎么做云計算大數(shù)據(jù)？我們誰也不知道。現(xiàn)在來了個人叫王堅，他說我知道怎么做，為什么不支持呢？這是第二點。第三點，即使萬一做失敗了，那也沒關(guān)系，咱們的人倒下70%，還有30%活著，咱們活下來的人繼續(xù)清掃戰(zhàn)場，換個方向繼續(xù)干，總要把它做出來。有了老大的這種明確表態(tài)，劉振飛心里清楚該怎么做了?！霸朴嬎闶枪緫?zhàn)略，什么叫戰(zhàn)略？戰(zhàn)略就是公司一定要干，理解了執(zhí)行，不理解你也要執(zhí)行。”接下來2012年的頭幾個月，他連續(xù)得罪了兩個人。一個是負(fù)責(zé)阿里金融的孫權(quán)〔胡曉明〕。他們是阿里云的第一個重要內(nèi)部客戶。但是由于阿里云的產(chǎn)品當(dāng)時仍不太成熟，問題很多，孫權(quán)找到劉振飛，表示不想用阿里云了，要改用淘寶的體系，讓技術(shù)保障部來支持。劉振飛本著云計算是公司戰(zhàn)略的精神，拒絕了這一要求。同時，阿里云和技術(shù)保障部專門抽調(diào)技術(shù)骨干組成團(tuán)隊，駐扎到濱江辦公區(qū)為阿里金融提供貼身效勞。最終獲得了他們的認(rèn)可。下一個被得罪的，是時任淘寶副總裁的菲青〔王文彬〕。他為了上聚石塔工程〔電商開放平臺〕，來找劉振飛談技術(shù)保障方面的事情，也是不愿意用阿里云，要用淘寶技術(shù)體系，同樣吃了閉門羹?！拔耶?dāng)時說如果用淘寶體系的話你自己找人去玩兒，要用云計算，我全力頂你。我就是這樣非常粗暴地利用手中職權(quán)強(qiáng)迫大家往戰(zhàn)略方向上去走?！眲⒄耧w笑著說。2012年的雙十一，阿里云支撐聚石塔完成全部訂單20%的處理，成為云計算的一大亮點。集團(tuán)外部也有CCTV5的網(wǎng)上直播、浙江臺風(fēng)預(yù)警系統(tǒng)等出色的案例。但阿里云最終真正證明自己，還是2013年的事情。除了依靠阿里云迅速成長為基金業(yè)土豪的余額寶之外，飛天5K工程具有決定性的意義。事后總結(jié)，飛天5K這個工程并非人為規(guī)劃而是逐步開展出來的，其中有幾個歷史節(jié)點很關(guān)鍵。第一個關(guān)鍵點就是去IOE，雖然去IOE最開始是王堅提出來的，但與云計算沒有直接關(guān)系，可是做著做著就發(fā)現(xiàn)殊途同歸了。去IOE內(nèi)部的爭議也非常大，但做到最后，大家發(fā)現(xiàn)這是一個有利于國計民生的大事。第二個關(guān)鍵點是2010年我們自己研發(fā)的海量關(guān)系數(shù)據(jù)庫OceanBase立項，現(xiàn)在已經(jīng)成為整個公司的根底數(shù)據(jù)庫，包括支付寶交易和賬務(wù)系統(tǒng)所用的Oracle，很多應(yīng)用所用的MySQL，最終都會轉(zhuǎn)到OceanBase上。第三個關(guān)鍵點是2010年的雙十一，技術(shù)保障部的組織和雙十一的保障流程建立起來了。然后的關(guān)鍵節(jié)點就是飛天5K工程，之后內(nèi)部通過登月方案，正在爭先恐后地將原有的數(shù)據(jù)處理平臺全部遷移到基于飛天5K的ODPS上。最先動手的登月一號是支付寶，已經(jīng)完成了。接下來的關(guān)鍵點還有今年ODPS的對外發(fā)布，外部客戶現(xiàn)在所用的根底設(shè)施和內(nèi)部支付寶、淘寶所用的，已經(jīng)是完全一樣的了。劉振飛說，更長遠(yuǎn)地來看，5K這個工程將在阿里巴巴歷史上留下很重的一筆。在此之后，阿里技術(shù)團(tuán)隊內(nèi)部停止了爭論，原來做兩攤事兒不時競爭的人，兵合一處，并肩作戰(zhàn)。與之對應(yīng)的，是阿里云的口碑越來越好，網(wǎng)上能見到的吐槽也越來越少。馬云后來說過一句話，他說飛天、ODPS和云OS這三個東西，是我們阿里巴巴要重心打造的重武器或者核武器，這是我們的技術(shù)的核心，一定要搞好。劉振飛透露，最近淘寶系的負(fù)責(zé)人也向他表示，已經(jīng)在認(rèn)真考慮核心系統(tǒng)上云的問題了。內(nèi)部對云計算達(dá)成共識之后，劉振飛和阿里技術(shù)保障部基于幾年的實戰(zhàn)經(jīng)驗，對云計算本身和自己要承當(dāng)?shù)呢?zé)任與面臨的挑戰(zhàn)，做了全面思考。關(guān)于他們的思考結(jié)果和方案，我們留給下一期。劉振飛其人劉振飛這個名字，可能外界并不太熟悉。其實，對于技術(shù)圈，尤其是《程序員》雜志的老讀者和CSDN網(wǎng)站的資深網(wǎng)友來說，劉振飛并不陌生。他是河南魯山人，卻有點山東大漢的意思，個子很高，性格直率。1996年獲得北京大學(xué)碩士學(xué)位，C++程序員出身，曾在微軟Office組任程序經(jīng)理。早在2004年，他就因BugFree這款開源軟件受到廣泛關(guān)注。2005年《程序員》雜志從第1期開始連續(xù)三期刊出了對他的訪談《Bug管理的經(jīng)驗與實踐》，第8、9期又連載了他撰寫的《網(wǎng)站工程成功管理實踐》。這一系列細(xì)論軟件和互聯(lián)網(wǎng)研發(fā)管理經(jīng)驗的文章廣為流傳，產(chǎn)生了很大影響。2007年和2008年兩屆SD2.0大會，劉振飛又成為演講嘉賓，這時他已經(jīng)成為淘寶廣告團(tuán)隊的技術(shù)總監(jiān)。2009年，他受命組建淘寶技術(shù)保障部，后開展為整個阿里集團(tuán)的根底技術(shù)支撐部門。2014年成為阿里27名合伙人之一。不期而遇的飛天之路發(fā)表于2014-09-2711:07|

2731次閱讀|來源未知|

1

條評論|作者郭雪梅，童陽飛天5K阿里云摘要：2006年Amazon推出S3效勞，揭開了以分布式存儲和大規(guī)模計算為標(biāo)志的云計算的面紗。阿里一直關(guān)注并在思考著如何來做云計算。2008年，王堅博士參加阿里，阿里正式成立云計算公司，并決定自主研發(fā)大規(guī)模分布式計算系統(tǒng)——“飛天〔Apsara〕”。2006年Amazon推出S3效勞，揭開了以分布式存儲和大規(guī)模計算為標(biāo)志的云計算的面紗。阿里一直關(guān)注并在思考著如何來做云計算。2008年，王堅博士參加阿里，阿里正式成立云計算公司，并決定自主研發(fā)大規(guī)模分布式計算系統(tǒng)——“飛天〔Apsara〕”。2009年春節(jié)后上班第一天，阿里云團(tuán)隊在北京上地一間簡陋的連空調(diào)都沒有的辦公室寫下第一行代碼。而彼時，在大洋此岸，唐洪剛從北美第四大搜索公司Ask跳到美國雅虎，正在埋頭于大規(guī)模分布式計算系統(tǒng)Hadoop。當(dāng)王堅博士在美國硅谷偶遇唐洪并初次介紹“飛天”時，唐洪對王堅博士說了一句大實話：“開發(fā)飛天這件事，完全不靠譜?！本瓦B王堅博士后來也坦承：“我覺得他是對的，世界上沒有人會覺得這個事情靠譜，因為它很難?！睍r光總愛開玩笑。一年以后，唐洪遭遇了事業(yè)開展中的巨大挑戰(zhàn)——“2010年的時候雅虎在Hadoop上的投入也在逐漸減少，而當(dāng)時雅虎已經(jīng)確定了把所有與數(shù)據(jù)相關(guān)的業(yè)務(wù)和處理都搬到Hadoop上。越來越繁重的業(yè)務(wù)壓力，讓程序員們?yōu)橹С志€上系統(tǒng)疲于奔命。所以我們有很多好的想法，都無法實現(xiàn)?！毙枰貥?gòu)職業(yè)路線：是放棄自己執(zhí)著多年的東西去一些新領(lǐng)域嘗試新的技術(shù)挑戰(zhàn)，比方當(dāng)時在硅谷熾熱的社交網(wǎng)絡(luò)Startup；還是參加一家真正有決心和堅持的公司去共同攀登大規(guī)模分布式計算系統(tǒng)的技術(shù)巔峰？而此時，盡管相對Google、微軟、Amazon這些分布式底層已經(jīng)比擬成熟的企業(yè)而言，阿里才剛剛起步，但阿里云的決心卻已讓“飛天”有了更大的成長空間。一通漫長的越洋之后，2010年，唐洪離開硅谷，正式加盟阿里云，并帶著美國、杭州、北京多個團(tuán)隊，肩負(fù)起阿里云計算整個技術(shù)底層的研發(fā)，成為剛剛兩周歲還處于雛形階段的飛天技術(shù)負(fù)責(zé)人。對于這一選擇，唐洪曾如此解釋：“世界上除了Google、微軟和Amazon，就只有阿里了，我找不到第五家公司能有決心長期投入在自主研發(fā)大規(guī)模分布式系統(tǒng)上?！比OE，飛天勢在必行阿里的IT基因中，開始植入云計算，伴隨著一場“去IOE”運動的進(jìn)行。翻開歷史，淘寶曾啟用全亞洲最大的OracleRAC集群，阿里更是購置過3年無限制的許可，阿里在IBM小型機(jī)以及EMCSAN存儲上的投入也曾成為媒體爭相報道的事件。但隨著互聯(lián)網(wǎng)爆發(fā)式開展，淘寶、支付寶和阿里巴巴B2B的注冊用戶數(shù)激增，阿里只能不停地通過水平和垂直擴(kuò)展架構(gòu)來應(yīng)對新增用戶生成的海量數(shù)據(jù)。而這種集中式數(shù)據(jù)庫的架構(gòu)，使得數(shù)據(jù)庫成為了整個系統(tǒng)的瓶頸，越來越不適應(yīng)海量數(shù)據(jù)對計算能力的巨大需求，更不用說越來越難以承受的高昂投入。阿里的“去IOE”已經(jīng)勢在必行：通過自主研發(fā)的分布式系統(tǒng)取代集中式數(shù)據(jù)庫架構(gòu)，使用MySQL+HBase取代MySQL，商用機(jī)取代小型機(jī)+SAN。選擇自主研發(fā)，這也是阿里云在步入云計算之路上做出的最重要的抉擇：堅持追求擁有自有的最有競爭力的核心技術(shù)。在唐洪看來，云計算是一門高技術(shù)門檻的生意，具備核心技術(shù)競爭力等于具備了在戰(zhàn)場上可以正面抗衡競爭對手的實力，盡管這個技術(shù)攻關(guān)的歷程非常之艱難。選擇自主研發(fā)而非采用開源Hadoop優(yōu)化，也是基于一定的考慮，盡管Hadoop在離線大數(shù)據(jù)處理上具備優(yōu)勢，但無法完全提供阿里云要求的大規(guī)模分布式計算與處理的能力，而目前基于飛天上線的云效勞，已遠(yuǎn)遠(yuǎn)超出Hadoop的能力。開源可以說是一條先易后難的路，盡管一開始可以走一些捷徑，但事后在版本升級、研發(fā)上都會受頗多限制；從核心知識產(chǎn)權(quán)角度來看，今天無論是微軟、Amazon或者Google的云計算平臺，都沒有采用Hadoop且不開放代碼開源，本質(zhì)上都是在追求自有的核心競爭力。開源軟件無法徹底成為一個云計算底層平臺的根底，采用開源軟件并非解決做分布式系統(tǒng)這個問題的一劑良方。開展自有技術(shù)，堅持底層自主研發(fā)，如今能夠構(gòu)建超級計算機(jī)的飛天已成為阿里擁抱云計算，以及對外提供云計算效勞的堅實根底。目標(biāo)5K，突破再突破理想有多么美好，挑戰(zhàn)就有多么巨大。在技術(shù)上，唐洪把自主研發(fā)大規(guī)模分布式系統(tǒng)飛天的挑戰(zhàn)概括為三點。第一，小概率事情變成常態(tài)，主要包括故障率放大、故障類型不可預(yù)知及線上診斷修復(fù)不可防止；第二，昂貴的全局同步代價，JimGray在1996SIGMOD的論文里指出，競爭代價是規(guī)模增長的三次方，因此，10節(jié)點集群擴(kuò)展到1000節(jié)點，同步代價有可能放大百萬倍，這就意味著兩點——性能關(guān)鍵路徑上需要防止全局同步，并與不精準(zhǔn)的全局狀態(tài)達(dá)成妥協(xié)；第三，動態(tài)的運行環(huán)境，這個問題主要是基于線上業(yè)務(wù)，由互聯(lián)網(wǎng)應(yīng)用的爆發(fā)式增長、效勞器負(fù)載的周期性變化，及系統(tǒng)熱點的無時不在和瞬時轉(zhuǎn)移特性導(dǎo)致。迎難而上，是突破再突破。2008年10月24日，組建飛天團(tuán)隊開始做設(shè)計；2009年12月18日，飛天有了第一個應(yīng)用——為阿里金融做的大規(guī)模離線處理；2010年8月24日，飛天成功地支持搜索、郵箱、大規(guī)模數(shù)據(jù)處理、彈性計算存儲等效勞；2011年7月28日，阿里云自主研發(fā)的飛天云計算平臺開始以公共效勞的方式對外提供云計算商業(yè)效勞；同年，首屆阿里云開發(fā)者大會上，基于飛天的阿里云開放效勞產(chǎn)品體系全面亮相；2013年3月，飛天單集群規(guī)模已達(dá)1500臺；2013年8月15日，飛天5K成功，承載著阿里巴巴集團(tuán)數(shù)據(jù)業(yè)務(wù)的“開放數(shù)據(jù)處理效勞〔OpenDataProcessingService，簡稱ODPS〕”集群正式開始生產(chǎn)運營，單集群規(guī)模到達(dá)5000臺。在實現(xiàn)單集群5000節(jié)點之后，通過上層應(yīng)用ODPS，飛天已經(jīng)支撐了阿里內(nèi)部大局部數(shù)據(jù)業(yè)務(wù)，其中包括阿里小貸、數(shù)據(jù)魔方、阿里媽媽廣告聯(lián)盟、廣告搜索、點擊預(yù)測模型訓(xùn)練、支付寶所有業(yè)務(wù)、淘寶指數(shù)、阿里無線等。2014年7月，以RESTfulAPI方式提供數(shù)據(jù)倉庫、數(shù)據(jù)挖掘和其他數(shù)據(jù)應(yīng)用效勞的ODPS，正式對外開放。今天，已有近百萬應(yīng)用部署在阿里云平臺上面，客戶普及全國不同地域、不同行業(yè)領(lǐng)域。取得一系列技術(shù)突破的背后，是不為人知的一場艱難的歷程，其中更大的困難在于人。召集一群能夠做這件事的人難，而召集一群能耐住寂寞為夢想實現(xiàn)而甘于奉獻(xiàn)的人更難，無數(shù)難題讓飛天人吃盡苦頭。回想一路的歷程，唐洪說：“當(dāng)飛天第一天立項、從第一行代碼開始，便是帶著明知山有虎，偏向虎山行的決絕和勇氣前進(jìn)的。而這一路不僅僅有阿里巴巴集團(tuán)的研發(fā)人員在投入這場戰(zhàn)斗，還有更多的是我們的客戶、合作伙伴的支持，才能走到今天5K的目標(biāo)。2013年10月25日，杭州轉(zhuǎn)塘阿里云創(chuàng)業(yè)創(chuàng)新基地專門為飛天5K設(shè)立了紀(jì)念標(biāo)志，我們在這個標(biāo)志上不僅留下了在工程室小黑屋封閉開發(fā)的程序員、趕著早頂峰下班的開發(fā)運維人員的名字，也有每個周末都趕來陪同加班的家屬，更有把身家性命放在阿里云上的客戶的名字，其實從另一個維度來說，因為有了他們才有了今天的5K。”未來，騰飛的阿里云計算飛天5K的正式上線，也標(biāo)志著阿里與Google、微軟和Amazon比肩，從此成為世界上獨立擁有相關(guān)技術(shù)能力的屈指可數(shù)的公司之一。未來，唐洪看得更遠(yuǎn)：“目前飛天所支撐的業(yè)務(wù)占有市場份額還缺乏1%，接下來的路還很漫長且艱辛。著眼未來，5K只能是飛天已經(jīng)邁過的一道門檻，是阿里云一個新的起點。”有一種追求叫自主研發(fā)！相信唐洪和這群有理想、有信仰的年輕人們在這片更加廣闊的天空中能夠更加自由地翱翔！探索5K巔峰，云梯架設(shè)的飛天之夢發(fā)表于2014-09-2711:19|

2030次閱讀|來源未知|

2

條評論|作者郭雪梅，童陽阿里云飛天5K摘要：5年的時間，飛天平臺從1500臺的集群規(guī)模到3000臺的集群規(guī)模，再到2013年8月，飛天開放平臺最終成功實現(xiàn)單集群超越5000臺、同時支持多集群跨機(jī)房計算的目標(biāo)。IDC研究顯示，包含結(jié)構(gòu)化和非結(jié)構(gòu)化的大數(shù)據(jù)正在以每年60%的增長率持續(xù)增長，到了2020年全球數(shù)據(jù)總量將增長44倍，到達(dá)35.2ZB。而著眼國內(nèi)，2013年產(chǎn)生的數(shù)據(jù)總量已經(jīng)超過0.8ZB，兩倍于2012年，相當(dāng)于2009年全球的數(shù)據(jù)總量。預(yù)計到2020年，中國產(chǎn)生的數(shù)據(jù)總量更可能超過8.5ZB。井噴的數(shù)據(jù)在給各個機(jī)構(gòu)帶來數(shù)不盡機(jī)遇和財富的同時，也在存儲、計算、帶寬等領(lǐng)域給企業(yè)帶來無盡的挑戰(zhàn)。擁有數(shù)億注冊用戶的阿里巴巴感受最明顯——2013年3月28日，一封來自技術(shù)保障部架構(gòu)師的郵件直達(dá)阿里集團(tuán)最高層：“按照數(shù)據(jù)增量與未來業(yè)務(wù)增長的情況，云梯1〔以Hadoop為底層的集群〕系統(tǒng)存儲和計算能力將在6月21日到達(dá)瓶頸，數(shù)據(jù)業(yè)務(wù)將會停滯，淘數(shù)據(jù)、量子等業(yè)務(wù)都會受到影響；而云梯2〔以飛天為底層的集群〕也有同樣的問題，阿里金融的貸款業(yè)務(wù)將因為無法進(jìn)行信用數(shù)據(jù)運算而中止?！睂θ魏纹髽I(yè)而言，效勞壓力上漲都是幸福的煩惱。而到了阿里這樣的規(guī)模，不管是幸福還是煩惱都被放大了無數(shù)倍。對于大規(guī)模分布式離線存儲和計算集群來說，如果原有集群不能通過簡單的增添主機(jī)來增加存儲空間和計算能力，橫向擴(kuò)展遭遇不可逾越的瓶頸，就代表著系統(tǒng)重構(gòu)的開始。此時，擺在阿里面前只有兩個選擇：第一，直接擴(kuò)容云梯1，從成熟度、穩(wěn)定性、工程的復(fù)雜程度、投入力量來看，這條路平安有效，但基于飛天的云梯2同樣岌岌可危；第二，同時擴(kuò)容云梯1和云梯2，擴(kuò)容后兩個數(shù)據(jù)系統(tǒng)的單集群規(guī)模都將到達(dá)5000臺，實現(xiàn)跨機(jī)房集群處理，但3個月的deadline和巨額的人力、物力投入同樣不容無視。面對只有不到3個月的實施時間，這道選擇題變得異常艱難——是高效地選擇盡快到達(dá)“平安地帶”，還是在兼顧“平安”的同時，投入大量人力、物力，選擇一次史無前例的“突破”？意料之中，也是意料之外，阿里毅然選擇了“背水一戰(zhàn)”：云梯1和云梯2同時并行擴(kuò)容！擴(kuò)容不可阻擋事實上，無論是從規(guī)劃理念、技術(shù)開展，還是從集群規(guī)模來看，飛天擴(kuò)容的最正確時機(jī)已經(jīng)到來?；貞涳w天的歷史。2009年，自投身云計算，阿里云就立志要自主研發(fā)出以“飛天”為代號的大規(guī)模分布式計算系統(tǒng)。飛天的設(shè)計宗旨就是通過構(gòu)建一套綜合性的軟硬件系統(tǒng)，將數(shù)以千計的效勞器連成一臺“超級計算機(jī)”，并最終實現(xiàn)兩個目標(biāo)：對內(nèi)，通過對這臺超級計算機(jī)進(jìn)行物理資源分配、程序運行操控，以及保障效勞及數(shù)據(jù)平安的操作系統(tǒng)，支撐阿里集團(tuán)效勞的核心技術(shù)平臺；對外，將這臺超級計算機(jī)的計算、存儲等資源，以公共效勞的方式，輸送給互聯(lián)網(wǎng)上的用戶或者其他應(yīng)用系統(tǒng)。云梯的元老級創(chuàng)立者羅李〔花名鬼厲〕曾表示，之所以起名云梯，工程組建時就被定義為阿里云計算平臺的鋪路者，寓意奉獻(xiàn)。而著眼飛天，這個工程無疑承載了阿里的云計算愿景，從第一行代碼被寫下時就意義非凡。5年的時間，飛天平臺從1500臺的集群規(guī)模到3000臺的集群規(guī)模，再到2013年8月，飛天開放平臺最終成功實現(xiàn)單集群超越5000臺、同時支持多集群跨機(jī)房計算的目標(biāo)。放眼全球，能做到這一點的企業(yè)，屈指可數(shù)。諸神實現(xiàn)飛天之夢飛天，是親近水的一位神的名字，是可以為人們帶來幸福和桔祥之神。和飛天一樣，系統(tǒng)中的各個模塊也被賦予了上古諸神的名字：分布式文件系統(tǒng)是開天辟地承載一切根底之神——盤古〔Pangu〕；負(fù)責(zé)任務(wù)調(diào)度和資源管理模塊的是占卜和預(yù)測之神——伏羲〔Fuxi〕；從底層上監(jiān)視和處理導(dǎo)致集群性能下降的集群診斷系統(tǒng)——華佗〔Huatuo〕；負(fù)責(zé)網(wǎng)絡(luò)連接的模塊——夸父〔Kuafu〕；監(jiān)控系統(tǒng)——神農(nóng)〔Shennong〕；集群部署——大禹〔Dayu〕……以諸神之名，映射出的是背后的理想主義色彩。眾神協(xié)作下，飛天負(fù)責(zé)管理數(shù)據(jù)中心Linux集群的物理資源，控制分布式程序進(jìn)行，并隱藏下層故障恢復(fù)和數(shù)據(jù)冗余等細(xì)節(jié)，有效地提供彈性計算和負(fù)載均衡的效勞。而數(shù)千節(jié)點規(guī)模下，無論是系統(tǒng)的打造還是擴(kuò)容都面臨著眾多技術(shù)挑戰(zhàn)，在5K擴(kuò)容過程中，平臺的各個模塊在規(guī)模性能、高可用以及可運維性等方面都做了大量的改良和優(yōu)化?！霰P古，在內(nèi)部架構(gòu)上盤古采用Master/ChunkServer結(jié)構(gòu)，Master管理元數(shù)據(jù)，ChunkServer負(fù)責(zé)實際數(shù)據(jù)讀寫，通過Client對外提供類POSIX的專有API。在集群擴(kuò)展到5K規(guī)模后，相關(guān)問題紛至沓來，主要可分為兩個局部：首先，盤古MasterIOPS問題，因為更大的集群意味著更多文件和更多訪問，上層應(yīng)用對存儲億級文件和十億級文件集群的IOPS是有顯著區(qū)別的。同時更大規(guī)模的集群讓快速開展的上層應(yīng)用看到了更多可能性，導(dǎo)致更多業(yè)務(wù)上云，存儲更多數(shù)據(jù)，也間接導(dǎo)致了對IOPS的更高需求。此前盤古Master較低的IOPS已經(jīng)限制了上層業(yè)務(wù)的快速擴(kuò)張，業(yè)務(wù)頂峰期時有告警，亟待提升。另外一個規(guī)模相關(guān)問題就是盤古Master冷啟動速度，更多的文件和Chunk數(shù)導(dǎo)致更長的冷啟動時間，影響集群可用性。在具體的性能優(yōu)化上，主要工作有克服鎖瓶頸、優(yōu)化架構(gòu)〔包括Pipeline優(yōu)化和GroupCommit〕，以及不斷深入細(xì)節(jié)反復(fù)嘗試以解決規(guī)模導(dǎo)致的冷啟動時間過長，詳情請閱讀《優(yōu)化無極限：盤古Master優(yōu)化實踐》?！龇耍w天平臺的分布式調(diào)度系統(tǒng)。在5K攻堅中，從設(shè)計到實現(xiàn)每一步都可能存在性能“陷阱”，原因主要在三個方面：規(guī)模放大效應(yīng)，當(dāng)節(jié)點數(shù)增大到數(shù)千個時，系統(tǒng)中原本不是瓶頸的與規(guī)模成正比的環(huán)節(jié)，其影響會被放大；木桶效應(yīng)，未經(jīng)優(yōu)化的那一小局部很可能成為影響系統(tǒng)性能的致命的瓶頸；長路徑模塊依賴，被依賴模塊性能的不穩(wěn)定性最終會影響某個請求處理的性能和穩(wěn)定性。為此，阿里從通信、關(guān)鍵函數(shù)、模塊依賴等多個方面進(jìn)行了優(yōu)化，詳情參閱《走近伏羲，談5000節(jié)點集群調(diào)度與性能優(yōu)化》?！鋈A佗，運維的模式隨著5K的到來發(fā)生了很大的改變，在解決實際問題的過程中，華佗應(yīng)運而生，上通飛天系統(tǒng)，下達(dá)運維各種系統(tǒng)。其架構(gòu)足夠健壯、簡單和開放，PE可以很方便地將自己豐富的運維經(jīng)驗轉(zhuǎn)換成華佗的插件。華佗可以針對各種異常情況，進(jìn)行故障磁盤管理還有系統(tǒng)異常處理，PE也可以通過它做流程和管理自動化的工作。同時，不必再做幾分鐘的快速人工修復(fù)，而是當(dāng)故障設(shè)備積累到一定量后批量地做替換，大量地節(jié)省了人力本錢。當(dāng)下華佗已經(jīng)運用到磁盤管理、機(jī)器管理、網(wǎng)絡(luò)故障檢測等多個場景，更多詳情可關(guān)注《走近華佗，解析自動化故障處理系統(tǒng)背后的秘密》?！霎?dāng)運維的效勞器到達(dá)數(shù)千臺甚至上萬規(guī)模機(jī)器的時候，必然會遇到諸多挑戰(zhàn)，如硬件配置的差異化，用戶數(shù)和任務(wù)數(shù)的急劇膨脹，大壓力下的邊界效應(yīng)，小概率事件被觸發(fā)等。在這個前提下需要做好快速部署，自動化運維、監(jiān)控報警、Log分析、精細(xì)化計量等需求會越來越迫切。在這些方面，阿里付出了更多的心血以保證業(yè)務(wù)穩(wěn)定和平安的運行，詳情可見《飛天5K實戰(zhàn)經(jīng)驗：大規(guī)模分布式系統(tǒng)運維實踐》。當(dāng)飛天第一個五千臺規(guī)模集群——飛天5K正式投入運營時，所承載上線的效勞即是ODPS。以底層大規(guī)模分布式系統(tǒng)的性能優(yōu)化和運維保障為根底，支撐起了更上層的平臺——OpenDataProcessingSystem，開放數(shù)據(jù)處理效勞。ODPS譜寫飛天5K應(yīng)用ODPS和飛天的關(guān)系，可以追溯到更早的時候。2010年春節(jié)，ODPS的前身SQLEngine第一版上線，運行在當(dāng)時30臺機(jī)器的飛天集群上。2011年1月，由于業(yè)務(wù)上需要支持更多數(shù)據(jù)模型，SQLEngine被重構(gòu)，命名為DataEngine數(shù)據(jù)倉庫發(fā)布上線，穩(wěn)定運行在100臺機(jī)器上。但是，DataEngine0.2支持的數(shù)據(jù)量還遠(yuǎn)不滿足需要，而且它的穩(wěn)定性還有待提升。2011年Q3，飛天團(tuán)隊開始探索支撐集團(tuán)內(nèi)部數(shù)倉業(yè)務(wù)，利用莫邪〔Moye〕系統(tǒng)，在1500臺機(jī)器上并行運行云梯1的生產(chǎn)作業(yè)，并取得了不輸于Hadoop的性能和穩(wěn)定性成績。2012年Q1，團(tuán)隊在DataEngine和莫邪之間做技術(shù)選擇，并決定使用莫邪作為ODPS產(chǎn)品的核心引擎，DataEngine退出歷史舞臺。飛天5K工程之后，ODPS隨之進(jìn)入5000臺機(jī)器和跨機(jī)房調(diào)度時代。作為飛天的重要模塊，它不僅僅得到了擴(kuò)容，而且還進(jìn)一步實現(xiàn)了跨集群的數(shù)據(jù)復(fù)制，詳情見《ODPS跨集群遷移與數(shù)據(jù)同步經(jīng)驗分享》。ODPS遠(yuǎn)不只是一個簡單的大數(shù)據(jù)平臺，功能包括SQL，基于Java的MapReduce編程框架，圖計算編程模型，一系列機(jī)器學(xué)習(xí)算法的實現(xiàn)等。所有的功能是以RESTfulAPI的形式對外提供，從系統(tǒng)邊界上說，這層API隔離了ODPS平臺和用戶的系統(tǒng)，和Hadoop的區(qū)別也很明顯。ODPS設(shè)計之初就是為了對外開放，做基于互聯(lián)網(wǎng)的多租戶的公共數(shù)據(jù)處理效勞，所以平安性在ODPS的設(shè)計和實現(xiàn)中具有最高的優(yōu)先級。ODPS作為離線數(shù)據(jù)處理平臺，許多新的技術(shù)也是第一次應(yīng)用到5K工程，并且經(jīng)受了準(zhǔn)生產(chǎn)環(huán)境的檢驗，同時也為未來數(shù)據(jù)業(yè)務(wù)長期開展打下了堅實的根底。目前在阿里集團(tuán)內(nèi)部已經(jīng)被廣泛用于海量結(jié)構(gòu)化數(shù)據(jù)的處理分析，幫助阿里集團(tuán)將業(yè)務(wù)實踐沉淀的海量數(shù)據(jù)進(jìn)行提煉分析，從而讓數(shù)據(jù)誕生新的價值?！禣DPS技術(shù)架構(gòu)及應(yīng)用實踐》一文中對這些內(nèi)容有更詳細(xì)的講述。期待更多飛天精神時至今日，已經(jīng)實現(xiàn)5000節(jié)點單集群的飛天5K擁有驚人的規(guī)模：10萬核的計算能力；100PB存儲空間；可處理15萬并發(fā)任務(wù)數(shù)；可承載億級別文件數(shù)目；100TB排序30分鐘完成，遠(yuǎn)超今年7月1日Yahoo!在SortBenchmark排序測試DaytonaGraySort所創(chuàng)造的世界紀(jì)錄——100TB排序完成時間約71分鐘。飛天5K不僅成為阿里集團(tuán)最為重要的技術(shù)平臺，而且集群中的計算、存儲等能力已經(jīng)完全以云效勞的方式在對外輸出。這意味著“云計算可以讓一個人的公司，跟一個很大的公司，站在同一條起跑線上競爭”。飛天5K，不僅是阿里云計算技術(shù)開展的一個里程碑，同時也將注定在中國云計算技術(shù)開展的歷史中留下濃墨重彩的一筆。展望中國云計算產(chǎn)業(yè)的將來，期待有更多像飛天一樣的技術(shù)，也期待有更多像飛天一樣，百折不撓的精神。優(yōu)化無極限：盤古Master優(yōu)化實踐瀏覽次數(shù)：82次

CSDN

2014年10月22日

字號:

大

中

小分享到：QQ空間新浪微博騰訊微博人人網(wǎng)豆瓣網(wǎng)開心網(wǎng)更多0盤古是一個分布式文件系統(tǒng)，在整個阿里巴巴云計算平臺——“飛天”中，它是最早被開發(fā)出的效勞，因此用中國古代神話中開天辟地的盤古為其命名，希冀能創(chuàng)立出一個全新的“云世界”。在“飛天”平臺中，它是負(fù)責(zé)數(shù)據(jù)存儲的基石性系統(tǒng)，其上承載了一系列的云效勞〔如圖1所示〕。盤古的設(shè)計目標(biāo)是將大量通用機(jī)器的存儲資源聚合在一起，為用戶提供大規(guī)模、高可用、高吞吐量和良好擴(kuò)展性的存儲效勞。盤古的上層效勞中，既有要求高吞吐量，期待I/O能力隨集群規(guī)模線性增長的“開放存儲”；又有要求低時延的“彈性計算”，而作為底層平臺核心模塊的盤古必須二者兼顧，同時具備高吞吐量和低時延。圖1飛天整體架構(gòu)圖在內(nèi)部架構(gòu)上盤古采用Master/ChunkServer結(jié)構(gòu)〔如圖2所示〕，Master管理元數(shù)據(jù)，多Master之間采用Primary-Secondaries模式，基于PAXOS協(xié)議來保障效勞高可用；ChunkServer負(fù)責(zé)實際數(shù)據(jù)讀寫，通過冗余副本提供數(shù)據(jù)平安；Client對外提供類POSIX的專有API，系統(tǒng)地提供豐富的文件形式，滿足離線場景對高吞吐量的要求，在線場景下對低延遲的要求，以及虛擬機(jī)等特殊場景下隨機(jī)訪問的要求。圖2盤古簡明架構(gòu)圖自5K工程以來，集群規(guī)模快速擴(kuò)張到5000個節(jié)點，規(guī)模引發(fā)的相關(guān)問題紛至沓來。首當(dāng)其沖的就是盤古MasterIOPS問題，因為更大的集群意味著更多文件和更多訪問，顯然上層應(yīng)用對存儲億級文件和十億級文件集群的IOPS是有顯著區(qū)別的。同時更大規(guī)模的集群讓快速開展的上層應(yīng)用看到了更多可能性，導(dǎo)致更多業(yè)務(wù)上云，存儲更多數(shù)據(jù)，也間接導(dǎo)致了對IOPS的更高需求。此前盤古Master較低的IOPS已經(jīng)限制了上層業(yè)務(wù)的快速擴(kuò)張，業(yè)務(wù)頂峰期時有告警，亟待提升。另外一個規(guī)模相關(guān)問題就是盤古Master冷啟動速度，更多的文件和Chunk數(shù)導(dǎo)致更長的冷啟動時間，影響集群可用性。要解決上述問題，性能優(yōu)化勢在必行。但對于盤古這樣復(fù)雜的大型系統(tǒng)，不可能畢其功于一役，需要在不同的階段解決不同的性能瓶頸。優(yōu)化通常會伴隨整個生命周期，因此優(yōu)化工作本身也需要進(jìn)行經(jīng)驗、工具等方面的積累，為后續(xù)持續(xù)優(yōu)化提供方便。因此在這次規(guī)模問題優(yōu)化中，我們積極建設(shè)了自己的鎖Profile工具，并依此解決了多個鎖導(dǎo)致的性能問題；在解決主要的鎖瓶頸后，我們進(jìn)行了架構(gòu)上的優(yōu)化，包括Pipeline優(yōu)化和GroupCommit優(yōu)化，取得了良好效果；最后我們通過對細(xì)節(jié)的不斷深入，反復(fù)嘗試，較好地解決了由規(guī)模導(dǎo)致冷啟動時間過長的問題。工具篇在盤古這樣復(fù)雜的大型系統(tǒng)上，鎖是優(yōu)化過程經(jīng)常遇到的問題。優(yōu)化的首要任務(wù)是找出具體瓶頸，切忌猜測和盲目修改代碼。先用壓測工具對盤古Master加壓，通過Top、Vmstat等系統(tǒng)工具發(fā)現(xiàn)CPU負(fù)載不到物理核的一半，ContextSwitch高達(dá)幾十萬，初步疑心是鎖競爭導(dǎo)致。同事也覺得某些路徑下的鎖還有優(yōu)化空間，但到底是哪些鎖競爭厲害？哪些鎖持有的時間長？哪些鎖等待時間長？具體又是哪些操作需要這些鎖？由于缺少切實可靠的數(shù)據(jù)支撐，不能盲目下手，而堅持?jǐn)?shù)據(jù)說話是一個工程師應(yīng)有的品質(zhì)。盤古Master提供了眾多的讀寫接口，內(nèi)部的不同模塊使用了大量的鎖，我們需要準(zhǔn)確得知是哪類操作導(dǎo)致哪個鎖競爭嚴(yán)重，此前常用的一些Profile工具難以滿足需求，因此我們有必要打造自己的“手術(shù)刀”——鎖分析工具，方便后續(xù)工作。首先為了區(qū)分不同的鎖，我們需要對代碼中所有的鎖進(jìn)行統(tǒng)一命名，并將命名記錄到鎖實現(xiàn)內(nèi)，同時為了區(qū)分不同的操作，還需要對所有的操作進(jìn)行一個唯一的類型編號。在某個Worker線程從RPC中讀取到具體請求時，將類型編號寫入到該Worker線程私有數(shù)據(jù)中，隨后在該RPC請求的處理過程中，不同鎖的拿鎖操作，都?xì)w類于該操作類型。在每個鎖內(nèi)部，維護(hù)一個Vector數(shù)據(jù)，LockPerfRecord記錄鎖的Profile信息，具體定義如下：每個操作對應(yīng)Vector中的一個元素，線程私有數(shù)據(jù)中記錄的操作編號即Vector下標(biāo)。整體來看形成了表1中的稀疏二維數(shù)組，空記錄表示該操作未使用對應(yīng)鎖。表1操作類型與鎖統(tǒng)計示意表具體實現(xiàn)上，AcquireCounts采用原子變量，時間測量上采用Rdtsc。談到Rdtsc有不少人色變，認(rèn)為有CPU變頻、多CPU之間不一致等問題，但在長時間粒度〔分鐘級〕和大量調(diào)用〔億次〕的壓測背景下，這些可能存在的影響不會干擾最終結(jié)果，屢次實驗結(jié)果也證實了這一點。其他實現(xiàn)細(xì)節(jié)，如定時定量〔每n分鐘或者每發(fā)起x次操作〕發(fā)起不影響主流程的PerfDump就不再贅述。整個代碼在百行左右，對平臺的侵入也很小，僅需要為每個鎖添加一個初始化命名，在RPC處理函數(shù)的入口設(shè)定操作編號即可。利器在手，按圖索驥，對存在性能問題的鎖進(jìn)行各種優(yōu)化。例如使用多個鎖來替換原來全局唯一鎖，減少沖突概率；減少加鎖范圍；使用無鎖的數(shù)據(jù)結(jié)構(gòu)，或者使用更輕量級的鎖來優(yōu)化。整個優(yōu)化過程極富趣味性，經(jīng)常是解決一個鎖瓶頸后，發(fā)現(xiàn)瓶頸又轉(zhuǎn)移到另外一個鎖上，在工具的Profile結(jié)果中有非常直觀的展示。先后優(yōu)化了ClientSession、Placement等模塊中鎖的使用，取得了顯著的效果，CPU根本可以跑滿，ContextSwitch大幅度下降，整個過程酣戰(zhàn)淋漓。架構(gòu)篇在鎖競爭問題解決到一定程度后，繼續(xù)進(jìn)行鎖的優(yōu)化就很難在IOPS上取得較大收益。此時結(jié)合業(yè)務(wù)邏輯，我們發(fā)現(xiàn)可以從架構(gòu)上做出局部調(diào)整，以提升整體的IOPS。讀寫別離〔快慢別離〕整個盤古Master對外接口眾多，根據(jù)是否需要在Primary和Secondaries之間同步OperationLog來分成讀和寫兩大類。所有讀操作都不需要同步OperationLog，所有的寫操作基于數(shù)據(jù)一致性必須同步?？紤]到Primary和Secondaries隨時都可能發(fā)生切換，要保證數(shù)據(jù)一致，Client端發(fā)送的每一個寫請求，Primary必須在同步OperationLog完全成功后才能返回Client。顯而易見，寫比讀要慢得多，如果讓同一個線程池來同時效勞讀和寫，將會導(dǎo)致什么結(jié)果？一個形象的隱喻是多車道的高速公路，如果一條高速公路上不按照速度來劃分多車道，而是隨心所欲地混跑，20碼和120碼的車跑在同一條車道上，整體的吞吐量無論如何也不會高。參照高速公路設(shè)計，進(jìn)行快慢別離，耗時低的讀操作占用一個線程池，耗時高的寫操作使用另外一個線程池，雙方互不干擾，進(jìn)行這樣一個簡單的切分后，讀IOPS得到顯著提升，而寫操作并未受影響。Pipeline讀寫別離后，讀的IOPS性能得到極大提升，但寫操作依然有待提升。寫操作的根本流程如圖3所示。圖3寫操作根本流程圖在Master端，寫操作最大的時間開銷在同步OperationLog到Secondaries。這里的關(guān)鍵缺陷在于同步OperationLog期間，工作線程只能被動地等待一段相當(dāng)長的時間，這個過程包括將數(shù)據(jù)同步到Secondaries上，并由Secondaries將這個數(shù)據(jù)同步寫入到磁盤，由于涉及到同步寫物理磁盤〔而非寫PageCache〕，這個時間是毫秒量級。所以寫操作的IOPS肯定不會高。定位問題后，在結(jié)構(gòu)上稍做調(diào)整如圖4所示。圖4寫操作Pipeline簡要流程圖類似中斷處理程序，整個RPC的處理流程分成了上半部和下半部，上半部由Worker線程處理Request，將OperationLog提交到OplogServer，不再阻塞等待同步Oplog成功，而是接著處理下一個Request。下半部的工作包括填充Response，將Response寫入到RPCServer，下半部由另外一個線程池承當(dāng)，通過Oplog同步成功的消息觸發(fā)。這樣Worker線程源源不斷地處理新的Request，寫操作IOPS顯著提升。由于只有同步Oplog完全成功才會返回Response，所以數(shù)據(jù)一致性與此前的實現(xiàn)相同。GroupCommit經(jīng)過Pipeline優(yōu)化后，寫操作性能顯著提升，但我們對結(jié)果依然不太滿意，想進(jìn)一步提升IOPS，為上層客戶提供一個更好的結(jié)果。繼續(xù)Profile，發(fā)現(xiàn)新實現(xiàn)下同步Oplog吞吐量較低，主要原因是每個寫請求都導(dǎo)致一次主備間同步Oplog，而且這條Oplog在Primary和Secondaries上都需要同步寫到磁盤。壓力較高時，將有大量的同步RPC和小片數(shù)據(jù)同步寫磁盤，導(dǎo)致吞吐量低。通常分布式系統(tǒng)會使用GroupCommit技術(shù)來優(yōu)化這個問題，將時間上接近的Oplog組成一個Group，整個Group一次提交，吞吐量可以明顯提升。但傳統(tǒng)的GroupCommit會帶來Latency的明顯增加，需要在吞吐量和Latency之間做權(quán)衡。魚與熊掌如何兼得？我們對GroupCommit過程進(jìn)行了適當(dāng)優(yōu)化，較好地解決了這個問題。將組Group和同步Group別離，前者由一個Serialize線程承當(dāng)，后者由Sync線程完成。Serialize線程作為生產(chǎn)者，Sync線程作為消費者，兩者通過一個隊列來共享數(shù)據(jù)，當(dāng)Serialize線程發(fā)現(xiàn)隊列中大于M個Group等待被同步的時候，將暫停組新的Group；而當(dāng)Sync線程發(fā)現(xiàn)隊列中等待的Group小于N個的時候，將喚醒Serialize線程組新的Group，由于Serialize線程經(jīng)過了一段時間的等待，積累了一批數(shù)據(jù)，此時可以組成更大的Group，同時又不會造成Latency的提升。當(dāng)整個系統(tǒng)負(fù)載低的時候，隊列為空，Serialize無需等待，Latency很低；當(dāng)系統(tǒng)負(fù)載較高的時候，隊列中有堆積，此時暫停Serialize，也不會增加額外的Latency，而且隨后可以組成較大的Group，獲得高吞吐量收益。通過對Serialize和Sync操作的壓力測試，可以確定最優(yōu)化的M、N值。細(xì)節(jié)篇專注細(xì)節(jié)，做深做透對一個大型復(fù)雜系統(tǒng)而言尤為重要。在整個優(yōu)化過程中，我們遇到很多富有趣味性的細(xì)節(jié)問題，經(jīng)過深入挖掘后，取得了良好成果。其中具有代表性的一個例子就是Sniff的深入優(yōu)化。在5K工程前，盤古Master冷啟動時間以小時計，5K后由于規(guī)模擴(kuò)張，Chunk數(shù)劇增，冷啟動時間會更長。冷啟動時，需要做Sniff操作，獲取所有ChunkServer上Chunk的信息〔Chunk的數(shù)量在十億數(shù)量級〕，將這些信息會聚到幾個Map結(jié)構(gòu)中，在多線程環(huán)境下Map結(jié)構(gòu)的插入和更新必須鎖保護(hù)。通過鎖工具Profile也證實瓶頸就在鎖保護(hù)的Map上。所以縮短啟動時間就轉(zhuǎn)化為如何對鎖保護(hù)的Map進(jìn)行讀寫性能優(yōu)化這樣十分具體的細(xì)節(jié)問題。為減少鎖競爭，調(diào)整結(jié)構(gòu)如圖5所示。圖5Sniff優(yōu)化示意圖引入一個無鎖隊列，所有的工作線程將數(shù)據(jù)更新到無鎖隊列，隨后由單一線程從無鎖隊列中批量更新到Map，調(diào)整后Sniff期間ContextSwitch從40萬降低到4萬左右，耗時縮減到半小時，效果顯著。但我們依然覺得過長，繼續(xù)深挖，發(fā)現(xiàn)此時CAS操作異常頻繁，而且單一的更新線程已經(jīng)占滿一個核，繼續(xù)優(yōu)化感覺無從下手了，此時回過頭來研究業(yè)務(wù)特點，看看能否根據(jù)業(yè)務(wù)特點來減少某些約束。功夫不負(fù)有心人，最終我們發(fā)現(xiàn)了一些非常有趣的細(xì)節(jié)，即在Sniff階段，我們根本不讀取這些Map，只在Sniff完成后，第一個寫請求的處理過程中需要讀取Map，這意味著只要Sniff完成后Map結(jié)果保證正確即可，而在Sniff過程中，Map更新不及時導(dǎo)致的不準(zhǔn)確是可接受的。根據(jù)這個細(xì)節(jié)，我們讓每個工作線程在TSD〔線程私有數(shù)據(jù)〕中緩存一個同類型的Map，形成圖6中的結(jié)構(gòu)。圖6Sniff深入優(yōu)化示意圖每個工作線程直接將Sniff數(shù)據(jù)更新到線程私有的Map中，這個過程不需要鎖保護(hù)，當(dāng)TSD中會聚的數(shù)據(jù)超過一定規(guī)模，或者數(shù)據(jù)沉淀了一定時間后再提交到無鎖隊列中，這樣此前每個數(shù)據(jù)進(jìn)一次無鎖隊列變成批量數(shù)據(jù)進(jìn)一次隊列，效率明顯提升。當(dāng)然這里也產(chǎn)生一個新問題，Map進(jìn)入無鎖隊列是由前端Sniff數(shù)據(jù)驅(qū)動的，當(dāng)Sniff完成時，前端再無數(shù)據(jù)驅(qū)動，TSD中可能滯留了一批“漂浮”數(shù)據(jù)無法提交到隊列中，影響最終結(jié)果的準(zhǔn)確性，這里我們引入一個超時線程來解決這個問題。最終優(yōu)化完成后，Sniff在數(shù)分鐘內(nèi)完成?？偨Y(jié)與展望經(jīng)過這一輪優(yōu)化，MasterIOPS有數(shù)倍提升，冷啟動時間大幅縮減，取得了良好效果。優(yōu)化過程中我們形成了如下一些共識，希望能對后續(xù)工作有所指導(dǎo)。堅持用數(shù)據(jù)來確認(rèn)瓶頸。一個點是不是瓶頸，是否需要優(yōu)化，這是一個根本的方向性問題。可以大膽猜測，但一定要用數(shù)據(jù)來確認(rèn)具體的瓶頸，否那么方向性問題搞錯了，會導(dǎo)致后續(xù)在非關(guān)鍵路徑上浪費大量資源。密切結(jié)合業(yè)務(wù)邏輯。很多時候系統(tǒng)的優(yōu)化不是一個簡單的計算機(jī)科學(xué)領(lǐng)域問題，而是與業(yè)務(wù)邏輯高度相關(guān)，結(jié)合業(yè)務(wù)邏輯特點進(jìn)行優(yōu)化，往往會事半功倍。追求極致。在到達(dá)預(yù)期目標(biāo)后，再問問自己是否到達(dá)了理論極限？是否還有潛力可挖？有時候多走一步，性能可能會有質(zhì)的飛躍。性能優(yōu)化不僅僅是一項工作，更是一種鍥而不舍、精益求精的態(tài)度，優(yōu)化沒有終點，我們一直在路上！走近伏羲，談5000節(jié)點集群調(diào)度與性能優(yōu)化發(fā)表于2014-09-2712:41|

2333次閱讀|來源未知|

2

條評論|作者陶陽宇伏羲阿里云摘要：5K工程是飛天平臺的里程碑，系統(tǒng)在規(guī)模、性能和容錯方面都得到了飛躍式的開展，到達(dá)世界領(lǐng)先水平。伏羲作為飛天平臺的分布式調(diào)度系統(tǒng)，能支持單集群5000節(jié)點，并發(fā)運行10000作業(yè)，30分鐘完成100TB數(shù)據(jù)Terasort，性能是當(dāng)時Yahoo!在SortBenchmark上世界紀(jì)錄的兩倍。5K工程是飛天平臺的里程碑，系統(tǒng)在規(guī)模、性能和容錯方面都得到了飛躍式的開展，到達(dá)世界領(lǐng)先水平。伏羲作為飛天平臺的分布式調(diào)度系統(tǒng)，能支持單集群5000節(jié)點，并發(fā)運行10000作業(yè)，30分鐘完成100TB數(shù)據(jù)Terasort，性能是當(dāng)時Yahoo!在SortBenchmark上世界紀(jì)錄的兩倍。伏羲介紹“飛天”是阿里巴巴的云計算平臺，其中的分布式調(diào)度系統(tǒng)被命名為“伏羲”〔代碼名稱Fuxi〕，名字來自我國古代神話人物。伏羲主要負(fù)責(zé)管理集群的機(jī)器資源和調(diào)度并發(fā)的計算任務(wù)，目前支持離線數(shù)據(jù)處理〔DAGJob〕和在線效勞〔Service〕，為上層分布式應(yīng)用如ODPS/OSS/OTS提供穩(wěn)定、高效、平安的資源管理和任務(wù)調(diào)度效勞，為阿里巴巴集團(tuán)打造數(shù)據(jù)分享第一平臺的目標(biāo)提供了強(qiáng)大的計算引擎。伏羲系統(tǒng)設(shè)計上采用M/S架構(gòu)〔如圖1所示〕，系統(tǒng)有一個被稱為“伏羲Master”的集群控制中心，其余每臺機(jī)器上會運行一個叫做“伏羲Agent”的守護(hù)進(jìn)程，守護(hù)進(jìn)程除了管理節(jié)點上運行的任務(wù)外，還負(fù)責(zé)收集該節(jié)點上的資源使用情況，并將之匯報給控制中心。控制中心與伏羲Agent之間使用心跳機(jī)制，以監(jiān)測節(jié)點健康狀態(tài)。當(dāng)用戶向伏羲Master提交一個任務(wù)時，伏羲Master會調(diào)度出一個可用節(jié)點在其上啟動任務(wù)的主控進(jìn)程AppMaster，主控進(jìn)程隨后會向伏羲Master提出資源請求，得到伏羲Master分配的資源后，AppMaster通知相應(yīng)節(jié)點上的伏羲Agent開始運行任務(wù)Worker。伏羲是一個支持多任務(wù)并發(fā)的調(diào)度系統(tǒng)，控制中心伏羲Master負(fù)責(zé)在多個任務(wù)之間仲裁，支持優(yōu)先級、資源Quota配額和搶占。使用伏羲，用戶可以運行常見的MapReduce任務(wù)，還可以托管在線效勞，滿足不同應(yīng)用場景的需求。多用戶可以共享集群，伏羲支持配置分組的資源配額，限定每個用戶組可以使用的計算資源。緊急任務(wù)如重要數(shù)據(jù)報表可以提高任務(wù)優(yōu)先級來優(yōu)先使用計算資源。5K帶來的挑戰(zhàn)在5K工程攻堅過程中，我們看到大型云計算平臺從設(shè)計到實現(xiàn)每一步都可能存在性能“陷阱”，原因主要有三個方面：規(guī)模放大效應(yīng)，當(dāng)系統(tǒng)擴(kuò)展到數(shù)千節(jié)點時，原本非瓶頸與規(guī)模成正比的環(huán)節(jié)，其影響會被放大；木桶效應(yīng)，很多時候，系統(tǒng)中99%的地方都被優(yōu)化過，完成剩下1%的優(yōu)化看起來也只是“錦上添花”，然而那1%很可能就會成為影響系統(tǒng)性能的致命的瓶頸；長路徑模塊依賴，有些請求處理過程可能需要跨越多個模塊〔包括外部模塊〕，而外部模塊性能的不穩(wěn)定性最終可能會影響到這個請求的處理性能和穩(wěn)定性。5K工程是一場全方位戰(zhàn)役，給伏羲系統(tǒng)帶來規(guī)模、性能、穩(wěn)定、運維等多方面的技術(shù)挑戰(zhàn)，例如下面的性能“陷阱”?！鐾ㄐ畔DoS：在5000規(guī)模的集群中，不同進(jìn)程之間的RPC請求數(shù)量會隨規(guī)模猛增，網(wǎng)絡(luò)中總請求數(shù)可達(dá)10000QPS，極易造成系統(tǒng)中單點進(jìn)程的消息擁塞，從而導(dǎo)致請求處理嚴(yán)重超時。另外消