在剛剛結束的由InfoQ舉辦的ArchSummit全球架構師峰會（北京站）上，七牛云存儲CTO韓拓帶來了《七牛云存儲產品的三年演進之路》。結合七牛的實戰經驗，分析七牛的客戶使用云計算的架構方式，以及為了適應不同的客戶類型和使用場景，七牛的產品變化過程，并在此基礎上與大家共同探討云計算的產業構成，給出企業如何更好使用云計算基礎設施的建議。
以下為演講實錄：
實錄內容：
韓拓：今天分享的話題是七牛的產品演進之路，看這個題目像是來做廣告的，來了這么多人我挺高興的，并不是在做廣告。
七牛是2011年成立的，我們作為在國內云計算產業的一個參與者，見證了云計算這個產業從剛開始的一個起步到今天大家看到這么蓬勃的發展，這三年是經歷了這樣一個過程。
咱們今天會場大的話題是真實的云計算，我這個題目的本意是想看看七牛這個公司和產品變化的經歷引發大家對國內云計算的環境都有誰？怎么樣做云計算？誰在用云計算。
先講一下七牛以及產品關鍵的節點，主持人說誰在用七牛，我不相信人這么少，應該是有的人沒有舉手。2011年下半年成立的，10月份寫了第一行代碼，當時的辦公室也沒有，我們幾個人是在上海的浦東圖書館辦公的。那個地方有免費的空間、網絡和水。大家在上海創業也可以考慮這么做，那個地方是很好的。
2011接近年底的時候，第一版系統上線，有了第一個機會和第一個使用云存儲的客戶。
2012年初我們有了第二個機房，后續的有很多的機房，去構建我們上傳和下載加速的能力。
2012年這一年我們是打造存儲1.0和數據處理的1.0版本。
2013年開始我們做存儲的2.0，進一步降低存儲的成本冗余度和提高數據的可靠性。
數據處理的2.0，異步的上傳回調處理，包括用戶可以定義自己處理的模塊等等功能。
現在做的是我們前兩天上線的分區域處理的中心，整個的配置和原數據、里面存儲的文件和另外一個區域是獨立的。我們在北京做了一個很大的數據中心，作為我們第二個存儲的區域。
這三年七牛在怎么樣的環境產業中生存呢？正好契合了我們今天的話題，真實的云計算。
我在七牛做這份工作，我們現在很冷靜、客觀的看我們國內云計算到底是什么情況。我觀察到在IaaS層面就是兩個：云主機和云存儲。國內還有一個很有意思的現象，沒有一家能夠把這兩個都做的很好。至少到今天，七牛還是專注在云存儲上面。云主機有三四家是做的比較好的，好像還沒有形成AWS那樣一整套很好用的方案。
在PaaS一層在我看來是有很多垂直化的云，涉及了很多方面，我這里羅列了。就是一個圖片的云，或者是一個視頻的云。還有更垂直的，比如說我是給電商的客戶做云，或者是給游戲的客戶做云，這是PaaS在國內非常生機勃勃的現象，非常好。
甚至這里面有很多的產品自己都沒有叫云，本身它已經是云了。
從托管的形態上看，現在在國內有公有云，這個是最多的。跟國外不太一樣的地方是我們見到了很多私有云和混合云這樣的方案。私有云是在你的數據中心內把我的軟件賣給你，混合云是某種程度上的代運維，邊界是每個廠商找的都會略有區別。但是核心的思路是硬件的設備是在你的數據中心內的，但是運維的事情是提供這個服務的廠商去管的。尤其是一些傳統的行業，一下子還接觸不了把我的數據放在公有云上，他們更傾向私有云和混合云方面。
產業形勢是三個：布局基本完成。任何一個業務你設想自己在做的事情，如果你想用云計算構建自己的業務的時候，想不到還缺什么，基本是全的。應用也開始落地，2014年非常多的企業開始選擇云計算，從七牛業務的曲線也能看出來，2014年初開始有一個很大的爆發。包括大量的傳統行業也開始進入云計算的這個行業。生態還未形成，有這么多做云計算的，大家之間的關聯還沒有建立起來，還是在各自為政，自己玩自己的。這個其實是和國外的云計算相比是差的比較遠的一塊，比如說在國外我做一個處理圖片的PaaS，我必然是基于AWS做，我從S3讀取完以后再存儲到里面。其實不同的云計算供應商之間，有千絲萬縷的關系。但是這個現象在國內到今天我們暫時還沒有看到。
咱們看一看在國內有什么人使用云計算呢？從七牛角度來說，當然是不全面的，我們沒有做統計或者國內云存儲的使用情況。有一類是初創型做APP的非常多，這也是國內使用云計算最先的一波人。他們關注的是什么呢？他們關注的是方便，你的API是不是夠簡單，你的SDK是不是拿過來就能用。初創型的APP唯一的訴求是快，假如說我拷貝一個國外的模式，我肯定希望一個月或者三個月內就能夠上線，他們關注的是產品的應用性是怎么樣的。
還有一類很奇怪，他們也是使用云計算最早的一波人。是什么樣的人呢？是傳統媒體屬性的互聯網服務，比如說做新聞、論壇的。為什么他們這么早使用云計算呢？他們的業務是以靜態的數據為主，他們對云的需求并不強，說白了他們是把云存儲當成一個旁柜加CDN做的，算起來比較便宜，就遷過來了。這類客戶關注的是成本，一定要比其他方案更便宜。
下面一類是UGC或者是web2.0類的業務，做社交的，比如說搖的。現在做圖片分享的，短視頻分享的這樣一類人。他們為什么用云計算呢？因為他們對用戶體驗的要求是最高的，我不能搖一搖什么都出不來。也不能說拍一個短視頻，傳半天也傳不出去。他們在世界上對用戶體驗最苛刻的一群人，使用云計算可以幫助他們用比較低的代價去獲得一個更好的用戶體驗，這是一類用云計算的人。
還有一類是做PaaS的供應商也會用七牛的產品，比如說我是一個做視頻的解決方案，幫你把客戶端的播放器做好，內容的管理、后臺怎么審核我都幫你做好了，他們還缺少存儲和網絡加速的方案。這個時候，基于一個云去構建PaaS的業務，使他們更專注于他們想做的點，而不用去操心我要去買一個數據中心等等的問題。
這一類客戶其實更關注的是你的這個產品平臺是不是夠開放，你分享的精神是不是夠強，在這個行業里的職業道德是不是夠好，他們可能是關注的這個。
還有一類是已經比較成熟的業務，帶寬幾十個G，存儲是幾百T，或者是幾個PB這樣的規模了。往往是從一個小的規模發展起來的，這個過程中可能是忙于和業務相關的那一塊，忽略了基礎設施上的積累。這時候他們就發現我的規模突然變大了之后，我在技術上有瓶頸了。我以前用的到了量大的時候就出現問題了，或者說帶寬有上百個G，我不知道怎么管理CDN的供應商了。這樣一波人會很迫切的使用云計算，幫助他們解決技術上尤其是基礎設施這一層遇到的瓶頸。
最后一個是傳統的行業，已經開始互聯網化的傳統行業。我關注到2014年開始，大規模的有傳統行業進入到互聯網這一塊。比如說做家電、安防視頻、教育等等。他們的特點是什么呢？第一個是他們的量很大，因為它不是白手起家的一個業務。比如說做安防的，我以前是賣政府、學校、超市等等2B的，但是這個量一旦乘以一百、一千的量，比如說我賣給家庭，你上班的時候我幫你看著家里有沒有進小偷，家里的狗是否去咬沙發了。
還有一點是互聯網說白了是很屌絲的，真正見到錢，掙過錢的并不多，但是傳統行業是見到錢的，并不會很吝嗇的花錢。上面的業務都對錢很關心，但是傳統行業對效果是最關心的，你一定要夠好用，夠快速，夠穩定。錢都好談，這是對傳統行業來說。
這個可能是把一個東西賣給互聯網用戶和賣給傳統行業的用戶是有區別的。
下面講一講七牛該怎么樣做產品呢？有一個大的前提是我們叫七牛云存儲，至少到今天還是叫七牛云存儲，肯定是圍繞存儲這個話題來討論我們該怎么做產品。下面幾個問題都要回答了，存儲是什么？存儲的客戶是誰？他們的需求是什么？最后一個是七牛應該怎么滿足這些客戶存儲上的需求？
2011年我們剛成立的時候一群人聚在一起想大干一場，那個時候想做云存儲，面對的第一個問題是存儲是什么？取決于你該怎么做事情，要做什么產品的第一個問題。我們在當時其實是很茫然的，討論出來的一個結果也是很沮喪。這個是存儲，很簡單，就是一個存儲的池子，有兩個API，一個是往上傳的，一個是下的。這是一個很沮喪的結果，這么一群人聚在一起雄心壯志，想干一番事業。就發現你的事業就是這樣的，怎么辦呢？因為當時我們是菜鳥，我們并不能回答這個問題，云存儲這個平臺應該是什么樣的？今天你看七牛的文檔，它的功能很復雜。到底是怎么去變化的呢？我們七牛這幫人是怎么從這樣一個菜鳥能夠去深刻的理解怎么做云存儲的呢？
最核心的思路就是說我們對產品的設計是很克制的，從來不會去想象什么東西，完全是以客戶的需求為導向的，客戶需要什么我們就加什么？可能就隨著你客戶的種類越來越豐富，你的產品適用性越來越強。這個是我們的第一個客戶，那個時候還很流行刷圖片，很多的圖片在刷。他用了七牛，我們在上海附近做了第一個數據中心，這個客戶在北京。他說你們功能挺不錯，API也很簡單，當然確實是很簡單。但是就是速度太慢了，因為它追求的是流暢的感覺，經常是斷了，要加載一下下面一屏才出來。后來我們就反思這個問題，要加CDN的點，我幫你對下載做緩存，對上傳也要加速。對上傳加速比較難，因為它沒有什么可緩存，我只能從網絡上幫你做加速，這是我們第一次的迭代，加了一層CDN。是我們自己去做了一些機房，和我們的CDN合作的伙伴要了一些點，形成這樣一個變化。
這個加上之后，我們每天晚上都睡不好覺。這個機房做存儲的，數據肯定不能丟，你把所有東西都放在那個機房了，機房還是在海邊，很擔心。電斷了服務就不可用了，這個還好，電來了我還可以做。萬一來海嘯或者突然一天被雷劈了怎么辦？我們又做了一個迭代，唯一好處是讓我們在晚上睡的好一點。大概在一百多公里之外，在杭州又做了一個機房，又花了一些錢，找關系拉了一根裸光纖把兩個機房連在一起。其實連在一起就是一個局域網了，帶寬是一百多G級別的。在主機房上傳的數據我們異步實時的同步到備用數據中心，對下載來說還是從主機房去下載。但是我們會做一件事情，把主機房所有下載的訪問日志同時在備用機房播放一遍，保證這個機房所有的緩存是熱的。
所以你看到兩個機房帶寬圖是完全一樣的，假如說這個機房的電停了，或者說這個區域的網斷了，我們立刻通過DNS上傳下來的口切到這個機房，立刻就可以用。這個機房被類劈了和海水淹了，我們也有一份帶副本的數據在這個機房，數據的可靠性也能保證。
這個東西做好之后，我們就覺得挺完善的了，我們現有的客戶都滿足了，他們用的很開心，我們晚上睡的也安穩，挺不錯的。后來我們發現一些問題，你一直找那些創業型的APP，好像做風投一樣，一百家有兩三家做起來就不錯了。世界上真正有保有存儲數據的還是更成熟的APP或者是網站，怎么樣把他們的數據弄過來呢？我們發現挺難的，起碼它是幾個T。你也可以想象一下公司里的非結構化規模是怎么樣的，隨便一個APP跑一個月就是幾個T，大一點是PB的，傳的話要用四五年，肯定是不行的。
我們就推出了一款產品或者服務，大概是一個盒子，里面可以塞五六塊磁盤。我們就從我們的機房把盒子寄到我們客戶的數據中心去，借口是USB3.0的，插到服務器上導入這個硬盤上，叫快遞再寄回到我們數據中心。我們運維再把這個盒子插到我們的服務器上，再往我們存儲系統里面導，導完之后就可以跟客戶說你的業務可以切過來了，你的數據已經七牛了。
這個方式的工作非常好，你可以算帶寬，是很高的，而且成本很低。這么一個東西，寄快遞就像上淘寶似的，一二十塊錢就搞定了。但是它有一個問題，你數據量再大怎么辦？這個是五塊盤，按三個T是15T，如果是300T不能寄這樣一堆盒子，插也插不過來。怎么辦？我們就應該有更大的方案，寄機柜。不光是寄的東西變大了，方案也不一樣了。這個數據要導兩次，進了客戶的機房之后，從它的存儲系統里面往這個上面拷，放的是這個磁盤上格式化一個系統，按照一個文件一個文件的去擺放，回到我們這里再導一次。這個方案是導一次就可以了，因為它規模大，這個圖里面寄六個機柜，就是60臺服務器插滿3個T的盤，一臺機器插12塊。
我們認為這個東西發出去的時候，已經是我們存儲系統的一部分了。這個時候在客戶這里就導一次，導入的程序是我們來編寫的。當然這個時候不是用USB插，是連到局域網里面的。我們獲得了網絡可訪問之后就可以讀了，讀完了我們直接燒制成存儲系統里面，該怎么放就怎么放。這個東西再寄回去，往我們存儲局域網里面一放就立刻可以用了，速度變的非常快。磁盤也很多，整個六個機柜的吞吐比如每個用四根一萬兆的線跟現有的網絡對接，總存儲是很大的。
還有一個問題，它的數據是不斷有上傳的？通過這個東西把既有的東西搬過來了，快遞寄回來的時候又有新東西上傳，但是并不能切過來，訪問的數據是看不到的。我們又推出了鏡像存儲的功能，一個標準的存儲系統里面有三個文件，我突然去getkey1版必定是404。現在我把原來的數據中心建立關聯，我配置到上面以后，再getkey1的時候發現沒有了，在原來舊的數據有有。比如說寄快遞的這三天新上傳的文件就拖回去了，拖到七牛的數據中心，跟你新上傳的請求是一樣的，上傳到存儲系統，返回到外面，對客戶來說是透明的。
區別在于是它會把數據給你存下來，它把六個機柜寄過來之后，再配上鏡像存儲，下載這一塊的東西可以馬上切過來。隨著它切的時間越長，機房的訪問量越少，這個相當于是做緩存了，持久化的存在你的系統里面。
假如說客戶端是直接上傳到七牛的話，原來數據中心變成只讀的數據中心，鏡像存儲跑一段時間可以預期的是基本上就沒有訪問了，很平滑的把數據切過來了。后面比對一下原數據還缺哪些，這個數據量就很少了。
配合這三個東西，讓七牛把一些大的客戶，好幾百T的客戶給拉過來了。現在聊的是你新上傳的東西早晚要切到云，不能一直往你的數據中心傳。七牛的上傳方案是什么呢？所以UGC一類的業務不能容忍的一點是這個數據從我的客戶端到我的服務器，再從我的服務器到七牛，太慢了。它的數據中心是單個的，沒有做加速的，速度也會很慢。其實它期望的是客戶端直接跟七牛的服務器建立關聯，不能隨便一個人就傳，所以我們做授權的模型是客戶端跟客戶業務的服務器申請一個授權，這個可以是單次的也可以是批量的，比如說想上傳一百個文件，就把一百個文件的批量授權申請過來。在七牛的accesskey和secretkey傳，七牛用客戶的兩個kea去驗證是不是合法的。這樣就能夠做到客戶端和業務的服務器僅僅是有一些原數據的溝通，費流量的，慢的東西是客戶端直接切到七牛服務器的。
如果說客戶端直接往七牛傳就沒有它什么事了，作為業務最中心的服務器肯定是需要控制的，我們又加了一個功能是做回調。客戶端直接往七牛這里傳，返回到客戶端之前我們有一個回調客戶服務器的，如果可以我們再返回到客戶端。這樣業務的服務器就可以做很多的事情，比如我去做一個分享的鏈接、推送等等，就看它的業務邏輯是什么樣的。
下面這一塊是說七牛是怎么對數據做處理的架構圖，比如說刷圖片的APP，上傳的是原始的圖片，可能用手機拍攝的，大概是1兆到幾兆。但是都是幾KB的圖片，把幾兆用到客戶端縮小是非常不經濟的，面對這樣的需求有這樣一個集群，是專門做和運算相關的。比如說把一個圖片縮小、放大、打水印或者對視頻做轉碼等等，這是一個專門的集群。普通下載是跟最早的一樣，跟存儲集群下載。帶有數據處理的是根據計算集群的，從內部拖過來之后做完處理再返回到客戶端。
具體使用是這樣的，比如說這張圖片很大，就有一個參數，比如說是一百乘一百的分辨率。七牛的服務器最入口的時候看到帶問號的，并且是處理的。下載路徑就變成這樣了，把好幾兆的圖片加載到集群里面去，縮成一百乘一百的分辨率，再返回到客戶端。
下面是一個讓你的URL更好看一些，直接定義-small，這個語義和上面是一樣的。
還有一些很極客的東西，這是在我們數據處理里面也是能支持的。這是一個視頻，是對視頻第10秒做截圖，然后我可能想去縮小它或者打一個水印，這是另外計算的操作，我們就用一個廣告圖接起來，加上打水印或者做成一百乘一百，很實用。有的客戶URL拼的非常長，做了很多的操作。所有自定義操作都可以用管道的方式拼接起來。
剛才我們說計算2.0，是什么意思呢？剛才講的是1.0。因為最近做音頻和視頻的多了，比如說上傳的文件是AVI的，但是想在瀏覽器里面看，不能說幾百兆的視頻當場給你轉出來，肯定是很慢的。這一套主要是針對副媒體類的特別大的圖片，用單反拍出來音視頻之類的。這個工作是上傳一個三百兆的視頻，我在API配置對這個視頻做處理的異步任務。這個任務就會被扔到任務管理的集群里面去，或者你不是上傳出發也可以。比如說我已經存了這么一堆的視頻了，可以通過它的API直接添加這樣的任務，這兩個是一樣的。這里面其實是一個隊列，這個隊列的優先級和費用、CPO都可以配置，特別急就貴一些，不急就等半夜，很便宜。
調度之后會到數據處理集群，讀取到原始文件會返回來。我們做了一個持久化操作，你用什么文件名放到哪個目錄里面都可以配置，處理完之后會有一個業務回調。比如說你這個時候你就可以給用戶發回調了，比如說我轉碼已經完成，你可以發給你的朋友看了。
如果說沒有做完的，這個時候你添加的時候有一個任務的UID，比如說你還在排隊，前面還有多少人，估計多長時間做完，也是有這樣一個查詢的API。
時間關系，我后面就不講了。在中國到底是什么樣的人在用云存儲呢？到底是怎么在用？七牛做產品的風格又是怎么樣的呢？怎么樣一步一步從讓人很沮喪的圖，變成了我們自認為還是挺完整的存儲系統，希望這個話題對大家去了解和認識到國內云存儲和云計算的產業形態有幫助。
謝謝！
京公網安備 11010502049343號