很高興有這個機會跟大家交流阿里巴巴在云計算的探索，部署的過程中跟服務(wù)器、軟硬件相關(guān)的嘗試摸索。介紹一下服務(wù)器開發(fā)、驗證、軟硬件優(yōu)化過程中我們遇到的一些事情。先做個廣告，最近一個里程碑事件，對于阿里云來說，付費的用戶數(shù)量首次超過100萬，對阿里是個比較大的事情，這是亞洲首家超過100萬用戶的云計算公司。

簡單回顧一下云計算業(yè)務(wù)的發(fā)展以及這些發(fā)展對于基礎(chǔ)設(shè)施服務(wù)器、網(wǎng)絡(luò)、存儲的新要求，技術(shù)方面大家比較熟悉了，這里舉的一個例子是網(wǎng)站的業(yè)務(wù)發(fā)展的過程，最開始如果我們要做一個網(wǎng)站的話，簡單來說需要有一臺或者幾臺服務(wù)器的主機。隨著我業(yè)務(wù)規(guī)模的擴大，我需要把我的數(shù)據(jù)庫獨立出來，同時如果服務(wù)器數(shù)量越來越多，可能要考慮負載均???????，如果數(shù)據(jù)庫的業(yè)務(wù)獨立出來之后還要考慮緩存的事情，要考慮數(shù)據(jù)庫的安全性、可靠性。如果我的業(yè)務(wù)數(shù)據(jù)繼續(xù)增加，對于數(shù)據(jù)的存儲有新的要求，需要有獨立的存儲技術(shù)，包括分布式存儲、針對某些特定應(yīng)用的結(jié)構(gòu)化的存儲。隨著我的業(yè)務(wù)的規(guī)模越來越大，我可能要擴展到全國對于全球，對網(wǎng)絡(luò)會提出一些新的要求，比如為了更好的客戶體驗，降低成本，需要內(nèi)容分發(fā)??絡(luò)??隨??數(shù)據(jù)進一步增加，最后還需要有處理大數(shù)據(jù)的專用的業(yè)務(wù)。

在業(yè)務(wù)發(fā)展的過程中，不同的應(yīng)用對于基礎(chǔ)設(shè)施服務(wù)器來說會提出不同的要求，比如有些對成本特別敏感的業(yè)務(wù)，對于數(shù)據(jù)庫的業(yè)務(wù)，對于性能要求是多少，彈性存儲的各種業(yè)務(wù)，對于可靠性要求是多少，海量的服務(wù)器在數(shù)據(jù)中心運維的要求是什么樣的。都在我們設(shè)計服務(wù)器開發(fā)驗證流程中提出各式各樣的要求。對于服務(wù)器的實現(xiàn)來說，在具體的配置???????我們會有不同的具體配置，偏重主頻的、大IO的、大容量存儲的、高內(nèi)存的，這幾年又發(fā)展出很多新的異構(gòu)計算的加速計算的。

舉一個例子，以計算和存儲來說，IT技術(shù)發(fā)展過程中計算和存儲一直是分分合合的，2007、2008年左右做云計算的時候一個比較主要的共識或者當時主流的做法就是需要本地化，計算的資源和存儲的資源盡可能靠近，盡可能減少獲取數(shù)據(jù)的成本，很多時候會把計算和存儲做在一個物理上本地化的資源池或者盒子里，同時盡可能的把計算和存儲的能力同時都往最大的方向做。當時很多業(yè)務(wù)的架構(gòu)，用單一的集群大容量存儲加上高性能計算可以滿足很多當時業(yè)務(wù)的需求，隨著接下來幾年行業(yè)的發(fā)展，特別是北美互聯(lián)網(wǎng)行業(yè)的發(fā)展下面，因為計算技術(shù)的發(fā)展、存儲技術(shù)的發(fā)展，NVMe，網(wǎng)絡(luò)技術(shù)的發(fā)展，數(shù)據(jù)獲取的成本大幅度降低，現(xiàn)在比較主流的是計算和存儲分離的架構(gòu)。傳統(tǒng)的集中式的存儲都是在主機里面，通過共享的交換機連到其他遠端的服務(wù)器上去，大部分數(shù)據(jù)的處理和備份都在同一個交換機下面完成。計算資源在物理上集中的放在某些機架位上，通過特定的交換機連到遠端的存儲資源上。在這些架構(gòu)變化方面我們會遇到各種各樣的問題，各種各樣的挑戰(zhàn)，其中有一個印象比較深的是在最早嘗試這樣架構(gòu)的時候，我們在不同的物理機架位上我們放的是計算資源比較集中，我們典型的業(yè)務(wù)部署上去的時候發(fā)現(xiàn)存儲節(jié)???????的交換機的帶寬很容易被打滿，丟包率和重傳率都非常高，因為我們的業(yè)務(wù)對于同一份數(shù)據(jù)會有多份副本拷貝的設(shè)計，在新的架構(gòu)下面，在副本拷貝的過程中會發(fā)生比以往多的多的拷貝的失敗，會重新發(fā)起副本的重傳，這樣會進一步加劇網(wǎng)絡(luò)上帶寬的浪費，因為有更多的包會倍發(fā)出來，又有更多的包被丟掉。

