“這是中國第一份全面的云計(jì)算報(bào)告！旨在讓讀者一窺國內(nèi)公有云服務(wù)發(fā)展之真實(shí)面貌。

▋編者注：

本報(bào)告共包括團(tuán)隊(duì)建設(shè)篇、產(chǎn)品研發(fā)篇、 服務(wù)運(yùn)營篇、用戶體驗(yàn)篇，以及其他討論篇，因?yàn)槠P(guān)系，這里僅發(fā)布“用戶體驗(yàn)篇+其他討論篇”，有刪節(jié)。如想閱讀完整報(bào)告，請移步「細(xì)說云計(jì)算」公眾號，ID：CloudNote。

在文章的準(zhǔn)備過程中，作者系統(tǒng)地閱讀了國內(nèi)較為知名的幾份云計(jì)算白皮書[1，2，3]。在本文的范疇內(nèi)，“公有云”一詞泛指面向公眾開放服務(wù)的平臺即服務(wù)和設(shè)施即服務(wù)。除此之外，各種名義的私有云（Private Cloud）、專有云（Dedicated Cloud）、托管云（Managed Cloud）均未包括在本文的范疇之中。

本文僅討論中國本土的公有云服務(wù)提供商。Amazon Web Services(AWS)、Microsoft Azure、Google Cloud Platform等等進(jìn)入或者未進(jìn)入中國市場的外資企業(yè)不在本文的討論范圍之內(nèi)。

 

▋老司機(jī)簡介：

蔣清野，悉尼大學(xué)信息技術(shù)學(xué)院博士研究生，同時(shí)也是AWS悉尼技術(shù)支持中心的員工。他于1999年獲得清華大學(xué)學(xué)士學(xué)位（土木工程），2000年獲得伊利諾伊大學(xué)香檳分校碩士學(xué)位（土木工程），2015年獲得悉尼大學(xué)碩士學(xué)位（計(jì)算機(jī)科學(xué)）。

他的研究興趣包括分布式與高性能計(jì)算、開源社區(qū)的社會學(xué)行為、信息技術(shù)領(lǐng)域的微觀經(jīng)濟(jì)學(xué)分析。他是美國電子電氣工程師學(xué)會（IEEE）的高級會員。

▋用戶體驗(yàn)：

在這個(gè)部分，我們以用戶體驗(yàn)為主線，對不同公有云服務(wù)提供商的產(chǎn)品進(jìn)行一些小規(guī)模測試。這些測試旨在探測客戶關(guān)心的幾個(gè)關(guān)鍵參數(shù)：

•服務(wù)規(guī)模；

•網(wǎng)絡(luò)與存儲吞吐能力；

•資源隔離狀況；

•客服能力。

‖服務(wù)規(guī)模

針對服務(wù)規(guī)模的測試，是通過端口掃描進(jìn)行的。針對一個(gè)特定的IaaS服務(wù)提供商，這個(gè)測試分為兩個(gè)步驟進(jìn)行：

•在所有區(qū)域分不同時(shí)段（時(shí)間跨度長達(dá)一個(gè)月）大量創(chuàng)建云主機(jī)，通過枚舉得出云主機(jī)所用公網(wǎng)IP所在的B段列表，并通過公開的信息進(jìn)行矯正；

•對所有的B段針對22、80、443、3389端口進(jìn)行掃描，將掃描結(jié)果記錄到數(shù)據(jù)庫。

有些B段IP地址，可能超出了IaaS服務(wù)提供商所擁有IP資源范圍。譬如某些服務(wù)提供商使用了運(yùn)營商提供的IP地址，在同一個(gè)B段里面還有用于其它用途的IP地址。有些B段IP地址，雖然由某個(gè)服務(wù)提供商擁有，但是并非用于IaaS服務(wù)。

因此，端口掃描得到的結(jié)果，反映的是從外界可以探測到的服務(wù)規(guī)模上限?？紤]到防火墻、安全組、部分云主機(jī)未配置公網(wǎng)等等多種因素，端口掃描的結(jié)果是小于實(shí)際服務(wù)規(guī)模的。

‖網(wǎng)絡(luò)與存儲吞吐能力

針對網(wǎng)絡(luò)吞吐能力的測試，是在同一個(gè)區(qū)域內(nèi)啟動N對云主機(jī)。在所有的云主機(jī)內(nèi)安裝Apache服務(wù)，提供一個(gè)100MB大小的文件下載。在每一對云主機(jī)之間，在每臺云主機(jī)上啟動多個(gè)線程從對方下載如上所述100MB大小的文件，單次測試持續(xù)時(shí)間15分鐘。由于供下載的文件是同一個(gè)，該文件在第一次被讀取之后便駐留在內(nèi)存當(dāng)中，不再產(chǎn)生新的磁盤I/O。

因此，這個(gè)測試探測的是兩臺云主機(jī)之間的內(nèi)網(wǎng)帶寬。N的取值范圍，從1逐漸增加到10，目的在于探測單個(gè)用戶可以使用的網(wǎng)絡(luò)帶寬邊界。測試中使用的第一對云主機(jī)，一臺在用戶賬號A中，一臺在用戶賬號B中，目的在于測試網(wǎng)絡(luò)資源隔離狀況。針對一個(gè)特定的IaaS服務(wù)提供商，這個(gè)測試在不同時(shí)段進(jìn)行多次，以了解不同時(shí)段對網(wǎng)絡(luò)性能的影響。

針對存儲吞吐能力的測試，是在同一個(gè)區(qū)域內(nèi)啟動N臺云主機(jī)。在每臺云主機(jī)上掛載M塊云硬盤創(chuàng)建一個(gè)RAID0磁盤陣列。在云主機(jī)上啟動多個(gè)線程，分別往磁盤陣列上寫入多個(gè)遠(yuǎn)大于云主機(jī)物理內(nèi)存的大文件。單次測試持續(xù)15分鐘，記錄測試過程中的磁盤寫入帶寬。這個(gè)測試分為三個(gè)步驟進(jìn)行：

1.M的取值為1，探測單臺云主機(jī)上單塊云硬盤的存儲帶寬上限；

2.M的取值在2到4之間，探測單臺云主機(jī)上一個(gè)磁盤陣列的存儲帶寬上限；

3.N的取值在1到10之間，探測單個(gè)用戶可以使用的存儲帶寬上限。測試中使用的前兩臺云主機(jī)，一臺在用戶賬號A中，一臺在用戶賬號B中，目的在于測試存儲資源隔離狀況。針對一個(gè)特定的IaaS服務(wù)提供商，這個(gè)測試在不同時(shí)段進(jìn)行多次，以了解不同時(shí)段對存儲性能的影響。

作者也注意到一些公有云服務(wù)提供商采取了“地理區(qū)域——可用區(qū)——集群”這樣的結(jié)構(gòu)設(shè)計(jì)。在同一個(gè)可用區(qū)中，盡可能將同一用戶所使用的計(jì)算資源分配到同一個(gè)集群。因此，針對網(wǎng)絡(luò)吞吐能力的測試結(jié)果和針對存儲吞吐能力的測試結(jié)果反映的可能是一個(gè)可用區(qū)中某一個(gè)集群的網(wǎng)絡(luò)吞吐能力和存儲吞吐能力。

‖客服能力

針對客服能力的測試，是在云服務(wù)提供商的Web控制臺里提交工單。工單的內(nèi)容包括要求提高配額、詢問基礎(chǔ)性的使用問題、報(bào)告缺陷等等。這部分的測試，一方面在于了解客服的響應(yīng)速度，另一方面在于了解客服處理能力。

▋阿里云

阿里巴巴集團(tuán)在自治域AS37963、AS45102中一共聲明了120個(gè)B類IP地址段以及多個(gè)C類IP地址段。

2016年3月，從公網(wǎng)對全部120個(gè)B類IP地址段針對22（SSH）和3389（RDP）端口進(jìn)行掃描，有26.5萬個(gè)IP地址可以通過22端口創(chuàng)建網(wǎng)絡(luò)連接，有21.5萬個(gè)IP地址可以通過3389端口創(chuàng)建網(wǎng)絡(luò)連接。

2016年9月，從公網(wǎng)對如上所述IP地址段針對22（SSH）、80（HTTP）、443（HTTPS）和3389（RDP）端口進(jìn)行掃描。有35萬個(gè)IP地址可以通過22端口創(chuàng)建網(wǎng)絡(luò)連接，有92萬個(gè)IP地址可以通過80端口創(chuàng)建網(wǎng)絡(luò)連接，有9萬個(gè)IP地址可以通過443端口創(chuàng)建網(wǎng)絡(luò)連接，有25萬個(gè)IP地址可以通過3389端口創(chuàng)建網(wǎng)絡(luò)連接。

