作為“云計(jì)算”的一個(gè)普通開發(fā)者和是推廣者，我們所要談?wù)摰牟皇巧虡I(yè)領(lǐng)袖們所熱衷的云計(jì)算概念、云計(jì)算市場(chǎng)，而是想討論技術(shù)人員眼中云計(jì)算具體形態(tài)和切實(shí)的實(shí)現(xiàn)辦法。我們將從需求分析入手、進(jìn)而討論設(shè)計(jì)理念、再具體化到子系統(tǒng)設(shè)計(jì)和實(shí)現(xiàn)中存在的難點(diǎn)問(wèn)題、最后談?wù)勗朴?jì)算對(duì)外服務(wù)的技術(shù)選擇。其中有些觀點(diǎn)屬于業(yè)界共識(shí)，也不少屬于個(gè)人看法——難免有所偏頗——真誠(chéng)歡迎從事云計(jì)算開發(fā)的朋友積極討論和批評(píng)。

　　本文試圖回答這么幾么幾問(wèn)題：

　　1. 技術(shù)人員理想的云計(jì)算是什么。

　　2. 理想和現(xiàn)實(shí)的鴻溝是什么。

　　3. 云計(jì)算到底需要什么樣的基礎(chǔ)架構(gòu)。

　　4. 云計(jì)算基礎(chǔ)架構(gòu)可能的組成部分。

　　5. 虛擬機(jī)和App engine等云計(jì)算的關(guān)系。

　　強(qiáng)調(diào)一下——本文僅以開發(fā)人員視角出發(fā)!以大中型互聯(lián)網(wǎng)公司、海量數(shù)據(jù)、多業(yè)務(wù)線運(yùn)維為背景，圍繞后臺(tái)基礎(chǔ)架構(gòu)進(jìn)行分析討論。

　　我們到底要什么云

　　現(xiàn)在的麻煩

　　談理想之前先回顧當(dāng)前現(xiàn)實(shí)中RD(開發(fā)人員)和OP(運(yùn)維人員)的工作場(chǎng)景。作為一個(gè)”過(guò)來(lái)人”，分析一下RD和OP在開發(fā)、測(cè)試、部署一個(gè)新應(yīng)用時(shí)不得不做的那些麻煩事吧。

　　開發(fā)階段面對(duì)的麻煩：

Ø 可用性問(wèn)題—— 互聯(lián)網(wǎng)應(yīng)用作為在線服務(wù)都希望能用永遠(yuǎn)在線;而從成本考慮，規(guī)模使用廉價(jià)PC SERVER、廉價(jià)硬盤、廉價(jià)路由器等必然有會(huì)出現(xiàn)相對(duì)較高的故障率，甚至可以說(shuō)故障是常態(tài)，因此從應(yīng)用設(shè)計(jì)上必須考慮故障切換，而且最好是自動(dòng)透明的故障切換。

Ø 負(fù)載均衡問(wèn)題—— 無(wú)論存儲(chǔ)集群或者是應(yīng)用服務(wù)集群等都可能出現(xiàn)負(fù)載不均勻情況。同一集群中因種種原因總是會(huì)有熱點(diǎn)(因?yàn)樵L問(wèn)壓力大而造成的或磁盤空間不夠、或內(nèi)存不足、或cpu負(fù)載太高、或網(wǎng)絡(luò)帶寬不足)出現(xiàn)，當(dāng)熱點(diǎn)出現(xiàn)時(shí)，就需要將熱點(diǎn)的訪問(wèn)流量分流到比較冷的服務(wù)器上去。總之希望集群中的服務(wù)器冷熱均勻，服務(wù)才能穩(wěn)定、高效。

　　Ø 擴(kuò)容縮容—— 當(dāng)你的應(yīng)用用戶越來(lái)越多時(shí)，就要有擴(kuò)容要求(集群中補(bǔ)充新機(jī)器)，擴(kuò)容時(shí)最好能不停或者少停服務(wù)。

　　上面這些問(wèn)題，其實(shí)是分布系統(tǒng)的普遍共性問(wèn)題，解決辦法無(wú)非是采用supervisor、主從熱備、smartclient、狀態(tài)報(bào)告、一致性哈希、數(shù)據(jù)分區(qū)等等技術(shù)，兵來(lái)降擋，水來(lái)土掩的case by case的解決。

　　作為一個(gè)在線應(yīng)用RD，很可能在處理上述問(wèn)題花的功夫，比自己應(yīng)用邏輯本身的還要多不少，這顯然是一個(gè)不小的負(fù)擔(dān)。

　　測(cè)試階段面臨的麻煩

　　測(cè)試首先在于搭建環(huán)境和系統(tǒng)部署。這點(diǎn)說(shuō)起來(lái)簡(jiǎn)單，其實(shí)現(xiàn)實(shí)操作中可夠你折騰一陣了。因?yàn)槟悴坏貌蛔觯?/strong>

　　Ø 搶到足夠多的機(jī)器—— 你很可能要排隊(duì)、要求人、總之要費(fèi)點(diǎn)點(diǎn)功夫。

　　Ø 搭建存儲(chǔ)服務(wù)—— 應(yīng)用開發(fā)人員對(duì)存儲(chǔ)系統(tǒng)各種配置參數(shù)和部署方式的理解和摸索過(guò)程，絕對(duì)是一個(gè)常犯錯(cuò)誤，窩工活。

　　這個(gè)過(guò)程對(duì)很多RD和測(cè)試人員來(lái)說(shuō)，絕對(duì)比寫代碼要費(fèi)時(shí)費(fèi)力。溝通成本(公司大了，很多溝通都是跨部門的)不容小視呀。

　　部署的麻煩

Ø 容量規(guī)劃——個(gè)應(yīng)用上線前肯定需要根據(jù)經(jīng)驗(yàn)(或者拍腦袋)估算出未來(lái)一段時(shí)間內(nèi)系統(tǒng)面臨的負(fù)載。估算少了，肯定要面臨擴(kuò)容的風(fēng)險(xiǎn)，這無(wú)疑是自搬起石頭砸自己腳。再加上一些好大喜功的人類天性，應(yīng)用負(fù)責(zé)人肯定會(huì)滿打滿算的推算出最大可能的機(jī)器規(guī)模。

　　Ø 申請(qǐng)機(jī)器，搭建集群——申請(qǐng)機(jī)器意味著報(bào)計(jì)劃、等審批、等機(jī)器、走麻煩的流程(這很多都是經(jīng)理的事啦)。搭建集群則是RD和OP一起攜手完成(RD出上線步驟等，OP 實(shí)施)，這個(gè)過(guò)程要小心謹(jǐn)慎，需要不止一個(gè)人反復(fù)檢查(差勁點(diǎn)的應(yīng)用會(huì)是實(shí)例配置不統(tǒng)一，每個(gè)實(shí)例的配置都有所區(qū)別)，還常常需要RD陪同實(shí)施，總之絕對(duì)是個(gè)體力活。

　　Ø 備機(jī)準(zhǔn)備—— 很多應(yīng)用為了防止意外機(jī)器應(yīng)硬件故障(硬盤、主板、網(wǎng)卡、電源等壞了)下，能快速進(jìn)行故障恢復(fù)，還會(huì)搞一些備機(jī)，以防萬(wàn)一。這些機(jī)器純粹是養(yǎng)兵千日用兵一時(shí)。

　　任何一個(gè)自認(rèn)為重要的應(yīng)用都希望自己?jiǎn)为?dú)占領(lǐng)一個(gè)集群，如果和別人混合部署，害怕資源征用，自己被拖累。鑒于此原因一個(gè)應(yīng)用往往就意味者需要搭建1個(gè)以上集群(很可能存儲(chǔ)、或者其他服務(wù)都要單獨(dú)搭建一個(gè)集群為其使用)。應(yīng)用RD人員還好說(shuō)，為自己應(yīng)用搭建一次就OK了、存儲(chǔ)等基礎(chǔ)服務(wù)RD就要多搭建幾次，受點(diǎn)累了;而OP就更辛苦了，要不斷重復(fù)這些體力勞動(dòng)。

容量規(guī)劃和備機(jī)準(zhǔn)備多多少少會(huì)帶來(lái)物理資源的閑置，容量規(guī)劃意味著預(yù)先準(zhǔn)備未來(lái)一定時(shí)期內(nèi)都足以應(yīng)付請(qǐng)求壓力的足夠機(jī)器，那也就是說(shuō)初期用戶規(guī)模還沒(méi)上來(lái)前，壓力還不大時(shí)，集群中多余的機(jī)器或者每個(gè)機(jī)器上的多數(shù)資源都會(huì)被閑置。

　　上線后的麻煩

　　故障恢復(fù)——一旦出現(xiàn)物理故障，或者系統(tǒng)自動(dòng)FAILOVER做的不好情況下。但凡有機(jī)器異常，就有可能需要手動(dòng)或自動(dòng)(一般是手自一體的)進(jìn)行故障恢復(fù)了。這個(gè)時(shí)候如果是常見(jiàn)故障，OP則需要按照事先準(zhǔn)備的運(yùn)維預(yù)案進(jìn)行故障恢復(fù)。

　　OP最怕線上服務(wù)出現(xiàn)問(wèn)題，影響用戶訪問(wèn)。這種事故一旦碰到，就必須立刻響應(yīng)，不容有誤。如果不幸的OP碰到那些未能自動(dòng)透明的進(jìn)行故障恢復(fù)而倉(cāng)促上線的服務(wù)，那絕對(duì)夠喝一壺了。

　　一言以概之,困擾我們是:

　　ü 系統(tǒng)分布化帶來(lái)的麻煩

　　ü 反復(fù)溝通帶來(lái)的麻煩

　　ü 搭建環(huán)境帶來(lái)的麻煩

　　ü 資源浪費(fèi)(這點(diǎn)一般是大老板們關(guān)心的問(wèn)題)

　　我們憧憬的云計(jì)算

　　RD們真的希望能有一臺(tái)“超級(jí)計(jì)算機(jī)”，它大的有用不完的內(nèi)存和磁盤、有強(qiáng)大無(wú)比的計(jì)算能力、更有無(wú)限帶寬、而且還是永不宕機(jī)!!!

　　如果真有這么一臺(tái)超級(jí)計(jì)算機(jī)，那么我們開發(fā)程序就不用再去考慮什么分布化、什么機(jī)器故障、負(fù)載均衡等事啦;也不用費(fèi)神去申請(qǐng)機(jī)器，搭建集群(因?yàn)橘Y源無(wú)限嗎);甚至上線動(dòng)作都可省去，不再需要麻煩OP同學(xué)如縷破冰的部署程序，RD自己就能如同部署本機(jī)程序一樣簡(jiǎn)單的部署線上服務(wù)。

　　如果那樣就太酷斃了，應(yīng)用RD從此可以心無(wú)旁逸的投入到自己業(yè)務(wù)邏輯的開發(fā)中去，

　　徹底釋放自己的想象力了。

　　完美理想的破滅

　　OK ! 我們想要的已經(jīng)清楚了，那么當(dāng)今什么是否能有這樣的超級(jí)計(jì)算機(jī)呢?或者說(shuō)是否使用集群技術(shù)實(shí)現(xiàn)這種理想的超級(jí)計(jì)算機(jī)呢?答案是否定的!我們無(wú)法使用集群技術(shù)實(shí)現(xiàn)這樣的超級(jí)計(jì)算機(jī)。

