CIO:網際網路IT系統和傳統企業IT系統的異同

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

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

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

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

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

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

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

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

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

2. 這種方式下每台伺服器的cpu使用率都很低，而現在市面上的大存儲容量伺服器，cpu配置都很高。是以這種方式，基本上是對于cpu資源的一種浪費。是以，或許對于資料量适中的企業來說，用ec code這種以計算能力換存儲的分布式存儲解決方案會比多副本方案更經濟實惠。

3. 這種方式很容易讓it運維人員産生一種習慣性思維 – 即要提高系統線上時間就多買些伺服器就好了。因為伺服器多了分布性好了自然備援度就高了。于是不必要的伺服器采購就這麼産生了，每個資料中心也就又多了很大一筆不是很必要的電費開銷。

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

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

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

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

====================================分割線================================

本文轉自d1net（轉載）