需要說明的是，如上所述120個(gè)B類IP地址段并非全部用于阿里云的公有云服務(wù)。阿里巴巴集團(tuán)下的其他業(yè)務(wù)譬如淘寶網(wǎng)和支付寶所使用的IP地址也都在這120個(gè)B類IP地址段中。根據(jù)章文嵩2011年5月在第三屆中國云計(jì)算大會上的演講[10]，淘寶網(wǎng)的生產(chǎn)服務(wù)器大約為20,000臺。根據(jù)高山淵2012年6月在QClub深圳站上的演講[11]，阿里巴巴集團(tuán)的服務(wù)器規(guī)模接近10萬。

根據(jù)工信部電信研究院發(fā)布的《云計(jì)算白皮書（2014年）》，截止到2013年9月運(yùn)行在阿里云上的Web服務(wù)器數(shù)量達(dá)到18,000個(gè)，比2012年增長了500%。根據(jù)NetCraft在2015年6月發(fā)布的數(shù)據(jù)，阿里云所管理的Web服務(wù)器達(dá)到45,000個(gè)。

考慮到阿里巴巴集團(tuán)過去五年中的業(yè)務(wù)增長對計(jì)算資源的需求，阿里云公有云部分所使用的IP地址（包括物理機(jī)和虛擬機(jī)）可能只占如上所述活躍IP地址中的一小部分。

2016年3月，在阿里云各個(gè)區(qū)域內(nèi)創(chuàng)建云主機(jī)，并對云主機(jī)所在的A類內(nèi)網(wǎng)IP地址段針對22和3389端口進(jìn)行掃描，有39萬個(gè)內(nèi)網(wǎng)地址可以通過22端口創(chuàng)建網(wǎng)絡(luò)連接，有8萬個(gè)內(nèi)網(wǎng)地址可以通過3389端口創(chuàng)建網(wǎng)絡(luò)連接。在可以通過22端口連接的IP地址中，又發(fā)現(xiàn)了大量活躍的3306（MySQL）端口和11211（Memcached）端口。

運(yùn)行在11211端口的服務(wù)，大部分可以通過SET和GET命令直接進(jìn)行操作。運(yùn)行在3306端口的服務(wù)，有一定數(shù)量可以基于社會工程數(shù)據(jù)庫使用root帳號通過自動化測試程序登錄。

在可以通過3389端口連接的IP地址中，發(fā)現(xiàn)了部分活躍的1433（SQL Server）端口。運(yùn)行在1433端口的服務(wù)，也有一定數(shù)量可以基于社會工程數(shù)據(jù)庫使用Administrator帳號通過自動化測試程序登錄。由于SQL Server服務(wù)可以使用Windows身份驗(yàn)證，有理由認(rèn)為一定數(shù)量運(yùn)行Windows操作系統(tǒng)的云主機(jī)已經(jīng)淪為肉雞。

作者還注意到，在阿里云各個(gè)區(qū)域進(jìn)行內(nèi)網(wǎng)掃描獲得的端口數(shù)量是高度一致的。深圳、杭州、青島、北京、上海、香港、美西這七個(gè)區(qū)域的活躍端口數(shù)量，精確到千位數(shù)都是完全相同的。唯一的一個(gè)例外是新加坡區(qū)域，原因不明。

阿里云內(nèi)網(wǎng)帶寬測試（MB/s）

 

 

上表所示是在阿里云杭州區(qū)域進(jìn)行網(wǎng)絡(luò)帶寬探測的結(jié)果。測試中使用了7 對云主機(jī)，所有云主機(jī)都部署在同一個(gè)可用區(qū)內(nèi)。我們首先使用同樣的測試程序?qū)Σ煌脑浦鳈C(jī)實(shí)例類型進(jìn)行測試，發(fā)現(xiàn)不同的云主機(jī)實(shí)例類型所能夠達(dá)到的內(nèi)網(wǎng)帶寬是一樣的。

考慮到批量測試的費(fèi)用問題，如上測試使用的云主機(jī)實(shí)例類型為“系列二：通用型n1”，配置1顆vCPU和1GB內(nèi)存。在參與測試的14臺云主機(jī)中，1號云主機(jī)在一個(gè)用戶帳號中，2～14號云主機(jī)在另外一個(gè)用戶帳號中。1號云主機(jī)和2號云主機(jī)配為一對，3號云主機(jī)和4號云主機(jī)配為一對，以此類推。

在編號為1的測試中，只有第一對云主機(jī)產(chǎn)生網(wǎng)絡(luò)流量，其他云主機(jī)處于空閑狀態(tài)；在編號為2的測試中，第一對和第二對云主機(jī)產(chǎn)生網(wǎng)絡(luò)流量，其他云主機(jī)處于空閑狀態(tài)，以此類推。

如上測試在一個(gè)月中的不同時(shí)段進(jìn)行了多次，不同批次的測試結(jié)果之間高度一致。作者將云主機(jī)的總量增加到10對（共20臺），可以得到同樣的測試結(jié)果?；谌缟蠝y試，可以認(rèn)為阿里云的網(wǎng)絡(luò)質(zhì)量達(dá)到了較高的水平，具體表現(xiàn)在：

1.以云主機(jī)為單位進(jìn)行精確限流，吞吐量指標(biāo)基本沒有發(fā)生抖動；

2.在小規(guī)模測試中，未能探測到單個(gè)用戶能夠使用的網(wǎng)絡(luò)帶寬上限；

3.在小規(guī)模測試中，未能探測到單個(gè)用戶大量占用網(wǎng)絡(luò)帶寬對其他用戶使用網(wǎng)絡(luò)產(chǎn)生影響。

阿里云存儲帶寬測試（MB/s）

 

 

上表所示是在阿里云杭州區(qū)域進(jìn)行存儲帶寬探測的結(jié)果。測試中使用了10臺云主機(jī)，所有云主機(jī)都部署在同一個(gè)可用區(qū)內(nèi)。

•首先，我們使用不同的云主機(jī)實(shí)例類型掛載單塊云硬盤進(jìn)行測試，可以達(dá)到阿里云文檔所標(biāo)注的256MB/s帶寬上限。此外，我們發(fā)現(xiàn)存儲帶寬上限與云硬盤的容量有關(guān)，但是與云主機(jī)實(shí)例類型無關(guān)。

•其次，我們在同一臺云主機(jī)上掛載多塊云硬盤創(chuàng)建RAID0磁盤陣列進(jìn)行同樣測試。與單塊云硬盤相比，用兩塊云硬盤創(chuàng)建的RAID0磁盤陣列可以達(dá)到400MB/s的存儲帶寬。用三塊或者四塊云硬盤創(chuàng)建的RAID0磁盤陣列，其存儲帶寬和用兩塊云硬盤創(chuàng)建的RAID0磁盤陣列是同樣的。

考慮到批量測試的費(fèi)用問題，如上測試使用的云主機(jī)實(shí)例類型為“系列二：通用型n1”，配置1顆vCPU和1GB內(nèi)存，掛載兩塊500GB的云硬盤配置成RAID0磁盤陣列。在參與測試的10臺云主機(jī)中，1號云主機(jī)在一個(gè)用戶帳號中，2～10號云主機(jī)在另外一個(gè)用戶帳號中。

在編號為1的測試中，只有1號云主機(jī)產(chǎn)生存儲流量，其他云主機(jī)處于空閑狀態(tài)；在編號為2的測試中，1號和2號對云主機(jī)產(chǎn)生存儲流量，其他云主機(jī)處于空閑狀態(tài)，以此類推。

如上測試在一個(gè)月中的不同時(shí)段進(jìn)行了多次，不同批次的測試結(jié)果之間高度一致。將云主機(jī)的總量增加到20臺，可以得到同樣的測試結(jié)果?；谌缟蠝y試，可以認(rèn)為阿里云的存儲質(zhì)量達(dá)到了較高的水平，具體表現(xiàn)在：

1.以云主機(jī)和云硬盤為單位進(jìn)行精確限流，吞吐量指標(biāo)基本沒有發(fā)生抖動；

2.在小規(guī)模測試中，未能探測到單個(gè)用戶能夠使用的存儲帶寬上限；

3.在小規(guī)模測試中，未能探測到單個(gè)用戶大量占用存儲帶寬對其他用戶使用存儲產(chǎn)生影響。

▋金山云

金山云對客戶的挑選比較苛刻。作者自主在金山云的網(wǎng)站上注冊帳號，可以完成注冊但是無法激活帳號。未激活帳號依然可以對帳號進(jìn)行充值，但是充值完成之后無法創(chuàng)建云主機(jī)，也無法使用金山云提供的任何其他資源。

作者通過在線客服功能聯(lián)系到金山云的客服人員，客服人員提供了一個(gè)激活帳號的連接，但是依然無法成功激活帳號。（注：2016年5月31日前，金山云客戶網(wǎng)上注冊，需要通過線下人員審核后可激活賬戶。6月1日后，金山云客戶可實(shí)現(xiàn)網(wǎng)上自助注冊。）

金山云在自治域AS59019中聲明了多個(gè)C類IP地址段，IP地址總數(shù)接近一個(gè)B段。