否定的原因在于：1. 我們沒(méi)法將集群機(jī)器中的CPU計(jì)算代數(shù)相加，變成超級(jí)CPU(能做的只能是把任務(wù)分解，讓多個(gè)CPU并行計(jì)算罷了);2. 我們沒(méi)法將集群機(jī)器的內(nèi)存代數(shù)相加，變成超大內(nèi)存。千萬(wàn)別想著用我們普通以太網(wǎng)做共享內(nèi)存嘗試，要知道內(nèi)存帶寬(GB量級(jí))可要比網(wǎng)絡(luò)帶寬(MB量級(jí))高出好多個(gè)量級(jí);

　　次完美理想的再破滅

　　我們向現(xiàn)實(shí)第一次妥協(xié)，我們不求像寫單機(jī)程序那樣寫應(yīng)用了，我們將應(yīng)用請(qǐng)求分區(qū)處理，即將應(yīng)用請(qǐng)求按照給定規(guī)則劃分成多個(gè)處理單元，每個(gè)處理單元都下發(fā)到集群中的某臺(tái)機(jī)器上執(zhí)行—— 我們從理想的統(tǒng)一集中處理，變?yōu)?ldquo;化整為零分區(qū)并行處理”。

　　我們無(wú)法擁有資源無(wú)限的超級(jí)計(jì)算機(jī)來(lái)肆意開發(fā)程序，而是要遵循限制：

　　ü 必須在單機(jī)資源容量(尤其內(nèi)存)的顧慮下來(lái)開發(fā)服務(wù)程序——以求在集群中被并行處理。

　　ü 還必須給出分區(qū)規(guī)則——以求能化整為零，分區(qū)執(zhí)行。

然而我們?nèi)匀簧萃覀兛梢圆挥每紤]如何進(jìn)行分區(qū)、也不用考慮如何調(diào)度各子任務(wù)在集群中調(diào)度，不用考慮如何進(jìn)行故障遷移、不用考慮如何負(fù)載均衡、不用考慮擴(kuò)容縮容等分布系統(tǒng)的共性問(wèn)題;同時(shí)我們也奢望的程序上線自動(dòng)化(無(wú)需人工干預(yù))，即應(yīng)用可自動(dòng)在云環(huán)境中部署和自動(dòng)運(yùn)行的。至于如何分區(qū)、如何調(diào)度、何時(shí)擴(kuò)容等都交給“云”老大了。舉個(gè)例子，如果我們開發(fā)了一個(gè)key value系統(tǒng)，只要告訴“云老大”我們需要的分區(qū)規(guī)則(或者哈希打散、或者字典序分區(qū))則萬(wàn)事大吉了。

　　那么當(dāng)今什么是否能有這樣智能的云呢?答案還是否定的!我們還是無(wú)法真正實(shí)現(xiàn)這樣智能的云。為什么呢?

　　首先我們思索一下這種智能云如果存在，會(huì)隱含有那些具體要求：

　　Ø 規(guī)模足夠大 ——　足夠的規(guī)模的集群才配稱為云，才能提供認(rèn)我們?yōu)樗麨?，不用考慮無(wú)法獲取資源的情況(當(dāng)然不意味你可無(wú)限使用，可是要算錢的)。

　　Ø 支持共享　 —— 云可不是為了某一個(gè)應(yīng)用專門搭建的，它必然要支持各種千差萬(wàn)別的應(yīng)用服務(wù)同時(shí)運(yùn)行其中。

　　Ø 支持自動(dòng)分區(qū)、任務(wù)派發(fā)、啟動(dòng) —— 只要告訴分區(qū)規(guī)則，就能根據(jù)集群中資源情況，自動(dòng)對(duì)應(yīng)用服務(wù)進(jìn)行分區(qū)，并派發(fā)服務(wù)程序到合適節(jié)點(diǎn)機(jī)器上、然后自動(dòng)運(yùn)行服務(wù)。我們不需要具體指定該分多少區(qū)、該部署到那個(gè)機(jī)器上，也不用自己拷貝執(zhí)行程序和配置到目標(biāo)機(jī)器、也不用手動(dòng)去啟動(dòng)服務(wù)。

　　Ø 支持自動(dòng)故障切換—— 云應(yīng)該具備高可用性，任何在其中運(yùn)行的程序都應(yīng)該有可用性保證。所以云中任何“節(jié)點(diǎn)故障”的處理應(yīng)該能自動(dòng)實(shí)施故障切換;而且云中任何“應(yīng)用服務(wù)故障”也都應(yīng)該能獲得自動(dòng)故障切換的保障。應(yīng)用開發(fā)人員從此可高枕無(wú)憂了。

　　Ø 支持自動(dòng)擴(kuò)容—— 應(yīng)用服務(wù)當(dāng)壓力負(fù)載加大時(shí)，需要能不影響服務(wù)的前提下，自動(dòng)試試擴(kuò)容(獲得更多資源，運(yùn)行更多實(shí)例)。

　　Ø 支持負(fù)載均衡，智能調(diào)度——避免應(yīng)用所在實(shí)例中出現(xiàn)冷熱不均的情況。當(dāng)發(fā)生熱點(diǎn)時(shí)，可進(jìn)行分區(qū)再分區(qū)方式，變一個(gè)服務(wù)實(shí)例為多個(gè)服務(wù)實(shí)例，并將分出來(lái)的實(shí)例遷移到多個(gè)機(jī)器上運(yùn)行，從而消除熱點(diǎn)。

　　接下來(lái)的問(wèn)題應(yīng)該是：這些技術(shù)要求，從技術(shù)實(shí)現(xiàn)角度而言到底意味什么?實(shí)現(xiàn)難度到底在那里?

　　在我剛從事云基礎(chǔ)架構(gòu)設(shè)計(jì)開發(fā)時(shí)，對(duì)上述要求真可謂是信心百倍。甚至我們會(huì)有意炫耀式的掛載嘴邊的，無(wú)數(shù)次向別人吹噓。但事實(shí)教育了我，仰望星空，仍然要腳踏實(shí)地。我們展開來(lái)分析這些貌似理所當(dāng)然的一些技術(shù)點(diǎn)，在云計(jì)算實(shí)踐中會(huì)有那些困難制約我們。

　　應(yīng)用共享云資源之制約

　　不同用戶、不同特征的應(yīng)用在一起混合部署、同時(shí)運(yùn)行時(shí)候，相互之間需要保證“資源隔離”，這種隔離意味著避免相互資源爭(zhēng)用，否則同一機(jī)器上的不同程序服務(wù)必然相互影響，對(duì)資源的你爭(zhēng)我?jiàn)Z的情況下，服務(wù)性能必然發(fā)生抖動(dòng)，從而破壞我們?cè)S諾的SLA(服務(wù)質(zhì)量保證)—— 這也是為什么很多項(xiàng)目經(jīng)理，都怕和別人的應(yīng)用公用一個(gè)服務(wù)集群或存儲(chǔ)集群的原因。

資源隔離這個(gè)問(wèn)題，我們要深刻認(rèn)識(shí)，這點(diǎn)是實(shí)現(xiàn)大規(guī)模云計(jì)算面臨的一個(gè)普遍問(wèn)題(誰(shuí)也躲不開)。對(duì)于資源隔離這個(gè)共性問(wèn)題，自然前人研究過(guò)無(wú)數(shù)種解法: 內(nèi)存的預(yù)分區(qū)使用(如機(jī)器虛擬機(jī)XEN為domu預(yù)分配內(nèi)存)、CPU的分核(利用CPU Affinity性)和配額限制下的分時(shí)復(fù)用、磁盤的分盤器使用、網(wǎng)絡(luò)QOS等等。

　　但是很不幸的是—— 相對(duì)富足的資源(如CPU在當(dāng)前服務(wù)器中多數(shù)情況下大多屬于營(yíng)養(yǎng)過(guò)剩，供大于求)和可以分區(qū)使用資源(如MEM、磁盤容量都可按配額預(yù)先劃分給應(yīng)用)可以理想的做到資源隔離(或者說(shuō)應(yīng)用之間影響有限);可對(duì)于機(jī)器中緊缺資源，說(shuō)白了就是“IO資源”(磁盤I/O和網(wǎng)絡(luò)I/O)隔離效果就很不理想了。我們實(shí)驗(yàn)結(jié)果表明網(wǎng)卡QOS將損失近近一半帶寬，而磁盤QOS幾乎不能有效防止I/O爭(zhēng)用(兩個(gè)I/O密集型應(yīng)用在一起爭(zhēng)奪I/O依舊那么不可控制)。

　　因此當(dāng)前的技術(shù)條件下，你可借助內(nèi)核工具Cgroup(google放出來(lái)的一個(gè)內(nèi)核資源受控功能)，或用戶信號(hào)suspend\resume、自維護(hù)內(nèi)存池等等技術(shù)做到給應(yīng)用服務(wù)固定的CPU和內(nèi)存配額限制，但沒(méi)有太好方法多I/O進(jìn)行配額限制(至少?zèng)]很理想辦法)。所以我個(gè)人認(rèn)為要想解決I/O 爭(zhēng)用問(wèn)題，要么借助于新硬件的升級(jí)——萬(wàn)兆網(wǎng)絡(luò)代替千兆網(wǎng)絡(luò)、SSD代替IDE硬盤等——使得I/O資源變的相當(dāng)富足;要么就避免I/O密集性程序混合部署，也避免離線任務(wù)(多是I/O密集性任務(wù))和在線任務(wù)(尤其是有數(shù)據(jù)查詢的在線任務(wù)，key value 存儲(chǔ)服務(wù))混合部署，以防止I/O爭(zhēng)用給在線服務(wù)造成響應(yīng)延遲。

　　智能調(diào)度之制約

　　我們理想的調(diào)度意味著應(yīng)用服務(wù)程序可以在集群中任意資源夠用的機(jī)器上啟動(dòng)運(yùn)行，甚至更理想的是能不停服務(wù)的情況下，將應(yīng)用程序進(jìn)行機(jī)器間動(dòng)態(tài)遷移。

　　很顯然如若讓應(yīng)用程序可在任意機(jī)器上執(zhí)行，就要求應(yīng)用服務(wù)的“上下文狀態(tài)”不能持久化在本地磁盤，也不能從本地反持久化(總之不能依賴本地存儲(chǔ))——這就是常說(shuō)的無(wú)狀態(tài)。只有這樣才有可能實(shí)現(xiàn)程序的運(yùn)行和位置無(wú)關(guān)(即，和運(yùn)行其的宿主機(jī)無(wú)關(guān))，從而才能有智能調(diào)度的基礎(chǔ)。

　　“上下文”不持久化于本地，就要求云環(huán)境能提供存儲(chǔ)服務(wù)，以便各應(yīng)用的上下文能存儲(chǔ)分布式的、安全、高效的存儲(chǔ)在云中，但至于具體在那里，應(yīng)用不必也不想關(guān)心。

　　“上下文” 的定義是寬泛的，包括各種格式的存儲(chǔ)容器。比如Hbase應(yīng)用中，可以將是range server看作應(yīng)用服務(wù)，而數(shù)據(jù)就是它的上下文——被分布式得存放于HDFS之中，也正是因?yàn)檫@種上下文位置無(wú)關(guān)的設(shè)計(jì)，使得Rangeserver可以被智能調(diào)度。 同樣Hbase又被作為一個(gè)上下文存儲(chǔ)服務(wù)，供其他更多應(yīng)用服務(wù)使用，那么這些應(yīng)用服務(wù)也就和位置無(wú)關(guān)了。

