什么是云計(jì)算,？維基百科是這樣解釋的,，“云計(jì)算是基于網(wǎng)絡(luò)提供的按需的、共享的,、可配置的計(jì)算以及其他資源”,。

圖表1是云計(jì)算的“例行”組成，IaaS將計(jì)算,、網(wǎng)絡(luò),、存儲抽象后提供資源級產(chǎn)品，PaaS將資源操作封裝后提供應(yīng)用級產(chǎn)品,，SaaS將1個或者多個應(yīng)用封裝后提供服務(wù)產(chǎn)品,。

圖表1 云計(jì)算構(gòu)成

然而， 筆者認(rèn)為這不是“什么是云計(jì)算”的答案,，而是“云計(jì)算是什么樣子”的答案,。通俗一點(diǎn)，這個回答方式類似,，問“中華武學(xué)是什么”,，答“中華武學(xué)是詠春拳”。

那云計(jì)算的“神”是什么,，筆者會以當(dāng)前云計(jì)算的領(lǐng)頭羊AWS的成功實(shí)踐為依據(jù),，嘗試回答這個問題。

在1999年HighPerformance Transaction Systems Hybrid Systems conference 中一篇題目為“Fault Avoidance vs. Fault Tolerance: TestingDoesn’t Scale”的論文觀點(diǎn)認(rèn)為：軟件設(shè)計(jì)應(yīng)該可以容錯,，而不是努力的通過大量測試而避免錯誤,。因?yàn)檐浖膹?fù)雜度越來越高,，代碼量越來越大，會導(dǎo)致軟件質(zhì)量下降,。而模塊化設(shè)計(jì)不能減少復(fù)雜度,，同時測試也覆蓋不到所有復(fù)雜的，相互關(guān)聯(lián)的特性,。

在2009年 SIGCOMComputer Communications Review 中另外一篇 “The Cost of a Cloud： Research Problems in DataCenter Networks”  的論文,，提出兩種建設(shè)數(shù)據(jù)中心的思路。一種是建設(shè)10萬臺+的超大規(guī)模數(shù)據(jù)中心,，有更好的性價(jià)比,，但會有資源碎片等副作用。另外一種是圍繞著最終用戶建立一系列小型數(shù)據(jù)中心,，會有好的訪問延時,，但數(shù)據(jù)中心之間的互聯(lián)會十分昂貴。

接下來我們看AWS是怎么做的……

圖表 3 AWS實(shí)例規(guī)格統(tǒng)計(jì)

結(jié)合圖表3,，AWS的金牌合作伙伴RightScale發(fā)布的，關(guān)于其代維的AWS云主機(jī)規(guī)格統(tǒng)計(jì)餅圖,，我們可以看到1核~2核規(guī)格的云主機(jī)是主流,，占據(jù)了近70%的比例。按照常規(guī)AWS物理主機(jī)的2個Intel Xeon E5 12 core的配置來看,，平均每個物理機(jī)上應(yīng)該承載12個左右的云主機(jī)數(shù)量。而6萬臺的數(shù)據(jù)中心應(yīng)該包含72萬臺云主機(jī),。按照每Availability Zone平均包含3個數(shù)據(jù)中心算,，AWS在每個Region擁有可高質(zhì)量互通的7.5個6萬+的數(shù)據(jù)中心群，其中可部署45萬+的物理機(jī),，承載540萬+的云主機(jī),，這是個非常巨型的解決方案。

圖表 4 Region間骨干網(wǎng)(單擊放大)

再從圖表5看其Region內(nèi)網(wǎng)絡(luò)互聯(lián)設(shè)計(jì),。Region內(nèi)的各個數(shù)據(jù)中心，通過兩個獨(dú)立的transit節(jié)點(diǎn)接入上面講的Region間骨干網(wǎng),，以保證鏈路冗余性,。Region內(nèi)的2~3個AZ間保證全互連，互聯(lián)鏈路帶寬達(dá)到25Tbps,。按照之前推論的AZ內(nèi)包含180萬+個云主機(jī)計(jì)算,，每個云主機(jī)平均有14Mbps的帶寬。每個AZ內(nèi)的1~6個數(shù)據(jù)中心之間保證全互聯(lián),，互聯(lián)鏈路達(dá)到102Tbps,，平均每個云主機(jī)擁有178Mbps的鏈路帶寬。

圖表 5 AZ內(nèi)網(wǎng)絡(luò)連接

