對(duì)于云服務(wù)來(lái)說(shuō)，三分靠開(kāi)發(fā)，七分靠運(yùn)維。云存儲(chǔ)究竟難在哪兒?為什么 HDFS，glusterfs,mogilefs 不能作為云存儲(chǔ)的基礎(chǔ)設(shè)施?本文基于對(duì)七牛云存儲(chǔ)首席架構(gòu)師李道兵帶來(lái)的《三分開(kāi)發(fā)，七分運(yùn)維》的精彩分享的整理，希望大家能從中尋得答案。

　　我們?yōu)槭裁葱枰粋€(gè)公有云?

作為一個(gè)創(chuàng)業(yè)或者開(kāi)公司也好，最基礎(chǔ) 的要解決幾個(gè)問(wèn)題。第一個(gè)問(wèn)題你的客戶是誰(shuí)，簡(jiǎn)單的說(shuō)客戶就是有存儲(chǔ)需求的人。什么人有存儲(chǔ)需求呢?像一些應(yīng)用就有很多的圖片存儲(chǔ)需求，比如說(shuō)需要把拍的 照片發(fā)到網(wǎng)上，存儲(chǔ)需求就很強(qiáng)，有很多做音頻、視頻的，比如說(shuō)美拍，它就面臨一個(gè)很大的問(wèn)題，用戶的視頻要放在哪里?

另外一個(gè)很大的需求就是說(shuō)日志存儲(chǔ)，一個(gè)網(wǎng)站每天產(chǎn)生很多的日志，也有很大的價(jià)值。但是把它存哪里是一個(gè)大問(wèn)題。

日志和富媒體都還面臨著另外一個(gè)問(wèn)題，我需要有很強(qiáng)的運(yùn)維功底，不夠強(qiáng)的話，維護(hù)起來(lái)成本比較高。特別是對(duì)創(chuàng)業(yè)團(tuán)隊(duì)來(lái)講，組建一個(gè)優(yōu)秀的運(yùn)維團(tuán)隊(duì)是一個(gè)非常昂貴的事情。

別人去解決這個(gè)問(wèn)題的時(shí)候，他們的成本究竟是多少呢?比如說(shuō)存儲(chǔ)圖片，在我們學(xué)PHP的時(shí)候，就有一些超級(jí)簡(jiǎn)單的解決方案，比如直接上傳到服務(wù)器的磁盤(pán)里邊。

這種情況你的文件會(huì)放在磁盤(pán)里面，在使用RAID5或者RAID10的情況下，可以保證在單個(gè)磁盤(pán)壞了的時(shí)候整個(gè)數(shù)據(jù)不丟，是不是這樣就可以了呢?至少還有如下幾個(gè)問(wèn)題，第一個(gè)問(wèn)題是宕機(jī)，特別是主板損壞或者內(nèi)存損壞的情況，在機(jī)器修好之前這部分?jǐn)?shù)據(jù)就不可訪問(wèn)了，互聯(lián)網(wǎng)企業(yè)宕機(jī)造成的損失越來(lái)越大，用這種方案帶來(lái)的第一個(gè)問(wèn)題是單點(diǎn)故障怎么解決?這是個(gè)很難接受的后果。

第二個(gè)問(wèn)題是IOPS和吞吐量都很有限。IOPS的限制在你的磁盤(pán)。一般存圖片和音視頻不會(huì)使用SSD，如果做RAID5的話你能拿到 200~300的IOPS，RAID10能達(dá)到600左右，但如果你有大量的小圖片(比如縮略圖)，這點(diǎn) IOPS 就無(wú)法支撐你的業(yè)務(wù)了。另外一點(diǎn)是吞吐量，如果整個(gè)網(wǎng)站越做越大的時(shí)候，一些音視頻的下載很可能把你的機(jī)器壓跨，特別是在只配備了千兆網(wǎng)卡的情況下。萬(wàn)兆網(wǎng)卡能好一些，但是對(duì)應(yīng)的成本很高。

最大的問(wèn)題是容量有限，市面上能買(mǎi)的是4T盤(pán)，12塊盤(pán)加起來(lái)是48T，你做一個(gè) RAID10后是24T。你的存儲(chǔ)存滿了之后，單機(jī)存儲(chǔ)方案就有問(wèn)題了。存儲(chǔ)滿了這個(gè)方案就完全走不通了。所以說(shuō)這種方案只適合一些實(shí)驗(yàn)性質(zhì)的，自己玩一玩的東西還是很適合，如果你去創(chuàng)業(yè)，開(kāi)一個(gè)新公司，真正做一個(gè)服務(wù)的話，從最開(kāi)頭你就要考慮這個(gè)東西存哪里合適，要怎么存。

