傳統制造企業IT架構和互聯網企業的IT架構，之間的區別

說壹說對互聯網系統和傳統企業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架構有擴展性和靈活性方面的巨大優勢，但也存在資源浪費和故障隱患危險。在這壹方面，分布式系統架構還需要多向傳統架構的運維管理學習借鑒，提升自身的憂患意識和故障預警處理能力。