　　作為一個(gè)云服務(wù)，應(yīng)該提供有：基于offset的類文件存儲(chǔ)系統(tǒng);key value存儲(chǔ)系統(tǒng);類似數(shù)據(jù)庫(kù)(SQL)存儲(chǔ)系統(tǒng);類似big table這種(No Sql)列存儲(chǔ)系統(tǒng);甚至可能的圖存儲(chǔ)等等。

　　不過(guò)這種上下文遠(yuǎn)程存儲(chǔ)實(shí)現(xiàn)在實(shí)踐中所面臨的最大挑戰(zhàn)是網(wǎng)絡(luò)帶寬不夠，一旦數(shù)據(jù)持久化的真實(shí)位置與提交、查詢的位置不在一個(gè)機(jī)器內(nèi)的情況發(fā)生，必然帶來(lái)

　　ü 響應(yīng)時(shí)間惡化。

　　ü 帶寬被大大占用。

仍以hbase為例，range server 接受客戶端提交的數(shù)據(jù)，然后當(dāng)數(shù)據(jù)在內(nèi)存中積攢到一定量后，再寫入到hdfs中，因?yàn)閔dfs的寫入優(yōu)先選擇最近的chunk server，而chunk server和range server是混合部署的，所以必然初期負(fù)責(zé)某個(gè)分區(qū)的range server與該分區(qū)落地的數(shù)據(jù)實(shí)際上是存儲(chǔ)都在同一個(gè)機(jī)器上(這就是hbase所謂的location相關(guān)性指標(biāo)此刻為%100)。但當(dāng)range server負(fù)責(zé)的分區(qū)數(shù)據(jù)過(guò)多，已至超過(guò)單機(jī)存儲(chǔ)量時(shí);或者range server發(fā)生了故障切換后被重新調(diào)度，則rangeserver 和對(duì)應(yīng)數(shù)據(jù)可能就不再在一個(gè)物理機(jī)器上時(shí)，顯然讀寫都必須多了一次跨機(jī)器交互——這種多余交互在千兆以太網(wǎng)環(huán)境下很可能要花去幾毫秒，對(duì)于強(qiáng)調(diào)響應(yīng)時(shí)間的在線應(yīng)用很可能是不可接受的。

　　跨機(jī)器帶來(lái)額外的帶寬占用毋庸置疑，更需要考慮的還有，因?yàn)樾阅茉騬ange server不可能每一條數(shù)據(jù)都寫透到hdfs中,而必須聚合起來(lái)到達(dá)一大批時(shí)才一次推到hdfs中(目的無(wú)非是減少網(wǎng)絡(luò)交互的消耗)。但是如果還沒(méi)有被推入hdfs之前，range server所在機(jī)器宕機(jī)則肯定要丟失數(shù)據(jù)了。所以為了防止丟失，range server需要在成批寫入hdfs之前，將提交請(qǐng)求先記錄下來(lái)(所謂editlog)，為安全和調(diào)度時(shí)效性原因(rangeserver故障后，需要立刻進(jìn)行故障切換)，也不能存儲(chǔ)于本地，而又是要存儲(chǔ)在遠(yuǎn)程(實(shí)際上是以append模式寫到hdfs中)。我們知道為了避免數(shù)據(jù)丟失，hfds存儲(chǔ)采用了多副本技術(shù)(一般3份)。因此一份數(shù)據(jù)從客戶端提交開始有可能需要在網(wǎng)絡(luò)中傳播7次(從客戶端到range server一份，range server寫editlog三份，range server聚合后到hdfs三份)。對(duì)于網(wǎng)絡(luò)的壓力可想而知，所以沒(méi)有一個(gè)超級(jí)強(qiáng)大的網(wǎng)絡(luò)基礎(chǔ)架構(gòu)休想這樣理想的實(shí)現(xiàn)所有上下文數(shù)據(jù)遠(yuǎn)程化。

很多公司都設(shè)想數(shù)據(jù)遠(yuǎn)程化，但這之前請(qǐng)先設(shè)計(jì)一個(gè)強(qiáng)大的網(wǎng)絡(luò)環(huán)境。谷歌網(wǎng)絡(luò)環(huán)境許諾“任何機(jī)器”之間都能達(dá)到500大B的傳送速度;而我們國(guó)內(nèi)又有幾家能保證這么快呢，可能500小b都不敢拍胸脯保證。

　　故障切換之制約

　　故障切換除了要求和智能調(diào)度一樣的"上下文數(shù)據(jù)遠(yuǎn)程化"意以外，還有一個(gè)很重要的要求——速度快，要做到對(duì)客戶端透明。

　　客戶端透明的一般要借助于Smart client和服務(wù)邏輯尋址技術(shù)。Smartclient是指服務(wù)端盡量無(wú)狀態(tài)(或者狀態(tài)在啟動(dòng)后可以重建)，而把智能放在客戶端實(shí)現(xiàn)。其中一個(gè)重要智能就是故障探測(cè)和故障切換;服務(wù)邏輯尋址是說(shuō)尋址過(guò)程不再直接使用具體Ip尋址，而是使用一個(gè)邏輯名稱表示某個(gè)服務(wù)實(shí)例(邏輯名稱對(duì)應(yīng)實(shí)際的ip屬于系統(tǒng)全局信息)。Client根據(jù)邏輯地址查詢系統(tǒng)全局信息，獲得具體Ip地址，從而進(jìn)行訪問(wèn)。當(dāng)服務(wù)發(fā)生故障，進(jìn)行故障切換后，系統(tǒng)刷新該全局信息。而client發(fā)現(xiàn)原Ip地址訪問(wèn)失效后，則從系統(tǒng)全局信息處重新獲取給定邏輯地址對(duì)應(yīng)的Ip地址，重新進(jìn)行連接并訪問(wèn) ——透明的完成故障切換。

　　全局信息維護(hù)并非難事，主要是考慮高可用性。不過(guò)這方面已經(jīng)有很多成功辦法了。如erlang有Globe 模塊提供全局注冊(cè)名、zookeeper等服務(wù)也可作為配置中心存放這種全局信息。

　　回頭來(lái)說(shuō)切換速度的問(wèn)題。切換速度取決于幾個(gè)方面

　　{故障發(fā)現(xiàn)+ 應(yīng)用服務(wù)重啟后構(gòu)建上下文｝

故障發(fā)現(xiàn)看似簡(jiǎn)單，其實(shí)是個(gè)錯(cuò)誤多發(fā)區(qū)，而且也沒(méi)太好解決辦法。分布系統(tǒng)故障有機(jī)器故障、服務(wù)故障、網(wǎng)絡(luò)故障(還有包括該死的網(wǎng)絡(luò)分區(qū)故障)。故障發(fā)現(xiàn)一般依外部watch dog監(jiān)控、心跳等機(jī)制、或者外部搶鎖等機(jī)制。但不管如何判斷都要是要一定時(shí)間的，因?yàn)樾枰獮榱朔乐辜偎狼闆r——一旦發(fā)生服務(wù)假死，而發(fā)生故障切換，就會(huì)出現(xiàn)雙主并存而引發(fā)數(shù)據(jù)錯(cuò)亂等等麻煩——所以往往需要一個(gè)確認(rèn)時(shí)間(或者租約到期，或者是提升版本確認(rèn)新主)。另外，上下文重建也需要時(shí)間，比如key value服務(wù)或range server等服務(wù)可能需要加載一些索引進(jìn)內(nèi)存，才能開始提供服務(wù)，那么這個(gè)加載動(dòng)作根據(jù)數(shù)量級(jí)不同而不同，數(shù)據(jù)多時(shí)，甚至需要數(shù)分鐘才能完成。

　　我們要心知肚明——這些故障切換耗時(shí)并非所有應(yīng)用都能接受，有些應(yīng)用可能根本無(wú)法容忍分鐘級(jí)別的切換時(shí)間(記得亞馬遜的傳奇論文dynamo就是一個(gè)要求always writeable的產(chǎn)品)。這種應(yīng)用實(shí)際上并不合適采用上述的準(zhǔn)實(shí)時(shí)故障切換策略，而是需要采用熱備、熱切、多提交點(diǎn)等架構(gòu)才能得意滿足。

　　調(diào)度以及負(fù)載均衡的制約

　　master-slave模式的分布系統(tǒng)應(yīng)用中，master的職能一般包含元數(shù)據(jù)管理、接受用戶命令并下發(fā)給slave、還有就是負(fù)載均衡、故障切換等了?？傊中詣?dòng)作一般都需要 由master參與處理。

　　智能云老大要想使用統(tǒng)一的方式接管各種應(yīng)用的“負(fù)載均衡”和“故障切換”，也就是說(shuō)實(shí)現(xiàn)一個(gè)大Master負(fù)責(zé)所有應(yīng)用的負(fù)載均衡和故障切換。想法很好，但難免有寫天真。原因有二。

第一，應(yīng)用的負(fù)載均衡和故障切換未必能簡(jiǎn)單粗暴的使用一種模式完成。也就是說(shuō)不一定僅僅選一個(gè)資源(cpu、內(nèi)存、I/O)夠的機(jī)器就能可以遷移應(yīng)用，或者進(jìn)行恢復(fù)。很多應(yīng)用具有自己特殊的調(diào)度要求，比如有些應(yīng)用要求所有實(shí)例都處于一個(gè)路由器之下(如VM在線遷移)、或者要求必須不能處于同一機(jī)架(如DFS等)。

　　這種約束往往是case by case的，并不容易統(tǒng)一抽象出來(lái)。所以大Master方法對(duì)于各種約束是否能從容面對(duì)，是其一個(gè)很大挑戰(zhàn)!

　　第二，實(shí)時(shí)負(fù)載均衡就必須隨時(shí)掌握應(yīng)用實(shí)例的負(fù)載情況，也就是要不斷采集(很多信息是靠心跳消息報(bào)帶給master ) 應(yīng)用實(shí)例的各種負(fù)載指標(biāo)。采集越勤，調(diào)度越實(shí)時(shí)。但是高頻度采集狀態(tài)是有代價(jià)的，它必然會(huì)給大Master帶來(lái)不小負(fù)載(網(wǎng)絡(luò)帶寬負(fù)載、處理請(qǐng)求計(jì)算負(fù)載等)。所以全局性的狀態(tài)監(jiān)控是系統(tǒng)擴(kuò)展性的一大障礙，經(jīng)驗(yàn)數(shù)據(jù)是大Master大約監(jiān)視6000-10000個(gè)應(yīng)用實(shí)例的負(fù)載就是處理上線了，再大就很難調(diào)度管理了。

　　分區(qū)的制約

　　我們雖然很想把如何分區(qū)工作交給云來(lái)做，我們只用給出規(guī)則?？蓪?shí)現(xiàn)這個(gè)理想還是有些障礙的。