從AWS的數(shù)據(jù)中心以及網(wǎng)絡(luò)設(shè)計(jì)實(shí)踐看,，與前面兩篇論文的理論是一致的,。在Fault Avoidance上，AWS提出了Region與AvailabilityZone的概念,，幫助客戶構(gòu)建高可用應(yīng)用,。Region為完全隔離的兩個資源池，而Availability Zone是可互通的,、但風(fēng)火水電隔離的資源池,。客戶將服務(wù)部署到不同的Region與Availability Zone中,，使用負(fù)載分擔(dān)實(shí)現(xiàn)Active-Active高可用,，以避免可能的單點(diǎn)故障。Availability Zone在其悉尼Region故障中經(jīng)過了檢驗(yàn),，在1個AZ完全停止服務(wù)時,，另外一個AZ可以提供完整的服務(wù)，避免客戶應(yīng)用完全不可服務(wù),。

在數(shù)據(jù)中心設(shè)計(jì)上 ,，AWS選擇了兩種方案的結(jié)合。按照地理位置建立獨(dú)立的,、45萬+物理機(jī)的超大規(guī)模數(shù)據(jù)中心集群,，既保證了規(guī)模效應(yīng)的高性價(jià)比，又實(shí)現(xiàn)了最終客戶良好的網(wǎng)絡(luò)體驗(yàn),。獨(dú)立的數(shù)據(jù)中心集群間只保持較小的互聯(lián)帶寬,，避免大范圍網(wǎng)絡(luò)互聯(lián)的高投資。數(shù)據(jù)中心集群內(nèi)，在數(shù)據(jù)中心間,、以及數(shù)據(jù)中心內(nèi)設(shè)計(jì)了很高的互聯(lián)帶寬,，實(shí)現(xiàn)資源池的統(tǒng)一SLA體驗(yàn)。

在2008年的 InternationalConference on Data Engineering,，一篇名為 “cloud computing imperatives”  的論文提出,，大型的數(shù)據(jù)中心比中型數(shù)據(jù)中心可以提供7.1倍的網(wǎng)絡(luò)性價(jià)比、5.7倍的存儲性價(jià)比,、以及高達(dá)15.7倍的管理成本性價(jià)比,。同時在計(jì)算能力成本日益下降的背景下，發(fā)展大型的數(shù)據(jù)中心,，才能解決數(shù)據(jù)傳輸高延時與能耗不足的基礎(chǔ)設(shè)施瓶頸,。

AWS在2011年左右引入了10Gb的智能網(wǎng)卡（驅(qū)動兼容Intel的ixgbevf,，生產(chǎn)廠商不詳），并對所有規(guī)格的云主機(jī)規(guī)格開放,，提供普通vif與SRIOV VF兩種接口（如圖表7）,。隨后在2015年隨x1機(jī)型推出了25Gb的智能網(wǎng)卡（使用自有ENA驅(qū)動，收購的annapurna設(shè)計(jì)）,。

圖表 7智能網(wǎng)卡

智能網(wǎng)卡承擔(dān)了原本物理機(jī)內(nèi)虛擬交換機(jī)的路由,、contrack匹配、ACL過濾,、VTEP查表,、MAC代答、tunnel建立等工作負(fù)載,，大幅度降低了網(wǎng)絡(luò)延時,，提高了網(wǎng)絡(luò)吞吐量。同時硬件實(shí)現(xiàn)了虛擬機(jī)粒度的,、嚴(yán)格的帶寬以及五元組流的QoS，保證基本所有類型以及規(guī)格的云主機(jī)都有穩(wěn)定可預(yù)測的網(wǎng)絡(luò)性能,。

圖表 8云主機(jī)存儲演進(jìn)

從圖表8看,，AWS使用存儲介質(zhì)的策略也相對比業(yè)界激進(jìn)，從2007年開始的c1實(shí)例使用了SATA口的SSD，2015年在x1實(shí)例上使用了PCIE SSD（在2007年~2015年之間也在少量機(jī)型上使用了PCIE SSD,，應(yīng)該是維護(hù)困難放棄了,，x1實(shí)例因?yàn)?/span>SATA SSD的IOPS能力不夠），在2016年底的p2實(shí)例上正式推出了NVMe SSD,。比業(yè)界的選擇整體快1~4年,。當(dāng)前NVMe SSD的使用上時間點(diǎn)接近，這個是因?yàn)榇鎯夹g(shù)發(fā)展比網(wǎng)絡(luò)慢很多,。

雖然大家都使用NVMe SSD作為存儲介質(zhì),，但從下表可以看出，AWS最新推出的i3實(shí)例的物理機(jī)掛載8個1.9T的NVMe盤,，可以同時承載32個i3.large規(guī)格的實(shí)例,，并且可以保證這些實(shí)例的存儲SLA。筆者推測推測其在i3實(shí)例物理機(jī)上使用了類似JBOF中的NVMe controller,，將云主機(jī)的最多32個NVMe SSD盤的后端卸載到該controller卡上,。同時NVMe controller需要對掛載的8個NVMe SSD進(jìn)行了條帶化，從而實(shí)現(xiàn)1個NVMe盤同時提供給兩個云主機(jī)使用,，而且有嚴(yán)格的SLA保證,。