2016年9月，從公網(wǎng)對如上所述IP地址段針對22（SSH）、80（HTTP）、443（HTTPS）和3389（RDP）端口進(jìn)行掃描。有1500個(gè)IP地址可以通過22端口創(chuàng)建網(wǎng)絡(luò)連接，有1900個(gè)IP地址可以通過80端口創(chuàng)建網(wǎng)絡(luò)連接，有1300個(gè)IP地址可以通過443端口創(chuàng)建網(wǎng)絡(luò)連接，有300個(gè)IP地址可以通過3389端口創(chuàng)建網(wǎng)絡(luò)連接。

除此之外，作者未能對金山云進(jìn)行其他用戶體驗(yàn)層面的測試。

▋美團(tuán)云

美團(tuán)云啟用的公網(wǎng)IP地址只有一個(gè)B段。通過ip-tracker.org進(jìn)行查詢，未能確認(rèn)這些IP地址屬于美團(tuán)云。

2016年3月，從公網(wǎng)對該地址段中針對22（SSH）和3389（RDP）端口進(jìn)行掃描。有3,700個(gè)IP地址可以通過22端口創(chuàng)建網(wǎng)絡(luò)連接，有1600個(gè)IP地址可以通過3389端口創(chuàng)建網(wǎng)絡(luò)連接。

2016年9月，從公網(wǎng)對該地址段針對22（SSH）、80（HTTP）、443（HTTPS）和3389（RDP）端口進(jìn)行掃描。有5,500個(gè)IP地址可以通過22端口創(chuàng)建網(wǎng)絡(luò)連接，有6,400個(gè)IP地址可以通過80端口創(chuàng)建網(wǎng)絡(luò)連接，有3,000個(gè)IP地址可以通過443端口創(chuàng)建網(wǎng)絡(luò)連接，有2,000個(gè)IP地址可以通過3389端口創(chuàng)建網(wǎng)絡(luò)連接。

由于美團(tuán)云的規(guī)模相對較小，作者未對1433、3306和11211等端口進(jìn)行掃描和自動化登錄測試。基于同樣的原因，作者也未對美團(tuán)云進(jìn)行網(wǎng)絡(luò)、存儲、客服等方面的測試。

▋青云

青云啟用的公網(wǎng)IP地址有4個(gè)B段。通過ip-tracker.org進(jìn)行查詢，未能確認(rèn)這些IP地址屬于青云。

2016年3月，從公網(wǎng)對全部4個(gè)B類IP地址段針對22（SSH）和3389（RDP）端口進(jìn)行掃描，有7,000個(gè)IP地址可以通過22端口創(chuàng)建網(wǎng)絡(luò)連接，有2,000個(gè)IP地址可以通過3389端口創(chuàng)建網(wǎng)絡(luò)連接。

在青云的基礎(chǔ)網(wǎng)絡(luò)上創(chuàng)建云主機(jī)，可以在云主機(jī)所在的A類內(nèi)網(wǎng)IP地址段掃描到大量活躍的云主機(jī)。在青云的私有網(wǎng)絡(luò)上創(chuàng)建云主機(jī)，則無法掃描到不屬于用戶自己的云主機(jī)。

2016年9月，從公網(wǎng)對全部4個(gè)B類IP地址段針對22（SSH）、80（HTTP）、443（HTTPS）和3389（RDP）端口進(jìn)行掃描。有5,500個(gè)IP地址可以通過22端口創(chuàng)建網(wǎng)絡(luò)連接，有14,100個(gè)IP地址可以通過80端口創(chuàng)建網(wǎng)絡(luò)連接，有4,400個(gè)IP地址可以通過443端口創(chuàng)建網(wǎng)絡(luò)連接，有1,700個(gè)IP地址可以通過3389端口創(chuàng)建網(wǎng)絡(luò)連接。

基于如上端口掃描結(jié)果，青云的總體規(guī)模還是比較小的。即使是規(guī)模最大的一個(gè)可用區(qū)，云主機(jī)的數(shù)量級也不過是千位數(shù)而已。這樣的規(guī)模，對于一個(gè)內(nèi)部自用的私有云來說可能不小，但是對于面向公眾提供服務(wù)的公有云的確不大。

作者注意到青云于2016年1月高調(diào)發(fā)布了一個(gè)“超大規(guī)模網(wǎng)絡(luò)SDN/NFV 2.0網(wǎng)絡(luò)”[22]。與青云的實(shí)際規(guī)模相比，這樣的宣傳未免名不副實(shí)。

青云內(nèi)網(wǎng)帶寬測試（MB/s）

 

 

上表所示是在青云北京2區(qū)（PEK-2）進(jìn)行網(wǎng)絡(luò)帶寬探測的結(jié)果。測試中使用了7對云主機(jī)，所有云主機(jī)都部署在同一個(gè)區(qū)域內(nèi)。我們首先使用同樣的測試程序?qū)Σ煌脑浦鳈C(jī)實(shí)例類型進(jìn)行測試，發(fā)現(xiàn)不同的云主機(jī)實(shí)例類型所能夠達(dá)到的內(nèi)網(wǎng)帶寬是一樣的。

考慮到批量測試的費(fèi)用問題，如上測試使用的云主機(jī)實(shí)例類型為“超高性能主機(jī)”，配置1顆vCPU和1GB內(nèi)存。在參與測試的14臺云主機(jī)中，1號云主機(jī)在一個(gè)用戶帳號中，2～14號云主機(jī)在另外一個(gè)用戶帳號中。1號云主機(jī)和2號云主機(jī)配為一對，3號云主機(jī)和4號云主機(jī)配為一對，以此類推。

在編號為1的測試中，只有第一對云主機(jī)產(chǎn)生網(wǎng)絡(luò)流量，其他云主機(jī)處于空閑狀態(tài)；在編號為2的測試中，第一對和第二對云主機(jī)產(chǎn)生網(wǎng)絡(luò)流量，其他云主機(jī)處于空閑狀態(tài)，以此類推。

如上測試在一個(gè)月中的不同時(shí)段進(jìn)行了多次，不同批次的測試結(jié)果之間基本一致?；谌缟蠝y試，可以認(rèn)為青云的網(wǎng)絡(luò)質(zhì)量相對較低，具體表現(xiàn)在：

1.沒有對云主機(jī)采取限流措施，吞吐量指標(biāo)存在大規(guī)模抖動；

2.在小規(guī)模測試中，僅用6臺云主機(jī)即可探測到網(wǎng)絡(luò)性能惡化的跡象；

3.隨著參與測試的云主機(jī)數(shù)量的增加，網(wǎng)絡(luò)性能惡化極快；

4.單個(gè)用戶可以使用的網(wǎng)絡(luò)帶寬上限低于700MB/s；

5.在小規(guī)模測試中，可以觀察到單個(gè)用戶大量占用網(wǎng)絡(luò)帶寬對其他用戶使用網(wǎng)絡(luò)產(chǎn)生影響。

青云存儲帶寬測試（MB/s）

 

 

上表所示是在青云北京2區(qū)（PEK-2）進(jìn)行存儲帶寬探測的結(jié)果。測試中使用了10臺云主機(jī)，所有云主機(jī)都部署在同一個(gè)區(qū)域內(nèi)。

•首先，我們使用不同的云主機(jī)實(shí)例類型掛載單塊云硬盤進(jìn)行測試，發(fā)現(xiàn)存儲帶寬上限為200MB/s。這個(gè)存儲帶寬上限既與云硬盤的容量無關(guān)，也與云主機(jī)實(shí)例類型無關(guān)。

•其次，我們在同一臺云主機(jī)上掛載多塊云硬盤創(chuàng)建RAID0磁盤陣列進(jìn)行同樣測試。與單塊云硬盤相比，用兩塊云硬盤創(chuàng)建的RAID0磁盤陣列可以獲得400MB/s的存儲帶寬。用三塊或者四塊云硬盤創(chuàng)建的RAID0磁盤陣列，則可以獲得600MB/s和800MB/s的存儲帶寬。

考慮到批量測試的費(fèi)用問題，如上測試使用的云主機(jī)實(shí)例類型為“超高性能主機(jī)”，配置1顆vCPU和1GB內(nèi)存，掛載四塊50GB的云硬盤配置成RAID0磁盤陣列。在參與測試的10臺云主機(jī)中，1號云主機(jī)在一個(gè)用戶帳號中，2～10號云主機(jī)在另外一個(gè)用戶帳號中。

在編號為1的測試中，只有1號云主機(jī)產(chǎn)生存儲流量，其他云主機(jī)處于空閑狀態(tài)；在編號為2的測試中，1號和2號對云主機(jī)產(chǎn)生存儲流量，其他云主機(jī)處于空閑狀態(tài)，以此類推。

如上測試在一個(gè)月中的不同時(shí)段進(jìn)行了多次，不同批次的測試結(jié)果之間基本一致。基于如上測試，可以認(rèn)為青云的存儲質(zhì)量相對較低，具體表現(xiàn)在：

1.沒有對云主機(jī)或者云硬盤采取限流措施，吞吐量指標(biāo)存在大規(guī)模抖動；