1. 這個(gè)規(guī)則描述上就有一定的難度。因?yàn)槊總€(gè)分布應(yīng)用往往都有自己的分區(qū)方式(其實(shí)就是我們所謂的7層負(fù)載均衡)，如hbase使用字典序分區(qū)(因?yàn)橐獙?shí)現(xiàn)按序檢索);memcache 則實(shí)現(xiàn)一致性哈希分區(qū)(隨機(jī)查詢);還有些應(yīng)用使用步長(zhǎng)式分區(qū);而更多應(yīng)用則有自己特殊的規(guī)則進(jìn)行分區(qū)，比如有些應(yīng)用按地域分區(qū)(美國(guó)的請(qǐng)求一個(gè)區(qū)、日本請(qǐng)求一個(gè)區(qū)等)、有的按用戶年齡、甚至還有的按照動(dòng)態(tài)負(fù)載進(jìn)行分區(qū)等等。

2 .除了規(guī)則難以統(tǒng)一外，更棘手的是：實(shí)例的資源分配量，云很難確定。如果錯(cuò)誤的資源配置很可能應(yīng)用實(shí)例無(wú)法使用—— 有些應(yīng)用會(huì)要求實(shí)例的最小資源配額(如有些服務(wù)要加載巨大的字典表，就必須要有足夠的內(nèi)存才能完成);而有些應(yīng)用實(shí)例更會(huì)因?yàn)榉謪^(qū)大小的不同對(duì)資源的要求也不同(分區(qū)越大資源要求越大，但比例關(guān)系并非線性，所以不好確定)。

　　3 .剩下的麻煩就是擴(kuò)容時(shí)如何將分區(qū)再劈開呢? 字典序列、一致性哈希等還算好劈開，按地點(diǎn)則難度就麻煩些了，要是分區(qū)規(guī)則更復(fù)雜，則劈分區(qū)也絕對(duì)是個(gè)有難度的事情了。

　　綜上所屬，就分區(qū)一事與調(diào)度、負(fù)載均衡一樣是個(gè)性化的東西，可謂各應(yīng)用蛇有蛇道，鼠有鼠道。真的很難做到一刀切的統(tǒng)一實(shí)現(xiàn)。

　　現(xiàn)實(shí)可能的云計(jì)算

　　上述分析后(我也實(shí)際實(shí)踐過(guò))，我們知道了現(xiàn)實(shí)環(huán)境的種種制約。我們不得不尊重現(xiàn)實(shí)，因此我們要重新定義我們智能云的職責(zé)功能了，重點(diǎn)是明確云的職能范圍(有所為，而有所不為!)。

　　強(qiáng)化資源管理職能

　　資源管理智能需要從下面幾個(gè)方面考慮：

　　Ø 沙箱容器

　　要想混合部署各種服務(wù)實(shí)例，我們自然希望有類似沙箱的容器，能把運(yùn)行實(shí)例“封”在其中，所謂封意思限制其資源使用。既包含有資源配額管理，也包含隔離意思。最徹底、但也是最重(為什么重，我們后面分析)的容器自然是機(jī)器虛擬機(jī)(machine virtual machine)、其次是系統(tǒng)虛擬機(jī)(system virtual machine);另外java 、perl、erlang等語(yǔ)言虛擬機(jī)也可算是不太合格的容器(封的不夠)。

但不要迷信虛擬機(jī)做容器，道理上講凡是能提供受限環(huán)境都屬于容器。容器實(shí)現(xiàn)并未有確切套路。比如一個(gè)C開發(fā)的基于事件(網(wǎng)絡(luò)io、信號(hào)、超時(shí)、甚至磁盤Io)驅(qū)動(dòng)的服務(wù)程序便可是一個(gè)很好的容器，它接管了所有事件處理，提供了一些標(biāo)準(zhǔn)的資源訪問(wèn)接口。任何應(yīng)用邏輯都將被實(shí)現(xiàn)為一個(gè)動(dòng)態(tài)庫(kù)，按需加載到該服務(wù)程序中，從而能通過(guò)自身實(shí)現(xiàn)的消息回調(diào)函數(shù)執(zhí)行具體的業(yè)務(wù)邏輯;同時(shí)對(duì)內(nèi)存、磁盤當(dāng)訪問(wèn)也都使用容器提供的特定接口完成，不再直接調(diào)用標(biāo)準(zhǔn)庫(kù)。如此資源使用、對(duì)外通訊都被容器所監(jiān)控——google 的app engine 就是類似這種實(shí)現(xiàn)的，不過(guò)不是借用了一些語(yǔ)言虛擬機(jī)的能力罷了。

　　如果應(yīng)用不情愿使用容器提供的資源接口，而是按傳統(tǒng)方式申請(qǐng)資源。那么從外部使用cgroup等手段也可達(dá)到資源配額管理的目的。

　　Ø 接管IO

只從容器限制應(yīng)用服務(wù)的資源還不夠，因?yàn)槿萜髦荒芸刂谱约罕旧淼馁Y源使用。但是對(duì)是整個(gè)機(jī)器的資源卻缺乏“全局控制”。若要從機(jī)器角度控制資源，不能僅靠容器，而應(yīng)該借助于獨(dú)立的駐機(jī)監(jiān)控程序完成。

　　Cgroup 實(shí)際上就是一個(gè)這樣的監(jiān)控程序(雖然實(shí)現(xiàn)于內(nèi)核)，它可以控制機(jī)器上所有程序的資源(cpu/mem)配額。

　　IO配額管理也同樣道理，需要單獨(dú)服務(wù)程序接管機(jī)器上所有程序的IO使用——即，代理所有IO請(qǐng)求。機(jī)器上所有其它服務(wù)程序都不能再擅自直接使用IO，而是將請(qǐng)求交給代理服務(wù)進(jìn)行;機(jī)器之間也不會(huì)存在服務(wù)socket直連，只可能是各自的代理服務(wù)socket連接(其實(shí)這也可減少socket連接資源占用)。

　　這樣做的好處是：代理服務(wù)能控制所有應(yīng)用服務(wù)的IO配額，從而避免資源爭(zhēng)用——壞處不用說(shuō)：IO流程被加長(zhǎng)，效率低了點(diǎn)。

　　注意，我們這里所說(shuō)的IO包括網(wǎng)絡(luò)IO，也包括磁盤IO。網(wǎng)絡(luò)IO代理可以做的類似于消息中間件，甚至可以實(shí)現(xiàn)點(diǎn)播、組播、廣播、故障切換等功能。磁盤IO代理則還要考慮管理多個(gè)磁盤的IO排隊(duì)，優(yōu)先級(jí)問(wèn)題等。

　　分區(qū)、調(diào)度策略、故障恢復(fù)等智能下放給應(yīng)用

　　上一個(gè)章節(jié)我們分析了應(yīng)用之間的差別性使得很難存在一個(gè)超級(jí)Master一刀切的處理各種應(yīng)用的分區(qū)、調(diào)度、故障恢復(fù)等還有“智能”的行為。尤其要認(rèn)識(shí)到越是基礎(chǔ)性的服務(wù)——尤其在線核心服務(wù)，其“智能”越強(qiáng)，因?yàn)槠淇捎眯缘纫笤絿?yán)格、設(shè)計(jì)也更具復(fù)雜性、也越難進(jìn)行統(tǒng)一方式管理。

　　比如，對(duì)于可用性要求比較寬松的應(yīng)用服務(wù)而言：Master探測(cè)到slave發(fā)生故障后，再重新再另外機(jī)器上啟動(dòng)一個(gè)新實(shí)例(可能還要重構(gòu)上下文)，然后再對(duì)外提供服務(wù)。這個(gè)時(shí)間很可能需要數(shù)分鐘之久(探測(cè)故障需要花時(shí)間、重啟實(shí)例需要時(shí)間、重構(gòu)上下文需要時(shí)間);

　　再高要求一些的應(yīng)用，備用實(shí)例可能預(yù)先啟動(dòng)好，所以切換時(shí)只需要重啟上下文(如hbase就是將故障分區(qū)交給其他在分區(qū)管理);

　　如果要求繼續(xù)加快故障切換時(shí)間，那么就需要使用熱備熱切方式了(所謂熱備份是指實(shí)時(shí)同步主備之間數(shù)據(jù)同步，保持同構(gòu)上下文)

　　如果這還不夠，那么就采用對(duì)等網(wǎng)結(jié)構(gòu)，也就是無(wú)主結(jié)構(gòu)(保證系統(tǒng)無(wú)單點(diǎn))?？蛻舳丝啥帱c(diǎn)提交，各點(diǎn)之間的一致性通過(guò)集中決策等技術(shù)保證(如dynamo系統(tǒng))

　　說(shuō)了這么多，無(wú)非是告訴大家，不要指望有一個(gè)超級(jí)智能的大Master能搞定應(yīng)用程序的各種智能，尤其是越重要的應(yīng)用越難接管。所謂人貴在有自知之明，當(dāng)我們熟悉互聯(lián)網(wǎng)應(yīng)用的復(fù)雜性后，就別再?gòu)?qiáng)求做大一統(tǒng)的Master了。不如退而求其次，放手將智能性的動(dòng)作下發(fā)給各個(gè)應(yīng)用服務(wù)本身把，因?yàn)橹挥兴麄冏约焊私庾约旱男枨蟆?/strong>

　　下放智能意味著各應(yīng)用可以有自己的Master來(lái)處理個(gè)性化的、“智能”高的需求，而智能低的需求當(dāng)然可以交出去統(tǒng)一完成了。

　　注：master傳統(tǒng)意義上負(fù)責(zé)那些職責(zé)(籠統(tǒng)概念，實(shí)際并非絕對(duì)如此，往往都是具備下述部分功能罷了)：

　　ü 負(fù)責(zé)存儲(chǔ)原數(shù)據(jù)——slave節(jié)點(diǎn)位置信息、各服務(wù)實(shí)例運(yùn)行配置?？傊菓?yīng)用之間的數(shù)據(jù)中心。

　　ü 負(fù)責(zé)管理命令——由于安全、以及元數(shù)據(jù)集中管理的原因，管理類命令一般只發(fā)給master,然后如果需要master再發(fā)向slave。

　　ü 負(fù)責(zé)數(shù)據(jù)分區(qū)和調(diào)度實(shí)例——化整為零的工作由master做。

　　ü 負(fù)責(zé)故障監(jiān)控——探測(cè)slave故障(如通過(guò)心跳)、并可做出故障切換。

　　ü 負(fù)責(zé)負(fù)載均衡——采樣負(fù)載信息(常通過(guò)心跳報(bào)實(shí)例負(fù)載)。

　　放棄統(tǒng)一的負(fù)載監(jiān)控、動(dòng)態(tài)調(diào)度

　　很多時(shí)候我們宣稱能削峰填谷式的使用集群中所有資源，可以根據(jù)集群中機(jī)器資源使用情況，動(dòng)態(tài)調(diào)度應(yīng)用實(shí)例。這樣不但可消除熱點(diǎn)，也能節(jié)約資源，因?yàn)閼?yīng)用實(shí)例可按需使用資源，不用的可以將資源還給大資源池。這種分時(shí)復(fù)用資源的方式無(wú)疑是很符合大老板的審美觀——似乎資源能被最有效的利用了。

　　但如果你多實(shí)施幾個(gè)大應(yīng)用，就會(huì)發(fā)現(xiàn)這么做不大現(xiàn)實(shí)。因?yàn)槟銜?huì)碰到如下幾個(gè)切實(shí)的障礙。

　　1. 監(jiān)控實(shí)例運(yùn)行態(tài)負(fù)載帶來(lái)的壓力。