glusterfs的問(wèn)題

回到幾年前的話，那時(shí)候有一個(gè)很漂亮的方案的glusterfs，做的比較早，大概 2006年就應(yīng)用的比較多了。他有很多很炫的東西，像可以當(dāng)一個(gè)普通磁盤(pán)來(lái)掛載，你可以在上面創(chuàng)建目錄，也可以使用任何其他 POSIX API，所以你以前針對(duì)本地文件的所有程序不用做任何修改就可以放到上面去。第二個(gè)來(lái)講無(wú)中心的架構(gòu)，機(jī)器數(shù)量不受限制。但是實(shí)際用下來(lái)缺點(diǎn)也很明顯。

第一個(gè)問(wèn)題是無(wú)中心的架構(gòu)有兩個(gè)缺點(diǎn)是致命的，是所有無(wú)中心架構(gòu)都無(wú)法逃避的缺點(diǎn)，一上來(lái)你不會(huì)上一個(gè)很大的集群，會(huì)先上3臺(tái)或者6臺(tái)測(cè)試一下，當(dāng)你的容量不夠的時(shí)候，就會(huì)想到擴(kuò)容到12臺(tái)，基于客戶端Hash就會(huì)出現(xiàn)問(wèn)題，之前一三五七放第1組，二四六八放第2組，現(xiàn)在變成一五放第1組，二六放第2組。剩下的三七要放到第3組，四八要放到第4組。你有一半的數(shù)據(jù)需要遷移，這個(gè)時(shí)候你整個(gè)系統(tǒng)就處于不可用的狀態(tài)。你知道搬數(shù)據(jù)特別是通過(guò)網(wǎng)絡(luò)搬數(shù)據(jù)是一件超級(jí)痛苦的事情，大家有空可以算一下，簡(jiǎn)簡(jiǎn)單單搬一個(gè)4T的盤(pán)透過(guò)千兆網(wǎng)搬的話是4萬(wàn)秒，差不多是一天，這樣才是一塊盤(pán)。如果通過(guò)網(wǎng)絡(luò)搬一臺(tái)機(jī)器12塊盤(pán)的話，幾天就過(guò)去了。這種架構(gòu)導(dǎo)致你的整個(gè)系統(tǒng)是一個(gè)固定容量好說(shuō)，如果你的系統(tǒng)容量不固定，在你擴(kuò)容的時(shí)候會(huì)超級(jí)痛苦。

第二個(gè)問(wèn)題這種客戶端架構(gòu)會(huì)導(dǎo)致兩三臺(tái)機(jī)器結(jié)構(gòu)完全對(duì)稱，從一個(gè)方面來(lái)說(shuō)比較好維護(hù)，我這個(gè)數(shù)據(jù)的這一份知道在哪里，另外也知道在哪里。但是有一個(gè)問(wèn)題，你第一塊磁盤(pán)壞了，你修復(fù)要多久?在對(duì)稱盤(pán)的情況下，第一塊磁盤(pán)修復(fù)了，我把這塊卸下來(lái)，安裝一模一樣好盤(pán)到當(dāng)前位置，拷貝出來(lái)數(shù)據(jù)。一塊4T要拷16小時(shí)，而且你還要考慮到在拷貝的過(guò)程中不要跟你的業(yè)務(wù)搶帶寬。在16個(gè)小時(shí)之內(nèi)，你的第二塊盤(pán)不能壞，有沒(méi)有可能運(yùn)氣超級(jí)不好的時(shí)候，第一塊壞了的話，沒(méi)有修復(fù)完成的時(shí)候，第二塊又壞掉了，這對(duì)你來(lái)講是災(zāi)難性的事件。

第二個(gè)是它自身的設(shè)計(jì)有些問(wèn)題，數(shù)據(jù)鏈路非常長(zhǎng)，所以小文件性能是超級(jí)差的。比如說(shuō)幾十K級(jí)別的文件，在互聯(lián)網(wǎng)應(yīng)用里面，特別是針對(duì)圖片的一些應(yīng)用的話，幾十K是超級(jí)常用的東西?？蛻羯蟼饕恍┰紙D或者縮略圖等等，這些小文件的性能超級(jí)差。

