1.當妳的數據量很小(小於PB)時，將壹份數據存儲三份的成本實際上比任何現有的商業存儲方案都要高。
2.這樣每臺服務器的CPU利用率都很低，而市面上大存儲容量服務器的CPU配置都很高，所以這種方式基本上是浪費CPU資源。因此，對於數據量適中的企業來說，使用EC CODE這種以計算能力換取存儲的分布式存儲解決方案可能比多副本方案更經濟。
3.這種方式很容易讓IT運維人員產生壹種* *慣性思維，就是要提高系統的在線時間，多買幾臺服務器就好了，因為服務器多分布好，自然冗余高，所以產生了不必要的服務器采購，每個數據中心也有很多不必要的電費支出。
其次，我認為分布式架構中的壹些故障很可能會產生連鎖效應，導致更嚴重的全球癱瘓。比如我們都知道赤壁之戰的故事裏有壹個著名的橋段，龐同賢的連招。當初鐵鏈把曹操的壹萬多艘戰船連成壹個整體，前後能攻能退能守都照顧得天衣無縫，但只有壹個諸葛亮和周瑜用的命門。其實我覺得有壹種類似名門主機的互聯網分布式架構，因為太貴了。其實很多時候用戶都是百萬分之壹甚至十億分之壹的付費，而互聯網，現在的公有雲架構，在設計之初，基本考慮的就是大用戶，大並發，然後盡量降低TCO。所以很多時候，在設計架構的時候，會先排除那些萬裏挑壹的。系統上線後暫時不考慮，穩定運行壹段時間後用戶數會* *的，精力往往會集中在擴容上。也許會漏掉壹些人，所以萬壹東風吹在門上，後果估計比曹阿瞞還要慘，因為IT界不那麽仁厚的關雲長會讓曹操走上華容道。
最後我想說，互聯網和雲計算的業務類型其實和傳統企業是不壹樣的，所以大型機、系統處理的任務和運行計算不壹定適合移植到分布式系統架構上。就拿交通工具來說吧:我要去美國，但目前只有飛機能滿足我的需求。當然，妳可以說我可以坐動車，無非就是換乘幾趟國際列車，但是很勉強，很慢，費時費力，沒有意義。
那麽有什麽辦法可以解決這些問題呢？其實我覺得解決以上問題的關鍵就是兩個字:分布式系統的運維，保證其安全可靠的運行，合理有效的擴展，關鍵不在於系統的軟硬件，而在於系統搭建後的運維以及系統的不斷完善和修正！現在網上很多人熱衷於openstack、Hadoop等各種開源架構的開發，以及應用場景的討論。但個人認為，這些開源系統的特點是構造簡單，維護困難！要想真正將這些架構和技術投入到成熟的企業應用中，運維管理的投入成本可能會高很多，因為這些系統架構更加分散，不可預測，同時更需要有人明確什麽時候使用分布式架構，哪些場景還需要傳統架構。那麽可能有人會問，既然如此，我們還有必要走分布式系統的道路嗎？當然有！原因也很簡單:分布式架構賦予了我們處理海量請求的能力和處理突發事件的靈活性；同時，分布式架構也使得系統具有更好的擴展性和更多業務創新的可能性。