圖表 9 AWS I3實(shí)例設(shè)計(jì)

從AWS在云主機(jī)設(shè)計(jì)的實(shí)踐看，其完全遵守了前面論文的理論,，通過大型數(shù)據(jù)中心的規(guī)模效應(yīng)來提高資源池的品質(zhì),。通過全網(wǎng)使用更高帶寬的網(wǎng)絡(luò)技術(shù)，以及主機(jī)端的智能網(wǎng)卡,，實(shí)現(xiàn)了比業(yè)界大大降低的云主機(jī)網(wǎng)絡(luò)時延,。比業(yè)界更早的使用更高性能的存儲介質(zhì)，并且通過新的存儲卸載技術(shù),，大幅度的降低了存儲時延,，并且提高了存儲密度。

從前面圖表3中RightScale的統(tǒng)計(jì)圖我們可以看出,，AWS環(huán)境中80%以上的實(shí)例是小規(guī)格的,。越來越多的客戶傾向與開發(fā)微服務(wù)架構(gòu)的應(yīng)用，通過簡單的高擴(kuò)展的應(yīng)用架構(gòu)代替以往復(fù)雜的應(yīng)用架構(gòu),。AWS的云主機(jī)設(shè)計(jì)策略很明顯,，在保證整個資源池的計(jì)算、網(wǎng)絡(luò),、存儲性能優(yōu)勢以外,，還要保證有能力提供足夠小的資源顆粒粒度，同時保證這些顆粒有SLA的保證,。（AWS曾經(jīng)有過cc1,、cc2等大顆粒實(shí)例，但均淘汰了）

從通過智能網(wǎng)卡實(shí)現(xiàn)了高密度虛擬網(wǎng)卡，以及精確的QoS控制,，保證云主機(jī)的網(wǎng)絡(luò)質(zhì)量可預(yù)測,。到使用新的存儲卸載技術(shù)來提供高密度的虛擬NVMe設(shè)備，以及精確的QoS控制,，保證云主機(jī)的存儲質(zhì)量可預(yù)測,。我們看到了其為客戶提供細(xì)粒度資源的思路。

圖表 10 AWS實(shí)例設(shè)計(jì)目標(biāo)（左右滑動）

在2009年的StanfordClean Slate CTO Summit Invited Talk,上,，一篇名為“Data CenterNetworks Are in my Way”的論文中提出,，傳統(tǒng)的網(wǎng)絡(luò)設(shè)備沒有像x86服務(wù)器架構(gòu)一樣有開放的、標(biāo)準(zhǔn)的架構(gòu),。運(yùn)營商無法使用一套OSS系統(tǒng),，對局點(diǎn)內(nèi)的各類設(shè)備進(jìn)行管理，需要管理員手工進(jìn)行維護(hù),。

圖表 11 AWS云主機(jī)服務(wù)(單擊放大)

VPC在前一段時間炒的火熱,，各個大廠均出來講自己的實(shí)現(xiàn)以及優(yōu)勢。由于熱點(diǎn)起源于租戶云主機(jī)隔離,，所以VPC的討論也局限到隔離的特性,。就筆者對AWS的理解，其提出VPC的概念主要目的是為了租戶自助管理自己云網(wǎng)絡(luò)中的各個網(wǎng)元,，完成東西,、南北向網(wǎng)絡(luò)流量的配置。

租戶通過統(tǒng)一的console或者API自助配置自己網(wǎng)絡(luò)中的L3交換機(jī),，控制流量的路由,；

配置網(wǎng)絡(luò)中的虛擬防火墻，以及交換機(jī)ACL,，實(shí)現(xiàn)流量的安全隔離,；

自助選擇SNAT網(wǎng)關(guān)、公網(wǎng)網(wǎng)關(guān),、VPN網(wǎng)關(guān),、專線網(wǎng)關(guān)等流量流出VPC的方式。

這些特性,，極大的簡化了租戶的運(yùn)維負(fù)擔(dān),。

圖表 12 AWS VPC服務(wù)設(shè)計(jì)(單擊放大)

從AWS的云服務(wù)設(shè)計(jì)實(shí)踐上看，其使用API對客戶提供資源服務(wù)的思路與這兩篇論文思路一致,。其修建大規(guī)模的數(shù)據(jù)中心,，并優(yōu)化數(shù)據(jù)中心的運(yùn)維質(zhì)量與成本、提高資源使用效率,、提高整體的安全性,、實(shí)現(xiàn)數(shù)據(jù)中心的高擴(kuò)展性。最終通過統(tǒng)一的API與console作為界面,，使用自助的云服務(wù)屏蔽底層硬件差異,，最終將數(shù)據(jù)中心能力提供給客戶,。