　　監(jiān)控實(shí)例運(yùn)行狀態(tài)不是無(wú)代價(jià)的。監(jiān)控意味著需要頻繁對(duì)實(shí)例采樣和上報(bào)超級(jí)Master，上報(bào)必然要占用寶貴的網(wǎng)絡(luò)帶寬，尤其是要占用超級(jí)Master所在機(jī)器的帶寬(有時(shí)會(huì)利用前置衛(wèi)星機(jī)分擔(dān)Master壓力);而且超級(jí)Master還必須不斷記錄和隨時(shí)計(jì)算這些上報(bào)的負(fù)載信息。如果想盡可能及時(shí)發(fā)現(xiàn)負(fù)載變化，那么就要求盡可能頻繁負(fù)載采樣，從而給Master帶來(lái)更大傳輸和計(jì)算壓力。隨著越來(lái)越多的實(shí)例，Master將承擔(dān)越來(lái)越重的壓力，直到無(wú)法承受。

　　通常網(wǎng)絡(luò)環(huán)境(千兆以太網(wǎng))和機(jī)器情況(numa體系的8核路服務(wù)器)情況下，大概到6000-10000個(gè)實(shí)例(一個(gè)機(jī)器可運(yùn)行數(shù)個(gè)實(shí)例)就是監(jiān)控上限了，因此可見(jiàn)大Master方案本身對(duì)擴(kuò)展性就有制約。所以還是那句話，放棄大Master調(diào)度，各應(yīng)用的Master負(fù)責(zé)監(jiān)控自己應(yīng)用實(shí)例。

　　2. 調(diào)度代價(jià)太大

　　理想中當(dāng)發(fā)生熱點(diǎn)時(shí)，必須將肇事實(shí)例或相關(guān)實(shí)例遷移走。但遷移服務(wù)是有巨大代價(jià)的：

　　Ø 遷移很可能需要影響可用性

　　Ø 遷移很可能給網(wǎng)絡(luò)帶來(lái)壓力(重構(gòu)上下文需要網(wǎng)絡(luò)流量)

不過(guò)這些都不是最糾結(jié)的事，最糾結(jié)的是調(diào)度是否真的合理未嘗可知。因?yàn)槲覀冋{(diào)度無(wú)非是依靠曾經(jīng)的負(fù)載情況推斷未來(lái)的負(fù)載情況——當(dāng)發(fā)現(xiàn)眼前某個(gè)實(shí)例運(yùn)行資源不足時(shí)，需要找一個(gè)眼前和這一段時(shí)間負(fù)載都不重的機(jī)器，將實(shí)力遷移過(guò)去。但是眼前資源不足也許只是一個(gè)突發(fā)事件，而眼前和近一段時(shí)間負(fù)載輕的機(jī)器也許很快也將迎來(lái)自己的壓力高峰。如果調(diào)度碰到這種情況，就需要再重新調(diào)度，當(dāng)然還有可能又出現(xiàn)類似情況——這就是抖動(dòng)。如果這樣那反而不如不作為的好。

就一個(gè)公司而言，應(yīng)用數(shù)量有限，而且因?yàn)榈赜蛐曰蛘邞?yīng)用特性很有規(guī)律可循，那么負(fù)載規(guī)律也是有據(jù)可循的。有據(jù)可循自然容易合理調(diào)度(甚至可以制定完美的調(diào)度計(jì)劃——消峰填谷式的資源消耗不同類型應(yīng)用混合部署，也可差開時(shí)間段運(yùn)行不同類型應(yīng)用等)。但是當(dāng)你需要提供公共云服務(wù)時(shí)，天南地北、魚龍混雜的各種應(yīng)用就難說(shuō)負(fù)載有據(jù)可循了，發(fā)生調(diào)度抖動(dòng)的潛在危險(xiǎn)也將大大增加。因此與其去動(dòng)態(tài)調(diào)度，不如大方一點(diǎn)(不大方也不行呀)，給每個(gè)實(shí)例一個(gè)資源配置上限，即便運(yùn)行時(shí)資源利用不到上限，也不會(huì)讓別人占用——簡(jiǎn)而言之，實(shí)例資源不復(fù)用，讓實(shí)例霸占吧!!!。

　　現(xiàn)實(shí)中云計(jì)算大約的架構(gòu)

　　下來(lái)簡(jiǎn)要總結(jié)一下當(dāng)前業(yè)界所能接受和未來(lái)可能接受的云計(jì)算架構(gòu)。

　　數(shù)據(jù)總線(Data Bus)

　　我們?cè)噲D接管集群中所有的網(wǎng)絡(luò)IO請(qǐng)求，實(shí)現(xiàn)下述功能。

　　l 面向應(yīng)用的配額控制

　　l 優(yōu)先級(jí)控制

　　l 流控(滑動(dòng)窗口)

　　l 通訊故障處理

　　l 異步或同步消息

　　甚至可以將很多通用消息功能做到數(shù)據(jù)總線上：

　　l 點(diǎn)播、組播、廣播

　　l 負(fù)載均衡

　　消息總線實(shí)現(xiàn)和部署特點(diǎn)是：

　　1 數(shù)據(jù)總線是駐機(jī)后臺(tái)程序，每個(gè)機(jī)器理論上只部署一個(gè)。

　　2 數(shù)據(jù)總線服務(wù)程序兩兩之間只借助一個(gè)sock完成通訊，已節(jié)約連接資源。

　　分布式塊存儲(chǔ)

　　我們?cè)噲D將集群中機(jī)器所有磁盤都能通過(guò)網(wǎng)絡(luò)方式連為一體，形成存儲(chǔ)資源池。其目的在于：

　　1. 資源池化可防止局部存儲(chǔ)資源不足(單機(jī)存儲(chǔ)不夠)，使得資源利用最大化。

　　2. 存儲(chǔ)資源(磁盤存儲(chǔ))和計(jì)算資源和內(nèi)存資源剝離，從而解放任任務(wù)調(diào)度。

　　3. 接管所有的磁盤請(qǐng)求，原則不允許應(yīng)用直接訪問(wèn)本地磁盤。

　　4. 存儲(chǔ)高可用性，不比再擔(dān)心磁盤故障(多副本等冗余技術(shù)保證)

　　運(yùn)行容器

　　容器完全是個(gè)邏輯概念，虛擬機(jī)是容器(機(jī)器虛擬機(jī)，系統(tǒng)虛擬機(jī)，語(yǔ)言虛擬機(jī))，進(jìn)程也是容器。容器不在乎實(shí)現(xiàn)，而是在于是能做到應(yīng)用資源受限使用(重在內(nèi)容，不再形式)。關(guān)于容器詳細(xì)解釋見(jiàn)上文。

　　駐機(jī)精靈

　　說(shuō)白了就是一個(gè)系統(tǒng)默認(rèn)服務(wù)(系統(tǒng)安裝好就在其中，系統(tǒng)啟動(dòng)后就自動(dòng)運(yùn)行)。這個(gè)駐留精靈應(yīng)該具備一下功能：

　　1. 按要求下載指定應(yīng)用的應(yīng)用程序發(fā)布包

　　2. 對(duì)應(yīng)用程序運(yùn)行期管理——啟動(dòng)、關(guān)閉、暫停、恢復(fù)。注意當(dāng)發(fā)現(xiàn)應(yīng)用crash后，精靈往往要負(fù)責(zé)重啟，以提高系統(tǒng)可用性——這點(diǎn)可參看erlang的supervisor，都是類似的東西。

　　3. 對(duì)應(yīng)用程序資源配額限制——比如采用cgroup規(guī)定資源配額;或者監(jiān)控proc性能指標(biāo)而調(diào)整nice 、或通過(guò)suspend/resume信號(hào)控制程序運(yùn)行(好比輕點(diǎn)剎車一樣)?？傊椒ê芏?。

　　4. 匯報(bào)系統(tǒng)狀態(tài) —— 狀態(tài)包括有：靜態(tài)狀態(tài)(系統(tǒng)版本、機(jī)器資源等);應(yīng)用狀態(tài)(runing,crash等);機(jī)器和應(yīng)用負(fù)載(上文分析了負(fù)載可能會(huì)帶來(lái)性能問(wèn)題)。

　　資源分配中心

　　資源分配其實(shí)映射為程序運(yùn)行容器(可需可實(shí))的分配。資源分配中心要有集群中所有機(jī)器的資源信息和位置信息。當(dāng)有應(yīng)用需要運(yùn)行一個(gè)應(yīng)用實(shí)例時(shí)，就向該中新發(fā)出請(qǐng)求。中心從資源池中找一個(gè)能滿足需要的物理機(jī)，然后告知該機(jī)器上的駐機(jī)精靈去獲取該應(yīng)用的發(fā)布包，并按要求啟動(dòng)應(yīng)用實(shí)例。

　　上述是一個(gè)概要描述,具體實(shí)現(xiàn)可能要做如下幾個(gè)考慮：

1. 應(yīng)用和資源中心可協(xié)商資源(討價(jià)還價(jià))——比如應(yīng)用的master向中心要100個(gè)20G內(nèi)存的運(yùn)行容器，而中心發(fā)現(xiàn)資源池不足這么多可用容器，那么告訴只能給90個(gè)15G內(nèi)存的容器，你要不要? Master則根據(jù)具體情況，看是接受還是拒絕(如果可以將就著接受，那么master繼續(xù)啟動(dòng)，如果不能接受，則拒絕退出，不繼續(xù)不啟動(dòng))

2. 容器的資源請(qǐng)求可能受網(wǎng)絡(luò)環(huán)境、機(jī)架位置等約束。因?yàn)槌藘?nèi)存等資源要求外，有些應(yīng)用有要求機(jī)架感知要求(如HDFS)、或者有網(wǎng)絡(luò)布局要求(如要求在一個(gè)路由器下等——虛擬機(jī)動(dòng)態(tài)遷移往往需要統(tǒng)一路由器下，日次fake arp才能走通)。

3. 有時(shí)也能接管一些力所能及的負(fù)載均衡或故障切換等功能(注意，復(fù)雜的智能邏輯可做不來(lái)，應(yīng)該交給應(yīng)用自己的master處理)。當(dāng)然這要在應(yīng)用允許情況下(如發(fā)現(xiàn)機(jī)器起故障——精靈可報(bào)告，中心負(fù)責(zé)重新選擇一個(gè)新機(jī)器，再啟動(dòng)一個(gè)新容器，并重新運(yùn)行該實(shí)例)。

　　資源分配中心的存在為應(yīng)用部署、管理提供了很大方便。Google 內(nèi)部使用的borg就是這種系統(tǒng)的代表(對(duì)應(yīng)的駐機(jī)精靈叫borglet ——borg是德語(yǔ)城堡的意思，感覺(jué)不打貼切，不如我們?cè)?jīng)開發(fā)的matrix系統(tǒng)，對(duì)應(yīng)的祝機(jī)精靈叫smithJ)

　　另外值得注意的是應(yīng)用資源描述問(wèn)題!最高境界是開發(fā)一個(gè)描述性語(yǔ)言，做得簡(jiǎn)陋點(diǎn)就用XML、json等搞個(gè)配置文件，其中應(yīng)用資源被描述其中。資源描述應(yīng)該覆蓋如下方面：

　　ü 角色(如master ,slave)—— 一個(gè)應(yīng)用可能會(huì)包含多個(gè)角色(這點(diǎn)和erlang中一個(gè)relase 有多個(gè)application類似吧)

