以下內(nèi)容根據(jù)現(xiàn)場速記整理，未經(jīng)演講人本人確認(rèn)，或有疏漏刊物，僅供參考：
大家好，我今天談的內(nèi)容偏上層，也就是阿里巴巴怎么把閃存技術(shù)真正的應(yīng)用業(yè)務(wù)上面去。我在阿里巴巴做分布式存儲，我們的系統(tǒng)叫盤古，在阿里巴巴目前應(yīng)用在很多的業(yè)務(wù)上面。
上圖是我們的發(fā)展歷史，我們把這個叫統(tǒng)一存儲之路。
阿里巴巴做存儲可能跟其他公司不太一樣，我們真的做了一個存儲平臺，把各個業(yè)務(wù)統(tǒng)一起來，然后用同一套系統(tǒng)去支持這個業(yè)務(wù)。十年前我們開始做這個系統(tǒng)，隨后在2010年、2011年我們基于盤古系統(tǒng)發(fā)布了公有云的產(chǎn)品，像大數(shù)據(jù)的ODPS、ECS，還有我們的對象存儲OSS服務(wù)。
在2013年有一個關(guān)鍵事件——阿里巴巴的飛天5K項目落成。同一時代在阿里內(nèi)部還有其他的存儲系統(tǒng)在用，還有云梯1和云梯2系統(tǒng)，2013年把這兩個系統(tǒng)合并了，這是離線大數(shù)據(jù)上的標(biāo)志性事件。2016年，盤古2.0項目啟動等等。
阿里巴巴可能和其他做云產(chǎn)品的公司不一樣，對于我們來說，我們做這些新的技術(shù)，并不是讓大家去做小白鼠，阿里巴巴自己內(nèi)部關(guān)鍵的電商業(yè)務(wù)也是跑在同一套系統(tǒng)上。
比如電商交易的核心系統(tǒng)，比如雙11和雙12，大家在淘寶上下單，淘寶的數(shù)據(jù)庫、消息界面系統(tǒng)，都是由同一套系統(tǒng)來支撐的。我們的主力云產(chǎn)品包括ECS和OSS的存儲，也都是在我們的系統(tǒng)上。對于統(tǒng)一存儲，我覺得有幾個關(guān)鍵的業(yè)務(wù)特點：
第一，我們的規(guī)模非常大，應(yīng)該說阿里集團大部分的數(shù)據(jù)都在這個系統(tǒng)上。
第二，我們支持了非常核心的系統(tǒng)，內(nèi)部系統(tǒng)會和外部系統(tǒng)業(yè)務(wù)稍微有一些區(qū)別。
一方面，比如我們的業(yè)務(wù)系統(tǒng)的分布式架構(gòu)做的很好，因為它要面對雙11的沖擊，所以，要求系統(tǒng)能夠在短時間內(nèi)承受非常高的流量沖擊，需要你的系統(tǒng)有非常好的彈性。
一方面，云產(chǎn)品又稍微有點不一樣，云產(chǎn)品面對的是很多架構(gòu)上沒有那么好的公司，比如創(chuàng)業(yè)公司，他們的架構(gòu)比較簡單，但是對我們單個存儲或者單個OSS的可用性要求非常高，所以這兩個需求又有點不一樣。
同時受到這兩方面的驅(qū)動，我們做統(tǒng)一的存儲，用統(tǒng)一的技術(shù)服務(wù)這兩種類型的應(yīng)用。
為什么我們?nèi)ビ梅植际酱鎯鉀Q這些問題？
我講一個實踐例子，講一個今年我們用存儲技術(shù)支持雙11大促的例子。
上圖，今年雙11零點高峰期，數(shù)據(jù)庫對于分布式存儲的讀寫的圖，我們可以看到零點是一個標(biāo)志，到了0點之后流量開始上來了，到了0點30分流量開始下跌，是和之前差不多的情況。
所以，電商面臨這樣一個場景，我們到底要準(zhǔn)備多少臺機器去撐這個高峰，如果我們準(zhǔn)備了很多機器去滿足這個流量，那么這個流量只持續(xù)個把小時，那么這就是一種浪費。
所以，阿里在這兩三年一直在做一個叫做混部的技術(shù)，具體來說我們有很多應(yīng)用服務(wù)器是跑在線的業(yè)務(wù)，有另一些應(yīng)用服務(wù)器跑離線的業(yè)務(wù)。一般公司的做法都是在線業(yè)務(wù)比如數(shù)據(jù)庫、Web服務(wù)器都是延時敏感的業(yè)務(wù)，不能和離線業(yè)務(wù)放在一起。但是在阿里來說，面對電商雙11我們需要一個非常有彈性的系統(tǒng)，這兩年為了應(yīng)對雙11，我們能夠把離線業(yè)務(wù)的機器讓出來，讓它去跑在線應(yīng)用，等雙11這個高峰過去之后在線的應(yīng)用可以縮回來，讓離線的業(yè)務(wù)利用在線的機器完成自己的工程。
這樣一件事有很多挑戰(zhàn)，對于存儲來說意味著什么？挑戰(zhàn)在哪里？
我覺得有兩點：一個是在線應(yīng)用和離線應(yīng)用對于存儲要求完全不一樣。在線應(yīng)用現(xiàn)在SSD可以做到幾十微秒的延遲，離線應(yīng)用只要吞吐大、容量大就好。
有一些應(yīng)用是沒有狀態(tài)的，比如跑一個Web服務(wù)器，它在本地存儲的數(shù)據(jù)就是它的程序文件，運行時它可能有一些文件緩存，程序運行起來可能會打日志，這些東西都是當(dāng)程序從一個機器遷到另一臺機器做擴展時可以丟掉的，是可以重新從遠程拉起來的。
另一些程序是有狀態(tài)的，比如說數(shù)據(jù)庫，數(shù)據(jù)庫在本地有它的數(shù)據(jù)，消息隊列有它的數(shù)據(jù)文件，如果要做擴展，你需要把這個數(shù)據(jù)遷移到另一臺機器，過程很耗時，并且沒有什么彈性，你需要事先準(zhǔn)備很長時間。這兩點使得我們在做混部時，對存儲提出了很大挑戰(zhàn)。
怎么解決這個問題呢？
我們有一個概念叫做存儲和計算分離。老話說30年河西30年河?xùn)|，以前用企業(yè)存儲天然就是存儲和計算分離，現(xiàn)在我們又回到了這樣一個架構(gòu)。我們的在線服務(wù)器也不去寫本地的盤，單獨搭一個存儲的機器，把這些機器分成存儲和計算兩種，存儲專門放數(shù)據(jù)，上面不跑業(yè)務(wù)。計算上面跑業(yè)務(wù)，用計算節(jié)點的CPU資源、內(nèi)存，但是它不去寫本地的盤。這樣高峰到來，我們很輕松地把一些計算任務(wù)從一個計算的節(jié)點去彈性彈到離線的服務(wù)器上，峰值過去之后再縮回來。
有了存儲和計算分離后，數(shù)據(jù)就不用寫本地盤了，而是寫到遠程分布式存儲，這對于分布式存儲來說不太容易做到，但還好，隨著業(yè)界技術(shù)的進步，我們有了高性能的網(wǎng)絡(luò)和閃存，分布式存儲在一些方面上做的并不比本地的盤差，甚至在某些方面做的更好。
具體在哪些地方比較好呢？
首先，可靠性來說，分布式存儲天然就在做機器之間的冗余，可以打造更好的可靠性。
從性能來說，我們用了一些比較新的技術(shù)，用戶態(tài)的一些技術(shù)，能夠使分布式存儲和本地的盤達到差不多的水平，同時，因為分布式存儲后臺是一個大的資源池，對于特定的應(yīng)用，比如說當(dāng)IO集中在一塊盤上或者幾塊盤上，小部分的盤的時候，可以利用更多的機器來完成這個。在這種場景下，會比本地的盤更好。
成本方面也有彈性，當(dāng)你去用本地盤的時候，你會面臨容量規(guī)劃的問題，可能1%的情況下，某個程序有問題把盤用滿了，可能會引起整個系統(tǒng)的崩潰。在分布式存儲的情況下，它是一個資源池，容量規(guī)劃的時候更簡單?？梢园巡煌脩舻谋P，放在一個大的池子里，這樣一來，空閑的空間就會比較少。
我挑幾點詳細介紹一下。
第一點，當(dāng)我們做大規(guī)模糾刪碼的實踐，在傳統(tǒng)存儲對應(yīng)的就是做Raid的糾刪碼，但是Raid給人的印象是，這個東西比較慢，恢復(fù)的比較慢，恢復(fù)的過程會有損等等。當(dāng)你把這個問題放在跨機器的集群很多事會變得比較好辦。我們可以跨機器去做糾刪碼，我們可以跨網(wǎng)絡(luò)交換機做糾刪碼，甚至跨可用區(qū)做糾刪碼。我們會找一個城市，找三個地方，在三個地方之間搭機房，用比較快的網(wǎng)絡(luò)?？梢园岩徊糠?jǐn)?shù)據(jù)做糾刪碼，分在三個地方。
做糾刪碼的時候可以用更多的數(shù)據(jù)塊等等把這個做的更安全。我們線上基本采用的都是N+3，任何三塊盤死機我都不損失數(shù)據(jù)。同時因為池子變大了，所以，我們是在幾百、幾千臺機器的規(guī)模上去做糾刪碼。當(dāng)你一個節(jié)點死機的時候，我會有成百上千的機器做恢復(fù)，所以，可以解決傳統(tǒng)陣列恢復(fù)時間慢、有損的問題。
下面講分布式存儲的可靠性給業(yè)務(wù)帶來什么。
我們知道，在阿里自己的業(yè)務(wù)和云不太一樣，阿里自己的電商業(yè)務(wù)本身就是分布式的，是一個多地域、分布式的很多小應(yīng)用組成的系統(tǒng)。為什么這個時候還需要做存儲的分布式？以數(shù)據(jù)庫為例，數(shù)據(jù)庫非常有代表性，很多人首先覺得做分布式數(shù)據(jù)庫很難，基于MySQL做存儲計算分離也不太容易。
阿里在很多年之前就開始了去IOE進程，去IOE之后就走向了MySQL分庫、分表的架構(gòu)上。為什么做分庫分表？這因為MySQL單機的性能是受限的，隨著業(yè)務(wù)的增長必須用多臺機器去做，與此同時，為了解決單機的可靠性、可用性的問題，MySQL還去做主備，當(dāng)主死機以后可以馬上切備庫。同時在MySQL用本地盤的時候，還會給盤做Raid，進一步增加盤的可靠性。轉(zhuǎn)到分布式存儲之后，其實它解決的是數(shù)據(jù)可靠性問題，但是并沒有解決業(yè)務(wù)的可用性問題。
在業(yè)務(wù)層和存儲層，大家各司其職去擴展。存儲層專注于解決數(shù)據(jù)本身的高可靠、高可用問題。而MySQL應(yīng)用層，專注解決事物處理、擴展一致性的問題。
通常認(rèn)為分布式存儲是要走網(wǎng)絡(luò)，傳統(tǒng)本地存儲是直接用PCIe這樣的高速連接去連到存儲，分布式存儲然的弱點就是接入網(wǎng)絡(luò)，分布式存儲因為數(shù)據(jù)要寫多份，要跨故障率去寫多份，網(wǎng)絡(luò)的鏈路就會更長。
得益于現(xiàn)在用戶態(tài)技術(shù)的發(fā)展，前面雖然分布式存儲有很多好處，但是性能是一個硬的限制，一旦性能滿足不了要求，前面各種優(yōu)勢，在業(yè)務(wù)方面都沒有體現(xiàn)。
具體來說，我們用用戶的軟件棧做的事情就是采用Run-to-Completion的線程模型，這個過程中單機內(nèi)部沒有線程切換，沒有鎖、沒有口，我們把這些東西都去掉了，能夠達到非常好的性能。
同時因為分布式存儲自身的特點，它是基于這些不穩(wěn)定的硬件搭建出一個穩(wěn)定的系統(tǒng)。
總結(jié)一下。
在阿里巴巴做存儲，其實同時支持了自己內(nèi)部電商的應(yīng)用以及云的應(yīng)用，這兩部分應(yīng)用稍微有一些區(qū)別，在電商的應(yīng)用來說，我們更看重彈性，在云的應(yīng)用我們更看重單個實例的服務(wù)質(zhì)量?？傮w來說，做一個平臺，平臺需要承上啟下，我們希望能把在座各位在硬件方面做的工作帶來的發(fā)展的紅利，最終帶給我們的業(yè)務(wù)，謝謝大家！
