雲端數據處理，讓服務更輕—龐向才（1213開發者實踐日）

【龐向才】：今天介紹七牛繼續作雲端這樣數據的一些事情。

第一個簡單聊聊計算自己的一些事情，過去從PC開始用起的時候，那時候單機系統比較多一點。像2000年左右的時候，對於咱們作外部的應用、作單機的一些應用，基本上那時候數據也比較low一點，沒有接觸太高大上的系統。那時候全部的東西都設在單機上面，而後包括數據庫，那時候尚未Git。好久之前沒畢業的時候，在北京一家公司作兼職，作系統運維相關的工做時，系統比較亂，一臺機器只有幾十G的硬盤，都堆在上面。再往下面到了hadoop階段，這時候分佈式的文件系統，除了本身沒有開源之外，會有各類實現。

對於hadoop來說話，它數據自己是公佈的，它的框架裏面是說我計算的代碼能夠用各類語言實現。你能夠調動各類不一樣的任務，而後來執行。總的來說就是讓計算離數據更近一點，整體來說這個東西要越近越好。而後如今比較火的就是spark了，由於咱們的量實際太大了，一天XXX億的請求，分到內部的子系統裏面去，又差一個數量級的產生。咱們爲了監控系統的穩定性以及性能的達標，日誌基本上要作準時的分析。可是完成的時侯是很難的，好比說要特殊監控的地方，要否則這些東西都會導入到分佈式的系統裏面去，再作準時的分析。如今七牛在雲端基本上都存HTTP系統協議，七牛也好，包括其餘友商，基本上沒有例外的。

數據放到雲端之後，就會帶來一個問題，你好比說拍了一個裸圖，800像素的就是兩、三兆的大小。相機能夠表中圖、大圖、小圖，原始圖片放上去之後，基本上在國內的3G狀況下你無法看。最後的需求仍是說能不能把圖放得小一點，手機屏幕夠看就能夠，剛恰好符合手機屏幕的一個尺寸。最後就是說你有這種需求，可是數據離你很遠，你又想看，免不了作一些數據的處理。咱們經過HTTP的方式，給它發個指令，讓它處理完之後的結果，經過XX協議返回。

計算整體來說，右邊的圖畫得比較草，就是三個框。計算機體系從20年前到如今都沒有實質性的改變。從CPU到各類全部的加速卡，我要不想辦法，摩爾定律那樣頻率翻一番，快到必定的程度就沒有辦法了。後面就是說怎麼少概念？不少人要去重複的，可能不一樣的緯度、時間訪問同一個處理過的數據。後來就上cache，從CPU一、二、3級的cache，而後到你如今Web服務作得比較多的，我先簡單的單機系統，這樣的話我數據庫抗不住了，我就上radis之類的。對於雲端在作這些事情的時候，框架搭得更大一點，各家有各家的作法。好比說有些東西從一些慢盤取完之後，所謂的分級存儲。我只是說數據訪問了一次，第一次可能在很慢的三個盤上面，有第一我的訪問之後，這個數據就激活了，而後就會轉移到SASP上面去。而後小文件都會控制在一百納秒的樣子，而後就能夠從盤上讀出，剩下都是網絡。如今網絡很快的，每秒鐘處理包能夠處理幾十萬、百萬，應該是沒有問題的。包括數據存儲過程的開啓，這些東西主要都是爲了加速用的，讓你的感受更好一點，變得更快一點。可能大家的應用裏面也會用到，好比說我一臺機器的計算資源是有限的，我內存多是32G，服務端如今高一點，幾百是確定的。固然如今移動端的手機都是flash的芯片，僅僅是讀取之類的仍是很快的。可是一旦涉及到計算結果，放內存仍是好一點。

如今來說這不是高大上的內容，這都是一些比較現實的東西。實時性的一些處理，由於可能前兩天陌陌上市了，你們都知道陌陌的數據不少都在咱們這裏，他們爲了縮減流量，就是說數據流。一張圖片可能要XXK，小的也是幾K的樣子。