2.在小規(guī)模測試中，僅用4臺云主機(jī)即可探測到存儲性能惡化的跡象；

3.隨著參與測試的云主機(jī)數(shù)量的增加，存儲性能惡化極快；

4.單個(gè)用戶可以使用的存儲帶寬上限為4000MB/s；

5.在小規(guī)模測試中，可以觀察到單個(gè)用戶大量占用存儲帶寬對其他用戶使用存儲產(chǎn)生影響。

在針對客服能力的測試中，作者通過青云Web控制臺里提交了多個(gè)工單。所有工單的響應(yīng)時(shí)間均在30分鐘以內(nèi)。不同工單分別涉及配額上調(diào)、使用方法、缺陷報(bào)告等等內(nèi)容，處理所需要的時(shí)間也有不同。所有工單咨詢的問題最終都得到很好的解決。

▋盛大云

盛大云啟用的公網(wǎng)IP地址有3個(gè)B段。通過ip-tracker.org進(jìn)行查詢，未能確認(rèn)這些IP地址屬于盛大云。

2016年3月，從公網(wǎng)對全部3個(gè)B類IP地址段針對22（SSH）和3389（RDP）端口進(jìn)行掃描，有6,000個(gè)IP地址可以通過22端口創(chuàng)建網(wǎng)絡(luò)連接，有4,000個(gè)IP地址可以通過3389端口創(chuàng)建網(wǎng)絡(luò)連接。

2016年9月，從公網(wǎng)對全部4個(gè)B類IP地址段針對22（SSH）、80（HTTP）、443（HTTPS）和3389（RDP）端口進(jìn)行掃描。有5500個(gè)IP地址可以通過22端口創(chuàng)建網(wǎng)絡(luò)連接，有36000個(gè)IP地址可以通過80端口創(chuàng)建網(wǎng)絡(luò)連接，有3600個(gè)IP地址可以通過443端口創(chuàng)建網(wǎng)絡(luò)連接，有3,200個(gè)IP地址可以通過3389端口創(chuàng)建網(wǎng)絡(luò)連接。

由于盛大云的規(guī)模相對較小，作者未對1433、3306和11211等端口進(jìn)行掃描和自動化登錄測試?；谕瑯拥脑颍髡咭参磳γ缊F(tuán)云進(jìn)行網(wǎng)絡(luò)、存儲、客服等方面的測試。

▋UCloud

UCloud啟用的公網(wǎng)IP地址有8個(gè)B段。通過ip-tracker.org進(jìn)行查詢，僅有一個(gè)B段可以確認(rèn)屬于UCloud。

2016年3月，從公網(wǎng)對全部8個(gè)B類IP地址段針對22（SSH）和3389（RDP）端口進(jìn)行掃描，有24,000個(gè)IP地址可以通過22端口創(chuàng)建網(wǎng)絡(luò)連接，有9,000個(gè)IP地址可以通過3389端口創(chuàng)建網(wǎng)絡(luò)連接。UCloud給每個(gè)用戶均缺省地提供了一個(gè)私有網(wǎng)絡(luò)，用戶在自己的私有網(wǎng)絡(luò)上創(chuàng)建云主機(jī)，無法掃描到不屬于用戶自己的云主機(jī)。

2016年9月，從公網(wǎng)對全部8個(gè)B類IP地址段針對22（SSH）、80（HTTP）、443（HTTPS）和3389（RDP）端口進(jìn)行掃描。有43,100個(gè)IP地址可以通過22端口創(chuàng)建網(wǎng)絡(luò)連接，有54,200個(gè)IP地址可以通過80端口創(chuàng)建網(wǎng)絡(luò)連接，有27,500個(gè)IP地址可以通過443端口創(chuàng)建網(wǎng)絡(luò)連接，有22,800個(gè)IP地址可以通過3389端口創(chuàng)建網(wǎng)絡(luò)連接。

UCloud給每個(gè)用戶均缺省地提供了一個(gè)私有網(wǎng)絡(luò)，用戶在自己的私有網(wǎng)絡(luò)上創(chuàng)建云主機(jī)，無法掃描到不屬于用戶自己的云主機(jī)。由于UCloud的規(guī)模相對較小（相對于阿里云而言），作者未對1433、3306和11211等端口進(jìn)行掃描和自動化登錄測試。

UCloud內(nèi)網(wǎng)帶寬測試（MB/s）

 

 

上表所示是在UCloud北京D區(qū)（PEK-D）進(jìn)行網(wǎng)絡(luò)帶寬探測的結(jié)果。測試中使用了7對云主機(jī)，所有云主機(jī)都部署在同一個(gè)區(qū)域內(nèi)。我們首先使用同樣的測試程序?qū)Σ煌脑浦鳈C(jī)實(shí)例類型進(jìn)行測試，發(fā)現(xiàn)不同的云主機(jī)實(shí)例類型所能夠達(dá)到的內(nèi)網(wǎng)帶寬是一樣的。

考慮到批量測試的費(fèi)用問題，如上測試使用的云主機(jī)實(shí)例類型為“SSD高性能主機(jī)”，配置1顆vCPU和2GB內(nèi)存。在參與測試的14臺云主機(jī)中，1號云主機(jī)在一個(gè)用戶帳號中，2～14號云主機(jī)在另外一個(gè)用戶帳號中。1號云主機(jī)和2號云主機(jī)配為一對，3號云主機(jī)和4號云主機(jī)配為一對，以此類推。

在編號為1的測試中，只有第一對云主機(jī)產(chǎn)生網(wǎng)絡(luò)流量，其他云主機(jī)處于空閑狀態(tài)；在編號為2的測試中，第一對和第二對云主機(jī)產(chǎn)生網(wǎng)絡(luò)流量，其他云主機(jī)處于空閑狀態(tài)，以此類推。

如上測試在一個(gè)月中的不同時(shí)段進(jìn)行了多次，不同批次的測試結(jié)果之間基本一致。基于如上測試，可以認(rèn)為UCloud云的網(wǎng)絡(luò)質(zhì)量相對較好，具體表現(xiàn)在：

1.似乎對云主機(jī)采取了限流措施，但是吞吐量指標(biāo)存在一定范圍的抖動；

2.在小規(guī)模測試中，未探測到網(wǎng)絡(luò)性能明顯惡化的跡象；

3.在小規(guī)模測試中，未觀察到單個(gè)用戶大量占用網(wǎng)絡(luò)帶寬對其他用戶使用網(wǎng)絡(luò)產(chǎn)生影響。

基于現(xiàn)象（1），作者傾向于認(rèn)為UCloud尚未實(shí)現(xiàn)以云主機(jī)為單位進(jìn)行精準(zhǔn)限流。在小規(guī)模測試中觀察到現(xiàn)象（2）和（3）的根本原因是因?yàn)閁Cloud的規(guī)模較大（相對于青云而言），其網(wǎng)絡(luò)資源總量足以消化小規(guī)模測試所產(chǎn)生的網(wǎng)絡(luò)流量。

UCloud存儲帶寬測試（MB/s）

 

 

上表所示是在UCloud北京C區(qū)（PEK-C）進(jìn)行存儲帶寬探測的結(jié)果。測試中使用了10臺云主機(jī)，所有云主機(jī)都部署在同一個(gè)區(qū)域內(nèi)。

•首先，我們使用不同的云主機(jī)實(shí)例類型掛載單塊云硬盤進(jìn)行測試，發(fā)現(xiàn)存儲帶寬上限在100MB/s上下波動，但是并不穩(wěn)定。這個(gè)存儲帶寬上限既與云硬盤的容量無關(guān)，也與云主機(jī)實(shí)例類型無關(guān)。

•其次，我們在同一臺云主機(jī)上掛載多塊云硬盤創(chuàng)建RAID0磁盤陣列進(jìn)行同樣測試。與單塊云硬盤相比，用兩塊云硬盤創(chuàng)建的RAID0磁盤陣列可以獲得200MB/s的存儲帶寬。

用三塊或者四塊云硬盤創(chuàng)建的RAID0磁盤陣列，則可以獲得300MB/s和400MB/s的存儲帶寬。用六塊云硬盤創(chuàng)建的RAID0磁盤陣列，最高可以獲得580MB/s的存儲帶寬，但是均值只有400MB/s。

考慮到批量測試的費(fèi)用問題，如上測試使用的云主機(jī)實(shí)例類型為“SSD高性能主機(jī)”，配置1顆vCPU和2GB內(nèi)存，掛載四塊50GB的云硬盤配置成RAID0磁盤陣列。在參與測試的10臺云主機(jī)中，1號云主機(jī)在一個(gè)用戶帳號中，2～10號云主機(jī)在另外一個(gè)用戶帳號中。

在編號為1的測試中，只有1號云主機(jī)產(chǎn)生存儲流量，其他云主機(jī)處于空閑狀態(tài)；在編號為2的測試中，1號和2號對云主機(jī)產(chǎn)生存儲流量，其他云主機(jī)處于空閑狀態(tài)，以此類推。