圖表 13 研發(fā)模式演進(jìn)

Jeff從軟件開發(fā)者的角度生動的描述了軟件行業(yè)的演進(jìn)歷程，在功能交付要求越來越快的背景下,，由于軟件功能的堆積,，軟件的體積越來越大，復(fù)雜度越來越高,，同時軟件的質(zhì)量也越來越難以保證,。如圖表13，軟件開發(fā)模式開始從傳統(tǒng)的瀑布流模式轉(zhuǎn)化為今天的微服務(wù)模式,。復(fù)雜的單體式軟件,，拆解為一組簡單但高擴(kuò)展服務(wù)。大規(guī)模的開發(fā)團(tuán)隊(duì),，拆解為靈活獨(dú)立的開發(fā)小組,。長達(dá)半年到1年的交付周期，分解為以周為單位的快速迭代,。徹底的D/O分離的協(xié)助模式,，由于軟件的微服務(wù)化，軟件的業(yè)務(wù)運(yùn)維與開發(fā)團(tuán)隊(duì)融合,，形成了新的DevOps模式,。

開發(fā)模式的演進(jìn)，對基礎(chǔ)設(shè)施的要求也在變化,。從使用幾臺高配的服務(wù)器部署業(yè)務(wù),，變化為需要1個，甚至數(shù)個低配集群部署,，實(shí)現(xiàn)各個模塊的資源隔離,，以及整個業(yè)務(wù)的高可用,。對于有自建數(shù)據(jù)中心的大型公司來說，可能不是問題,，但對于中小型公司來說,，這可能是不可能的任務(wù)。尤其是對于一些to C的業(yè)務(wù),，增長曲線無法估計(jì),，提前3~5年來規(guī)劃基礎(chǔ)設(shè)施的建設(shè)，在業(yè)務(wù)前景還不明朗的時候可能是個笑話,。

返回主線，AWS是如何站在第三次計(jì)算領(lǐng)域的浪潮之巔呢,？

AWS在最終客戶的周邊修建了大型數(shù)據(jù)中心群,，并保證之間的互聯(lián)質(zhì)量以及高可用。

通過其數(shù)據(jù)中心的巨型體量,，使用各種最新的技術(shù)提高了資源的網(wǎng)絡(luò),、存儲效率，解決了功耗問題,，同時降低了運(yùn)維,、安全等運(yùn)營成本。

為滿足客戶的不同計(jì)算負(fù)載,，引入高性能計(jì)算,、GPU、FPGA等技術(shù),，并通過小顆粒的資源粒度,，通過統(tǒng)一、可編程的云服務(wù)模式提供給客戶,。

最后為了完成客戶遷移的工作,，提供了一系列搬遷工具、垂直解決方案,、服務(wù)部署工具,、適應(yīng)新基礎(chǔ)設(shè)施架構(gòu)的中間件。

當(dāng)然這些到現(xiàn)在,，也許是每個云計(jì)算工程師的常識,，但在2006年AWS開始提供云計(jì)算服務(wù)的時間點(diǎn)，僅有學(xué)術(shù)界的理論,，工程上仍然是無人區(qū),。AWS在云計(jì)算的巨額投入，這是一場有革命性的,、勇敢的賭博,。最終在2015年,，才最終證明了這次技術(shù)革命是成功的。

就此筆者曾向AWS的傳奇修車工,、卓越工程師,、副總裁James Hamilton求證，James的回答：We are both lucky,。

圖表 14 James的評論

如同芯片平臺Intel將芯片技術(shù)同等的提交給硬件集成商,、通信管道平臺華為將通信技術(shù)同等的提交給電信運(yùn)營商,、手機(jī)軟件平臺蘋果appstore將客戶無差別提交給軟件開發(fā)者、即時通訊平臺騰訊將連接提交給廣大最終用戶,。云計(jì)算基礎(chǔ)設(shè)施平臺將資源池效率/成本比,，無差別的提交給云計(jì)算應(yīng)用開發(fā)者，應(yīng)用開發(fā)者的投資最終從基礎(chǔ)設(shè)施變更到應(yīng)用開發(fā)本身,，使云計(jì)算分工更明確,，決策鏈條實(shí)現(xiàn)閉環(huán)迭代式發(fā)展。

本文作者鞏小東,，掃碼關(guān)注他的公眾號

你不會想到，他竟來自于AWS的友商