前不久，一則中行宕機(jī)的消息引起了網(wǎng)上IT人士的熱議。其中對于大型機(jī)或者RISC系統(tǒng)的穩(wěn)定性可靠性的質(zhì)疑更是熱議中的主流聲音，很多人拿現(xiàn)在互聯(lián)網(wǎng)系統(tǒng)做對比，認(rèn)為大型機(jī)所謂的幾個9都是吹出來的云云。在這里我想說幾句公道話：首先，這次宕機(jī)到底是什么原因，什么形式的宕機(jī)我們都沒有很清楚的了解，在這種情況下就去評論大型機(jī)或者RISC系統(tǒng)的穩(wěn)定性或者可靠性其實都是不負(fù)責(zé)任，站不住腳的。但是，我覺得倒是可以基于這次的事件來稍微發(fā)散一下，說一說我對互聯(lián)網(wǎng)系統(tǒng)和傳統(tǒng)企業(yè)IT系統(tǒng)的一些看法和觀點。

現(xiàn)在被炒的很火熱的互聯(lián)網(wǎng)，云計算架構(gòu)，其相對于傳統(tǒng)的大型企業(yè)系統(tǒng)架構(gòu)，最大的區(qū)別就是以分布式的架構(gòu)去替代原先的集中式系統(tǒng)架構(gòu)。

打個比方，原先的大型企業(yè)系統(tǒng)架構(gòu)，就好像一架大型的民航客機(jī)。作為出行來講，飛機(jī)無疑是最舒適最快的交通工具，同時安全性也很好。但飛機(jī)卻也不是人人都能坐的。首先：做飛機(jī)要經(jīng)過換領(lǐng)登機(jī)牌，安檢等若干道手續(xù)，乘客必須提前一個多小時到機(jī)場辦理各種手續(xù)，而坐火車大巴則隨到隨買隨上車，方便的多；其次：坐飛機(jī)很多東西不能隨身攜帶甚至不能托運，火車大巴則相對寬松;還有：機(jī)票很貴坐飛機(jī)花銷很大而且飛機(jī)運載能力也不如火車。當(dāng)你有數(shù)萬數(shù)千人要一次性到達(dá)某地時，一兩架飛機(jī)的運載能力根本不夠，要調(diào)動成批飛機(jī)的話整體成本又太高。最后：雖然飛機(jī)很少出事故，飛機(jī)一旦出現(xiàn)事故的話危險級別往往都會很高。

但是，以前除了飛機(jī)之外，就只有火車，大巴這種交通方式選擇了。相比之下，這些方式雖然收費低廉，乘車，攜帶物品都比較方便，但是速度實在太慢而且受外界因素諸如雨雪等等的影響太大，乘坐也不是很舒適。只能滿足那些相對時間寬裕，或者囊中羞澀人群的出行需求。

于是，為了滿足更多人，更便利更高速的交通運輸需求，新的交通運輸模式—動車/高鐵就出現(xiàn)了。它和火車最大的區(qū)別是：火車只有一節(jié)車頭有動力，后面能拖幾節(jié)車廂跑多快基本就是看一個車頭有多強(qiáng)勁。但個體的力量終究有限，一個車頭再強(qiáng)勁也有個極限，發(fā)展空間也就那點了，實在難以有太大作為。動車則不同，它每節(jié)列車都獨立有自己的動力系統(tǒng)，連在一起各節(jié)車廂動力系統(tǒng)就是一個疊加遞增的關(guān)系。所以理論上越多節(jié)車廂接在一起就可以拉更多人跑的更快，是一個無限擴(kuò)展的系統(tǒng)!而且因為動車可以搭載的乘客很多，所以均攤到每個乘客頭上，坐動車的速度可以某種程度上接近坐飛機(jī)，但成本要低很多。

現(xiàn)在互聯(lián)網(wǎng)，云計算的系統(tǒng)架構(gòu)其實和動車的理念相類似，就是分布式系統(tǒng)的架構(gòu) – 將任務(wù)分解交由每個小計算單元進(jìn)行分布式的并行處理，充分利用每個單元的計算和存儲能力，理論上性能可以無限線性擴(kuò)展，任何一個節(jié)點的故障不影響整個系統(tǒng)的運行，整個系統(tǒng)沒有單點故障。

也就是說：我們可以簡單把大型企業(yè)核心架構(gòu)，或者說就是大型機(jī)，RISC系統(tǒng)比作飛機(jī);而把互聯(lián)網(wǎng)，云計算的系統(tǒng)架構(gòu)比作動車。現(xiàn)在，就可以做些很有意思的討論了。