如上測試在一個(gè)月中的不同時(shí)段進(jìn)行了多次，不同批次的測試數(shù)據(jù)存在較大差別，但是所觀察到的現(xiàn)象基本一致。基于如上測試，可以認(rèn)為UCloud的存儲質(zhì)量相對較低，具體表現(xiàn)在：

1.沒有對云主機(jī)或者云硬盤采取限流措施，吞吐量指標(biāo)存在大規(guī)模抖動；

2.在小規(guī)模測試中，僅用4臺云主機(jī)即可探測到存儲性能惡化的跡象；

3.隨著參與測試的云主機(jī)數(shù)量的增加，存儲性能惡化極快；

4.在小規(guī)模測試中，可以觀察到單個(gè)用戶大量占用存儲帶寬對其他用戶使用存儲產(chǎn)生影響；

5.在被測試區(qū)域中可能存在其他用戶運(yùn)行的磁盤I/O密集型應(yīng)用，并且其磁盤I/O資源使用模式隨時(shí)間發(fā)生變化。

注：在針對青云的測試中，并未觀察到同類現(xiàn)象。青云的可觀測規(guī)模不足UCloud的1/3，如果青云上存在其他用戶運(yùn)行的磁盤I/O密集型應(yīng)用，應(yīng)該比UCloud更容易觀察到。因此，作者傾向于認(rèn)為在青云的被測試區(qū)域中存在其他用戶運(yùn)行的磁盤I/O密集型應(yīng)用的可能性較小。

▋騰訊云

騰訊集團(tuán)在自治域AS45090、AS132203、AS132591、AS134103中一共聲明了12個(gè)B類IP地址段以及多個(gè)C類IP地址段。

2016年3月，從公網(wǎng)對全部12個(gè)B類IP地址段針對22（SSH）和3389（RDP）端口進(jìn)行掃描，有40,000個(gè)IP地址可以通過22端口創(chuàng)建網(wǎng)絡(luò)連接，有40,000萬個(gè)IP地址可以通過3389端口創(chuàng)建網(wǎng)絡(luò)連接。

2016年9月，從公網(wǎng)對全部12個(gè)B類IP地址段針對22（SSH）、80（HTTP）、443（HTTPS）和3389（RDP）端口進(jìn)行掃描。有65000個(gè)IP地址可以通過22端口創(chuàng)建網(wǎng)絡(luò)連接，有90,000個(gè)IP地址可以通過80端口創(chuàng)建網(wǎng)絡(luò)連接，有20,000個(gè)IP地址可以通過443端口創(chuàng)建網(wǎng)絡(luò)連接，有50,000個(gè)IP地址可以通過3389端口創(chuàng)建網(wǎng)絡(luò)連接。

需要說明的是，如上所述12個(gè)B類IP地址段并非全部用于騰訊云的公有云服務(wù)。騰訊集團(tuán)下的其他業(yè)務(wù)譬如QQ和微信所使用的IP地址也都在這12個(gè)B類IP地址段中。

根據(jù)華為集團(tuán)2014年發(fā)布的成功案例《華為服務(wù)器助力騰訊構(gòu)建十萬級高效部署》[21]的成功案例，騰訊集團(tuán)現(xiàn)網(wǎng)服務(wù)器超過30萬臺，其中華為服務(wù)器超過10萬臺。假設(shè)騰訊集團(tuán)所使用的服務(wù)器當(dāng)中只有10%配置公網(wǎng)IP，需要占用的IP地址數(shù)量就超過3萬個(gè)。

考慮到騰訊集團(tuán)本身對計(jì)算資源的需求還在增長，同時(shí)也會占用更多的IP地址。因此，騰訊云的公有云服務(wù)所使用的IP地址（包括物理機(jī)和虛擬機(jī)）只占如上所述活躍IP地址中的一小部分。

▋其他討論

‖彈性計(jì)算

彈性計(jì)算的核心，是負(fù)載均衡與自動伸縮的有機(jī)結(jié)合。負(fù)載均衡這個(gè)概念出現(xiàn)得比較早，在整個(gè)IT行業(yè)都已經(jīng)被廣泛接受和廣泛應(yīng)用。本文中所討論的幾家公有云服務(wù)提供商，基本上都提供了負(fù)載均衡的功能或者特性。自動伸縮則是云計(jì)算“按需獲取、按量計(jì)費(fèi)”理念的具體實(shí)現(xiàn)，最早的實(shí)現(xiàn)是AWS針對其EC2服務(wù)所提供的AutoScaling Group（ASG）功能。

本文中討論的幾家公有云服務(wù)提供商，只有阿里云（2014年9月）、青云（2015年3月）和UCloud（2016年6月）提供了類似于ASG的自動伸縮功能。

對于一個(gè)正常的Web應(yīng)用，其負(fù)載通?？梢詣澐殖扇齻€(gè)檔次：長期平均負(fù)載，長期高峰負(fù)載，短期爆發(fā)負(fù)載。在每秒只有數(shù)百個(gè)請求的情況下，云主機(jī)集群具備每秒處理一萬個(gè)請求的能力是沒有必要的。在每秒達(dá)到數(shù)萬個(gè)請求的情況下，云主機(jī)集群只有每秒處理一萬個(gè)請求的能力是遠(yuǎn)遠(yuǎn)不夠的。

自動伸縮的目的，就是在應(yīng)用負(fù)載降低時(shí)自動將多余的云主機(jī)從負(fù)載均衡上移除并銷毀以節(jié)省成本，在應(yīng)用負(fù)載升高時(shí)自動啟動更多的云主機(jī)并加入負(fù)載均衡以應(yīng)對壓力。通過自動伸縮，用戶自動地按照實(shí)際負(fù)載購買計(jì)算資源，既不存在處理能力不足的問題，也不存在浪費(fèi)計(jì)算資源的問題。

顯而易見，自動伸縮要求云主機(jī)集群中的每一臺云主機(jī)都能夠穩(wěn)定地提供一定的處理能力。當(dāng)云主機(jī)數(shù)量增加時(shí)，集群處理能力隨之增加；當(dāng)云主機(jī)數(shù)量減少時(shí)，集群處理能力隨之減少。集群處理能力與云主機(jī)數(shù)量之間的關(guān)系不一定是線性的，但必須是正相關(guān)的。

在理想的情況下，這種關(guān)系應(yīng)該是可預(yù)測的。假設(shè)我們有一個(gè)網(wǎng)絡(luò)I/O密集型應(yīng)用，每處理1萬個(gè)請求會產(chǎn)生100MB的內(nèi)網(wǎng)流量，但是對CPU、內(nèi)存、存儲的要求不高。當(dāng)應(yīng)用的負(fù)載為每秒1萬個(gè)請求時(shí)，要求內(nèi)網(wǎng)帶寬大于100MB/s。在阿里云上應(yīng)對這樣的負(fù)載，要求在云主機(jī)集群中部署2臺云主機(jī)。在青云上應(yīng)對這樣的負(fù)載，要求云主機(jī)集群中部署1臺云主機(jī)。

當(dāng)應(yīng)用的負(fù)載為每秒10萬個(gè)請求時(shí)，要求內(nèi)網(wǎng)吞吐量大于1,000MB/s。在阿里云應(yīng)對這樣的負(fù)載，需要在云主機(jī)集群中部署17臺云主機(jī)。在青云上應(yīng)對這樣的負(fù)載，不管在云主機(jī)集群中部署多少臺云主機(jī)都無能為力，因?yàn)樾枰膬?nèi)網(wǎng)帶寬超出了單個(gè)用戶所能夠使用的帶寬上限。

因此，在彈性計(jì)算這個(gè)場景中，用戶需要了解的不是某個(gè)產(chǎn)品最高可以達(dá)到什么性能，而是最低可以達(dá)到什么性能。在云主機(jī)網(wǎng)絡(luò)帶寬測試中，阿里云兩臺云主機(jī)之間的網(wǎng)絡(luò)帶寬只有60MB/s，青云兩臺云主機(jī)之間的網(wǎng)絡(luò)帶寬達(dá)到115MB/s。

看起來似乎青云的網(wǎng)絡(luò)性能要好得多，但是阿里云的網(wǎng)絡(luò)性能是不隨著用戶使用量的增加而發(fā)生惡化的，青云的網(wǎng)絡(luò)性能則是隨著用戶使用量的增加而發(fā)生惡化的。在云主機(jī)存儲帶寬測試中，阿里云單臺云主機(jī)的存儲帶寬只有400MB/s，青云單臺云主機(jī)的存儲帶寬達(dá)到800MB/s。

看起來似乎青云的存儲性能要好得多，但是阿里云的存儲性能是不隨著用戶使用量的增加而發(fā)生惡化的，青云的存儲性能則是隨著用戶使用量的增加而發(fā)生惡化的。

阿里云給所有配置的云主機(jī)提供相同的網(wǎng)絡(luò)帶寬，并不符合“按需獲取、按量計(jì)費(fèi)”的理念。目前阿里云所提供的內(nèi)網(wǎng)帶寬可能可以滿足中小型Web應(yīng)用的需求，但是尚遠(yuǎn)遠(yuǎn)不能滿足大型Web應(yīng)用和科學(xué)計(jì)算應(yīng)用的需求。