國內帶寬很貴的，用戶在家裏收了錢之後，運營商還要收錢的。你上陌陌，同時不少人聊天，你手機流量會耗得很快的。另一端從運營商機房裏頭，全國是數千個節點。他們會以峯值給你打個XX折，可是你峯值很不穩定。這種狀況第一就是說避免波動，第二就是說讓傳輸的數據變少。原始的圖片放上去，最後你要加速他的訪問。你刷個圖片，刷5秒鐘刷不出來，可能最初懷疑本身網絡慢，你換了個應用刷一下，無論哪家應用來講，刷圖片過久刷不出來，又證實網絡是好的，你開始罵這個應用太差了。好比說移動網絡用3G，3秒、5秒你圖片能刷出來，由於國內的網絡覆蓋不大一致，延遲、波動都是難以免的。

我以爲國內的應用比較容易作，由於你們容忍度比較高一點。由於上下班中間要排隊，吃飯要排隊，排多了可能都適應了。可是實際上你實時性真的很好的時候，你以爲好爽好流暢。機器好壞明顯有區別的。實時性的響應，當前就是保證起來，就像那頭殭屍同樣，你每個問題可能都是一大波殭屍，須要付出代價的。當前好比說像美拍的應用，還有一些其餘的遊戲分享，就是遊戲我在手機上錄完之後，後臺傳輸，過個10秒鐘你就能夠分享了。分享完了，夥伴們就能夠看你錄下來的很帥的記錄。這種實時性要求高，從後端數百千米，數千千米的機房，經過各類路由器，最終到你小區的局域網，這條路是很長的，環境比較難控制。到真正的服務端，它必須數據要快，這就是雪上加霜。而後高吞吐，若是你們作服務端的話，你作APP有幾千、幾萬用戶的時候，可能和數據庫有需求的時候，或者說和圖片有需求的時候，你一秒鐘一臺服務器支個幾百個KPS了不得了。這種狀況下，怎麼保證性能的響應依然是良好的？量大，自己就是說小圖片太碎了。單機的系統來說，早年用過windows的人可能比較明顯，如今不少都有固態盤要好不少。之前沒有固態盤的時候，無論你臺式機仍是筆記本，裏面的碎片多一點的時候，你搜索、查詢一個文件會愈來愈慢。這個東西的複雜度和量是直接關係的。我之前作相對底層的文件系統，就是說你從陌陌結構，你的整個文件系統就像數據庫同樣。你的文件名、你的路徑，都是存放在某一塊區域，你的數據是被安排到另一塊區域，找的時候就像一顆樹同樣，用樹來找的已經比較快了。而後一層一層地找，你訪問一次之後，你下一次訪問就會變快。由於你的目錄樹都已經開啓在裏面了，這東西很重要。若是當前作服務端的話，用linux比較多，它的各類內存的配比都是幹什麼呢？可能你90%的內存都被page Cache耗掉了。其實不是系統能夠，也不是磁盤能夠，是他們的數據組織還能夠。右邊針對這些上面的全部的需求來說，複雜度都很高，你們知道創意、技術團隊其實人員是有限的。數據量多了之後，你須要找一個專門靠譜的地方幫你打理。

咱們看下一頁，若是有這些需求，特別是說你需求無論多複雜，你量少的時候都不是問題，量一變大都是問題。在國內作實時性的業務，有一大堆的坑。

咱們服務端爲了讓這些坑裏面跳得快一點，你服務端基本上必定要快的。你最終數據出去的地方必定要快。那就是說基本上最好的CPU，都放過來作計算，能減小一毫秒就是一毫秒。由於不一樣的CPU的主屏，都會影響處處理這些事。高效果Cache，在你數據計算正常的狀況下，把它塞到Cache裏面去，下一次不用再算了。可能說你們從手機上訪問到的全部的，可能你永遠不是第一個刷到這些內容的人，你基本上都會很快的。而後在原來的地方，你要有大容量的出口。若是你用過虛擬主機或者如今就買雲主機的話，雲主機就是VPS。都會有帶寬的一個限制，是共享的仍是獨佔的？獨佔可能比你主機還要貴。用戶一旦多了之後，就會擁擠。你的APK一下就是幾十兆，你瞬間其餘用戶就會有影響了。某服務商實際上都有限速，我儘量把數據快地推到用戶手裏，你不會作限制的。無論用哪家服務，出口帶寬如今都是按10GB去算的。一根光纖10GB，扯上10根、8根的。這樣子保證出口必定是靠譜、穩定的，而後延遲是4GB的。

