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

　　現在被炒的很火熱的互聯網，云計算架構，其相對于傳統的大型企業系統架構，***的區別就是以分布式的架構去替代原先的集中式系統架構。

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

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

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

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

　　也就是說：我們可以簡單把大型企業核心架構，或者說就是大型機，RISC系統比作飛機;而把互聯網，云計算的系統架構比作動車。現在，就可以做些很有意思的討論了。

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

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

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

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

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

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

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

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

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

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

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