作者曾經(jīng)試圖在阿里云上運(yùn)行一些對網(wǎng)絡(luò)I/O和磁盤I/O同時(shí)有較高需求的科學(xué)計(jì)算應(yīng)用，但是由于網(wǎng)絡(luò)I/O方面的限制未能取得預(yù)期的效果。作者注意到阿里云團(tuán)隊(duì)在2015年10月高調(diào)發(fā)布了新的100TB數(shù)據(jù)排序世界記錄[13]，但是這個(gè)世界紀(jì)錄不是在阿里云上獲得的，而是阿里云團(tuán)隊(duì)在物理機(jī)上獲得的。

出于好奇，作者將阿里云團(tuán)隊(duì)于2015年取得的進(jìn)展與Spark團(tuán)隊(duì)于2014年報(bào)告的成績[14]（基于AWS EC2服務(wù)，使用i2.8xlarge實(shí)例）以及加州大學(xué)圣地亞哥分校（UC San Diego，UCSD）和Google團(tuán)隊(duì)于2014年報(bào)告的成績[15]（基于AWS EC2服務(wù)，使用i2.8xlarge實(shí)例）進(jìn)行了對比。

下表是UCSD團(tuán)隊(duì)、Spark團(tuán)隊(duì)、阿里云團(tuán)隊(duì)在100TB排序中的各項(xiàng)參數(shù)：

作者發(fā)現(xiàn)，同樣是100TB數(shù)據(jù)排序，Spark團(tuán)隊(duì)使用了50TB內(nèi)存，UCSD團(tuán)隊(duì)使用了45TB內(nèi)存，阿里云使用了332TB內(nèi)存。打個(gè)極度簡化的比喻，Spark團(tuán)隊(duì)和UCSD團(tuán)隊(duì)需要5個(gè)手指頭來做0到9這十個(gè)數(shù)字的排序，而阿里云團(tuán)隊(duì)需要33個(gè)手指頭來做0到9這十個(gè)數(shù)字的排序。

學(xué)習(xí)過算法的從業(yè)人員都知道，在內(nèi)存富余的情況下進(jìn)行數(shù)據(jù)排序，其算法復(fù)雜度遠(yuǎn)低于在內(nèi)存不足的情況下進(jìn)行數(shù)據(jù)排序。在內(nèi)存不足的情況下，需要先將中間數(shù)據(jù)寫入磁盤，再分批從磁盤讀出進(jìn)行排序操作。

在100TB數(shù)據(jù)排序中，內(nèi)存不足的情況產(chǎn)生100TB的網(wǎng)絡(luò)I/O以及200TB的磁盤I/O（讀和寫操作都是200TB），內(nèi)存富余的情況則產(chǎn)生100TB的網(wǎng)絡(luò)I/O和100TB的磁盤I/O（讀和寫操作都是100TB）。

在這種情況下，Spark團(tuán)隊(duì)單顆CPU核心平均每秒鐘處理的數(shù)據(jù)量（以MB計(jì)算）是阿里云團(tuán)隊(duì)的1.72倍，UCSD團(tuán)隊(duì)單顆CPU核心平均每秒鐘處理的數(shù)據(jù)量（以MB計(jì)算）是阿里云團(tuán)隊(duì)的1.91倍。

我們也注意到阿里云團(tuán)隊(duì)所使用的處理器相對較老，其處理能力相對較低。就裸機(jī)單線程處理能力而言，Intel Xeon E5-2670 v2 @2.50GHz[18]是Intel Xeon E5-2630 @2.30GHz[16]的2.5倍，是Intel Xeon E5-2650 v2 @2.60GHz[17]的1.7倍。此外，我們也注意到EC2實(shí)例使用的是虛擬處理器核心，存在一定的虛擬化損失。

基于如上兩點(diǎn)，可以推測如果阿里云同樣采用Intel Xeon E5-2670 v2 @2.50GHz處理器的話，則其單顆CPU核心平均每秒鐘處理的數(shù)據(jù)量（以MB計(jì)算）表面上看來可以與Spark團(tuán)隊(duì)和UCSD團(tuán)隊(duì)所報(bào)告的成績持平。

問題在于，Spark團(tuán)隊(duì)和UCSD團(tuán)隊(duì)所處理的是一個(gè)比較復(fù)雜的場景（數(shù)據(jù)量是內(nèi)存的2倍），其算法復(fù)雜度較高；而阿里云所處理的是一個(gè)比較簡單的場景（內(nèi)存是數(shù)據(jù)量的3.3倍），其算法復(fù)雜度較低。

因此，阿里云所報(bào)告的成績只是集群規(guī)模增長的自然結(jié)果，其系統(tǒng)和算法遠(yuǎn)遠(yuǎn)不如Spark團(tuán)隊(duì)和UCSD團(tuán)隊(duì)的系統(tǒng)和算法。(阿里云所處理的場景與Yahoo團(tuán)隊(duì)于2013年所處理的場景[19]是類似的，并且其系統(tǒng)和算法優(yōu)于Yahoo團(tuán)隊(duì)的系統(tǒng)和算法。)

阿里云所報(bào)告的100TB數(shù)據(jù)排序成績，證明的是阿里云作為一家公司已經(jīng)具備了管理和使用超大型集群的能力。這個(gè)能力與阿里云于2014年在VLDB上發(fā)布的關(guān)于伏羲的論文[20]所報(bào)告的能力是類似的。但是，這個(gè)能力與阿里云所提供的產(chǎn)品和服務(wù)的能力并不直接相關(guān)。譬如說，阿里云的ECS（云主機(jī)）服務(wù)所提供的計(jì)算、網(wǎng)絡(luò)和存儲能力，尚遠(yuǎn)遠(yuǎn)不足以滿足運(yùn)行這個(gè)100TB數(shù)據(jù)排序的要求。

作者認(rèn)為，阿里云尚需加強(qiáng)其ECS服務(wù)所提供的計(jì)算、網(wǎng)絡(luò)和存儲能力。什么時(shí)候阿里云的用戶能夠自地主在阿里云所提供的ECS服務(wù)上運(yùn)行這個(gè)100TB數(shù)據(jù)排序并且達(dá)到Spark團(tuán)隊(duì)于2014年所取得的成績，那么阿里云的ECS服務(wù)就真的是達(dá)到AWS的EC2服務(wù)在2014年的水平了。

‖區(qū)域間網(wǎng)絡(luò)狀況

為了了解各個(gè)公有云服務(wù)提供商的不同區(qū)域間的網(wǎng)絡(luò)狀況，我們在阿里云、青云和UCloud的華南和華北區(qū)域各啟動云主機(jī)一臺，并在兩臺云主機(jī)之間進(jìn)行MTR測試。這部分測試數(shù)據(jù)，是在2016年8月底獲得的。

 

 

上圖所示為阿里云華南1區(qū)到華北2區(qū)的測試結(jié)果，數(shù)據(jù)包經(jīng)過11跳抵達(dá)目標(biāo)云主機(jī)。在這個(gè)路由當(dāng)中，有5跳（4～8）經(jīng)過的設(shè)備使用公網(wǎng)IP地址，其余6跳經(jīng)過的設(shè)備使用阿里云內(nèi)網(wǎng)IP。

值得說明的是，上圖所示的4個(gè)公網(wǎng)IP全部屬于阿里云（屬于自治域AS37963），說明從阿里云華南1區(qū)到華北2區(qū)的整個(gè)數(shù)據(jù)鏈路層都在阿里云的掌控之下。

 

 

上圖所示為青云北京2區(qū)到廣東1區(qū)的測試結(jié)果，數(shù)據(jù)包經(jīng)過23跳抵達(dá)目標(biāo)云主機(jī)。在這個(gè)路由當(dāng)中，有16跳（3～18）經(jīng)過公網(wǎng)，其余7跳在青云自己的內(nèi)網(wǎng)。在整個(gè)數(shù)據(jù)鏈路上，沒有任何一個(gè)公網(wǎng)IP屬于青云。

因此，青云不同區(qū)域間的互聯(lián)互通，完全依賴于數(shù)據(jù)中心服務(wù)提供商之間的互聯(lián)互通。從從這個(gè)測試結(jié)果來看，青云“1跳進(jìn)入全球任何網(wǎng)絡(luò)運(yùn)營商的主干網(wǎng)”這個(gè)目標(biāo)可能還需要很長時(shí)間方可達(dá)成。

 

 

上圖為UCloud廣東B區(qū)到北京C區(qū)的測試結(jié)果，數(shù)據(jù)包經(jīng)過19跳抵達(dá)目標(biāo)云主機(jī)。在這個(gè)路由當(dāng)中，有8跳（6～13）經(jīng)過公網(wǎng)，其余11跳在UCloud自己的內(nèi)網(wǎng)。在整個(gè)數(shù)據(jù)鏈路上，沒有任何一個(gè)公網(wǎng)IP屬于UCloud。因此，UCloud不同區(qū)域間的互聯(lián)互通，也完全依賴于數(shù)據(jù)中心服務(wù)提供商之間的互聯(lián)互通。