第三個(gè)是要實(shí)現(xiàn)兼容，大概是40多個(gè)API，簡(jiǎn)單的云存儲(chǔ)只需實(shí)現(xiàn)三到四個(gè)API就可以了。40多個(gè)API導(dǎo)致它的整個(gè)架構(gòu)非常復(fù)雜。

所以說(shuō)對(duì)于我來(lái)講glusterfs只能適用于一些特殊領(lǐng)域，小規(guī)模、容量可預(yù)估的，同時(shí)你的程序很難改造到基于云存儲(chǔ)的API來(lái)實(shí)現(xiàn)，比如買(mǎi)的是第三方提供的程序，這種情況下你用這個(gè)是最好的選擇。

mogilefs 的問(wèn)題

互聯(lián)網(wǎng)企業(yè)的話，mogilefs用的比較多，中小網(wǎng)站存一些圖片等等的用得非常廣。優(yōu)點(diǎn)是有中心、擴(kuò)容和修復(fù)更方便。缺點(diǎn)是總條目數(shù)受中心限制，還有就是大文件上傳不方便。因?yàn)樗闹行膶?shí)際是一個(gè)數(shù)據(jù)庫(kù)，所以他的能力就受這個(gè)數(shù)據(jù)庫(kù)的能力限制。比如說(shuō)mogilefs幾千萬(wàn)條問(wèn)題不大，再往上的數(shù)量級(jí)呢?幾億、十億，甚至更多的話就有點(diǎn)扛不住了。中國(guó)網(wǎng)民是4億人，如果每個(gè)人都來(lái)使用你的應(yīng)用的話，一百億的文件是一個(gè)可以很快達(dá)到的高度。在這個(gè)領(lǐng)域來(lái)說(shuō)，整個(gè)數(shù)據(jù)庫(kù)會(huì)出現(xiàn)問(wèn)題，會(huì)扛不住。

所以說(shuō)mogilefs適用于文件數(shù)量不太多，幾千萬(wàn)水平，總?cè)萘縋B往下的規(guī)模。訪問(wèn)頻率在數(shù)據(jù)庫(kù)能扛住，同時(shí)不用考慮太多大文件的問(wèn)題。

Hadoop 的問(wèn)題

當(dāng)然說(shuō)到存儲(chǔ)不得不提Hadoop的問(wèn)題，他的優(yōu)點(diǎn)是超強(qiáng)的伸縮性，不用任何改動(dòng)就可以上到1000臺(tái)規(guī)模，阿里在5000臺(tái)做過(guò)一些實(shí)驗(yàn)。只不過(guò)他們現(xiàn)在遷移到自己的系統(tǒng)，這個(gè)就慢慢地放棄掉了。

Hadoop拿來(lái)存文件有些什么問(wèn)題呢?本身設(shè)計(jì)的目標(biāo)不是做文件存儲(chǔ)的。它是按照離線數(shù)據(jù)分析業(yè)務(wù)來(lái)設(shè)計(jì)的，可用性就低了。你在上面不停地取文件，大概有很小的一個(gè)概率，大概千分之一到千分之五的情況下是取不到的。對(duì)離線分析業(yè)務(wù)來(lái)講不是什么問(wèn)題，取不到等三四秒重新做一遍就可以了。但是對(duì)在線應(yīng)用來(lái)講的話，圖刷不出來(lái)了，是一個(gè)紅叉，或者說(shuō)音視頻播放不了，這都是很大的問(wèn)題。

大概是兩個(gè)方面造成的，一個(gè)是Java語(yǔ)言本身的問(wèn)題，另一個(gè)是hadoop數(shù)據(jù)在平衡時(shí)數(shù)據(jù)訪問(wèn)會(huì)超時(shí)。

第二個(gè)是小文件支持不好，Hadoop的塊大小是64MB，你在上面直接存幾十K的文件，那么它的NameNode內(nèi)存會(huì)被用滿，可能你用十臺(tái)的話，就已經(jīng)到極限了。

混搭模型

就是說(shuō)你做存儲(chǔ)的話，很多小的公司自己做存儲(chǔ)是基于這些。還有一些其他的，比如說(shuō)Hbase、Hadoop+HBase等等這些，簡(jiǎn)單思路就是把小文件拼成一個(gè)大文件。

　　你有足夠強(qiáng)的運(yùn)維么?