下面就是說只有一個點快是不行的，由於大中華的局域網很是複雜，電信連不通聯通的。北方聯通到南方聯通，天天每一個時候還會堵一下。這些可能還不可控，最終只能說從更大層次的方案上面去規避。比方說北方的客戶用北方機房，南方的客戶用南方的機房。不是黑他們，確實不好，有些小運營商到你的節點路由都不通，這些須要專門的人幹。像國內的幾家CDN服務商，不少都是布點公司，在各個機房和運營商那邊都擺上他們的服務器，保證你的服務可連通性。他們的節點到你網站的快慢速度，到你當前用戶所在的位置，無論你用電信仍是聯通的3G、4G，你第一跳跳到那個節點，直接決定了你這一把網絡的快慢。這些東西都比較重要，也有一些自建的節點，可是在管理上主要靠CBD保證這些事情。處理這一塊上面說靠本身來保證，或者說放雲端，靠雲端來保證。

順便說一下咱們如今純作數據處理的服務器，線上在跑的就有幾臺，有些客戶的量太大了。簡單、高效的方式就是擴容，都說互聯網公司都是不差錢嘛。剩下的就是說簡單講一下坑吧，就是說什麼叫實時的處理呢？你在服務端秒之內能處理完，這算實時的請求。若是你在服務端一秒鐘能處理完，我以爲這基本上不算實時了。若是有界面的一些應用，沒有界面的還好，可能說是一些任務了。若是影響體驗的話，我以爲服務端處理絕對不該該超過一秒，超過一秒絕對是故障了。無論用哪一家的語言，用數據處理也好，用什麼服務也好，若是超過了一秒，用戶體驗受影響了，這基本上是必然的，由於路很長。若是數據都很小，而後你的數據自己的包括你可能有些實時的計算，好比說打個縮略圖，第一次訪問的時候，這種狀況下你用實時的處理都是沒問題的。這樣的話同步，你就坐等結果回來，這樣的邏輯簡單不少，就是這樣等就好了，這是最簡單的。可是有些東西一旦是說你訪問過之後，這樣子你又掉到下面一個坑裏面去了。主要是說CBD的緩存，常常有更新的狀況下，你對同一個文件更新，你發現更新完以後，你的用戶依然沒有刷出新的。你清完Cache，發現刷出來仍是老的。這樣的話，CBD他的運營商的節點很是多，自己是互聯網數據通道了。這種狀況下，可能一個小文件，要不就是你是他的客戶，去找他實時的刷新，可是它仍是有故障。他放上去的Key是同樣的，咱們默認第一天重複，次日從新拉一遍。搞了好幾天，看一下仍是很早之前的。它確實是某CDN，由於某些緣由沒有更新掉。你要作活動，你把主頁都換掉了，結果你刷了幾天仍是原來的圖，這樣人家會很傷心的。好比說你更新你全部的展現資源，你就索性用不一樣的名字，這是最簡單的。由於CDN的緩存通常都是靠URL，以及有定製的話，就是URL的某一段來緩存的，來識別你的內容是否是有變動。或者有沒有新內容須要緩存。這種狀況下，你乾脆把它淘汰掉，換數據的時候順便換名字。名字你隨便起一個，由於圖片的URL用戶歷來不會看。這種狀況下，你對你的實時性，包括你的整個內容的更新是放在本身手裏的。用戶刷你的源站，你的用戶服務器變掉了之後，就不存在刷新的問題。這多是咱們全部的客戶，包括全部的合做夥伴平時遇到的小煩惱，經過人工流或者特殊的途徑，去把你網站上的垃圾清掉是能夠的，只是過程比較久一點。主要就是說緩存這個坑，只要幫你加了速，你的應用就在這個區，可能有某CDN的服務器就在上海某個機房。一旦時間長了以後，就是說你更新的東西，他沒有更新，這樣也很坑。就是說也算是一種平衡吧。