從網(wǎng)絡(luò)拓?fù)鋪砜矗瑖鴥?nèi)互聯(lián)網(wǎng)可以分為主干網(wǎng)（公網(wǎng)）、地區(qū)網(wǎng)（廣域網(wǎng)）、主節(jié)點(diǎn)（城域網(wǎng)）幾個(gè)層次。在計(jì)算系統(tǒng)可靠度的時(shí)候，又可以進(jìn)一步將其簡化成一個(gè)串行系統(tǒng)來處理。

我們知道，串行系統(tǒng)的可靠度等于系統(tǒng)中各個(gè)組件的可靠度的乘積。串行系統(tǒng)中包含的組件越多，則整個(gè)系統(tǒng)的可靠性越低。假設(shè)一個(gè)串行系統(tǒng)中包含100個(gè)組件，每個(gè)組件的可靠度為0.999，則整個(gè)系統(tǒng)的可靠度為0.999100=0.905。

我們知道，中國ChinaNet骨干網(wǎng)的拓?fù)浣Y(jié)構(gòu)在邏輯上分為兩層，即核心層和大區(qū)層。核心層由北京、上海、廣州、沈陽、南京、武漢、成都、西安等8個(gè)城市的核心節(jié)點(diǎn)組成，其功能主要是提供與國際互聯(lián)的接口以及大區(qū)之間互聯(lián)的通路。全國31個(gè)省會城市按照行政區(qū)劃，以上述8個(gè)核心節(jié)點(diǎn)為中心劃分為8個(gè)大區(qū)網(wǎng)絡(luò)。這8個(gè)大區(qū)網(wǎng)共同構(gòu)成了大區(qū)層，大區(qū)之間通信必須經(jīng)過核心層。

基于這樣一個(gè)極度簡化的模型，云服務(wù)提供商某個(gè)區(qū)域所在的數(shù)據(jù)中心與核心層之間的串行系統(tǒng)的組件數(shù)量，約等于如上所述MTR測試結(jié)果中數(shù)據(jù)包經(jīng)過公網(wǎng)的跳數(shù)除以二。

以此估算，阿里云的串行系統(tǒng)組件數(shù)量為2，青云的串行系統(tǒng)組件數(shù)量為8，UCloud的串行系統(tǒng)組件數(shù)量為4。假設(shè)這個(gè)串行系統(tǒng)中每個(gè)組件的可靠度是相同的（實(shí)際上并不相同），則阿里云數(shù)據(jù)鏈路的可靠度大于UCloud，而UCloud數(shù)據(jù)鏈路的可靠度大于青云。

‖市場規(guī)模

公有云作為一種新型服務(wù)，其市場規(guī)模尚有相當(dāng)程度的自然增長空間。因此，五年之后的公有云可能達(dá)到的規(guī)模只會比這個(gè)數(shù)字更大?；谶@些估算，我們可以根據(jù)其規(guī)模將一家公有云創(chuàng)業(yè)企業(yè)的成長分為五個(gè)階段：

•概念階段，小于5,000臺虛擬機(jī)。公司的終極目標(biāo)相對模糊，在私有云解決方案提供商和公有云服務(wù)提供商之間搖擺不定。在戰(zhàn)術(shù)層面，缺乏明確的技術(shù)路線圖，產(chǎn)品形態(tài)相對原始并且沒有明確的技術(shù)指標(biāo)。

•原型階段，小于10,000臺虛擬機(jī)。公司基本上將其終極目標(biāo)定位為公有云服務(wù)提供商。由于公有云和私有云之間的巨大差異，必然要放棄私有云解決方案服務(wù)提供商的身份。在戰(zhàn)術(shù)層面，基本形成相對清晰的技術(shù)路線圖，基礎(chǔ)產(chǎn)品（云主機(jī)）基本定型，在宕機(jī)時(shí)間和產(chǎn)品性能方面均有明確的技術(shù)指標(biāo)。在云主機(jī)的基礎(chǔ)上，提供能夠承擔(dān)中低負(fù)載的負(fù)載均衡、數(shù)據(jù)庫、緩存等等周邊產(chǎn)品。

•成長階段，小于50,000臺虛擬機(jī)。基礎(chǔ)產(chǎn)品（云主機(jī)）能夠滿足高性能計(jì)算的要求，同時(shí)發(fā)展出一系列模塊化的周邊產(chǎn)品。普通用戶完全依靠云服務(wù)提供商所提供的不同模塊即可自主創(chuàng)建大規(guī)?？缮炜s型應(yīng)用（無需云服務(wù)提供商進(jìn)行干預(yù)）。

•成熟階段，小于100,000臺虛擬機(jī)。在技術(shù)方面，資源利用率開始提高，規(guī)模效應(yīng)開始出現(xiàn)。在市場方面，客戶忠誠度開始提高，馬太效應(yīng)開始出現(xiàn)。這標(biāo)志著公司在公有云領(lǐng)域已經(jīng)獲得了較有份量的市場份額，其產(chǎn)品和技術(shù)獲得了一個(gè)或者多個(gè)細(xì)分市場的廣泛認(rèn)可。

•產(chǎn)業(yè)階段，大于100,000臺虛擬機(jī)。只有進(jìn)入這一階段，才能夠認(rèn)為一個(gè)服務(wù)提供商已經(jīng)站穩(wěn)了腳跟，可以把公有云當(dāng)作一個(gè)產(chǎn)業(yè)來做了。至于最后能夠做多大，一個(gè)好看國內(nèi)的大環(huán)境，另外一個(gè)還得看公司自身的發(fā)展策略。

公有云服務(wù)的未來還遠(yuǎn)遠(yuǎn)不止于此。作者于2012年在《虛擬化、云計(jì)算、開放源代碼及其他》[6]]這篇博客里面提到了英國經(jīng)濟(jì)學(xué)家威廉杰文斯（William Stanley Jevons，1835-1882）在《煤礦問題》（The Coal Question）[5]一書中指出的一個(gè)似乎自相矛盾的現(xiàn)象：

蒸汽機(jī)效率方面的進(jìn)步提高了煤的能源轉(zhuǎn)換率，能源轉(zhuǎn)換率的提高導(dǎo)致了能源價(jià)格降低，能源價(jià)格的降低又進(jìn)一步導(dǎo)致了煤消費(fèi)量的增加。這種現(xiàn)象稱為杰文斯悖論，其核心思想是資源利用率的提高導(dǎo)致價(jià)格降低，最終會增加資源的使用量。

在過去150年當(dāng)中，杰文斯悖論在主要的工業(yè)原料、交通、能源、食品工業(yè)等多個(gè)領(lǐng)域都得到了實(shí)證?；谕瑯拥脑?，作者在這篇博客里面又進(jìn)一步斷言：“公共云計(jì)算服務(wù)的核心價(jià)值，是將服務(wù)器、存儲、網(wǎng)絡(luò)等等硬件設(shè)備從自行采購的固定資產(chǎn)變成了按量計(jì)費(fèi)的公共資源。虛擬化技術(shù)提高了計(jì)算資源的利用率，導(dǎo)致了計(jì)算資源價(jià)格的降低，最終會增加計(jì)算資源的使用量。”

‖用戶習(xí)慣

根據(jù)作者的觀察，目前國內(nèi)大部分公有云用戶還是把云主機(jī)當(dāng)作傳統(tǒng)物理服務(wù)器的替代品來使用。這個(gè)觀察在作者與各個(gè)公有云服務(wù)提供商負(fù)責(zé)人的訪談中也得到了驗(yàn)證。

在傳統(tǒng)的IT架構(gòu)中，操作系統(tǒng)是安裝在物理服務(wù)器上的。由于重新安裝操作系統(tǒng)需要造成很長的宕機(jī)時(shí)間，出現(xiàn)軟件層面故障時(shí)運(yùn)維或者開發(fā)人員往往傾向于尋找問題來源并予以排除。

很多時(shí)候，運(yùn)維或者開發(fā)人員需要花費(fèi)很長時(shí)間來尋找一些不易發(fā)覺的輸入或者拼寫錯(cuò)誤（例如四個(gè)空格和一個(gè)tab）。在彈性計(jì)算這個(gè)場景中，操作系統(tǒng)是通過映像模板創(chuàng)建的，獲得一臺全新的包含正確配置的云主機(jī)只需要數(shù)分鐘甚至更短的時(shí)間。

在這個(gè)時(shí)間優(yōu)勢的基礎(chǔ)上，云計(jì)算服務(wù)提供商終于可以直面長期以來被傳統(tǒng)IT服務(wù)提供商所刻意回避的兩個(gè)事實(shí)。第一個(gè)事實(shí)是組件的失效是必然的，是不可避免的；第二個(gè)事實(shí)是組件的失效是隨機(jī)的，是不可預(yù)測的。