　　ü 角色實(shí)例的資源要求 ——內(nèi)存量、IO吞吐、CPU能力等等

　　ü 角色實(shí)例故障后是否重新啟動(dòng)——　如erlang 中superivsor選擇重啟的幾個(gè)方式

　　ü 角色的全局地址—— 類似于erlang的全局注冊(cè)名等，供別人訪問(wèn)

　　還有很多七七八八的限制等，如依賴服務(wù)、日志級(jí)別、性能計(jì)數(shù)等等，不再嘮叨了。

　　全局命名中心

　　為了對(duì)各應(yīng)用通訊尋址實(shí)現(xiàn)解耦目的，我們要避免應(yīng)用實(shí)例之間直接寫定對(duì)方IP和端口地址(如寫在配置文件中)來(lái)實(shí)現(xiàn)通訊。因?yàn)橹苯咏o定IP意味著各程序的運(yùn)行宿主機(jī)固定不變，也就意味著我們失去了服務(wù)遷移、故障切換等自由——意味著資源被綁定。

若要解開資源綁定，我們需要使用邏輯地址代替物理IP+端口方式尋址，而邏輯地址具體綁定那個(gè)物理地址則是可變的。比如應(yīng)用的邏輯地址(類似于一個(gè)URI)是http://myexample.master，其開始運(yùn)行在192.168.0.1機(jī)器上，這時(shí)邏輯地址http://myexample.master實(shí)際指向192.168.0.1(端口2000);但當(dāng)應(yīng)用被遷移到192.168.0.2機(jī)器上，這時(shí)同樣的邏輯地址http://myexample.master則又指向192.168.0.2(端口2000)了。

　　顯然上述的邏輯地址到實(shí)際物理地址的映射關(guān)系需要存儲(chǔ)在某個(gè)地方，這便是我們所謂的全局命名中心。實(shí)例之間只知道對(duì)方的邏輯地址，相互連接前都要詢問(wèn)該中心獲得真實(shí)的ip地址，然后才能進(jìn)行連接通訊。當(dāng)通訊失敗(很可能是被連接實(shí)例切換機(jī)器了)后，需要再重新去命名中心詢問(wèn)該邏輯名對(duì)應(yīng)的新物理地址，再重新連接——這種更新邏輯地址映射關(guān)系和實(shí)際連接則往往是客戶端負(fù)責(zé)的事情了。

　　Erlang 中的global模塊提供的進(jìn)程全局注冊(cè)服務(wù)，完成的就是類似功能，只不過(guò)erlang的global服務(wù)沒(méi)集中存儲(chǔ)這個(gè)命名關(guān)系，而是分布存儲(chǔ)在集群中了。

　　配置管理中心

　　配置中心為各應(yīng)用實(shí)例提供了一個(gè)配置信息的集中存儲(chǔ)地。所有應(yīng)用都可以將自己的配置信息，尤其一些動(dòng)態(tài)變化的配置信息(靜態(tài)一般就由配置文件管理)存儲(chǔ)在該配置中心中，從而能在需要時(shí)(如重啟后)從配置中心獲取對(duì)應(yīng)配置。

比如HBase中的range 分區(qū)信息和Range Server的位置信息都屬于動(dòng)態(tài)變化信息，這些信息傳統(tǒng)上是交給Master維護(hù)。但更合理的做法是將這些原信息存儲(chǔ)在統(tǒng)一的配置中心，如此以來(lái)即便使得即便Master倒掉，也可借助查詢配置中心獲得上述信息了—— 簡(jiǎn)單講，Master把原數(shù)據(jù)存儲(chǔ)功能交出來(lái)了，自己不再負(fù)責(zé)，因?yàn)樵獢?shù)據(jù)存儲(chǔ)智能要求不高，完全可以由一個(gè)通用服務(wù)——配置管理中心——負(fù)責(zé)。

　　分布式鎖

　　分布應(yīng)用中難免有需要串行化完成的動(dòng)作——任務(wù)需要有序執(zhí)行;或者有需要保護(hù)的臨界資源——一個(gè)時(shí)刻只能一個(gè)實(shí)例訪問(wèn)。

　　上述的鎖要求和線程鎖的需求很類似，不同無(wú)非是放大了執(zhí)行單位——從線程粒度變?yōu)閷?shí)例粒度。使用上遵循非強(qiáng)制鎖(協(xié)同鎖)的使用方式，即鎖被作為一個(gè)外部服務(wù)，只提供加減鎖以及檢測(cè)是否加鎖的操作，但是不提供鎖的控制與協(xié)調(diào)工作。依賴于各應(yīng)用自覺(jué)的去檢測(cè)是否加鎖，然后通過(guò)內(nèi)部協(xié)議來(lái)約束各實(shí)例的行為。比如bigtable使用分布鎖chubby完成表格防并發(fā)訪問(wèn),就是各實(shí)例自己負(fù)責(zé)訪問(wèn)前加鎖，訪問(wèn)后解鎖。

　　故障監(jiān)控服務(wù)

我們上面提到過(guò)Master的各種任務(wù)，其中有一點(diǎn)是負(fù)責(zé)監(jiān)控slave各節(jié)點(diǎn)是否正常。如果發(fā)生異常則要進(jìn)行故障切換等動(dòng)作。而具體狀態(tài)監(jiān)控則往往通過(guò)心跳等方式——當(dāng)發(fā)現(xiàn)slave出現(xiàn)連續(xù)幾個(gè)未報(bào)心跳時(shí)，則認(rèn)為slave發(fā)生故障。

　　顯然監(jiān)控狀態(tài)這點(diǎn)事，也屬于通用型功能，完全可以提出來(lái)由一個(gè)公共服務(wù)來(lái)完成。也就是實(shí)例的心跳都報(bào)向該心跳監(jiān)控服務(wù)，將故障探測(cè)這個(gè)臟活交給從我們特有的應(yīng)用中剝離出來(lái)。

　　除了簡(jiǎn)單監(jiān)控各實(shí)例死活外，可能還要將其死訊通知其伙伴才算有始有終——因此告知給定的”聯(lián)系人”也應(yīng)該是該服務(wù)所接管。

在分布系統(tǒng)中現(xiàn)嘗碰到故障時(shí)的主備切換(這里主從是active –non active關(guān)系，別和master/slave模式搞混淆)，完全可以交給上述監(jiān)控服務(wù)完成——當(dāng)發(fā)現(xiàn)主點(diǎn)倒閉后，則通知備機(jī)點(diǎn)變?yōu)橹?，完成故障切換。

　　另外，為了避免系統(tǒng)雙主出現(xiàn)(因?yàn)橥鼽c(diǎn)要求必須是邏輯單點(diǎn)，才能確保操作的串行化次序，所以如果系統(tǒng)出現(xiàn)雙主，那怕暫時(shí)，也則會(huì)造成的數(shù)據(jù)錯(cuò)亂)。因此各實(shí)例常常需要和監(jiān)控服務(wù)定一個(gè)租約協(xié)議：當(dāng)租約超期時(shí)，監(jiān)控服務(wù)負(fù)責(zé)通知備機(jī)(重新選主);租約到期的實(shí)例則自殺來(lái)防止系統(tǒng)雙主出現(xiàn)。

　　注意：

　　全局命名中心、配置管理中心、分布鎖服務(wù)等幾個(gè)服務(wù)作為全局服務(wù)都有一個(gè)毋庸置疑的要求——高可用性;另外一個(gè)共性則是還一定的存儲(chǔ)能力——存儲(chǔ)配置、命名等記錄信息、鎖記錄;最后一個(gè)共性是服務(wù)必須邏輯上單點(diǎn)(即便內(nèi)部用小集群實(shí)現(xiàn))，才能原子和串行處理請(qǐng)求事務(wù)。

　　我們必須感謝開源項(xiàng)目zookeeper(打心底敬佩yahoo公司、雖然它業(yè)務(wù)上最近不大景氣，但從其推出的zookeeper、S4等重量級(jí)的開源系統(tǒng)來(lái)看，無(wú)疑國(guó)內(nèi)公司還未有能達(dá)到其高度的，至少開源胸懷上還不能相比)，因?yàn)樗粴夂浅傻奶峁┝松鲜鋈齻€(gè)服務(wù)。

　　Ø 它采用Paoxs類協(xié)議實(shí)現(xiàn)了高可用性(容錯(cuò)率達(dá)到2F+1)，以小集群形式實(shí)現(xiàn)了邏輯單點(diǎn);

　　Ø 它采用樹形結(jié)構(gòu)存儲(chǔ)描述實(shí)現(xiàn)了配置存儲(chǔ)管理和分布鎖;

　　Ø 它采用租約協(xié)議實(shí)現(xiàn)了故障監(jiān)控(不需要我們自己實(shí)現(xiàn)心跳探測(cè))。

　　從而用一種架構(gòu)同時(shí)提供了上述幾種全局服務(wù)，逐步成為分布系統(tǒng)服務(wù)基石之一，越來(lái)越被業(yè)界所認(rèn)可—— 不少自視甚高公司最終都選擇zookeeper，放棄了自己獨(dú)自開發(fā)類似項(xiàng)目的想法和實(shí)踐。

不過(guò)要知道zookeeeper強(qiáng)于高可用性，而非存儲(chǔ)能力，雖然它確實(shí)可用來(lái)存儲(chǔ)一些配置類信息。但因?yàn)槿魏蜳aoxs協(xié)議需要在小集群中一致性協(xié)商，所以性能必然隨集群規(guī)模而下降，尤其是寫性能尤為如此。所以不要把zookeeper當(dāng)作key value服務(wù)那樣，進(jìn)行頻繁IO請(qǐng)求。如果你只是想找一個(gè)可靠的地方存儲(chǔ)你那些不大變化的元數(shù)據(jù)，那么選擇zookeeper無(wú)疑是明智之舉。比如很多時(shí)候我們將分布系統(tǒng)的第一層(最上層)原信息存放在zookeeper上，比如你可以將向?qū)dfs的namenode分布化——將第一層分布分區(qū)和位置信息存放在zookeeper之上。

　　各種結(jié)構(gòu)或半結(jié)構(gòu)化數(shù)據(jù)存儲(chǔ)

　　數(shù)十年來(lái)使用的關(guān)系型數(shù)據(jù)庫(kù)在當(dāng)今互聯(lián)網(wǎng)應(yīng)用場(chǎng)景下已經(jīng)顯得有點(diǎn)力不從心、或者說(shuō)不合時(shí)宜了。究其原因大約如下：

　　1. 擴(kuò)展性(scalability)不夠好。關(guān)系型數(shù)據(jù)庫(kù)實(shí)現(xiàn)上那些范式規(guī)則強(qiáng)調(diào)數(shù)據(jù)關(guān)系約束性，但在大規(guī)模分布系統(tǒng)上實(shí)現(xiàn)這些約束，顯然則不是很高效——性能不會(huì)很高。

　　2. 可用性不夠好。傳統(tǒng)上數(shù)據(jù)庫(kù)實(shí)現(xiàn)多采用專用機(jī)器或者說(shuō)將異常情況交給硬件處理，本身軟件層面錯(cuò)誤處理做的比較少(也就是主從備份等吧)。而互聯(lián)網(wǎng)世界中更多采用大量廉價(jià)存儲(chǔ)機(jī)器搭建起來(lái)，因此錯(cuò)誤更常態(tài)化，所以軟件要做更多的容錯(cuò)工作——多副本、故障切換等考慮要更多。