遇到這樣問題的時候，我們現(xiàn)在有幾個不同嘗試的解決方法，比如我在交換機這一側(cè)可以選用我的端口的buffer，更大的交換機直接換硬件。這個會帶來硬件上的變化和成本上的變化。還有一個嘗試，我們嘗試把一定比例的存儲節(jié)點和計算節(jié)點在同一個機架位上混合部署，通過和實際的應(yīng)用業(yè)務(wù)做聯(lián)合的調(diào)試，比如以四個計算節(jié)點配一個存儲節(jié)點的比例???????部署的時候，以八個計算節(jié)點配一個存儲節(jié)點的比例，在不同的比例加上業(yè)務(wù)實際的部署情況下，可以逐步降低重傳率提高業(yè)務(wù)的效率，這是優(yōu)化前和優(yōu)化后的重傳率的數(shù)據(jù)的對比。另外一個遇到的問題是配置分布式存儲之后，在磁盤的吞吐率上面我們發(fā)現(xiàn)進行大文件大壓力寫的時候磁盤吞吐率達不到預(yù)期，大量內(nèi)存回收操作，cgroup內(nèi)存策略，夠用就行，內(nèi)存策略調(diào)整，釋??性??，??化成本。存儲節(jié)點里因為可以調(diào)整內(nèi)存上限，可以得到在系統(tǒng)架構(gòu)下面最大的需要內(nèi)存的物理空間的值，針對具體的存儲節(jié)點做內(nèi)存的優(yōu)化，比如最早我們給某個節(jié)點做系統(tǒng)架構(gòu)的時候選了512G的內(nèi)存，優(yōu)化下來發(fā)現(xiàn)源源不需要這么多內(nèi)存就能讓它達到原來預(yù)定的磁盤的性能，這樣可以節(jié)省一大筆內(nèi)存的成本。

某一個業(yè)務(wù)上我們發(fā)現(xiàn)同樣的架構(gòu)下，IOPS的性能測試的時候發(fā)現(xiàn)小塊讀寫性能達不到預(yù)期，大概是預(yù)期的60%，我們研究這個架構(gòu)計算節(jié)點和存儲節(jié)點比，比如原來是8比1的比例，每個計算節(jié)點寫了50個進程，有400比1可以配比，400比1相對來說還是偏小的比例。我們對所有的IO的分布，包括大小、時間，都做了統(tǒng)計，發(fā)現(xiàn)絕大部分的讀寫都是小塊的讀寫，???????們在計算節(jié)點下做了一些優(yōu)化，計算節(jié)點本身有一些小容量的SSD，我們根據(jù)具體業(yè)務(wù)把SSD容量換成NVMe的SSD，根據(jù)統(tǒng)計到的讀寫特征，把大部分的小塊的讀寫都放在了本地的NVMe的SSD上，把大的放到遠端的IO上面。滿足性能的條件下硬件成本的變化還是可以接受的。

現(xiàn)在我們在云計算業(yè)務(wù)高速發(fā)展的時候做的服務(wù)器開發(fā)工作跟原來有很大的不一樣，幾年前我們行業(yè)里大部分做的都是非常按部就班的，從方案開始，有比較長的研發(fā)過程，研發(fā)完之后在我們的業(yè)務(wù)適配有一個引入的過程，最后才會大規(guī)模的部署，每個業(yè)務(wù)都會幾個月來計，但現(xiàn)在在業(yè)務(wù)飛速發(fā)展的情況下大部分工作集中在后面的融合過程里面，在研???????其沒有結(jié)束沒有完全量產(chǎn)的情況下我們就已經(jīng)開始跟我們的業(yè)務(wù)做適配性、兼容性的測試，線上實際小規(guī)模的做一些部署，可以并行的流程早一點開始。引入的時候也做了一些調(diào)整，原來有幾個不同的階段，實驗室、小批量、灰度，分別針對阿里自己的線上的監(jiān)控業(yè)務(wù)、監(jiān)控的工具、運維的工具、業(yè)務(wù)的操作系統(tǒng)應(yīng)用的適配，現(xiàn)在都會做一些適當?shù)牟脺p，甚至有更激進的做??，??本??可以理解成我們縮短40%的引入時間，從一個項目立項大最終商用對外發(fā)布大大縮短。

對于新的融合的流程來說，我們的目的還是一樣的，我們希望上線的產(chǎn)品有足夠的可用性和可靠性，這些目標我們不會降低，同時我們希望繼續(xù)提升客戶應(yīng)用的實驗體驗，同時希望優(yōu)化成本。項目經(jīng)理們經(jīng)常掛在嘴上的話，又要快又要好又要便宜，這種事情是很難發(fā)生的，大部分我們都要為這個做出一些取舍，做出一些犧牲，今天的分享就到這里，謝???????大家。