而後這個題目起得比較矬一點，沒有細想。比方說你拍完了一段手機的錄屏，好比說今天這個活動下來，咱們視頻可能之後也會放在網站上分享。這種狀況下，它消耗是比較高的，以致於你用最好的CPU，也不可能把它在一秒鐘內處理完。這種狀況下，就可能要引入一套異步的機制。當前爲了兼容性也好，門檻也好，一些傳統的很老的一些協議，可能在互聯網時代都被拋棄了。好久之前家裏面都有機頂盒之類的，就是說有線電視的，他們走的一些協議都是很是複雜的。

包括數據流的協議，都是很是複雜。如今手機打電話，這套通信協議，學計算機的都知道是相對複雜的協議，這是保證可靠性的代價。電話費降不下來，運營商告訴你是由於什麼什麼，這是一方面。最後你可能異步化掉，你沒辦法作的，你發出請求，他告訴你收到請求了。最後結果要繼續查或者等通知，你去XX機關，告訴你XX工做日之後來取。最近咱們公司說去旅行，而後就有不少小夥伴連護照都沒有，由於剛畢業，也沒有出去過。辦護照，你就提交材料，告訴你15工做日就15工做日。早一天過去查，他們說尚未，看日期，明明還沒到你就來了。要麼就是坐等，要麼就是沒事去查一下。這樣會帶來應用層面的一些複雜性。這種東西要提早預料好的，你爲了本身的可控性以及體驗，就要這樣作。前天晚上咱們有一家廈門的客戶，是哪家不能說，凌晨一點50分左右，我在公司處理其餘公事，他們說他們的服務器掛了，從他們的老闆打到他們的CTO沒有一個接通的。最終從角落裏找到他們的銷售，那哥們的電話終於接通了。無論哪家雲服務，涉及到回調任務的，要仔細檢查每一個流程是否是穩定和可靠。由於對某些用戶來講，多是丟數據，這個問題比較嚴重。咱們正常來說一次回調不成功，再重試，好比說一個小時回調不成功，就再也不重試了。

剩下的都再也不細講了，反正就是注意回調裏面的坑。這個是處理完之後，你要從新再拿，以備後期本身拿。把Cache另存一個文件，而後方便本身去處理。這邊還有一些所謂的多樣化的應用，咱們客戶接多了。有些不能算奇葩類的公司，好比說有些公司JPG的圖片壓縮過了500M。可能一張圖片須要幾十G的內存，可能它一個圖片要切成5百萬份之類的事情。可是有點誇張了，切成幾千份是有的。數據的多樣性和應有性，每家雲公司都會提供一套基礎的支持，讓大衆接近的應用，可是有些很難接。

這邊有一些雲平臺做爲一個框架，做爲你有儲存接口、計算接口，咱們但願真的是有用戶有本身的開發能力，有特殊的需求，能夠定義本身的數據處理邏輯。

可是用戶說去咱們機房買一個處理器是能夠的。可是結果你要運維、機器所有覆蓋，這個流程作起來很累。而後咱們容許用戶把自定義程序打包完，放在這個框架裏跑。流程同樣，接口同樣，只是說command換一換。用戶的應用處理完之後，進入到指定的框架，讓用戶以插電的方式體驗本身的邏輯。

東西仍是這些東西，只是說但願你們若是有需求，能夠用服務來實現的，就不要本身來搞，這個事太累了。咱們累一次就能夠了，包括其餘的雲公司同樣的。信息處理就是數據加計算，如今主要是消費型的數據比較多一點，互聯網客戶這邊。傳統客戶可能有歸檔類的，爲了安全用來備份類的都有。但互聯網類的主要是用來消費的比較多，給客戶直接提供一些服務。這樣你們選儲存或者選服務商的時候要關注一些東西，爲了後期的一些發展。好比說會不會由於接口太複雜，接進去就出不來了，仍是基礎的服務不能知足要求，或者說給你制定一個計算的能力。

PS：開發者最佳實踐日·第8期－互聯網產品從設計到上線 北京站
報名地址：http://qiniu-8.eventdove.com