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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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