前面提到這些存儲(chǔ)的局限性，其實(shí)更重要的問(wèn)題是你怎么做好運(yùn)維的工作，為什么要運(yùn)維?一個(gè)軟件就可以了嗎?你的容量越大你需要解決的問(wèn)題就很多。你的機(jī)器會(huì)掛，磁盤(pán)會(huì)滿，網(wǎng)絡(luò)滿，內(nèi)存不足。這個(gè)還跟你簡(jiǎn)單的應(yīng)用層不一樣，應(yīng)用層的服務(wù)遇到問(wèn)題很簡(jiǎn)單把機(jī)器下線，把IP從nginx去掉，反向代理不到這臺(tái)機(jī)器來(lái)。如果應(yīng)用層做大再買(mǎi)機(jī)器就可以了。數(shù)據(jù)庫(kù)層面壓力過(guò)大怎么辦?分庫(kù)、分表以及機(jī)器本身的提升。用更好的磁盤(pán)、CPU來(lái)提升單臺(tái)數(shù)據(jù)的能力，這就是我們常規(guī)的應(yīng)用層和數(shù)據(jù)庫(kù)的伸縮辦法。

但是在存儲(chǔ)層就會(huì)面臨運(yùn)維壓力會(huì)非常大，磁盤(pán)從你簡(jiǎn)單的幾塊到達(dá)幾千塊的時(shí)候，簡(jiǎn)單存1PB的數(shù)據(jù)，數(shù)據(jù)要存3份，3個(gè)PB，數(shù)據(jù)盤(pán)按填充率75%計(jì)算，就需要一千塊4T磁盤(pán)。什么意思呢?考慮到磁盤(pán)壽命為3年多，那么平均每一天就有一塊磁盤(pán)會(huì)壞掉，這是你面新的問(wèn)題。機(jī)器會(huì)壞，磁盤(pán)會(huì)壞，同時(shí)又熱點(diǎn)請(qǐng)求，磁盤(pán)滿、網(wǎng)絡(luò)滿，磁盤(pán)過(guò)滿內(nèi)存不足。體系大到這個(gè)程度的時(shí)候，你還有大量的交換機(jī)，你還要考慮交換機(jī)壞死的情況，網(wǎng)絡(luò)上面的故障也會(huì)出來(lái)。網(wǎng)線也會(huì)出事，可能會(huì)有壞掉，接口不好等等都會(huì)變成你的需求。機(jī)器多了還有一個(gè)額外的問(wèn)題，如果出現(xiàn)安全更新，機(jī)器少的時(shí)候你可以手動(dòng)來(lái)做。但是數(shù)量達(dá)到一百臺(tái)的時(shí)候就做不了，你就需要安全更新的運(yùn)維方案。

一個(gè)想法，類似于我們?nèi)ベI(mǎi)EMC存儲(chǔ)一樣，你給我一個(gè)簡(jiǎn)單的接口，賣給我一個(gè)盒子，然后你幫我把這些情況都解決好，不是說(shuō)不可以，但是賣的很貴。但是有貴的道理，有些事情確實(shí)很難做，要不然所有東西有很高程度的冗余，你自己把細(xì)節(jié)測(cè)試的更全面，做的更好。

第二個(gè)來(lái)講你還得防止系統(tǒng)過(guò)敏，這種事情不是一個(gè)罕見(jiàn)的現(xiàn)象了。之前amazon東部機(jī)房有大面積宕機(jī)，原因是什么呢?是一些小問(wèn)題，小問(wèn)題修復(fù)起來(lái)造成了更大的問(wèn)題。拿人來(lái)比喻就是是過(guò)敏，可能是一個(gè)小問(wèn)題，但是由于它的一些修復(fù)機(jī)制放大了這個(gè)問(wèn)題，最后導(dǎo)致整個(gè)網(wǎng)絡(luò)堵死，又觸發(fā)了很多磁盤(pán)備份的工作，導(dǎo)致壓力過(guò)大，最后整個(gè)機(jī)房的機(jī)器全部宕掉。

如果把所有的意外防范都做在程序里邊，也會(huì)導(dǎo)致軟件研發(fā)和周期非常長(zhǎng)，架構(gòu)復(fù)雜度也大規(guī)模增加了。

這些問(wèn)題帶來(lái)的是你在市面上根本找不到一個(gè)云存儲(chǔ)軟件是非常完美的，能夠大規(guī)模降低運(yùn)維成本。同時(shí)你也很難找到足夠多足夠好的運(yùn)維解決這個(gè)問(wèn)題。

