背景介紹
2015年12月构灸，InfoQ的編輯魏星邀請作者撰寫一篇關(guān)于中國公有云服務(wù)發(fā)展狀況的文章澜躺。因為作者個人對公有云這個領(lǐng)域一直抱有很大的興趣瞒斩，便貿(mào)然答應(yīng)了下來增拥。在這篇文章的準備過程中啄巧，作者系統(tǒng)地閱讀了國內(nèi)較為知名的幾份云計算白皮書[1，2掌栅，3]秩仆。作者發(fā)現(xiàn)這些報告大都高瞻遠矚提綱挈領(lǐng)，缺乏對具體的公有云服務(wù)提供商的描述渣玲，未能讓讀者一窺國內(nèi)公有云服務(wù)發(fā)展之真實面貌逗概。在InfoQ的協(xié)調(diào)下，作者與國內(nèi)多家公有云服務(wù)提供商的主要負責(zé)人進行了電話訪談忘衍，圍繞團隊建設(shè)逾苫、產(chǎn)品研發(fā)、服務(wù)運營這三個問題進行了討論枚钓。除此之外铅搓，作者也在本文所探討的所有公有云上都注冊了賬號，從用戶體檢的角度進行了一些小規(guī)模的測試搀捷。這篇文章的目的星掰，便是從團隊建設(shè)多望、產(chǎn)品研發(fā)、服務(wù)運營氢烘、用戶體驗等四個方面對中國的公有云服務(wù)發(fā)展狀況做一個簡要的綜述怀偷。
根據(jù)美國國家標準技術(shù)研究院（NIST）的定義[4]，云計算在服務(wù)模型上可以劃分為軟件即服務(wù)（SaaS）播玖、平臺即服務(wù)（PaaS）和設(shè)施即服務(wù)（IaaS）椎工，在發(fā)布模型上又可以劃分為私有云、社區(qū)云蜀踏、公有云和混合云维蒙。需要說明的是，隨著云計算技術(shù)的發(fā)展果覆，如上所述服務(wù)模型和發(fā)布模型之間的界限也日趨模糊颅痊。在本文的范疇內(nèi)，“公有云”一詞泛指面向公眾開放服務(wù)的平臺即服務(wù)和設(shè)施即服務(wù)局待。除此之外斑响，各種名義的私有云（Private Cloud）、專有云（Dedicated Cloud）燎猛、托管云（Managed Cloud）均未包括在本文的范疇之中恋捆。
本文中“團隊建設(shè)”照皆、“產(chǎn)品研發(fā)”重绷、“服務(wù)運營”三個小節(jié)的數(shù)據(jù)來源有兩個。一個是云服務(wù)提供商主動發(fā)布的新聞資訊膜毁，另一個是作者與云服務(wù)提供商的主要負責(zé)人之間的電話訪談昭卓。作者與黃允松（青云）、季昕華（UCloud）瘟滨、李爽（美團云）候醒、錢廣杰（盛大云）、沈志華（又拍云）杂瘸、王慧星（騰訊云）倒淫、許式偉（七牛云）、朱樺（金山云）等業(yè)內(nèi)專家（按姓氏拼音排序）的訪談败玉，是由InfoQ方面統(tǒng)一協(xié)調(diào)安排的敌土，在此作者深表感謝。這個三個小節(jié)的內(nèi)容运翼，在定稿之前均經(jīng)過受訪者及其公關(guān)/市場團隊的確認返干，反映的是云服務(wù)提供商自身的觀點和思路。在審稿階段血淌，青云撤回了與作者進行訪談時所發(fā)表的一切言論矩欠；出于保護商業(yè)機密的考慮，阿里云拒絕了作者的訪談邀請。因此癌淮，如上三個小節(jié)未能包括青云和阿里云的觀點躺坟。
“用戶體驗”和“其他討論”這兩個小節(jié)，是作者獨立獲得的數(shù)據(jù)以及由此引出的觀點乳蓄，在定稿之前未接受任何一家云服務(wù)提供商的審核瞳氓。需要特別說明的是，如上所述云服務(wù)提供商的主要負責(zé)人接受作者的訪談并不代表他們認可作者在“用戶體驗”和“其他討論”這兩個小節(jié)中所報告的數(shù)據(jù)和觀點栓袖。此外匣摘，作者本人也并不持有本文中所討論的任何一家云服務(wù)提供商的內(nèi)幕信息，作者獨立獲得的數(shù)據(jù)僅僅是基于作者所使用的測試方法得到的觀測結(jié)果裹刮。受種種技術(shù)條件的限制音榜，作者無法對這些數(shù)據(jù)的準確性進行背書，也無法對其誤差范圍進行估算捧弃。本文中報告的大部分數(shù)據(jù)是在2016年3月底之前獲得的赠叼，這部分數(shù)據(jù)的獲取時間在正文中不再特別說明；小部分數(shù)據(jù)是在2016年8月底獲得的违霞，這部分數(shù)據(jù)的獲取時間在正文中會有特別說明嘴办。讀者在引用本文所報告之數(shù)據(jù)時，應(yīng)當考慮到數(shù)據(jù)的時效性买鸽。
本文中有多個小節(jié)對各個云服務(wù)提供商進行了逐一介紹涧郊。相關(guān)云服務(wù)提供商在這幾個小節(jié)中出現(xiàn)的順序是按照拼音字母次序排列的。
本文僅討論中國本土的公有云服務(wù)提供商眼五。Amazon Web Services(AWS)妆艘、Microsoft Azure、Google Cloud Platform等等進入或者未進入中國市場的外資企業(yè)不在本文的討論范圍之內(nèi)看幼。
在這個部分批旺，我們以用戶體驗為主線，對不同公有云服務(wù)提供商的產(chǎn)品進行一些小規(guī)模測試诵姜。這些測試旨在探測客戶關(guān)心的幾個關(guān)鍵參數(shù)：
（1）服務(wù)規(guī)模汽煮；
（2）網(wǎng)絡(luò)與存儲吞吐能力；
（3）資源隔離狀況棚唆；
（4）客服能力暇赤。
需要說明的是，這些測試僅僅是試探性的探測（probe ethos）瑟俭，并非嚴謹?shù)幕鶞蕼y試（benchmark）翎卓，測試結(jié)果反映的只是測試當時的用戶體驗。作者本人的技術(shù)背景與云主機類產(chǎn)品比較接近摆寄，對云存儲領(lǐng)域的了解相對有限失暴。因此坯门，這些測試僅針對設(shè)施層面的云主機類產(chǎn)品，并且沒有完整覆蓋所有國內(nèi)的IaaS服務(wù)提供商逗扒。（在此作者謹向七牛云和又拍云這兩家公有云服務(wù)提供商致以誠摯的歉意古戴。）
針對服務(wù)規(guī)模的測試，是通過端口掃描進行的矩肩。針對一個特定的IaaS服務(wù)提供商现恼，這個測試分為兩個步驟進行：
在所有區(qū)域分不同時段（時間跨度長達一個月）大量創(chuàng)建云主機，通過枚舉得出云主機所用公網(wǎng)IP所在的B段列表黍檩，并通過公開的信息進行矯正叉袍；
對所有的B段針對22、80刽酱、443喳逛、3389端口進行掃描，將掃描結(jié)果記錄到數(shù)據(jù)庫棵里。
有些B段IP地址润文，可能超出了IaaS服務(wù)提供商所擁有IP資源范圍。譬如某些服務(wù)提供商使用了運營商提供的IP地址殿怜，在同一個B段里面還有用于其它用途的IP地址典蝌。有些B段IP地址，雖然由某個服務(wù)提供商擁有头谜，但是并非用于IaaS服務(wù)骏掀。因此，端口掃描得到的結(jié)果乔夯，反映的是從外界可以探測到的服務(wù)規(guī)模上限砖织。考慮到防火墻末荐、安全組、部分云主機未配置公網(wǎng)等等多種因素新锈，端口掃描的結(jié)果是小于實際服務(wù)規(guī)模的甲脏。
針對網(wǎng)絡(luò)吞吐能力的測試，是在同一個區(qū)域內(nèi)啟動N對云主機妹笆。在所有的云主機內(nèi)安裝Apache服務(wù)块请，提供一個100MB大小的文件下載。在每一對云主機之間拳缠，在每臺云主機上啟動多個線程從對方下載如上所述100MB大小的文件墩新，單次測試持續(xù)時間15分鐘。由于供下載的文件是同一個窟坐，該文件在第一次被讀取之后便駐留在內(nèi)存當中海渊，不再產(chǎn)生新的磁盤I/O绵疲。因此，這個測試探測的是兩臺云主機之間的內(nèi)網(wǎng)帶寬臣疑。N的取值范圍盔憨，從1逐漸增加到10，目的在于探測單個用戶可以使用的網(wǎng)絡(luò)帶寬邊界讯沈。測試中使用的第一對云主機郁岩，一臺在用戶賬號A中，一臺在用戶賬號B中缺狠，目的在于測試網(wǎng)絡(luò)資源隔離狀況问慎。針對一個特定的IaaS服務(wù)提供商，這個測試在不同時段進行多次挤茄，以了解不同時段對網(wǎng)絡(luò)性能的影響蝴乔。
針對存儲吞吐能力的測試，是在同一個區(qū)域內(nèi)啟動N臺云主機驮樊。在每臺云主機上掛載M塊云硬盤創(chuàng)建一個RAID0磁盤陣列薇正。在云主機上啟動多個線程，分別往磁盤陣列上寫入多個遠大于云主機物理內(nèi)存的大文件囚衔。單次測試持續(xù)15分鐘挖腰，記錄測試過程中的磁盤寫入帶寬。這個測試分為三個步驟進行：
M的取值為1练湿，探測單臺云主機上單塊云硬盤的存儲帶寬上限猴仑；
M的取值在2到4之間，探測單臺云主機上一個磁盤陣列的存儲帶寬上限肥哎；
N的取值在1到10之間辽俗，探測單個用戶可以使用的存儲帶寬上限。測試中使用的前兩臺云主機篡诽，一臺在用戶賬號A中崖飘，一臺在用戶賬號B中，目的在于測試存儲資源隔離狀況杈女。針對一個特定的IaaS服務(wù)提供商朱浴，這個測試在不同時段進行多次，以了解不同時段對存儲性能的影響达椰。
作者也注意到一些公有云服務(wù)提供商采取了“地理區(qū)域——可用區(qū)——集群”這樣的結(jié)構(gòu)設(shè)計翰蠢。在同一個可用區(qū)中，盡可能將同一用戶所使用的計算資源分配到同一個集群啰劲。因此梁沧，針對網(wǎng)絡(luò)吞吐能力的測試結(jié)果和針對存儲吞吐能力的測試結(jié)果反映的可能是一個可用區(qū)中某一個集群的網(wǎng)絡(luò)吞吐能力和存儲吞吐能力。
針對客服能力的測試蝇裤，是在云服務(wù)提供商的Web控制臺里提交工單廷支。工單的內(nèi)容包括要求提高配額频鉴、詢問基礎(chǔ)性的使用問題、報告缺陷等等酥泞。這部分的測試砚殿，一方面在于了解客服的響應(yīng)速度，另一方面在于了解客服處理能力芝囤。
阿里巴巴集團在自治域AS37963似炎、AS45102中一共聲明了120個B類IP地址段以及多個C類IP地址段。
2016年3月悯姊，從公網(wǎng)對全部120個B類IP地址段針對22（SSH）和3389（RDP）端口進行掃描羡藐，有26.5萬個IP地址可以通過22端口創(chuàng)建網(wǎng)絡(luò)連接，有21.5萬個IP地址可以通過3389端口創(chuàng)建網(wǎng)絡(luò)連接悯许。
2016年9月仆嗦，從公網(wǎng)對如上所述IP地址段針對22（SSH）、80（HTTP）先壕、443（HTTPS）和3389（RDP）端口進行掃描瘩扼。有35萬個IP地址可以通過22端口創(chuàng)建網(wǎng)絡(luò)連接，有92萬個IP地址可以通過80端口創(chuàng)建網(wǎng)絡(luò)連接垃僚，有9萬個IP地址可以通過443端口創(chuàng)建網(wǎng)絡(luò)連接集绰，有25萬個IP地址可以通過3389端口創(chuàng)建網(wǎng)絡(luò)連接。
需要說明的是谆棺，如上所述120個B類IP地址段并非全部用于阿里云的公有云服務(wù)栽燕。阿里巴巴集團下的其他業(yè)務(wù)譬如淘寶網(wǎng)和支付寶所使用的IP地址也都在這120個B類IP地址段中。根據(jù)章文嵩2011年5月在第三屆中國云計算大會上的演講[10]改淑，淘寶網(wǎng)的生產(chǎn)服務(wù)器大約為20,000臺碍岔。根據(jù)高山淵2012年6月在QClub深圳站上的演講[11]，阿里巴巴集團的服務(wù)器規(guī)模接近10萬朵夏。根據(jù)工信部電信研究院發(fā)布的《云計算白皮書（2014年）》蔼啦，截止到2013年9月運行在阿里云上的Web服務(wù)器數(shù)量達到18,000個，比2012年增長了500%侍郭。根據(jù)NetCraft在2015年6月發(fā)布的數(shù)據(jù)询吴，阿里云所管理的Web服務(wù)器達到45,000個×猎考慮到阿里巴巴集團過去五年中的業(yè)務(wù)增長對計算資源的需求，阿里云公有云部分所使用的IP地址（包括物理機和虛擬機）可能只占如上所述活躍IP地址中的一小部分唠摹。
2016年3月爆捞，在阿里云各個區(qū)域內(nèi)創(chuàng)建云主機，并對云主機所在的A類內(nèi)網(wǎng)IP地址段針對22和3389端口進行掃描勾拉，有39萬個內(nèi)網(wǎng)地址可以通過22端口創(chuàng)建網(wǎng)絡(luò)連接煮甥，有8萬個內(nèi)網(wǎng)地址可以通過3389端口創(chuàng)建網(wǎng)絡(luò)連接盗温。在可以通過22端口連接的IP地址中，又發(fā)現(xiàn)了大量活躍的3306（MySQL）端口和11211（Memcached）端口成肘。運行在11211端口的服務(wù)卖局，大部分可以通過SET和GET命令直接進行操作。運行在3306端口的服務(wù)双霍，有一定數(shù)量可以基于社會工程數(shù)據(jù)庫使用root帳號通過自動化測試程序登錄砚偶。在可以通過3389端口連接的IP地址中，發(fā)現(xiàn)了部分活躍的1433（SQL Server）端口洒闸。運行在1433端口的服務(wù)染坯，也有一定數(shù)量可以基于社會工程數(shù)據(jù)庫使用Administrator帳號通過自動化測試程序登錄。由于SQL Server服務(wù)可以使用Windows身份驗證丘逸，有理由認為一定數(shù)量運行Windows操作系統(tǒng)的云主機已經(jīng)淪為肉雞单鹿。
作者還注意到，在阿里云各個區(qū)域進行內(nèi)網(wǎng)掃描獲得的端口數(shù)量是高度一致的深纲。深圳仲锄、杭州、青島湃鹊、北京儒喊、上海、香港涛舍、美西這七個區(qū)域的活躍端口數(shù)量澄惊，精確到千位數(shù)都是完全相同的。唯一的一個例外是新加坡區(qū)域富雅，原因不明掸驱。
在如上所述端口掃描和自動化登錄測試中，無論測試流量來自公網(wǎng)還是阿里云內(nèi)網(wǎng)没佑，測試程序均未檢測到連接被拒絕或者重置等主動防御行為毕贼。在針對1433、3306和11211端口的測試中蛤奢，測試程序僅進行計數(shù)而不記錄任何可以識別對方主機的數(shù)據(jù)鬼癣。
測試編號節(jié)點1節(jié)點2節(jié)點3節(jié)點4節(jié)點5節(jié)點6節(jié)點7節(jié)點8節(jié)點9節(jié)點10節(jié)點11節(jié)點12節(jié)點13節(jié)點14
16060
260606060
3606060606060
46060606060606060
560606060606060606060
6606060606060606060606060
76060606060606060606060606060
上表所示是在阿里云杭州區(qū)域進行網(wǎng)絡(luò)帶寬探測的結(jié)果。測試中使用了7 對云主機啤贩，所有云主機都部署在同一個可用區(qū)內(nèi)待秃。我們首先使用同樣的測試程序?qū)Σ煌脑浦鳈C實例類型進行測試，發(fā)現(xiàn)不同的云主機實例類型所能夠達到的內(nèi)網(wǎng)帶寬是一樣的痹屹。
考慮到批量測試的費用問題章郁，如上測試使用的云主機實例類型為“系列二：通用型n1”，配置1顆vCPU和1GB內(nèi)存志衍。在參與測試的14臺云主機中暖庄，1號云主機在一個用戶帳號中聊替，2～14號云主機在另外一個用戶帳號中。1號云主機和2號云主機配為一對培廓，3號云主機和4號云主機配為一對惹悄，以此類推。在編號為1的測試中肩钠，只有第一對云主機產(chǎn)生網(wǎng)絡(luò)流量泣港，其他云主機處于空閑狀態(tài)；在編號為2的測試中蔬将，第一對和第二對云主機產(chǎn)生網(wǎng)絡(luò)流量爷速，其他云主機處于空閑狀態(tài)，以此類推霞怀。如上測試在一個月中的不同時段進行了多次惫东，不同批次的測試結(jié)果之間高度一致。作者將云主機的總量增加到10對（共20臺）毙石，可以得到同樣的測試結(jié)果廉沮。基于如上測試徐矩，可以認為阿里云的網(wǎng)絡(luò)質(zhì)量達到了較高的水平滞时，具體表現(xiàn)在：
以云主機為單位進行精確限流，吞吐量指標基本沒有發(fā)生抖動滤灯；
在小規(guī)模測試中坪稽，未能探測到單個用戶能夠使用的網(wǎng)絡(luò)帶寬上限；
在小規(guī)模測試中鳞骤，未能探測到單個用戶大量占用網(wǎng)絡(luò)帶寬對其他用戶使用網(wǎng)絡(luò)產(chǎn)生影響窒百。
測試編號節(jié)點1節(jié)點2節(jié)點3節(jié)點4節(jié)點5節(jié)點6節(jié)點7節(jié)點8節(jié)點9節(jié)點10
1400
2400400
3400400400
4400400400400
5400400400400400
6400400400400400400
7400400400400400400400
8400400400400400400400400
9400400400400400400400400400
10400400400400400400400400400400
上表所示是在阿里云杭州區(qū)域進行存儲帶寬探測的結(jié)果。測試中使用了10臺云主機豫尽，所有云主機都部署在同一個可用區(qū)內(nèi)篙梢。
首先，我們使用不同的云主機實例類型掛載單塊云硬盤進行測試美旧，可以達到阿里云文檔所標注的256MB/s帶寬上限渤滞。此外，我們發(fā)現(xiàn)存儲帶寬上限與云硬盤的容量有關(guān)榴嗅，但是與云主機實例類型無關(guān)妄呕。
其次，我們在同一臺云主機上掛載多塊云硬盤創(chuàng)建RAID0磁盤陣列進行同樣測試嗽测。與單塊云硬盤相比趴腋，用兩塊云硬盤創(chuàng)建的RAID0磁盤陣列可以達到400MB/s的存儲帶寬。用三塊或者四塊云硬盤創(chuàng)建的RAID0磁盤陣列论咏，其存儲帶寬和用兩塊云硬盤創(chuàng)建的RAID0磁盤陣列是同樣的优炬。
考慮到批量測試的費用問題，如上測試使用的云主機實例類型為“系列二：通用型n1”厅贪，配置1顆vCPU和1GB內(nèi)存蠢护，掛載兩塊500GB的云硬盤配置成RAID0磁盤陣列。在參與測試的10臺云主機中养涮，1號云主機在一個用戶帳號中葵硕，2～10號云主機在另外一個用戶帳號中。在編號為1的測試中贯吓，只有1號云主機產(chǎn)生存儲流量懈凹，其他云主機處于空閑狀態(tài)；在編號為2的測試中悄谐，1號和2號對云主機產(chǎn)生存儲流量介评，其他云主機處于空閑狀態(tài)，以此類推爬舰。如上測試在一個月中的不同時段進行了多次们陆，不同批次的測試結(jié)果之間高度一致。將云主機的總量增加到20臺情屹，可以得到同樣的測試結(jié)果坪仇。基于如上測試垃你，可以認為阿里云的存儲質(zhì)量達到了較高的水平椅文，具體表現(xiàn)在：
以云主機和云硬盤為單位進行精確限流，吞吐量指標基本沒有發(fā)生抖動惜颇；
在小規(guī)模測試中皆刺，未能探測到單個用戶能夠使用的存儲帶寬上限；
在小規(guī)模測試中官还，未能探測到單個用戶大量占用存儲帶寬對其他用戶使用存儲產(chǎn)生影響芹橡。
在針對客服能力的測試中，作者通過阿里云Web控制臺里提交了兩個工單望伦。第一個工單的響應(yīng)時間為40分鐘林说，第二個工單的響應(yīng)時間為70分鐘。兩個工單詢問的是同一個問題：一臺云主機掛載多塊云硬盤創(chuàng)建RAID0磁盤陣列可以達到的存儲性能屯伞。在兩個工單的答復(fù)中腿箩，作者均未獲得正確的解答。通過阿里云Web控制臺對云主機進行銷毀操作時需要進行短信驗證劣摇，作者在測試過程中遇到了短信功能失效的情況珠移。
為了觀察阿里云的故障發(fā)現(xiàn)與處理效率，作者未通過工單系統(tǒng)報告此故障。等待了四個小時之后钧惧，故障依然存在暇韧。于是作者通過微博與一個包括多位阿里云員工的微信群公布了此故障。在微博和微信上浓瞪，均有阿里云的員工主動聯(lián)系作者了解情況懈玻，45分鐘之后故障得到解決。這個事件似乎表明在接近五個小時的時間里沒有其他阿里云用戶發(fā)現(xiàn)同一故障乾颁。換句話說涂乌，在接近五個小時的時間里，沒有其他阿里云用戶通過阿里云Web控制臺進行銷毀云主機的操作英岭。如果這個推斷成立湾盒，則意味著阿里云的用戶基本上是把云主機當成是長期運行的VPS服務(wù)器來使用的。
金山云對客戶的挑選比較苛刻诅妹。作者自助在金山云的網(wǎng)站上注冊帳號罚勾，可以完成注冊但是無法激活帳號。未激活帳號依然可以對帳號進行充值漾唉，但是充值完成之后無法創(chuàng)建云主機荧库，也無法使用金山云提供的任何其他資源。作者通過在線客服功能聯(lián)系到金山云的客服人員赵刑，客服人員提供了一個激活帳號的連接分衫，但是依然無法成功激活帳號。（注：2016年5月31日前般此，金山云客戶網(wǎng)上注冊蚪战，需要通過線下人員審核后可激活賬戶。6月1日后铐懊，金山云客戶可實現(xiàn)網(wǎng)上自助注冊邀桑。）
金山云在自治域AS59019中聲明了多個C類IP地址段，IP地址總數(shù)接近一個B段科乎。
2016年9月壁畸，從公網(wǎng)對如上所述IP地址段針對22（SSH）、80（HTTP）茅茂、443（HTTPS）和3389（RDP）端口進行掃描捏萍。有1500個IP地址可以通過22端口創(chuàng)建網(wǎng)絡(luò)連接，有1900個IP地址可以通過80端口創(chuàng)建網(wǎng)絡(luò)連接空闲，有1300個IP地址可以通過443端口創(chuàng)建網(wǎng)絡(luò)連接令杈，有300個IP地址可以通過3389端口創(chuàng)建網(wǎng)絡(luò)連接。
除此之外碴倾，作者未能對金山云進行其他用戶體驗層面的測試逗噩。
美團云啟用的公網(wǎng)IP地址只有一個B段掉丽。通過ip-tracker.org進行查詢，未能確認這些IP地址屬于美團云异雁。
2016年3月捶障，從公網(wǎng)對該地址段中針對22（SSH）和3389（RDP）端口進行掃描。有3,700個IP地址可以通過22端口創(chuàng)建網(wǎng)絡(luò)連接片迅，有1600個IP地址可以通過3389端口創(chuàng)建網(wǎng)絡(luò)連接残邀。
2016年9月，從公網(wǎng)對該地址段針對22（SSH）柑蛇、80（HTTP）、443（HTTPS）和3389（RDP）端口進行掃描驱闷。有5,500個IP地址可以通過22端口創(chuàng)建網(wǎng)絡(luò)連接耻台，有6,400個IP地址可以通過80端口創(chuàng)建網(wǎng)絡(luò)連接，有3,000個IP地址可以通過443端口創(chuàng)建網(wǎng)絡(luò)連接空另，有2,000個IP地址可以通過3389端口創(chuàng)建網(wǎng)絡(luò)連接盆耽。
由于美團云的規(guī)模相對較小，作者未對1433扼菠、3306和11211等端口進行掃描和自動化登錄測試摄杂。基于同樣的原因循榆，作者也未對美團云進行網(wǎng)絡(luò)析恢、存儲、客服等方面的測試秧饮。
青云啟用的公網(wǎng)IP地址有4個B段映挂。通過ip-tracker.org進行查詢，未能確認這些IP地址屬于青云盗尸。
2016年3月柑船，從公網(wǎng)對全部4個B類IP地址段針對22（SSH）和3389（RDP）端口進行掃描，有7,000個IP地址可以通過22端口創(chuàng)建網(wǎng)絡(luò)連接泼各，有2,000個IP地址可以通過3389端口創(chuàng)建網(wǎng)絡(luò)連接鞍时。在青云的基礎(chǔ)網(wǎng)絡(luò)上創(chuàng)建云主機，可以在云主機所在的A類內(nèi)網(wǎng)IP地址段掃描到大量活躍的云主機扣蜻。在青云的私有網(wǎng)絡(luò)上創(chuàng)建云主機逆巍，則無法掃描到不屬于用戶自己的云主機。
2016年9月弱贼，從公網(wǎng)對全部4個B類IP地址段針對22（SSH）蒸苇、80（HTTP）、443（HTTPS）和3389（RDP）端口進行掃描吮旅。有5,500個IP地址可以通過22端口創(chuàng)建網(wǎng)絡(luò)連接溪烤，有14,100個IP地址可以通過80端口創(chuàng)建網(wǎng)絡(luò)連接味咳，有4,400個IP地址可以通過443端口創(chuàng)建網(wǎng)絡(luò)連接，有1,700個IP地址可以通過3389端口創(chuàng)建網(wǎng)絡(luò)連接檬嘀。
基于如上端口掃描結(jié)果槽驶，青云的總體規(guī)模還是比較小的。即使是規(guī)模最大的一個可用區(qū)鸳兽，云主機的數(shù)量級也不過是千位數(shù)而已掂铐。這樣的規(guī)模，對于一個內(nèi)部自用的私有云來說可能不小揍异，但是對于面向公眾提供服務(wù)的公有云的確不大全陨。作者注意到青云于2016年1月高調(diào)發(fā)布了一個“超大規(guī)模網(wǎng)絡(luò)SDN/NFV 2.0網(wǎng)絡(luò)”[22]。與青云的實際規(guī)模相比衷掷，這樣的宣傳未免名不副實辱姨。
由于青云的規(guī)模相對較小，作者未對1433戚嗅、3306和11211等端口進行掃描和自動化登錄測試雨涛。同時，考慮到青云在國內(nèi)云計算行業(yè)具有很高的知名度懦胞，作者也對青云進行了網(wǎng)絡(luò)替久、存儲、客服等方面的測試躏尉。
測試編號節(jié)點1節(jié)點2節(jié)點3節(jié)點4節(jié)點5節(jié)點6節(jié)點7節(jié)點8節(jié)點9節(jié)點10節(jié)點11節(jié)點12節(jié)點13節(jié)點14
1115115
2115115115115
310595901059590
47065657565756565
560555560556555556560
6505050555055505055555555
74040404540454040454540504545
上表所示是在青云北京2區(qū)（PEK-2）進行網(wǎng)絡(luò)帶寬探測的結(jié)果蚯根。測試中使用了7對云主機，所有云主機都部署在同一個區(qū)域內(nèi)醇份。我們首先使用同樣的測試程序?qū)Σ煌脑浦鳈C實例類型進行測試稼锅，發(fā)現(xiàn)不同的云主機實例類型所能夠達到的內(nèi)網(wǎng)帶寬是一樣的×欧祝考慮到批量測試的費用問題矩距，如上測試使用的云主機實例類型為“超高性能主機”，配置1顆vCPU和1GB內(nèi)存怖竭。在參與測試的14臺云主機中锥债，1號云主機在一個用戶帳號中，2～14號云主機在另外一個用戶帳號中痊臭。1號云主機和2號云主機配為一對哮肚，3號云主機和4號云主機配為一對，以此類推广匙。在編號為1的測試中允趟，只有第一對云主機產(chǎn)生網(wǎng)絡(luò)流量，其他云主機處于空閑狀態(tài)鸦致；在編號為2的測試中潮剪，第一對和第二對云主機產(chǎn)生網(wǎng)絡(luò)流量涣楷，其他云主機處于空閑狀態(tài)，以此類推。如上測試在一個月中的不同時段進行了多次，不同批次的測試結(jié)果之間基本一致巾钉。基于如上測試驶鹉，可以認為青云的網(wǎng)絡(luò)質(zhì)量相對較低，具體表現(xiàn)在：
沒有對云主機采取限流措施，吞吐量指標存在大規(guī)模抖動；
在小規(guī)模測試中沙峻，僅用6臺云主機即可探測到網(wǎng)絡(luò)性能惡化的跡象；
隨著參與測試的云主機數(shù)量的增加鹃觉，網(wǎng)絡(luò)性能惡化極快专酗；
單個用戶可以使用的網(wǎng)絡(luò)帶寬上限低于700MB/s；
在小規(guī)模測試中盗扇，可以觀察到單個用戶大量占用網(wǎng)絡(luò)帶寬對其他用戶使用網(wǎng)絡(luò)產(chǎn)生影響。
測試編號節(jié)點1節(jié)點2節(jié)點3節(jié)點4節(jié)點5節(jié)點6節(jié)點7節(jié)點8節(jié)點9節(jié)點10
1800
2800800
3800800800
4330800800350
5320770730360800
6330800800360800800
7320800800350330780300
8380800400340320800300300
9340800360380330280320270620
10340350350380330290330270670350
上表所示是在青云北京2區(qū)（PEK-2）進行存儲帶寬探測的結(jié)果沉填。測試中使用了10臺云主機疗隶，所有云主機都部署在同一個區(qū)域內(nèi)。
首先翼闹，我們使用不同的云主機實例類型掛載單塊云硬盤進行測試斑鼻，發(fā)現(xiàn)存儲帶寬上限為200MB/s。這個存儲帶寬上限既與云硬盤的容量無關(guān)猎荠，也與云主機實例類型無關(guān)坚弱。
其次，我們在同一臺云主機上掛載多塊云硬盤創(chuàng)建RAID0磁盤陣列進行同樣測試关摇。與單塊云硬盤相比荒叶，用兩塊云硬盤創(chuàng)建的RAID0磁盤陣列可以獲得400MB/s的存儲帶寬。用三塊或者四塊云硬盤創(chuàng)建的RAID0磁盤陣列输虱，則可以獲得600MB/s和800MB/s的存儲帶寬些楣。
考慮到批量測試的費用問題，如上測試使用的云主機實例類型為“超高性能主機”宪睹，配置1顆vCPU和1GB內(nèi)存愁茁，掛載四塊50GB的云硬盤配置成RAID0磁盤陣列。在參與測試的10臺云主機中亭病，1號云主機在一個用戶帳號中鹅很，2～10號云主機在另外一個用戶帳號中。在編號為1的測試中罪帖，只有1號云主機產(chǎn)生存儲流量促煮，其他云主機處于空閑狀態(tài)邮屁；在編號為2的測試中，1號和2號對云主機產(chǎn)生存儲流量污茵，其他云主機處于空閑狀態(tài)樱报，以此類推。如上測試在一個月中的不同時段進行了多次泞当，不同批次的測試結(jié)果之間基本一致迹蛤。基于如上測試襟士，可以認為青云的存儲質(zhì)量相對較低盗飒，具體表現(xiàn)在：
沒有對云主機或者云硬盤采取限流措施，吞吐量指標存在大規(guī)模抖動陋桂；
在小規(guī)模測試中逆趣，僅用4臺云主機即可探測到存儲性能惡化的跡象；
隨著參與測試的云主機數(shù)量的增加嗜历，存儲性能惡化極快宣渗；
單個用戶可以使用的存儲帶寬上限為4000MB/s；
在小規(guī)模測試中梨州，可以觀察到單個用戶大量占用存儲帶寬對其他用戶使用存儲產(chǎn)生影響痕囱。
在針對客服能力的測試中，作者通過青云Web控制臺里提交了多個工單暴匠。所有工單的響應(yīng)時間均在30分鐘以內(nèi)鞍恢。不同工單分別涉及配額上調(diào)、使用方法每窖、缺陷報告等等內(nèi)容帮掉，處理所需要的時間也有不同。所有工單咨詢的問題最終都得到很好的解決窒典。
盛大云啟用的公網(wǎng)IP地址有3個B段蟆炊。通過ip-tracker.org進行查詢，未能確認這些IP地址屬于盛大云崇败。
2016年3月盅称，從公網(wǎng)對全部3個B類IP地址段針對22（SSH）和3389（RDP）端口進行掃描，有6,000個IP地址可以通過22端口創(chuàng)建網(wǎng)絡(luò)連接后室，有4,000個IP地址可以通過3389端口創(chuàng)建網(wǎng)絡(luò)連接缩膝。
2016年9月，從公網(wǎng)對全部4個B類IP地址段針對22（SSH）岸霹、80（HTTP）疾层、443（HTTPS）和3389（RDP）端口進行掃描。有5500個IP地址可以通過22端口創(chuàng)建網(wǎng)絡(luò)連接贡避，有36000個IP地址可以通過80端口創(chuàng)建網(wǎng)絡(luò)連接痛黎，有3600個IP地址可以通過443端口創(chuàng)建網(wǎng)絡(luò)連接予弧，有3,200個IP地址可以通過3389端口創(chuàng)建網(wǎng)絡(luò)連接。
由于盛大云的規(guī)模相對較小湖饱，作者未對1433掖蛤、3306和11211等端口進行掃描和自動化登錄測試【幔基于同樣的原因蚓庭，作者也未對美團云進行網(wǎng)絡(luò)、存儲仅仆、客服等方面的測試器赞。
UCloud啟用的公網(wǎng)IP地址有8個B段。通過ip-tracker.org進行查詢墓拜，僅有一個B段可以確認屬于UCloud港柜。
2016年3月，從公網(wǎng)對全部8個B類IP地址段針對22（SSH）和3389（RDP）端口進行掃描咳榜，有24,000個IP地址可以通過22端口創(chuàng)建網(wǎng)絡(luò)連接夏醉，有9,000個IP地址可以通過3389端口創(chuàng)建網(wǎng)絡(luò)連接。UCloud給每個用戶均缺省地提供了一個私有網(wǎng)絡(luò)涌韩，用戶在自己的私有網(wǎng)絡(luò)上創(chuàng)建云主機授舟，無法掃描到不屬于用戶自己的云主機。
2016年9月贸辈，從公網(wǎng)對全部8個B類IP地址段針對22（SSH）、80（HTTP）肠槽、443（HTTPS）和3389（RDP）端口進行掃描擎淤。有43,100個IP地址可以通過22端口創(chuàng)建網(wǎng)絡(luò)連接，有54,200個IP地址可以通過80端口創(chuàng)建網(wǎng)絡(luò)連接秸仙，有27,500個IP地址可以通過443端口創(chuàng)建網(wǎng)絡(luò)連接嘴拢，有22,800個IP地址可以通過3389端口創(chuàng)建網(wǎng)絡(luò)連接。
UCloud給每個用戶均缺省地提供了一個私有網(wǎng)絡(luò)寂纪，用戶在自己的私有網(wǎng)絡(luò)上創(chuàng)建云主機席吴，無法掃描到不屬于用戶自己的云主機。由于UCloud的規(guī)模相對較欣痰啊（相對于阿里云而言）孝冒，作者未對1433、3306和11211等端口進行掃描和自動化登錄測試拟杉。
測試編號節(jié)點1節(jié)點2節(jié)點3節(jié)點4節(jié)點5節(jié)點6節(jié)點7節(jié)點8節(jié)點9節(jié)點10節(jié)點11節(jié)點12節(jié)點13節(jié)點14
1175175
2175175175170
3175175170175175165
4170165165175165175165165
5175175175175175165165165
6175175175130175180170160165170180
7175175165180190175185155150190170190190150
上表所示是在UCloud北京D區(qū)（PEK-D）進行網(wǎng)絡(luò)帶寬探測的結(jié)果庄涡。測試中使用了7對云主機，所有云主機都部署在同一個區(qū)域內(nèi)搬设。我們首先使用同樣的測試程序?qū)Σ煌脑浦鳈C實例類型進行測試穴店，發(fā)現(xiàn)不同的云主機實例類型所能夠達到的內(nèi)網(wǎng)帶寬是一樣的撕捍。考慮到批量測試的費用問題泣洞，如上測試使用的云主機實例類型為“SSD高性能主機”忧风，配置1顆vCPU和2GB內(nèi)存。在參與測試的14臺云主機中球凰，1號云主機在一個用戶帳號中狮腿，2～14號云主機在另外一個用戶帳號中。1號云主機和2號云主機配為一對弟蚀，3號云主機和4號云主機配為一對蚤霞，以此類推。在編號為1的測試中义钉，只有第一對云主機產(chǎn)生網(wǎng)絡(luò)流量昧绣，其他云主機處于空閑狀態(tài)；在編號為2的測試中捶闸，第一對和第二對云主機產(chǎn)生網(wǎng)絡(luò)流量夜畴，其他云主機處于空閑狀態(tài)，以此類推删壮。如上測試在一個月中的不同時段進行了多次贪绘，不同批次的測試結(jié)果之間基本一致⊙氲基于如上測試税灌，可以認為UCloud云的網(wǎng)絡(luò)質(zhì)量相對較好，具體表現(xiàn)在：
似乎對云主機采取了限流措施亿虽，但是吞吐量指標存在一定范圍的抖動菱涤；
在小規(guī)模測試中，未探測到網(wǎng)絡(luò)性能明顯惡化的跡象洛勉；
在小規(guī)模測試中粘秆，未觀察到單個用戶大量占用網(wǎng)絡(luò)帶寬對其他用戶使用網(wǎng)絡(luò)產(chǎn)生影響。
基于現(xiàn)象（1）收毫，作者傾向于認為UCloud尚未實現(xiàn)以云主機為單位進行精準限流攻走。在小規(guī)模測試中觀察到現(xiàn)象（2）和（3）的根本原因是因為UCloud的規(guī)模較大（相對于青云而言），其網(wǎng)絡(luò)資源總量足以消化小規(guī)模測試所產(chǎn)生的網(wǎng)絡(luò)流量此再。
測試編號節(jié)點1節(jié)點2節(jié)點3節(jié)點4節(jié)點5節(jié)點6節(jié)點7節(jié)點8節(jié)點9節(jié)點10
1280
2280260
3200260240
4200250210220
5200230250200200
6200200210230160180
7140220140140140170140
8140190140140140140140180
9140180140140140140140140140
10120160120120120140140140140120
上表所示是在UCloud北京C區(qū)（PEK-C）進行存儲帶寬探測的結(jié)果昔搂。測試中使用了10臺云主機，所有云主機都部署在同一個區(qū)域內(nèi)引润。
首先巩趁，我們使用不同的云主機實例類型掛載單塊云硬盤進行測試，發(fā)現(xiàn)存儲帶寬上限在100MB/s上下波動，但是并不穩(wěn)定议慰。這個存儲帶寬上限既與云硬盤的容量無關(guān)蠢古，也與云主機實例類型無關(guān)。
其次别凹，我們在同一臺云主機上掛載多塊云硬盤創(chuàng)建RAID0磁盤陣列進行同樣測試草讶。與單塊云硬盤相比，用兩塊云硬盤創(chuàng)建的RAID0磁盤陣列可以獲得200MB/s的存儲帶寬炉菲。用三塊或者四塊云硬盤創(chuàng)建的RAID0磁盤陣列堕战，則可以獲得300MB/s和400MB/s的存儲帶寬。用六塊云硬盤創(chuàng)建的RAID0磁盤陣列拍霜，最高可以獲得580MB/s的存儲帶寬嘱丢，但是均值只有400MB/s。
考慮到批量測試的費用問題祠饺，如上測試使用的云主機實例類型為“SSD高性能主機”越驻，配置1顆vCPU和2GB內(nèi)存，掛載四塊50GB的云硬盤配置成RAID0磁盤陣列道偷。在參與測試的10臺云主機中缀旁，1號云主機在一個用戶帳號中，2～10號云主機在另外一個用戶帳號中勺鸦。在編號為1的測試中并巍，只有1號云主機產(chǎn)生存儲流量，其他云主機處于空閑狀態(tài)换途；在編號為2的測試中懊渡，1號和2號對云主機產(chǎn)生存儲流量，其他云主機處于空閑狀態(tài)军拟，以此類推距贷。如上測試在一個月中的不同時段進行了多次，不同批次的測試數(shù)據(jù)存在較大差別吻谋，但是所觀察到的現(xiàn)象基本一致∠趾幔基于如上測試漓拾，可以認為UCloud的存儲質(zhì)量相對較低，具體表現(xiàn)在：
沒有對云主機或者云硬盤采取限流措施戒祠，吞吐量指標存在大規(guī)模抖動骇两；
在小規(guī)模測試中，僅用4臺云主機即可探測到存儲性能惡化的跡象姜盈；
隨著參與測試的云主機數(shù)量的增加低千，存儲性能惡化極快；
在小規(guī)模測試中，可以觀察到單個用戶大量占用存儲帶寬對其他用戶使用存儲產(chǎn)生影響示血；
在被測試區(qū)域中可能存在其他用戶運行的磁盤I/O密集型應(yīng)用棋傍，并且其磁盤I/O資源使用模式隨時間發(fā)生變化。
注：在針對青云的測試中难审，并未觀察到同類現(xiàn)象瘫拣。青云的可觀測規(guī)模不足UCloud的1/3，如果青云上存在其他用戶運行的磁盤I/O密集型應(yīng)用告喊，應(yīng)該比UCloud更容易觀察到麸拄。因此，作者傾向于認為在青云的被測試區(qū)域中存在其他用戶運行的磁盤I/O密集型應(yīng)用的可能性較小黔姜。
針對存儲帶寬的測試結(jié)果拢切，也從側(cè)面驗證了作者在網(wǎng)絡(luò)帶寬測試中所做的判斷。UCloud尚未實現(xiàn)以云主機為單位對網(wǎng)絡(luò)和存儲流量進行精準限流秆吵。在網(wǎng)絡(luò)帶寬測試中淮椰，UCloud的網(wǎng)絡(luò)資源總量足以消化小規(guī)模測試所產(chǎn)生的網(wǎng)絡(luò)流量，從測試結(jié)果中僅能觀察到網(wǎng)絡(luò)帶寬的波動帮毁。在存儲帶寬測試中实苞，UCloud的存儲資源總量不足以消化小規(guī)模測試所產(chǎn)生的存儲流量，從測試結(jié)果中可以觀察到顯著的性能惡化烈疚。
在針對客服能力的測試中黔牵，作者通過UCloud的Web控制臺里提交了多個工單。所有工單的響應(yīng)時間均在30分鐘以內(nèi)爷肝。不同工單分別涉及配額上調(diào)猾浦、使用方法、缺陷報告等等內(nèi)容灯抛，處理所需要的時間也有不同金赦。工單所咨詢的問題，大部分得到很好的解決对嚼，小部分工單沒有得到解決夹抗。
騰訊集團在自治域AS45090、AS132203纵竖、AS132591漠烧、AS134103中一共聲明了12個B類IP地址段以及多個C類IP地址段。
2016年3月靡砌，從公網(wǎng)對全部12個B類IP地址段針對22（SSH）和3389（RDP）端口進行掃描已脓，有40,000個IP地址可以通過22端口創(chuàng)建網(wǎng)絡(luò)連接，有40,000萬個IP地址可以通過3389端口創(chuàng)建網(wǎng)絡(luò)連接通殃。
2016年9月度液，從公網(wǎng)對全部12個B類IP地址段針對22（SSH）、80（HTTP）、443（HTTPS）和3389（RDP）端口進行掃描堕担。有65000個IP地址可以通過22端口創(chuàng)建網(wǎng)絡(luò)連接已慢，有90,000個IP地址可以通過80端口創(chuàng)建網(wǎng)絡(luò)連接，有20,000個IP地址可以通過443端口創(chuàng)建網(wǎng)絡(luò)連接照宝，有50,000個IP地址可以通過3389端口創(chuàng)建網(wǎng)絡(luò)連接蛇受。
需要說明的是，如上所述12個B類IP地址段并非全部用于騰訊云的公有云服務(wù)厕鹃。騰訊集團下的其他業(yè)務(wù)譬如QQ和微信所使用的IP地址也都在這12個B類IP地址段中兢仰。根據(jù)華為集團2014年發(fā)布的成功案例《華為服務(wù)器助力騰訊構(gòu)建十萬級高效部署》[21]的成功案例，騰訊集團現(xiàn)網(wǎng)服務(wù)器超過30萬臺剂碴，其中華為服務(wù)器超過10萬臺把将。假設(shè)騰訊集團所使用的服務(wù)器當中只有10%配置公網(wǎng)IP，需要占用的IP地址數(shù)量就超過3萬個忆矛〔於祝考慮到騰訊集團本身對計算資源的需求還在增長，同時也會占用更多的IP地址催训。因此洽议，騰訊云的公有云服務(wù)所使用的IP地址（包括物理機和虛擬機）只占如上所述活躍IP地址中的一小部分。
由于騰訊云的規(guī)模相對較小漫拭，作者未對1433亚兄、3306和11211等端口進行掃描和自動化登錄測試〔勺ぃ基于同樣的原因审胚，作者也未對騰訊云進行網(wǎng)絡(luò)、存儲礼旅、客服等方面的測試膳叨。
騰訊云使用QQ的帳號管理體系，可能是騰訊云用戶最大的風(fēng)險之一痘系。眾所周知菲嘴，QQ用戶在密碼丟失、手機停機汰翠、切換地理位置的時候临谱，均有QQ號碼被騰訊集團回收的可能。作者于2000年成為QQ早期用戶奴璃，十多年如一日地使用同一個QQ號碼。在此期間城豁，作者從美國伊利諾州移居加州苟穆，又從加州移居北京，再從北京移居海南，從未放棄過使用該QQ號碼與親朋好友進行聯(lián)系雳旅。2014年2月跟磨，作者從海南移居悉尼，QQ以登錄地理位置可疑為由拒絕作者登錄攒盈。由于作者居住在北京時向騰訊登記的密碼保護手機號碼已經(jīng)停用抵拘，作者選擇通過早期好友確認的方式找回QQ號碼。盡管所有三位早期好友均向騰訊作出了確認型豁，騰訊方面依然拒絕作者繼續(xù)使用該QQ號碼僵蛛。作者先前設(shè)置了QQ郵件轉(zhuǎn)發(fā)，盡管作者已經(jīng)不再擁有該QQ號碼的使用權(quán)迎变，但是發(fā)向該QQ號碼的電子郵件依然被轉(zhuǎn)發(fā)到作者的常用郵箱里充尉。假設(shè)一家創(chuàng)業(yè)公司選擇在騰訊云部署服務(wù)，而其所使用的QQ號碼由于某種已知或者未知的原因被騰訊回收衣形，必定會對其業(yè)務(wù)產(chǎn)生不可知的重大影響驼侠。創(chuàng)業(yè)者最不愿意看到的情形之一，可能是你所提供的服務(wù)還在正常運行谆吴，但是你已經(jīng)不再擁有運行這些服務(wù)的計算資源的使用權(quán)和管理權(quán)了倒源。
作者蔣清野是悉尼大學(xué)信息技術(shù)學(xué)院的博士研究生，同時也是AWS悉尼技術(shù)支持中心的員工句狼。他于1999年獲得清華大學(xué)學(xué)士學(xué)位（土木工程）笋熬，2000年獲得伊利諾伊大學(xué)香檳分校碩士學(xué)位（土木工程），2015年獲得悉尼大學(xué)碩士學(xué)位（計算機科學(xué)）鲜锚。他的研究興趣包括分布式與高性能計算突诬、開源社區(qū)的社會學(xué)行為、信息技術(shù)領(lǐng)域的微觀經(jīng)濟學(xué)分析芜繁。他是美國電子電氣工程師學(xué)會（IEEE）的高級會員旺隙。
在接受InfoQ方面的邀請準備規(guī)劃這篇報告的時候，作者的內(nèi)心是興奮的骏令。在獲得所有測試數(shù)據(jù)準備撰寫這篇報告的時候蔬捷，作者的內(nèi)心是矛盾的。一方面榔袋，作為并行與分布式計算領(lǐng)域的學(xué)生周拐，作者希望為業(yè)界提供一些有用的信息和觀點；另一方面凰兑，作為公有云服務(wù)領(lǐng)域的從業(yè)人員妥粟，作者深知發(fā)表一份涉及多家友商的報告會帶來諸多爭議。在InfoQ方面的鼓勵下吏够，作者選擇以真實的身份發(fā)布這些的數(shù)據(jù)和觀點勾给，希望能夠?qū)鴥?nèi)云計算從業(yè)人員有所幫助滩报。
本文轉(zhuǎn)載自infoQ
