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

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

圖表1 云計算構成

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

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

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

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

接下來(lái)我們看AWS是怎么做的……

AWS數據中心的設計實(shí)踐

圖表 2 AWS數據中心概覽

從圖表2中的黃色標記可以看出，其圍繞著(zhù)客戶(hù)在全球建立了16個(gè)資源隔離的Region，每個(gè)Region包含2~3個(gè)Availability Zone（可用區）。Availability Zone為一個(gè)數據中心群，包含1~6個(gè)6萬(wàn)+規模的超大數據中心。Availability Zone間距離通常為30~100公里，以保證風(fēng)火水電的隔離。

圖表 3 AWS實(shí)例規格統計

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

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

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

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

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

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

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

AWS云主機網(wǎng)絡(luò )設計實(shí)踐

圖表 6數據中心內網(wǎng)絡(luò )演進(jìn)

從圖表6看，AWS的數據中心內網(wǎng)絡(luò )帶寬選擇領(lǐng)先業(yè)界近3年。在2010年的cg1實(shí)例上明確使用10Gb網(wǎng)絡(luò )，到2015年的x1實(shí)例上明確使用25Gb的網(wǎng)絡(luò )。更高的數據中心內網(wǎng)絡(luò )帶寬，不僅給每個(gè)云主機提供更多的帶寬資源，最重要的會(huì )降低路徑上所有網(wǎng)絡(luò )設備的隊列深度，從而得到更低的東西向流量網(wǎng)絡(luò )延時(shí)。

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

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

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

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

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

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

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

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

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

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

圖表 10 AWS實(shí)例設計目標（左右滑動(dòng)）

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

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

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

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

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

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

這些特性，極大的簡(jiǎn)化了租戶(hù)的運維負擔。

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

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

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

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

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

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

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

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

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

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

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

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

圖表 14 James的評論

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

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

你不會(huì )想到，他竟來(lái)自于A(yíng)WS的友商