　　3. 數(shù)據(jù)組織方式不合時(shí)宜。關(guān)系型數(shù)據(jù)庫(kù)更合適處理離線的數(shù)據(jù)倉(cāng)庫(kù)這種復(fù)雜關(guān)系模型的統(tǒng)計(jì)、分析任務(wù)。而互聯(lián)網(wǎng)上面數(shù)據(jù)組織和查詢有所區(qū)別，具體來(lái)講：

　　Ø 可能需要?dú)v史版本。

　　Ø 可能關(guān)系性要求弱，而強(qiáng)調(diào)訪問(wèn)速度，因此可能需要進(jìn)行——空間換時(shí)間、反范式化、利用過(guò)濾代替jion、非精確查詢(允許少量錯(cuò)誤)等折中手段達(dá)到性能要求。

　　Ø 可能數(shù)據(jù)更稀疏，列訪問(wèn)特征突出。

　　Ø 可能需要圖元遍歷，比如廣度和深度遍歷好友等。

　　總而言之互聯(lián)網(wǎng)世界受歡迎的存儲(chǔ)系統(tǒng)(不敢稱數(shù)據(jù)庫(kù)系統(tǒng))會(huì)有：

　　l Key Value 存儲(chǔ) —— 代表作有dynoma (對(duì)等網(wǎng)實(shí)現(xiàn)) 、MemcacheDB、Tokyo Tyrant 等

　　l NoSql 存儲(chǔ) —— 代表作有Bigtable 、HBase 等。

他們最大共同特點(diǎn)是擴(kuò)展性很強(qiáng)、總體性能幾乎可以線性擴(kuò)展!弱點(diǎn)是和數(shù)據(jù)相比，關(guān)系特性要簡(jiǎn)單的多，key value不用說(shuō)，就是bigtable、Hbase等NoSql存儲(chǔ)也只是支持簡(jiǎn)單的select查詢，復(fù)雜join、事務(wù)操作、存儲(chǔ)過(guò)程等強(qiáng)關(guān)系操作都能不支持。

　　更重要的妥協(xié)還在于放棄了傳統(tǒng)數(shù)據(jù)庫(kù)的ACID(Atomicity(原子性)、Consistency(一致性)、Isolation(隔離性)、Durability(持久性))精髓;而去擁抱BASE(Basically Availble(基本可用)、Soft-state、EventualConsistency(最終一致性)) 和CAP(Consistenc(一致性)、Availability(可用性)、Tolerance of network Partition (分區(qū)容忍性——可理解為部分節(jié)點(diǎn)故障或節(jié)點(diǎn)之間連接故障下系統(tǒng)仍可正常工作)。

　　這種弱一致性妥協(xié)極大松綁了分布式存儲(chǔ)設(shè)計(jì)，雖然和完美主義要求有不小差距，但對(duì)互聯(lián)網(wǎng)世界來(lái)說(shuō)，夠了!!!

　　存儲(chǔ)的分層實(shí)現(xiàn)策略

如果能忍受性能上的一定損耗，我很贊同數(shù)據(jù)存儲(chǔ)的分層實(shí)現(xiàn)——即最下層是抽象類的塊存儲(chǔ)層，其上是分布類文件系統(tǒng)層，建立在其上的是結(jié)構(gòu)化和半結(jié)構(gòu)化數(shù)據(jù)存儲(chǔ)層—— 即hadoop中的ssFile，hdfs層和其上的hbase的關(guān)系(google 也是分層設(shè)計(jì)的擁戴者)。

　　所謂類文件系統(tǒng)層就是在用戶態(tài)實(shí)現(xiàn)的分布存儲(chǔ)系統(tǒng)，又為了方便管理實(shí)現(xiàn)了一些類文件操作的語(yǔ)意，如open/close/write/read/opendir等等。結(jié)構(gòu)化和半結(jié)構(gòu)化存儲(chǔ)層則是建立在類文件系統(tǒng)層之上，自己按需組織數(shù)據(jù)——數(shù)據(jù)又已文件形式存儲(chǔ)在類文件系統(tǒng)之上。

　　類文件系統(tǒng)這層負(fù)責(zé)所有集群磁盤資源管理：負(fù)責(zé)處理數(shù)據(jù)冗余存儲(chǔ)(多副本)、負(fù)責(zé)機(jī)器容錯(cuò)(故障切換)、負(fù)責(zé)負(fù)載均衡等等任務(wù)。而上層結(jié)構(gòu)化數(shù)據(jù)存儲(chǔ)層則不再關(guān)心這些特性，只需要處理具體的數(shù)據(jù)組織。這種分層實(shí)現(xiàn)避免了各種結(jié)構(gòu)數(shù)據(jù)存儲(chǔ)系統(tǒng)重復(fù)開發(fā)分布系統(tǒng)的通用特性，也很有利于運(yùn)維簡(jiǎn)單化。

　　另外值得一提的是我個(gè)人很贊同類文件系統(tǒng)層采用——只允許追加方式修改的設(shè)計(jì)，不允許隨機(jī)修改。因?yàn)檫@樣做帶來(lái)了好處很明顯：

　　ü 寫操作只會(huì)順序向前進(jìn)行，對(duì)于IDE硬盤而言，能提供更大的寫吞吐和寫響應(yīng)速度(對(duì)于SSD而言雖然沒(méi)有磁頭機(jī)械臂的移動(dòng)，但其實(shí)順序?qū)懸矔?huì)帶來(lái)巨大收益)

　　ü 不允許隨機(jī)修改，對(duì)于系統(tǒng)多副本一致性和故障后的反熵(同步各副本差異)操作帶來(lái)了很大遍歷，簡(jiǎn)化了很多。

當(dāng)然，如果下層的類文件系統(tǒng)只能追加寫，那么上層的結(jié)構(gòu)化存儲(chǔ)必然需要以log structure 方式實(shí)現(xiàn)。比如其上實(shí)現(xiàn)livedb那樣實(shí)現(xiàn)key value結(jié)構(gòu)存儲(chǔ);或者h(yuǎn)base那樣實(shí)現(xiàn)nosql結(jié)構(gòu)都是如此。Log structure 存儲(chǔ)系統(tǒng)實(shí)踐證明，性能沒(méi)問(wèn)題，而且很容易實(shí)現(xiàn)歷史版本查詢，還可實(shí)現(xiàn)快照等我們夢(mèng)寐的高級(jí)功能;其代價(jià)則是需要更多的磁盤空間(還好，當(dāng)前認(rèn)為最廉價(jià)的就是磁盤了)，還有經(jīng)常的垃圾回收(別怕，總有閑的時(shí)候讓你回收)。

　　重要思想重申

　　上面分析了似乎不少，其實(shí)各個(gè)部對(duì)于做分布式系統(tǒng)的朋友來(lái)說(shuō)都應(yīng)該都不陌生。只不過(guò)大家可能過(guò)去更多關(guān)心具體的分布應(yīng)用、或者分布存儲(chǔ)、或者調(diào)度等專用系統(tǒng)的設(shè)計(jì)開發(fā)中，而不大會(huì)上升到全公司甚至更大范疇的基礎(chǔ)架構(gòu)體系角度去考慮——如何消除重復(fù)勞動(dòng)、提高資源利用率。

　　所以思路的轉(zhuǎn)變是做云計(jì)算的首要前提——要從宏觀上考慮云計(jì)算實(shí)現(xiàn)，而不是一城一池的得失;其次從云計(jì)算技術(shù)上將其實(shí)并無(wú)太大躍變，其仍可看坐是分布存儲(chǔ)、并行計(jì)算等普遍技術(shù)的再升華——主要體現(xiàn)更強(qiáng)調(diào)大規(guī)模、強(qiáng)調(diào)普通硬件、強(qiáng)調(diào)低成本等。

　　明白上述兩點(diǎn)，就能除去云計(jì)算的神秘。這里我們回過(guò)頭來(lái)再重申幾個(gè)云計(jì)算架構(gòu)設(shè)計(jì)中的核心思想，我們把握這下面幾個(gè)主要原則，有所為有所不為。

　　Ø 分層劃分和實(shí)現(xiàn)功能

　　盡可能將系統(tǒng)分層設(shè)計(jì)(雖然會(huì)損失一定性能，但你得到的更多)，這樣每層能各司其職，非常有利于功能收斂、系統(tǒng)穩(wěn)定;減少重復(fù)勞動(dòng);便于調(diào)試;便于優(yōu)化;解耦等。只有再一個(gè)好的層次結(jié)構(gòu)下，系統(tǒng)才能有序演化。所以很建議將資源分配、塊存儲(chǔ)、類分布文件系統(tǒng)、結(jié)構(gòu)數(shù)據(jù)存儲(chǔ)等功能分層實(shí)現(xiàn)。

　　Ø 接管資源分配

盡可能接管一切資源分配工作，原因很簡(jiǎn)單——我們希望做類似超級(jí)計(jì)算機(jī)，那么就需要像單機(jī)操作系統(tǒng)那樣，在集群中接管資源分配：包括內(nèi)存、IO、存儲(chǔ)等。莫要讓用戶程序自己直接調(diào)用本地操作系統(tǒng)接口使用資源，以防止從全局角度失控。比如不要讓用戶自己直接寫本地磁盤，而是使用存儲(chǔ)服務(wù)操作;也不要讓不通機(jī)器程序自己直連，而是要委托消息中間件進(jìn)行連接。

　　Ø 應(yīng)用服務(wù)上下文分布存儲(chǔ)

　　為了達(dá)到準(zhǔn)實(shí)時(shí)的failover，以及按需調(diào)度服務(wù)等談性，就必須保證服務(wù)的上下文數(shù)據(jù)不能本地持久化，而要分布式持久化到遠(yuǎn)程,從而應(yīng)用運(yùn)行和位置無(wú)關(guān)。不怎么變的小數(shù)據(jù)可放在zookeeper中，大數(shù)據(jù)可借助于key value、hdfs、hbase等存儲(chǔ)。

　　Ø 化整為零管理

不要指望我們的云無(wú)所不能，無(wú)所不知;不要讓其做智能太高的事情，與其讓云告訴我們?cè)撟鍪裁?，不如我們告訴它該如何做。所以對(duì)于故障遷移、任務(wù)調(diào)度等差異性大、和應(yīng)用耦合性高的邏輯還是下方給應(yīng)用自己去管理吧。

　　對(duì)外服務(wù)該如何做呢

　　當(dāng)你真有了這么一套分布式體系架構(gòu)后(即便沒(méi)有也可以對(duì)外服務(wù)，只不過(guò)運(yùn)維成本很高罷了)，對(duì)內(nèi)服務(wù)搞定后(即便沒(méi)搞定也沒(méi)關(guān)系，對(duì)外也可以服務(wù)J——往往內(nèi)部阻力更大)，那么到底如何對(duì)外出賣服務(wù)呢?

　　在談服務(wù)方式之前，首先我們要清楚云計(jì)算服務(wù)的對(duì)象是誰(shuí)?服務(wù)包含那些內(nèi)容?