還是來說說穩(wěn)定性和可靠性：就說2012年吧，飛機(jī)也好，動車也好，新聞里面都有報道過出現(xiàn)嚴(yán)重事故，可見沒有一種系統(tǒng)是完全穩(wěn)定可靠不會出現(xiàn)任何宕機(jī)風(fēng)險的，但是其概率都是非常非常小的。從整體來講，都是很穩(wěn)定很可靠很安全的選擇。只不過各自對于如何防災(zāi)冗余的策略還是有些不一樣。先說飛機(jī)，因為飛在空中，萬一出了事情沒有后備可用，所以能采取的方式只有想盡一切辦法提高飛機(jī)自身個部件的冗余度，設(shè)計時盡可能多的考慮各種小概率事件。哪怕發(fā)生某故障的概率只有千萬分之一甚至億萬分之一，只要有可能，也要把應(yīng)對措施設(shè)計進(jìn)去。這也是飛機(jī)造價為什么會那么高，對攜帶物的要求會那么多的原因。而動車則相對簡單：反正多拖幾節(jié)車廂又不影響我速度，那我就盡量多拖些備用車廂跑著唄。萬一某節(jié)車廂出事了，就把里面乘客挪到備用車廂里，車照樣跑得歡。然后等到了站再去更換檢查有問題車廂也不遲。

回到IT世界也是一樣。分布式系統(tǒng)基本都是基于x86的PC服務(wù)器。單就一臺服務(wù)器而言，雖然性能可靠性在不斷加強(qiáng)，但肯定還是不如RISC系統(tǒng)的。但是沒關(guān)系，咱可以用數(shù)量來彌補(bǔ)單機(jī)冗余度的不足啊。設(shè)計沒你好冗余度沒你考慮的多我就多拉幾臺唄。壞了幾臺沒事，應(yīng)用任務(wù)再分配到別的空閑機(jī)器上就好了。壞了的機(jī)器也不用馬上修，反正沒壞的機(jī)器加起來也夠用。等到故障機(jī)器到了一定數(shù)量我再一次性批量檢修更換部件效率更高。對于用戶來講，即使我壞了100來臺服務(wù)器只要剩下的服務(wù)器還能正常工作，應(yīng)用就不會受任何影響。谷歌，F(xiàn)acebook那些超大型數(shù)據(jù)中心現(xiàn)在的工作思路大致如此。這么做看起來是個很簡單有效，很聰明的方法，但其實也有不少問題存在。

首先我覺得這個架構(gòu)好處是實現(xiàn)原理簡單，而且擴(kuò)展性彈性比起RISC架構(gòu)來好處不言而喻。但其實這個架構(gòu)里面也存在著無謂的資源浪費可能性。例如拿存儲而言，目前Hadoop類的多副本分布式存儲很火。一份數(shù)據(jù)存三份，發(fā)現(xiàn)有數(shù)據(jù)損壞立即找空閑空間恢復(fù)。聽上去很簡單很容易實現(xiàn)很高效，但如果你真的坐下來仔細(xì)算算賬，你就會發(fā)現(xiàn)：

1. 當(dāng)你數(shù)據(jù)量不大(小于PB)的情況下這種一份數(shù)據(jù)存三份方式的成本其實比現(xiàn)有任何商業(yè)存儲方案的成本都要高。

2. 這種方式下每臺服務(wù)器的CPU利用率都很低，而現(xiàn)在市面上的大存儲容量服務(wù)器，CPU配置都很高。所以這種方式，基本上是對于CPU資源的一種浪費。所以，或許對于數(shù)據(jù)量適中的企業(yè)來說，用EC CODE這種以計算能力換存儲的分布式存儲解決方案會比多副本方案更經(jīng)濟(jì)實惠。

3. 這種方式很容易讓IT運維人員產(chǎn)生一種習(xí)慣性思維 – 即要提高系統(tǒng)在線時間就多買些服務(wù)器就好了。因為服務(wù)器多了分布性好了自然冗余度就高了。于是不必要的服務(wù)器采購就這么產(chǎn)生了，每個數(shù)據(jù)中心也就又多了很大一筆不是很必要的電費開銷。