用AWS首席技術(shù)長官Werner Vogels的原話來說，就是“任何組件可在任何時(shí)刻失效”（Everything fails, all the time.）。一個(gè)集群中任意云主機(jī)均可以在任意時(shí)刻由于任意原因（底層硬件、網(wǎng)絡(luò)環(huán)境、操作系統(tǒng)、應(yīng)用軟件）發(fā)生失效。

有了負(fù)載均衡與自動伸縮后，一臺云主機(jī)發(fā)生失效時(shí)，自動伸縮功能自動地將其從負(fù)載均衡上移除并進(jìn)行銷毀，同時(shí)自動地啟動一臺新的云主機(jī)并加入負(fù)載均衡。

因此，用戶可以將云主機(jī)視為“即用即拋型”一次性資源。忽略云主機(jī)的失效，不僅不會犧牲應(yīng)用服務(wù)質(zhì)量，還可以將寶貴的資源集中投入到公司的關(guān)鍵業(yè)務(wù)。

可惜的是，由于缺乏對彈性計(jì)算的理解，大量系統(tǒng)管理員延續(xù)了在使用物理服務(wù)器時(shí)期培養(yǎng)的習(xí)慣。他們在云主機(jī)等計(jì)算資源失效時(shí)驚慌失措，并且熱衷于尋找所謂的“根本原因分析”（root cause analysis）。

他們在潛意識里還是將基礎(chǔ)設(shè)施視為公司的資產(chǎn)，試圖去了解和掌握云主機(jī)之下每一個(gè)層面的信息。他們沒有意識到在彈性計(jì)算這個(gè)場景里這些努力不僅沒有必要而且會阻礙整個(gè)公司技術(shù)進(jìn)步。

解決這個(gè)問題，需要所有的公有云服務(wù)提供商持之以恒地對用戶進(jìn)行教育。用戶的認(rèn)知水平提高了，也會進(jìn)一步促進(jìn)公有云市場的發(fā)展。除了對用戶進(jìn)行教育之外，公有云服務(wù)提供商也需要加強(qiáng)對員工的教育。

‖安全問題

在“用戶體驗(yàn)”這個(gè)小節(jié)的網(wǎng)絡(luò)測試部分，作者僅報(bào)告了針對阿里云的1433、3306和11211端口掃描情況。主要的考慮在于小型公有云服務(wù)提供商更加需要保護(hù)，因此不宜對小型公有云服務(wù)提供商進(jìn)行同類測試；次要的考慮在于公有云服務(wù)提供商無法獨(dú)立承擔(dān)安全重任，因此需要向從業(yè)人員披露公有云服務(wù)中存在的安全隱患。

需要說明的是，作者在阿里云內(nèi)網(wǎng)和外網(wǎng)獲得的端口掃描結(jié)果，并非阿里云獨(dú)有的現(xiàn)象。任何一個(gè)剛剛學(xué)會運(yùn)行bash腳本的從業(yè)人員，都可以通過類似方法在AWS所在的IP段掃描到類似的結(jié)果。

阿里云和AWS的不同之處，在于阿里云教育客戶“選擇云盾，讓您的業(yè)務(wù)安全性如同阿里巴巴一般”，AWS則教育客戶“安全共擔(dān)”（shared responsibility）模型。云盾的產(chǎn)品介紹頁面宣稱“每天防御超過958萬次暴力破解攻擊”，但是作者基于社會工程數(shù)據(jù)庫的自動化登錄測試也獲得了部分成功。這樣的結(jié)果，可以有三個(gè)解釋：

•大部分被成功登錄的云主機(jī)沒有使用云盾服務(wù)；

•少部分被成功登錄的云主機(jī)雖然使用了云盾服務(wù)但是其密碼設(shè)置過于薄弱，因此在云盾未被激活之前就已經(jīng)被成功登錄；

•類似于Memcached這樣免登錄的服務(wù)，云盾目前是完全無能為力的。在阿里云內(nèi)網(wǎng)，作者還探測到大量其他免登錄或者僅使用弱口令保護(hù)的網(wǎng)絡(luò)服務(wù)，例如RabbitMQ。

因此，不管用戶是否使用服務(wù)提供商所提供的云安全服務(wù)，均應(yīng)對客戶進(jìn)行“安全共擔(dān)”的教育，引導(dǎo)客戶采取必要的措施保護(hù)其所使用的計(jì)算資源。遺憾的是，阿里云作為國內(nèi)規(guī)模最大的公有云服務(wù)提供商，向用戶傳達(dá)了完全錯(cuò)誤的信息。

作者建議阿里云安全團(tuán)隊(duì)針對阿里云內(nèi)網(wǎng)進(jìn)行常規(guī)性的分布式端口掃描，充分了解安全隱患的嚴(yán)重程度，并在此基礎(chǔ)上向阿里云的用戶提出針對性的改進(jìn)建議。

▋結(jié)語：

在接受InfoQ方面的邀請準(zhǔn)備規(guī)劃這篇報(bào)告的時(shí)候，作者的內(nèi)心是興奮的。在獲得所有測試數(shù)據(jù)準(zhǔn)備撰寫這篇報(bào)告的時(shí)候，作者的內(nèi)心是矛盾的。一方面，作為并行與分布式計(jì)算領(lǐng)域的學(xué)生，作者希望為業(yè)界提供一些有用的信息和觀點(diǎn)；

另一方面，作為公有云服務(wù)領(lǐng)域的從業(yè)人員，作者深知發(fā)表一份涉及多家友商的報(bào)告會帶來諸多爭議。在InfoQ方面的鼓勵(lì)下，作者選擇以真實(shí)的身份發(fā)布這些的數(shù)據(jù)和觀點(diǎn)，希望能夠?qū)鴥?nèi)云計(jì)算從業(yè)人員有所幫助。

作者丨蔣清野

▋參考文獻(xiàn)：

1.工業(yè)和信息化部電信研究院（中國信通院，CAICT），《云計(jì)算白皮書（2014年）》，2014年5月

2、中國電子信息產(chǎn)業(yè)發(fā)展研究院工業(yè)和信息化部賽迪智庫，《云計(jì)算發(fā)展白皮書（2015版）》，2015年4月

3.工業(yè)和信息化部電信研究院（中國信通院，CAICT），《云計(jì)算白皮書（2016年）》，2016年9月

4.Peter Mell and Timothy Grance, “The NIST Definition of Cloud Computing”, NIST Special Publication 800-145, September 2011

5.William Stanley Jevons, “The Coal Question”, 1866

6.蔣清野，《虛擬化、云計(jì)算、開放源代碼及其他》，2012年10月

7.蔣清野，《從王博士說起》，2013年12月

8.蔣清野，《淺談“中國”語境下的公有云發(fā)展》，2015年5月

9.Qingye Jiang, Young Choon Lee, Albert Y. Zomaya, “Price Elasticity in the Enterprise Computing Resource Market”, IEEE Cloud Computing, vol.3, no. 1, pp. 24-31, Jan.-Feb. 2016, doi:10.1109/MCC.2016.14

10.章文嵩，《淘寶軟件基礎(chǔ)設(shè)施構(gòu)建實(shí)踐》，第三屆中國云計(jì)算大會，2011年5月

11.高山淵，《阿里巴巴系統(tǒng)運(yùn)維實(shí)踐分享》，QClub深圳站，2012年6月

12.Netcraft, “Aliyun cloud growth makes Alibaba largest hosting company in China”, May 2015

13.Jiamang Wang, Yongjun Wu, Hua Cai, Zhipeng Tang, Zhiqiang Lv, Bin Lu, Yangyu Tao, Chao Li, Jingren Zhou, Hong Tang, "FuxiSort", Alibaba Group Inc, October 2015

14.Reynold Xin, Parviz Deyhim, Ali Ghodsi, Xiangrui Meng, Matei Zaharia, "GraySort> 15.Michael Conley, Amin Vahdat, George Porter, "TritonSort 2014", University of California at San Diego, 2014

16.Intel Xeon E5-2630基準(zhǔn)測試數(shù)據(jù)

17.Intel Xeon E5-2650基準(zhǔn)測試數(shù)據(jù)

18.Intel Xeon E5-2670基準(zhǔn)測試數(shù)據(jù)

19.Thomas Graves, "GraySort and MinuteSort at Yahoo> 20.Zhuo Zhang, Chao Li, Yangyu Tao, Renyu Yang, Hong Tang, and Jie Xu. "Fuxi: a fault-tolerant resource management and job scheduling system at internet scale." Proceedings of the VLDB Endowment 7, no. 13 (2014): 1393-1404.

21.華為集團(tuán)，《華為服務(wù)器助力騰訊構(gòu)建十萬級高效部署》，2014年7月

22.陳海泉，《下一代超大規(guī)模軟件定義網(wǎng)絡(luò)技術(shù)實(shí)踐》，2016年1月

23.高旭磊，《招商銀行關(guān)于金融云的思考》，中國金融電腦，2016年8月

24.阿里云，《阿里云生態(tài)路線圖》，2015年7月