廣義上講任何互聯(lián)網(wǎng)服務(wù)都能納入云計(jì)算(至少他們這么宣傳)，為了不陷入茫茫云海，我們收斂一下，只談一下俠義的云計(jì)算——出賣計(jì)算能力、存儲(chǔ)能力;那么顯然我們的服務(wù)對(duì)象就是第三方互聯(lián)網(wǎng)公司或者個(gè)人應(yīng)用。

　　對(duì)外服務(wù)方式業(yè)界已經(jīng)有兩個(gè)案例供我們借鑒。一個(gè)代表是亞馬遜的EC2 (服務(wù)stack中還有simpledb，s3，消息中間件等等);一個(gè)是google為代表的app engine(服務(wù)stack中有HRD等)。前者是基于虛擬機(jī)容器為外界提供計(jì)算、存儲(chǔ)服務(wù);后者則是通過(guò)語(yǔ)言虛擬機(jī)+受限進(jìn)程容器對(duì)外提供計(jì)算和存儲(chǔ)服務(wù)。

　　到底孰優(yōu)?孰劣?

　　APP ENGINE 和 虛擬機(jī)比較

　　APP ENGINE 和虛擬機(jī)(我們這里專指機(jī)器虛擬機(jī)如xen/kvm)概念上應(yīng)該屬于一個(gè)范疇：資源沙盒;但實(shí)現(xiàn)差別很大。所謂尺有所長(zhǎng)，寸有所短。它們也一樣，各自有自己的優(yōu)勢(shì)，也有自己的不足。具體如何選擇，我們分析看看。

　　Ø 誰(shuí)更輕，誰(shuí)更重。

　　我們所謂輕是說(shuō)系統(tǒng)資源使用更少，更有利于資源復(fù)用。搞操作系統(tǒng)的人應(yīng)該都知道APP ENGINE 相比虛擬機(jī)更輕，原因很簡(jiǎn)單：

　　1. APP ENGINE不需要模擬硬件平臺(tái)，它作為宿主操作系統(tǒng)內(nèi)的進(jìn)程運(yùn)行;而XEN需要模擬硬件平臺(tái)，需要截獲敏感性硬件指令轉(zhuǎn)換處理，也需要運(yùn)行級(jí)上下文切換。

　　2. APP ENGINE 更有利于資源復(fù)用，因?yàn)槠洳恍枰A(yù)先霸占資源(主要是內(nèi)存資源)，而是按需使用(你甚至可以突發(fā)性使用整個(gè)機(jī)器的內(nèi)存);而XEN等虛擬機(jī)則需要預(yù)先霸占資源(雖然QOD等模式也開始學(xué)習(xí)按需使用內(nèi)存，但超限使用內(nèi)存還是很難——除非你愿意費(fèi)勁去采用熱插拔技術(shù);另外值得贊賞的是TMEM技術(shù)似乎可以避免預(yù)先霸占，但不幸的是它需要修改DOMU的內(nèi)核中的內(nèi)存分配例程)。

輕重就這些區(qū)別嗎? 其實(shí)不然，我個(gè)人認(rèn)為系統(tǒng)虛擬機(jī)最重的是對(duì)網(wǎng)絡(luò)資源(mac地址ip地址)的使用!系統(tǒng)虛擬機(jī)每個(gè)都會(huì)霸占一個(gè)mac和ip地址，別把村長(zhǎng)不當(dāng)干部，以為虛擬的網(wǎng)絡(luò)地址不是真實(shí)地址。對(duì)于路由器、交換機(jī)而言等網(wǎng)絡(luò)設(shè)備而言，它們?nèi)匀粫?huì)占用地址映射表等。一般路由器ip-mac表也就3000多項(xiàng)，用一個(gè)少一個(gè)所以大規(guī)模系統(tǒng)使用虛擬機(jī)勢(shì)必要定制更多表項(xiàng)的路由器;另外如果是大二層網(wǎng)中運(yùn)行眾多虛擬機(jī)，則廣播風(fēng)暴也是一個(gè)不得不考慮的麻煩。所以虛擬機(jī)對(duì)網(wǎng)絡(luò)設(shè)備來(lái)講更尤為“重。

　　Ø 誰(shuí)更友好，誰(shuí)更約束。

　　使用APP ENGINE的最大不便在于，你必須接受它的約束—— 資源訪問(wèn)需要按照其規(guī)定的接口進(jìn)行;不能自己?jiǎn)⑦M(jìn)程等。這種不便使得APP ENGINE多是被個(gè)人票友所熱衷，而公司用戶沒(méi)有幾個(gè)。公司若要使用APP Engine 則必須要修改自己已有程序、修改自己已有運(yùn)維方式、更糟糕的是開發(fā)人員培訓(xùn)或者招聘成本都要高很多(市場(chǎng)上找一個(gè)會(huì)Linux開發(fā)的人，要比找一個(gè)會(huì)app engine開發(fā)的人要容易的多)——當(dāng)然這些不利因素對(duì)于公司內(nèi)部使用到不存在，所以google自己內(nèi)部使用app engine到是可行(但我也聽說(shuō)gmail 也不再使用app engine了，難道內(nèi)部都推不開嗎?)

機(jī)器虛擬機(jī)則對(duì)用戶很是友好，所有程序都可以不加修改的運(yùn)行在機(jī)器虛擬機(jī)當(dāng)中，如果實(shí)現(xiàn)二層虛擬子網(wǎng)，那么已有的管理軟件都可原封不動(dòng)遷移過(guò)來(lái)——再次做一下廣告，我們cloudxy項(xiàng)目目標(biāo)之一就是實(shí)現(xiàn)二層子網(wǎng)虛擬化http://code.google.com/p/cloudxy/。所以對(duì)于用戶而言，他們顯然更喜歡機(jī)器虛擬化方式的云計(jì)算服務(wù)。亞馬遜在美國(guó)的成功也證明了這點(diǎn)——注意一下，在美國(guó)成功不代表在中國(guó)也能成功，畢竟互聯(lián)網(wǎng)在中國(guó)還是暴利，所以沒(méi)有多少像樣的企業(yè)為了節(jié)約目的而使用你虛擬機(jī)租賃服務(wù)，另外在當(dāng)今國(guó)內(nèi)環(huán)境中，也沒(méi)有幾個(gè)企業(yè)敢于把自己核心數(shù)據(jù)托管到別人提供的虛擬機(jī)之上。

　　注：

　　除了xen/kvm機(jī)器虛擬機(jī)外，還有zone，vps等系統(tǒng)虛擬機(jī)，以及jvm、python等語(yǔ)言虛擬機(jī)、進(jìn)程虛擬機(jī)qeum, 甚至普通進(jìn)程也可看虛擬機(jī)。從輕重角度將，機(jī)器虛擬機(jī)最重其次是系統(tǒng)虛擬機(jī);

　　云計(jì)算生態(tài)圈

　　下來(lái)說(shuō)的純粹是題外話了，都是個(gè)人觀點(diǎn)，不知所云：)

　　云計(jì)算如果僅僅是提供計(jì)算資源和存儲(chǔ)資源服務(wù)(如亞馬遜那樣),我個(gè)人認(rèn)為只是一個(gè)初級(jí)形態(tài)，而且在中國(guó)可能沒(méi)多大前途。

　　個(gè)人認(rèn)為真正理想的云計(jì)算應(yīng)該是一個(gè)“圍繞數(shù)據(jù)服務(wù)的生態(tài)圈”，在數(shù)據(jù)周圍應(yīng)聚集大量的第三方應(yīng)用—— 他們使用數(shù)據(jù)同時(shí)又產(chǎn)生數(shù)據(jù)，從而數(shù)據(jù)越來(lái)越多、越來(lái)越有序;應(yīng)用也越來(lái)越豐富、越來(lái)越專業(yè)——這就猶如滾雪球，良性循環(huán)，價(jià)值逐步放大。

　　偉大的企業(yè)一定是積累了足夠有價(jià)值的數(shù)據(jù)(網(wǎng)頁(yè)內(nèi)容、買賣記錄、用戶關(guān)系等都屬于數(shù)據(jù))。不管怎樣，要明白第三方企業(yè)入駐入你的云計(jì)算服務(wù)，首要是希望獲得你的數(shù)據(jù)或者流量(我認(rèn)為前者更重要)，而不是看重什么計(jì)算和存儲(chǔ)服務(wù)(互聯(lián)網(wǎng)暴利時(shí)代，機(jī)器成本目前還不是企業(yè)最緊迫的問(wèn)題)。但如果在你的云環(huán)境中更有利于他們獲得數(shù)據(jù)和流量，那他們自然而然會(huì)接受將服務(wù)hosting到你的云中。

　　以ebay為例來(lái)說(shuō)，長(zhǎng)期積累的交易記錄就是其最有價(jià)值的數(shù)據(jù)，這些數(shù)據(jù)準(zhǔn)確、有序、結(jié)構(gòu)化強(qiáng)，非常有利于檢索、分析;假若再結(jié)合交易者信息，個(gè)性化服務(wù)則是舉手之勞(如果不涉及隱私的話);另外它還有很強(qiáng)的入口作用。這些無(wú)疑都是吸引第三方應(yīng)用的重要因素，如果他們開放數(shù)據(jù)，有提供托管環(huán)境——托管環(huán)境中能更快訪問(wèn)其數(shù)據(jù)，甚至還能提供統(tǒng)一的支付、用戶認(rèn)證等服務(wù)，那么無(wú)疑第三方是愿意租用其計(jì)算和存儲(chǔ)服務(wù)的。而第三方應(yīng)用，尤其那些數(shù)據(jù)分析應(yīng)用所產(chǎn)生數(shù)據(jù)又可被其它應(yīng)用所使用，則就進(jìn)入了上面談到的滾雪球模式了：)

　　國(guó)內(nèi)的百度、騰訊、阿里、新浪微博等幾個(gè)大佬們都有自己的數(shù)據(jù)和入口地位。百度搜索入口能力強(qiáng)，結(jié)構(gòu)化數(shù)據(jù)弱一些，比較適合于咨詢類應(yīng)用;騰訊游戲/sns類入口能力強(qiáng)，用戶關(guān)系數(shù)據(jù)強(qiáng)，適合游戲類應(yīng)用;阿里電子商務(wù)內(nèi)入口能力強(qiáng)，結(jié)構(gòu)化商業(yè)數(shù)據(jù)豐富，適合于商務(wù)服務(wù)類應(yīng)用;新浪微博用戶極度活躍、消息產(chǎn)生和傳播優(yōu)勢(shì)明顯，也很適合做咨詢和游戲類應(yīng)用。所以這幾家做云計(jì)算成功可能性最大，希望他們能抓住機(jī)會(huì)，取得成功。

　　不成熟的幾個(gè)斷言

　　Ø 專用系統(tǒng)必然比通用系統(tǒng)性能更高

　　Ø 網(wǎng)絡(luò)帶寬是當(dāng)前云計(jì)算中的最短板

　　Ø 沒(méi)有能統(tǒng)一天下的云計(jì)算環(huán)境

　　Ø 云計(jì)算絕不等于虛擬機(jī)，虛擬機(jī)只不過(guò)是沙箱實(shí)現(xiàn)的一種。

　　Ø 絕對(duì)的實(shí)時(shí)調(diào)度難以在實(shí)際中做到，自動(dòng)化管理可以期待。

　　Ø 萬(wàn)兆網(wǎng)和SSD等新硬件的到來(lái)將帶來(lái)云計(jì)算架構(gòu)的變革。