其次，我覺得分布式架構(gòu)的某些故障很可能會產(chǎn)生連鎖效應(yīng)，導(dǎo)致更嚴(yán)重全局癱瘓。打個比方，大家都知道赤壁之戰(zhàn)的故事。里面有個很著名的橋段就是龐統(tǒng)獻(xiàn)連環(huán)計，鐵鎖連舟。起始時使曹操萬余戰(zhàn)船連成一體穩(wěn)如平地進(jìn)可攻退可守前后都可照應(yīng)看似完美，但唯有一個命門就是怕火攻。而諸葛亮周瑜正是利用這個命門，解東風(fēng)火燒赤壁把曹操百萬大軍殺的丟盔卸甲?；ヂ?lián)網(wǎng)的分布式架構(gòu)其實我覺得也有類似“命門”。大型機(jī)或者RISC系統(tǒng)之所以那么貴，其實很多時候用戶在為千萬分之一甚至億萬分之一的“萬一”買單。而互聯(lián)網(wǎng)，現(xiàn)在的公有云架構(gòu)，在設(shè)計之初，基本的考慮思路是大用戶，大并發(fā)，然后盡量減少TCO。所以很多時候，設(shè)計架構(gòu)時會先把那些“千萬分之一”排除在外，暫時不予考慮。而系統(tǒng)上線之后，穩(wěn)定運行一段時間用戶量暴漲，精力往往又會去專注擴(kuò)容方面了。搞不好就會把一些“命門”漏掉，于是乎萬一正好遇上“東風(fēng)”吹到了命門上，后果估計會比曹阿瞞更慘。因為IT世界里還沒有那么仁義的關(guān)云長會在華容道上放曹操一馬。

其實從最近Facebook，Amazon、谷歌的幾次宕機(jī)事件來看，已經(jīng)有些那個苗頭了。好在那些互聯(lián)網(wǎng)領(lǐng)頭羊們應(yīng)該是已經(jīng)意識到這些問題，已經(jīng)在積極修補(bǔ)“命門”了。

最后，我想說互聯(lián)網(wǎng)，云計算的業(yè)務(wù)類型其實和傳統(tǒng)企業(yè)的業(yè)務(wù)類型不一樣，所以大型機(jī)，RISC系統(tǒng)處理的任務(wù)，運行的計算并不一定都適合移植到分布式系統(tǒng)架構(gòu)上來。還是以交通運輸舉例：我要去美國，目前還是只有飛機(jī)可以滿足我的需求。當(dāng)然你可以說我坐動車也可以，無非是多轉(zhuǎn)幾趟跨國列車。但那畢竟很勉強(qiáng)，速度不快，費時費力還不省錢，毫無意義。人家直接飛過去就行了，你卻要繞著太平洋海岸線跑一個大圈來兜，何必呢?

那么以上這些問題有沒有辦法解決呢?其實我覺得解決以上問題的關(guān)鍵就是兩個字：運維。分布式系統(tǒng)，要保障其安全可靠的運行，合理有效的擴(kuò)容，關(guān)鍵不在系統(tǒng)的軟硬件，而是在系統(tǒng)搭建之后的運維和持續(xù)的對系統(tǒng)的改進(jìn)修正!現(xiàn)在網(wǎng)絡(luò)上很多人都在熱衷于各種開源架構(gòu)如openstack，Hadoop的開發(fā)，應(yīng)用場景探討。但個人以為這些開源系統(tǒng)的特點是搭建簡單，維護(hù)艱難!要想把這些架構(gòu)和技術(shù)真正投入企業(yè)成熟應(yīng)用，在運維管理上投入的成本可能要比RISC大得多。因為這些系統(tǒng)架構(gòu)更分散，出現(xiàn)的不可預(yù)估性更多，同時也更需要有人來理清何時用分布式架構(gòu)，何種場景還是需要傳統(tǒng)架構(gòu)。那么可能有人要問，既然如此，我們還有必要走分布式系統(tǒng)這條路嗎?當(dāng)然有!原因也很簡單：分布式架構(gòu)給了我們處理海量請求的能力和應(yīng)對突發(fā)事件的彈性;同時分布式架構(gòu)也使系統(tǒng)具備了更好的擴(kuò)展能力和更多業(yè)務(wù)創(chuàng)新的可能性。

說了這么多，基本要講的也就講得差不多了。怕前面說的有些散稍微總結(jié)下我想說的觀點：無論傳統(tǒng)RISC架構(gòu)還是現(xiàn)在流行的分布式架構(gòu)，雖然實現(xiàn)方式各有不同，但都是具有很高的穩(wěn)定性可靠性的系統(tǒng)。但沒有一個系統(tǒng)是絕對穩(wěn)定不會宕機(jī)的，要保障系統(tǒng)穩(wěn)定可靠運行，運維管理很重要。分布式系統(tǒng)相比傳統(tǒng)RISC架構(gòu)有擴(kuò)展性和靈活性方面的巨大優(yōu)勢，但也存在資源浪費和故障隱患危險。在這一方面，分布式系統(tǒng)架構(gòu)還需要多向傳統(tǒng)架構(gòu)的運維管理學(xué)習(xí)借鑒，提升自身的憂患意識和故障預(yù)警處理能力。