云服務構建法則：三分開發，七分運維
對于云服務來說，三分靠開發，七分靠運維。云存儲究竟難在哪兒?為什么 HDFS，glusterfs,mogilefs 不能作為云存儲的基礎設施?本文基于對七牛云存儲***架構師李道兵帶來的《三分開發，七分運維》的精彩分享的整理，希望大家能從中尋得答案。
我們為什么需要一個公有云?
作為一個創業或者開公司也好，最基礎 的要解決幾個問題。***個問題你的客戶是誰，簡單的說客戶就是有存儲需求的人。什么人有存儲需求呢?像一些應用就有很多的圖片存儲需求，比如說需要把拍的 照片發到網上，存儲需求就很強，有很多做音頻、視頻的，比如說美拍，它就面臨一個很大的問題，用戶的視頻要放在哪里?
另外一個很大的需求就是說日志存儲，一個網站每天產生很多的日志，也有很大的價值。但是把它存哪里是一個大問題。
日志和富媒體都還面臨著另外一個問題，我需要有很強的運維功底，不夠強的話，維護起來成本比較高。特別是對創業團隊來講，組建一個優秀的運維團隊是一個非常昂貴的事情。
別人去解決這個問題的時候，他們的成本究竟是多少呢?比如說存儲圖片，在我們學PHP的時候，就有一些超級簡單的解決方案，比如直接上傳到服務器的磁盤里邊。
這種情況你的文件會放在磁盤里面，在使用RAID5或者RAID10的情況下，可以保證在單個磁盤壞了的時候整個數據不丟，是不是這樣就可以了呢?至少還有如下幾個問題，***個問題是宕機，特別是主板損壞或者內存損壞的情況，在機器修好之前這部分數據就不可訪問了，互聯網企業宕機造成的損失越來越大，用這種方案帶來的***個問題是單點故障怎么解決?這是個很難接受的后果。
第二個問題是IOPS和吞吐量都很有限。IOPS的限制在你的磁盤。一般存圖片和音視頻不會使用SSD，如果做RAID5的話你能拿到 200~300的IOPS，RAID10能達到600左右，但如果你有大量的小圖片(比如縮略圖)，這點 IOPS 就無法支撐你的業務了。另外一點是吞吐量，如果整個網站越做越大的時候，一些音視頻的下載很可能把你的機器壓跨，特別是在只配備了千兆網卡的情況下。萬兆網卡能好一些，但是對應的成本很高。
***的問題是容量有限，市面上能買的是4T盤，12塊盤加起來是48T，你做一個 RAID10后是24T。你的存儲存滿了之后，單機存儲方案就有問題了。存儲滿了這個方案就完全走不通了。所以說這種方案只適合一些實驗性質的，自己玩一玩的東西還是很適合，如果你去創業，開一個新公司，真正做一個服務的話，從最開頭你就要考慮這個東西存哪里合適，要怎么存。
glusterfs的問題
回到幾年前的話，那時候有一個很漂亮的方案的glusterfs，做的比較早，大概 2006年就應用的比較多了。他有很多很炫的東西，像可以當一個普通磁盤來掛載，你可以在上面創建目錄，也可以使用任何其他 POSIX API，所以你以前針對本地文件的所有程序不用做任何修改就可以放到上面去。第二個來講無中心的架構，機器數量不受限制。但是實際用下來缺點也很明顯。
***個問題是無中心的架構有兩個缺點是致命的，是所有無中心架構都無法逃避的缺點，一上來你不會上一個很大的集群，會先上3臺或者6臺測試一下，當你的容量不夠的時候，就會想到擴容到12臺，基于客戶端Hash就會出現問題，之前一三五七放第1組，二四六八放第2組，現在變成一五放第1組，二六放第2組。剩下的三七要放到第3組，四八要放到第4組。你有一半的數據需要遷移，這個時候你整個系統就處于不可用的狀態。你知道搬數據特別是通過網絡搬數據是一件超級痛苦的事情，大家有空可以算一下，簡簡單單搬一個4T的盤透過千兆網搬的話是4萬秒，差不多是一天，這樣才是一塊盤。如果通過網絡搬一臺機器12塊盤的話，幾天就過去了。這種架構導致你的整個系統是一個固定容量好說，如果你的系統容量不固定，在你擴容的時候會超級痛苦。
第二個問題這種客戶端架構會導致兩三臺機器結構完全對稱，從一個方面來說比較好維護，我這個數據的這一份知道在哪里，另外也知道在哪里。但是有一個問題，你***塊磁盤壞了，你修復要多久?在對稱盤的情況下，***塊磁盤修復了，我把這塊卸下來，安裝一模一樣好盤到當前位置，拷貝出來數據。一塊4T要拷16小時，而且你還要考慮到在拷貝的過程中不要跟你的業務搶帶寬。在16個小時之內，你的第二塊盤不能壞，有沒有可能運氣超級不好的時候，***塊壞了的話，沒有修復完成的時候，第二塊又壞掉了，這對你來講是災難性的事件。
第二個是它自身的設計有些問題，數據鏈路非常長，所以小文件性能是超級差的。比如說幾十K級別的文件，在互聯網應用里面，特別是針對圖片的一些應用的話，幾十K是超級常用的東西。客戶上傳一些原始圖或者縮略圖等等，這些小文件的性能超級差。
第三個是要實現兼容，大概是40多個API，簡單的云存儲只需實現三到四個API就可以了。40多個API導致它的整個架構非常復雜。
所以說對于我來講glusterfs只能適用于一些特殊領域，小規模、容量可預估的，同時你的程序很難改造到基于云存儲的API來實現，比如買的是第三方提供的程序，這種情況下你用這個是***的選擇。
mogilefs 的問題
互聯網企業的話，mogilefs用的比較多，中小網站存一些圖片等等的用得非常廣。優點是有中心、擴容和修復更方便。缺點是總條目數受中心限制，還有就是大文件上傳不方便。因為它的中心實際是一個數據庫，所以他的能力就受這個數據庫的能力限制。比如說mogilefs幾千萬條問題不大，再往上的數量級呢?幾億、十億，甚至更多的話就有點扛不住了。中國網民是4億人，如果每個人都來使用你的應用的話，一百億的文件是一個可以很快達到的高度。在這個領域來說，整個數據庫會出現問題，會扛不住。
所以說mogilefs適用于文件數量不太多，幾千萬水平，總容量PB往下的規模。訪問頻率在數據庫能扛住，同時不用考慮太多大文件的問題。
Hadoop 的問題
當然說到存儲不得不提Hadoop的問題，他的優點是超強的伸縮性，不用任何改動就可以上到1000臺規模，阿里在5000臺做過一些實驗。只不過他們現在遷移到自己的系統，這個就慢慢地放棄掉了。
Hadoop拿來存文件有些什么問題呢?本身設計的目標不是做文件存儲的。它是按照離線數據分析業務來設計的，可用性就低了。你在上面不停地取文件，大概有很小的一個概率，大概千分之一到千分之五的情況下是取不到的。對離線分析業務來講不是什么問題，取不到等三四秒重新做一遍就可以了。但是對在線應用來講的話，圖刷不出來了，是一個紅叉，或者說音視頻播放不了，這都是很大的問題。
大概是兩個方面造成的，一個是Java語言本身的問題，另一個是hadoop數據在平衡時數據訪問會超時。
第二個是小文件支持不好，Hadoop的塊大小是64MB，你在上面直接存幾十K的文件，那么它的NameNode內存會被用滿，可能你用十臺的話，就已經到極限了。
混搭模型
就是說你做存儲的話，很多小的公司自己做存儲是基于這些。還有一些其他的，比如說Hbase、Hadoop+HBase等等這些，簡單思路就是把小文件拼成一個大文件。
#p#
你有足夠強的運維么?
前面提到這些存儲的局限性，其實更重要的問題是你怎么做好運維的工作，為什么要運維?一個軟件就可以了嗎?你的容量越大你需要解決的問題就很多。你的機器會掛，磁盤會滿，網絡滿，內存不足。這個還跟你簡單的應用層不一樣，應用層的服務遇到問題很簡單把機器下線，把IP從nginx去掉，反向代理不到這臺機器來。如果應用層做大再買機器就可以了。數據庫層面壓力過大怎么辦?分庫、分表以及機器本身的提升。用更好的磁盤、CPU來提升單臺數據的能力，這就是我們常規的應用層和數據庫的伸縮辦法。
但是在存儲層就會面臨運維壓力會非常大，磁盤從你簡單的幾塊到達幾千塊的時候，簡單存1PB的數據，數據要存3份，3個PB，數據盤按填充率75%計算，就需要一千塊4T磁盤。什么意思呢?考慮到磁盤壽命為3年多，那么平均每一天就有一塊磁盤會壞掉，這是你面新的問題。機器會壞，磁盤會壞，同時又熱點請求，磁盤滿、網絡滿，磁盤過滿內存不足。體系大到這個程度的時候，你還有大量的交換機，你還要考慮交換機壞死的情況，網絡上面的故障也會出來。網線也會出事，可能會有壞掉，接口不好等等都會變成你的需求。機器多了還有一個額外的問題，如果出現安全更新，機器少的時候你可以手動來做。但是數量達到一百臺的時候就做不了，你就需要安全更新的運維方案。
一個想法，類似于我們去買EMC存儲一樣，你給我一個簡單的接口，賣給我一個盒子，然后你幫我把這些情況都解決好，不是說不可以，但是賣的很貴。但是有貴的道理，有些事情確實很難做，要不然所有東西有很高程度的冗余，你自己把細節測試的更全面，做的更好。
第二個來講你還得防止系統過敏，這種事情不是一個罕見的現象了。之前amazon東部機房有大面積宕機，原因是什么呢?是一些小問題，小問題修復起來造成了更大的問題。拿人來比喻就是是過敏，可能是一個小問題，但是由于它的一些修復機制放大了這個問題，***導致整個網絡堵死，又觸發了很多磁盤備份的工作，導致壓力過大，***整個機房的機器全部宕掉。
如果把所有的意外防范都做在程序里邊，也會導致軟件研發和周期非常長，架構復雜度也大規模增加了。
這些問題帶來的是你在市面上根本找不到一個云存儲軟件是非常***的，能夠大規模降低運維成本。同時你也很難找到足夠多足夠好的運維解決這個問題。
你需要更多基于云存儲的服務
另外一個需求是基于存儲的計算。比如說一個簡單做圖片的，圖片有iPhone、安卓的，不同客戶端都有不同的分辨率需求。為了節約流量，客戶端希望下載一個小的圖片而不去下載原圖，iPhone和安卓要面臨分辨率的問題，你的產品經理和設計師會突然說之前覺得300很合適。但是決定加一個邊框，那么300的寬度就要變成298。你會發現你要把所有圖片重新做一下縮放，這個工作壓力非常大。所以你就希望有一些輔助的系統幫你做好這個事情，比如說你希望能有人能幫你搞定縮放、水印、原圖保護。
類似的音視頻領域有轉碼、切片、合成、快速預覽的需求。有些客戶還有自定義需求，比如美顏相機、人臉識別、數據統計。對于私有存儲方案就很麻煩了，但是你用一個公有云就可以了。
單機房100PB的挑戰
接下來講講云存儲對我們來講我們面臨的挑戰是什么?單機房100PB的挑戰是我們現在需要考慮的事情。就是說我們稍微細算一下，100PB意味著什么?4000臺存儲計算的話，不考慮冗余的情況下每臺承擔25TB的容量。考慮3份冗余后它要承擔大概75TB，4T乘12塊盤是48T，是不夠的。我們需要引入新的存儲方式，減少冗余。
在200KB的文件平均大小情況下，原數據條目是五千億條。怎么做好穩定的增刪查改工作，是我們需要考慮的問題。
元數據庫的壓力不僅是維護的問題，更重要的是扛住100W每秒的請求頻率，這是數據庫怎么扛住的問題。
除了這些還有前面提到的，比如說機器、網絡硬件、機房的出入口等等都會有問題，這些問題怎么解決才是我們考慮比較多的一個問題。
在單機房100PB的挑戰里面，架構做的東西不太多。對于架構來講，我們能做好的就是幾件事情，***個每個組件都是高可用，可伸縮的。同時，我的組件能輕易的從10個伸縮到100個甚至到4k、5k都沒有問題。在設計階段高可用、可伸縮都要作為一個必選項來考慮。
第二個是保持每個遠程調用都是可重入的，最簡單的拿交易做例子，什么是不可重入?給賬戶添加一百塊錢的API調用是不可以重入的，請求對方沒有返回再發一次就不合適了，有可能你給用戶一百塊，也有可能給用戶二百塊。可重入的加錢API長什么樣呢?如果賬戶版本是21的話，給它的賬戶添加一百塊錢，并且把版本改為22，重新調一次的話要不然它成功，要不然它告訴我對方的版本不變。我根據版本是否變化去確認我們之前成功還是不成功，這是可重入的概念。
我們這邊不涉及金錢的交易，所以很多時候會比這種簡單一點。
第三點網絡也是不可信的，傳過來一個文件，這個文件是否正確，我們如何來保證呢?如果我們容忍錯誤文件的話，客戶那邊就會給我們大量的抱怨。而且由于我們有緩存存在，這個問題會一直錯下去，直到緩存過期。所以對我們來講所有網絡傳輸都需要做校驗，架構層面做到這幾點，會保證你不會出一些低級的錯誤。
比較難的是規模擴大了之后怎么辦?來自墨菲定律的詛咒：凡是可能發生的都會發生，所有你想得到的事情都會發生，只是發生在哪一天而已。
墨菲定律的詛咒***個是多磁盤故障，常規情況一般是一塊磁盤壞了怎么修復。在量特別大的情況下你就面臨一個問題，兩塊磁盤一起壞會發生什么事情?多塊磁盤一起壞發生什么事情?如果其他機器屬于維護的狀態你又應該怎么做?
第二個是交換機故障，在常規的做設計的時候，一般不會去考慮這個問題。但是在做存儲的時候，這就變成你必須考慮的問題，你要仔細的給你存儲做一些分組。分組的目的是這臺宕了，怎么做到客戶完全無感知。不要把一份數據的所有備份都在同一個交換機下面，這是我們要確保的東西。
第三個是人為失誤，運維的工作量大就會有一些人為失誤。怎么確保即使操作失誤有不會影響你的系統，這是我們更多要注意的一個方向。
我們能做到什么呢?多預案。針對你的每樣事情你需要有一個預案，單磁盤壞了你怎么處理，多磁盤壞了怎么處理，交換機壞了整個流程怎么處理的?這些東西不要寫進你的預案里面，在運維發生報警的時候，打開預案一步一步的往下操作。
第二個是多演習，讓事故處理常態化，我們要有一個很大的測試集群，像我們前面提到的一些故障我們都會做一些定期或者不定期的演習。讓大家能夠了解這些東西會有哪些我們想到的事故。
第三個常規的數據處理一鍵化、自動化。更多的是我前面提到的防過敏，當有人在里面的時候，這種事故處理也許慢了一分兩分鐘。但是好處是通過人為介入到這里，整個事故不會擴大化，會讓它停掉，避免大規模的出現錯誤。
總結一下，自建存儲的缺點是運維成本高，便宜一點的運維人員一年也要15w左右，加上機器成本大概30w。如果你買100TB的云存儲話，也就是15w左右，所以購買云服務更劃算一些。
常規解決方案存在適用領域狹窄的問題，不夠通用。也就是你今天的業務是圖片，用mogilefs搞定了，之后想做視頻，mogilefs就不行了，又得找新方案。
***推薦兩本書，KK的《科技想要什么》，以及Eric Ries的 《THE LEAN STARTUP》。***本講了很多趨勢方面的東西，第二本講了在創業過程中怎么快速試錯，怎么快速讓你的用戶增長起來，在這方面的東西非常值得一看。