你需要更多基于云存儲(chǔ)的服務(wù)

另外一個(gè)需求是基于存儲(chǔ)的計(jì)算。比如說(shuō)一個(gè)簡(jiǎn)單做圖片的，圖片有iPhone、安卓的，不同客戶端都有不同的分辨率需求。為了節(jié)約流量，客戶端希望下載一個(gè)小的圖片而不去下載原圖，iPhone和安卓要面臨分辨率的問(wèn)題，你的產(chǎn)品經(jīng)理和設(shè)計(jì)師會(huì)突然說(shuō)之前覺(jué)得300很合適。但是決定加一個(gè)邊框，那么300的寬度就要變成298。你會(huì)發(fā)現(xiàn)你要把所有圖片重新做一下縮放，這個(gè)工作壓力非常大。所以你就希望有一些輔助的系統(tǒng)幫你做好這個(gè)事情，比如說(shuō)你希望能有人能幫你搞定縮放、水印、原圖保護(hù)。

類似的音視頻領(lǐng)域有轉(zhuǎn)碼、切片、合成、快速預(yù)覽的需求。有些客戶還有自定義需求，比如美顏相機(jī)、人臉識(shí)別、數(shù)據(jù)統(tǒng)計(jì)。對(duì)于私有存儲(chǔ)方案就很麻煩了，但是你用一個(gè)公有云就可以了。

單機(jī)房100PB的挑戰(zhàn)

接下來(lái)講講云存儲(chǔ)對(duì)我們來(lái)講我們面臨的挑戰(zhàn)是什么?單機(jī)房100PB的挑戰(zhàn)是我們現(xiàn)在需要考慮的事情。就是說(shuō)我們稍微細(xì)算一下，100PB意味著什么?4000臺(tái)存儲(chǔ)計(jì)算的話，不考慮冗余的情況下每臺(tái)承擔(dān)25TB的容量。考慮3份冗余后它要承擔(dān)大概75TB，4T乘12塊盤(pán)是48T，是不夠的。我們需要引入新的存儲(chǔ)方式，減少冗余。

在200KB的文件平均大小情況下，原數(shù)據(jù)條目是五千億條。怎么做好穩(wěn)定的增刪查改工作，是我們需要考慮的問(wèn)題。

元數(shù)據(jù)庫(kù)的壓力不僅是維護(hù)的問(wèn)題，更重要的是扛住100W每秒的請(qǐng)求頻率，這是數(shù)據(jù)庫(kù)怎么扛住的問(wèn)題。

除了這些還有前面提到的，比如說(shuō)機(jī)器、網(wǎng)絡(luò)硬件、機(jī)房的出入口等等都會(huì)有問(wèn)題，這些問(wèn)題怎么解決才是我們考慮比較多的一個(gè)問(wèn)題。

在單機(jī)房100PB的挑戰(zhàn)里面，架構(gòu)做的東西不太多。對(duì)于架構(gòu)來(lái)講，我們能做好的就是幾件事情，第一個(gè)每個(gè)組件都是高可用，可伸縮的。同時(shí)，我的組件能輕易的從10個(gè)伸縮到100個(gè)甚至到4k、5k都沒(méi)有問(wèn)題。在設(shè)計(jì)階段高可用、可伸縮都要作為一個(gè)必選項(xiàng)來(lái)考慮。

第二個(gè)是保持每個(gè)遠(yuǎn)程調(diào)用都是可重入的，最簡(jiǎn)單的拿交易做例子，什么是不可重入?給賬戶添加一百塊錢(qián)的API調(diào)用是不可以重入的，請(qǐng)求對(duì)方?jīng)]有返回再發(fā)一次就不合適了，有可能你給用戶一百塊，也有可能給用戶二百塊?？芍厝氲募渝X(qián)API長(zhǎng)什么樣呢?如果賬戶版本是21的話，給它的賬戶添加一百塊錢(qián)，并且把版本改為22，重新調(diào)一次的話要不然它成功，要不然它告訴我對(duì)方的版本不變。我根據(jù)版本是否變化去確認(rèn)我們之前成功還是不成功，這是可重入的概念。

我們這邊不涉及金錢(qián)的交易，所以很多時(shí)候會(huì)比這種簡(jiǎn)單一點(diǎn)。

第三點(diǎn)網(wǎng)絡(luò)也是不可信的，傳過(guò)來(lái)一個(gè)文件，這個(gè)文件是否正確，我們?nèi)绾蝸?lái)保證呢?如果我們?nèi)萑体e(cuò)誤文件的話，客戶那邊就會(huì)給我們大量的抱怨。而且由于我們有緩存存在，這個(gè)問(wèn)題會(huì)一直錯(cuò)下去，直到緩存過(guò)期。所以對(duì)我們來(lái)講所有網(wǎng)絡(luò)傳輸都需要做校驗(yàn)，架構(gòu)層面做到這幾點(diǎn)，會(huì)保證你不會(huì)出一些低級(jí)的錯(cuò)誤。

比較難的是規(guī)模擴(kuò)大了之后怎么辦?來(lái)自墨菲定律的詛咒：凡是可能發(fā)生的都會(huì)發(fā)生，所有你想得到的事情都會(huì)發(fā)生，只是發(fā)生在哪一天而已。

墨菲定律的詛咒第一個(gè)是多磁盤(pán)故障，常規(guī)情況一般是一塊磁盤(pán)壞了怎么修復(fù)。在量特別大的情況下你就面臨一個(gè)問(wèn)題，兩塊磁盤(pán)一起壞會(huì)發(fā)生什么事情?多塊磁盤(pán)一起壞發(fā)生什么事情?如果其他機(jī)器屬于維護(hù)的狀態(tài)你又應(yīng)該怎么做?

第二個(gè)是交換機(jī)故障，在常規(guī)的做設(shè)計(jì)的時(shí)候，一般不會(huì)去考慮這個(gè)問(wèn)題。但是在做存儲(chǔ)的時(shí)候，這就變成你必須考慮的問(wèn)題，你要仔細(xì)的給你存儲(chǔ)做一些分組。分組的目的是這臺(tái)宕了，怎么做到客戶完全無(wú)感知。不要把一份數(shù)據(jù)的所有備份都在同一個(gè)交換機(jī)下面，這是我們要確保的東西。

第三個(gè)是人為失誤，運(yùn)維的工作量大就會(huì)有一些人為失誤。怎么確保即使操作失誤有不會(huì)影響你的系統(tǒng)，這是我們更多要注意的一個(gè)方向。

我們能做到什么呢?多預(yù)案。針對(duì)你的每樣事情你需要有一個(gè)預(yù)案，單磁盤(pán)壞了你怎么處理，多磁盤(pán)壞了怎么處理，交換機(jī)壞了整個(gè)流程怎么處理的?這些東西不要寫(xiě)進(jìn)你的預(yù)案里面，在運(yùn)維發(fā)生報(bào)警的時(shí)候，打開(kāi)預(yù)案一步一步的往下操作。

第二個(gè)是多演習(xí)，讓事故處理常態(tài)化，我們要有一個(gè)很大的測(cè)試集群，像我們前面提到的一些故障我們都會(huì)做一些定期或者不定期的演習(xí)。讓大家能夠了解這些東西會(huì)有哪些我們想到的事故。

第三個(gè)常規(guī)的數(shù)據(jù)處理一鍵化、自動(dòng)化。更多的是我前面提到的防過(guò)敏，當(dāng)有人在里面的時(shí)候，這種事故處理也許慢了一分兩分鐘。但是好處是通過(guò)人為介入到這里，整個(gè)事故不會(huì)擴(kuò)大化，會(huì)讓它停掉，避免大規(guī)模的出現(xiàn)錯(cuò)誤。

總結(jié)一下，自建存儲(chǔ)的缺點(diǎn)是運(yùn)維成本高，便宜一點(diǎn)的運(yùn)維人員一年也要15w左右，加上機(jī)器成本大概30w。如果你買(mǎi)100TB的云存儲(chǔ)話，也就是15w左右，所以購(gòu)買(mǎi)云服務(wù)更劃算一些。

常規(guī)解決方案存在適用領(lǐng)域狹窄的問(wèn)題，不夠通用。也就是你今天的業(yè)務(wù)是圖片，用mogilefs搞定了，之后想做視頻，mogilefs就不行了，又得找新方案。

最后推薦兩本書(shū)，KK的《科技想要什么》，以及Eric Ries的 《THE LEAN STARTUP》。第一本講了很多趨勢(shì)方面的東西，第二本講了在創(chuàng)業(yè)過(guò)程中怎么快速試錯(cuò)，怎么快速讓你的用戶增長(zhǎng)起來(lái)，在這方面的東西非常值得一看。