背景介紹
2015年12月，InfoQ的編輯魏星邀請作者撰寫一篇關于中國公有云服務發展狀況的文章。因為作者個人對公有云這個領域一直抱有很大的興趣，便貿然答應了下來。在這篇文章的準備過程中，作者系統地閱讀了國內較為知名的幾份云計算白皮書[1，2，3]。作者發現這些報告大都高瞻遠矚提綱挈領，缺乏對具體的公有云服務提供商的描述，未能讓讀者一窺國內公有云服務發展之真實面貌。在InfoQ的協調下，作者與國內多家公有云服務提供商的主要負責人進行了電話訪談，圍繞團隊建設、產品研發、服務運營這三個問題進行了討論。除此之外，作者也在本文所探討的所有公有云上都注冊了賬號，從用戶體檢的角度進行了一些小規模的測試。這篇文章的目的，便是從團隊建設、產品研發、服務運營、用戶體驗等四個方面對中國的公有云服務發展狀況做一個簡要的綜述。
根據美國國家標準技術研究院（NIST）的定義[4]，云計算在服務模型上可以劃分為軟件即服務（SaaS）、平臺即服務（PaaS）和設施即服務（IaaS），在發布模型上又可以劃分為私有云、社區云、公有云和混合云。需要說明的是，隨著云計算技術的發展，如上所述服務模型和發布模型之間的界限也日趨模糊。在本文的范疇內，“公有云”一詞泛指面向公眾開放服務的平臺即服務和設施即服務。除此之外，各種名義的私有云（Private Cloud）、專有云（Dedicated Cloud）、托管云（Managed Cloud）均未包括在本文的范疇之中。
本文中“團隊建設”、“產品研發”、“服務運營”三個小節的數據來源有兩個。一個是云服務提供商主動發布的新聞資訊，另一個是作者與云服務提供商的主要負責人之間的電話訪談。作者與黃允松（青云）、季昕華（UCloud）、李爽（美團云）、錢廣杰（盛大云）、沈志華（又拍云）、王慧星（騰訊云）、許式偉（七牛云）、朱樺（金山云）等業內專家（按姓氏拼音排序）的訪談，是由InfoQ方面統一協調安排的，在此作者深表感謝。這個三個小節的內容，在定稿之前均經過受訪者及其公關/市場團隊的確認，反映的是云服務提供商自身的觀點和思路。在審稿階段，青云撤回了與作者進行訪談時所發表的一切言論；出于保護商業機密的考慮，阿里云拒絕了作者的訪談邀請。因此，如上三個小節未能包括青云和阿里云的觀點。
“用戶體驗”和“其他討論”這兩個小節，是作者獨立獲得的數據以及由此引出的觀點，在定稿之前未接受任何一家云服務提供商的審核。需要特別說明的是，如上所述云服務提供商的主要負責人接受作者的訪談并不代表他們認可作者在“用戶體驗”和“其他討論”這兩個小節中所報告的數據和觀點。此外，作者本人也并不持有本文中所討論的任何一家云服務提供商的內幕信息，作者獨立獲得的數據僅僅是基于作者所使用的測試方法得到的觀測結果。受種種技術條件的限制，作者無法對這些數據的準確性進行背書，也無法對其誤差范圍進行估算。本文中報告的大部分數據是在2016年3月底之前獲得的，這部分數據的獲取時間在正文中不再特別說明；小部分數據是在2016年8月底獲得的，這部分數據的獲取時間在正文中會有特別說明。讀者在引用本文所報告之數據時，應當考慮到數據的時效性。
本文中有多個小節對各個云服務提供商進行了逐一介紹。相關云服務提供商在這幾個小節中出現的順序是按照拼音字母次序排列的。
本文僅討論中國本土的公有云服務提供商。Amazon Web Services(AWS)、Microsoft Azure、Google Cloud Platform等等進入或者未進入中國市場的外資企業不在本文的討論范圍之內。
在這個部分，我們以用戶體驗為主線，對不同公有云服務提供商的產品進行一些小規模測試。這些測試旨在探測客戶關心的幾個關鍵參數：
（1）服務規模；
（2）網絡與存儲吞吐能力；
（3）資源隔離狀況；
（4）客服能力。
需要說明的是，這些測試僅僅是試探性的探測（probe ethos），并非嚴謹的基準測試（benchmark），測試結果反映的只是測試當時的用戶體驗。作者本人的技術背景與云主機類產品比較接近，對云存儲領域的了解相對有限。因此，這些測試僅針對設施層面的云主機類產品，并且沒有完整覆蓋所有國內的IaaS服務提供商。（在此作者謹向七牛云和又拍云這兩家公有云服務提供商致以誠摯的歉意。）
針對服務規模的測試，是通過端口掃描進行的。針對一個特定的IaaS服務提供商，這個測試分為兩個步驟進行：
在所有區域分不同時段（時間跨度長達一個月）大量創建云主機，通過枚舉得出云主機所用公網IP所在的B段列表，并通過公開的信息進行矯正；
對所有的B段針對22、80、443、3389端口進行掃描，將掃描結果記錄到數據庫。
有些B段IP地址，可能超出了IaaS服務提供商所擁有IP資源范圍。譬如某些服務提供商使用了運營商提供的IP地址，在同一個B段里面還有用于其它用途的IP地址。有些B段IP地址，雖然由某個服務提供商擁有，但是并非用于IaaS服務。因此，端口掃描得到的結果，反映的是從外界可以探測到的服務規模上限。考慮到防火墻、安全組、部分云主機未配置公網等等多種因素，端口掃描的結果是小于實際服務規模的。
針對網絡吞吐能力的測試，是在同一個區域內啟動N對云主機。在所有的云主機內安裝Apache服務，提供一個100MB大小的文件下載。在每一對云主機之間，在每臺云主機上啟動多個線程從對方下載如上所述100MB大小的文件，單次測試持續時間15分鐘。由于供下載的文件是同一個，該文件在第一次被讀取之后便駐留在內存當中，不再產生新的磁盤I/O。因此，這個測試探測的是兩臺云主機之間的內網帶寬。N的取值范圍，從1逐漸增加到10，目的在于探測單個用戶可以使用的網絡帶寬邊界。測試中使用的第一對云主機，一臺在用戶賬號A中，一臺在用戶賬號B中，目的在于測試網絡資源隔離狀況。針對一個特定的IaaS服務提供商，這個測試在不同時段進行多次，以了解不同時段對網絡性能的影響。
針對存儲吞吐能力的測試，是在同一個區域內啟動N臺云主機。在每臺云主機上掛載M塊云硬盤創建一個RAID0磁盤陣列。在云主機上啟動多個線程，分別往磁盤陣列上寫入多個遠大于云主機物理內存的大文件。單次測試持續15分鐘，記錄測試過程中的磁盤寫入帶寬。這個測試分為三個步驟進行：
M的取值為1，探測單臺云主機上單塊云硬盤的存儲帶寬上限；
M的取值在2到4之間，探測單臺云主機上一個磁盤陣列的存儲帶寬上限；
N的取值在1到10之間，探測單個用戶可以使用的存儲帶寬上限。測試中使用的前兩臺云主機，一臺在用戶賬號A中，一臺在用戶賬號B中，目的在于測試存儲資源隔離狀況。針對一個特定的IaaS服務提供商，這個測試在不同時段進行多次，以了解不同時段對存儲性能的影響。
作者也注意到一些公有云服務提供商采取了“地理區域——可用區——集群”這樣的結構設計。在同一個可用區中，盡可能將同一用戶所使用的計算資源分配到同一個集群。因此，針對網絡吞吐能力的測試結果和針對存儲吞吐能力的測試結果反映的可能是一個可用區中某一個集群的網絡吞吐能力和存儲吞吐能力。
針對客服能力的測試，是在云服務提供商的Web控制臺里提交工單。工單的內容包括要求提高配額、詢問基礎性的使用問題、報告缺陷等等。這部分的測試，一方面在于了解客服的響應速度，另一方面在于了解客服處理能力。
阿里巴巴集團在自治域AS37963、AS45102中一共聲明了120個B類IP地址段以及多個C類IP地址段。
2016年3月，從公網對全部120個B類IP地址段針對22（SSH）和3389（RDP）端口進行掃描，有26.5萬個IP地址可以通過22端口創建網絡連接，有21.5萬個IP地址可以通過3389端口創建網絡連接。
2016年9月，從公網對如上所述IP地址段針對22（SSH）、80（HTTP）、443（HTTPS）和3389（RDP）端口進行掃描。有35萬個IP地址可以通過22端口創建網絡連接，有92萬個IP地址可以通過80端口創建網絡連接，有9萬個IP地址可以通過443端口創建網絡連接，有25萬個IP地址可以通過3389端口創建網絡連接。
需要說明的是，如上所述120個B類IP地址段并非全部用于阿里云的公有云服務。阿里巴巴集團下的其他業務譬如淘寶網和支付寶所使用的IP地址也都在這120個B類IP地址段中。根據章文嵩2011年5月在第三屆中國云計算大會上的演講[10]，淘寶網的生產服務器大約為20,000臺。根據高山淵2012年6月在QClub深圳站上的演講[11]，阿里巴巴集團的服務器規模接近10萬。根據工信部電信研究院發布的《云計算白皮書（2014年）》，截止到2013年9月運行在阿里云上的Web服務器數量達到18,000個，比2012年增長了500%。根據NetCraft在2015年6月發布的數據，阿里云所管理的Web服務器達到45,000個。考慮到阿里巴巴集團過去五年中的業務增長對計算資源的需求，阿里云公有云部分所使用的IP地址（包括物理機和虛擬機）可能只占如上所述活躍IP地址中的一小部分。
2016年3月，在阿里云各個區域內創建云主機，并對云主機所在的A類內網IP地址段針對22和3389端口進行掃描，有39萬個內網地址可以通過22端口創建網絡連接，有8萬個內網地址可以通過3389端口創建網絡連接。在可以通過22端口連接的IP地址中，又發現了大量活躍的3306（MySQL）端口和11211（Memcached）端口。運行在11211端口的服務，大部分可以通過SET和GET命令直接進行操作。運行在3306端口的服務，有一定數量可以基于社會工程數據庫使用root帳號通過自動化測試程序登錄。在可以通過3389端口連接的IP地址中，發現了部分活躍的1433（SQL Server）端口。運行在1433端口的服務，也有一定數量可以基于社會工程數據庫使用Administrator帳號通過自動化測試程序登錄。由于SQL Server服務可以使用Windows身份驗證，有理由認為一定數量運行Windows操作系統的云主機已經淪為肉雞。
作者還注意到，在阿里云各個區域進行內網掃描獲得的端口數量是高度一致的。深圳、杭州、青島、北京、上海、香港、美西這七個區域的活躍端口數量，精確到千位數都是完全相同的。唯一的一個例外是新加坡區域，原因不明。
在如上所述端口掃描和自動化登錄測試中，無論測試流量來自公網還是阿里云內網，測試程序均未檢測到連接被拒絕或者重置等主動防御行為。在針對1433、3306和11211端口的測試中，測試程序僅進行計數而不記錄任何可以識別對方主機的數據。
測試編號節點1節點2節點3節點4節點5節點6節點7節點8節點9節點10節點11節點12節點13節點14
16060
260606060
3606060606060
46060606060606060
560606060606060606060
6606060606060606060606060
76060606060606060606060606060
上表所示是在阿里云杭州區域進行網絡帶寬探測的結果。測試中使用了7 對云主機，所有云主機都部署在同一個可用區內。我們首先使用同樣的測試程序對不同的云主機實例類型進行測試，發現不同的云主機實例類型所能夠達到的內網帶寬是一樣的。
考慮到批量測試的費用問題，如上測試使用的云主機實例類型為“系列二：通用型n1”，配置1顆vCPU和1GB內存。在參與測試的14臺云主機中，1號云主機在一個用戶帳號中，2～14號云主機在另外一個用戶帳號中。1號云主機和2號云主機配為一對，3號云主機和4號云主機配為一對，以此類推。在編號為1的測試中，只有第一對云主機產生網絡流量，其他云主機處于空閑狀態；在編號為2的測試中，第一對和第二對云主機產生網絡流量，其他云主機處于空閑狀態，以此類推。如上測試在一個月中的不同時段進行了多次，不同批次的測試結果之間高度一致。作者將云主機的總量增加到10對（共20臺），可以得到同樣的測試結果。基于如上測試，可以認為阿里云的網絡質量達到了較高的水平，具體表現在：
以云主機為單位進行精確限流，吞吐量指標基本沒有發生抖動；
在小規模測試中，未能探測到單個用戶能夠使用的網絡帶寬上限；
在小規模測試中，未能探測到單個用戶大量占用網絡帶寬對其他用戶使用網絡產生影響。
測試編號節點1節點2節點3節點4節點5節點6節點7節點8節點9節點10
1400
2400400
3400400400
4400400400400
5400400400400400
6400400400400400400
7400400400400400400400
8400400400400400400400400
9400400400400400400400400400
10400400400400400400400400400400
上表所示是在阿里云杭州區域進行存儲帶寬探測的結果。測試中使用了10臺云主機，所有云主機都部署在同一個可用區內。
首先，我們使用不同的云主機實例類型掛載單塊云硬盤進行測試，可以達到阿里云文檔所標注的256MB/s帶寬上限。此外，我們發現存儲帶寬上限與云硬盤的容量有關，但是與云主機實例類型無關。
其次，我們在同一臺云主機上掛載多塊云硬盤創建RAID0磁盤陣列進行同樣測試。與單塊云硬盤相比，用兩塊云硬盤創建的RAID0磁盤陣列可以達到400MB/s的存儲帶寬。用三塊或者四塊云硬盤創建的RAID0磁盤陣列，其存儲帶寬和用兩塊云硬盤創建的RAID0磁盤陣列是同樣的。
考慮到批量測試的費用問題，如上測試使用的云主機實例類型為“系列二：通用型n1”，配置1顆vCPU和1GB內存，掛載兩塊500GB的云硬盤配置成RAID0磁盤陣列。在參與測試的10臺云主機中，1號云主機在一個用戶帳號中，2～10號云主機在另外一個用戶帳號中。在編號為1的測試中，只有1號云主機產生存儲流量，其他云主機處于空閑狀態；在編號為2的測試中，1號和2號對云主機產生存儲流量，其他云主機處于空閑狀態，以此類推。如上測試在一個月中的不同時段進行了多次，不同批次的測試結果之間高度一致。將云主機的總量增加到20臺，可以得到同樣的測試結果。基于如上測試，可以認為阿里云的存儲質量達到了較高的水平，具體表現在：
以云主機和云硬盤為單位進行精確限流，吞吐量指標基本沒有發生抖動；
在小規模測試中，未能探測到單個用戶能夠使用的存儲帶寬上限；
在小規模測試中，未能探測到單個用戶大量占用存儲帶寬對其他用戶使用存儲產生影響。
在針對客服能力的測試中，作者通過阿里云Web控制臺里提交了兩個工單。第一個工單的響應時間為40分鐘，第二個工單的響應時間為70分鐘。兩個工單詢問的是同一個問題：一臺云主機掛載多塊云硬盤創建RAID0磁盤陣列可以達到的存儲性能。在兩個工單的答復中，作者均未獲得正確的解答。通過阿里云Web控制臺對云主機進行銷毀操作時需要進行短信驗證，作者在測試過程中遇到了短信功能失效的情況。
為了觀察阿里云的故障發現與處理效率，作者未通過工單系統報告此故障。等待了四個小時之后，故障依然存在。于是作者通過微博與一個包括多位阿里云員工的微信群公布了此故障。在微博和微信上，均有阿里云的員工主動聯系作者了解情況，45分鐘之后故障得到解決。這個事件似乎表明在接近五個小時的時間里沒有其他阿里云用戶發現同一故障。換句話說，在接近五個小時的時間里，沒有其他阿里云用戶通過阿里云Web控制臺進行銷毀云主機的操作。如果這個推斷成立，則意味著阿里云的用戶基本上是把云主機當成是長期運行的VPS服務器來使用的。
金山云對客戶的挑選比較苛刻。作者自助在金山云的網站上注冊帳號，可以完成注冊但是無法激活帳號。未激活帳號依然可以對帳號進行充值，但是充值完成之后無法創建云主機，也無法使用金山云提供的任何其他資源。作者通過在線客服功能聯系到金山云的客服人員，客服人員提供了一個激活帳號的連接，但是依然無法成功激活帳號。（注：2016年5月31日前，金山云客戶網上注冊，需要通過線下人員審核后可激活賬戶。6月1日后，金山云客戶可實現網上自助注冊。）
金山云在自治域AS59019中聲明了多個C類IP地址段，IP地址總數接近一個B段。
2016年9月，從公網對如上所述IP地址段針對22（SSH）、80（HTTP）、443（HTTPS）和3389（RDP）端口進行掃描。有1500個IP地址可以通過22端口創建網絡連接，有1900個IP地址可以通過80端口創建網絡連接，有1300個IP地址可以通過443端口創建網絡連接，有300個IP地址可以通過3389端口創建網絡連接。
除此之外，作者未能對金山云進行其他用戶體驗層面的測試。
美團云啟用的公網IP地址只有一個B段。通過ip-tracker.org進行查詢，未能確認這些IP地址屬于美團云。
2016年3月，從公網對該地址段中針對22（SSH）和3389（RDP）端口進行掃描。有3,700個IP地址可以通過22端口創建網絡連接，有1600個IP地址可以通過3389端口創建網絡連接。
2016年9月，從公網對該地址段針對22（SSH）、80（HTTP）、443（HTTPS）和3389（RDP）端口進行掃描。有5,500個IP地址可以通過22端口創建網絡連接，有6,400個IP地址可以通過80端口創建網絡連接，有3,000個IP地址可以通過443端口創建網絡連接，有2,000個IP地址可以通過3389端口創建網絡連接。
由于美團云的規模相對較小，作者未對1433、3306和11211等端口進行掃描和自動化登錄測試。基于同樣的原因，作者也未對美團云進行網絡、存儲、客服等方面的測試。
青云啟用的公網IP地址有4個B段。通過ip-tracker.org進行查詢，未能確認這些IP地址屬于青云。
2016年3月，從公網對全部4個B類IP地址段針對22（SSH）和3389（RDP）端口進行掃描，有7,000個IP地址可以通過22端口創建網絡連接，有2,000個IP地址可以通過3389端口創建網絡連接。在青云的基礎網絡上創建云主機，可以在云主機所在的A類內網IP地址段掃描到大量活躍的云主機。在青云的私有網絡上創建云主機，則無法掃描到不屬于用戶自己的云主機。
2016年9月，從公網對全部4個B類IP地址段針對22（SSH）、80（HTTP）、443（HTTPS）和3389（RDP）端口進行掃描。有5,500個IP地址可以通過22端口創建網絡連接，有14,100個IP地址可以通過80端口創建網絡連接，有4,400個IP地址可以通過443端口創建網絡連接，有1,700個IP地址可以通過3389端口創建網絡連接。
基于如上端口掃描結果，青云的總體規模還是比較小的。即使是規模最大的一個可用區，云主機的數量級也不過是千位數而已。這樣的規模，對于一個內部自用的私有云來說可能不小，但是對于面向公眾提供服務的公有云的確不大。作者注意到青云于2016年1月高調發布了一個“超大規模網絡SDN/NFV 2.0網絡”[22]。與青云的實際規模相比，這樣的宣傳未免名不副實。
由于青云的規模相對較小，作者未對1433、3306和11211等端口進行掃描和自動化登錄測試。同時，考慮到青云在國內云計算行業具有很高的知名度，作者也對青云進行了網絡、存儲、客服等方面的測試。
測試編號節點1節點2節點3節點4節點5節點6節點7節點8節點9節點10節點11節點12節點13節點14
1115115
2115115115115
310595901059590
47065657565756565
560555560556555556560
6505050555055505055555555
74040404540454040454540504545
上表所示是在青云北京2區（PEK-2）進行網絡帶寬探測的結果。測試中使用了7對云主機，所有云主機都部署在同一個區域內。我們首先使用同樣的測試程序對不同的云主機實例類型進行測試，發現不同的云主機實例類型所能夠達到的內網帶寬是一樣的。考慮到批量測試的費用問題，如上測試使用的云主機實例類型為“超高性能主機”，配置1顆vCPU和1GB內存。在參與測試的14臺云主機中，1號云主機在一個用戶帳號中，2～14號云主機在另外一個用戶帳號中。1號云主機和2號云主機配為一對，3號云主機和4號云主機配為一對，以此類推。在編號為1的測試中，只有第一對云主機產生網絡流量，其他云主機處于空閑狀態；在編號為2的測試中，第一對和第二對云主機產生網絡流量，其他云主機處于空閑狀態，以此類推。如上測試在一個月中的不同時段進行了多次，不同批次的測試結果之間基本一致。基于如上測試，可以認為青云的網絡質量相對較低，具體表現在：
沒有對云主機采取限流措施，吞吐量指標存在大規模抖動；
在小規模測試中，僅用6臺云主機即可探測到網絡性能惡化的跡象；
隨著參與測試的云主機數量的增加，網絡性能惡化極快；
單個用戶可以使用的網絡帶寬上限低于700MB/s；
在小規模測試中，可以觀察到單個用戶大量占用網絡帶寬對其他用戶使用網絡產生影響。
測試編號節點1節點2節點3節點4節點5節點6節點7節點8節點9節點10
1800
2800800
3800800800
4330800800350
5320770730360800
6330800800360800800
7320800800350330780300
8380800400340320800300300
9340800360380330280320270620
10340350350380330290330270670350
上表所示是在青云北京2區（PEK-2）進行存儲帶寬探測的結果。測試中使用了10臺云主機，所有云主機都部署在同一個區域內。
首先，我們使用不同的云主機實例類型掛載單塊云硬盤進行測試，發現存儲帶寬上限為200MB/s。這個存儲帶寬上限既與云硬盤的容量無關，也與云主機實例類型無關。
其次，我們在同一臺云主機上掛載多塊云硬盤創建RAID0磁盤陣列進行同樣測試。與單塊云硬盤相比，用兩塊云硬盤創建的RAID0磁盤陣列可以獲得400MB/s的存儲帶寬。用三塊或者四塊云硬盤創建的RAID0磁盤陣列，則可以獲得600MB/s和800MB/s的存儲帶寬。
考慮到批量測試的費用問題，如上測試使用的云主機實例類型為“超高性能主機”，配置1顆vCPU和1GB內存，掛載四塊50GB的云硬盤配置成RAID0磁盤陣列。在參與測試的10臺云主機中，1號云主機在一個用戶帳號中，2～10號云主機在另外一個用戶帳號中。在編號為1的測試中，只有1號云主機產生存儲流量，其他云主機處于空閑狀態；在編號為2的測試中，1號和2號對云主機產生存儲流量，其他云主機處于空閑狀態，以此類推。如上測試在一個月中的不同時段進行了多次，不同批次的測試結果之間基本一致。基于如上測試，可以認為青云的存儲質量相對較低，具體表現在：
沒有對云主機或者云硬盤采取限流措施，吞吐量指標存在大規模抖動；
在小規模測試中，僅用4臺云主機即可探測到存儲性能惡化的跡象；
隨著參與測試的云主機數量的增加，存儲性能惡化極快；
單個用戶可以使用的存儲帶寬上限為4000MB/s；
在小規模測試中，可以觀察到單個用戶大量占用存儲帶寬對其他用戶使用存儲產生影響。
在針對客服能力的測試中，作者通過青云Web控制臺里提交了多個工單。所有工單的響應時間均在30分鐘以內。不同工單分別涉及配額上調、使用方法、缺陷報告等等內容，處理所需要的時間也有不同。所有工單咨詢的問題最終都得到很好的解決。
盛大云啟用的公網IP地址有3個B段。通過ip-tracker.org進行查詢，未能確認這些IP地址屬于盛大云。
2016年3月，從公網對全部3個B類IP地址段針對22（SSH）和3389（RDP）端口進行掃描，有6,000個IP地址可以通過22端口創建網絡連接，有4,000個IP地址可以通過3389端口創建網絡連接。
2016年9月，從公網對全部4個B類IP地址段針對22（SSH）、80（HTTP）、443（HTTPS）和3389（RDP）端口進行掃描。有5500個IP地址可以通過22端口創建網絡連接，有36000個IP地址可以通過80端口創建網絡連接，有3600個IP地址可以通過443端口創建網絡連接，有3,200個IP地址可以通過3389端口創建網絡連接。
由于盛大云的規模相對較小，作者未對1433、3306和11211等端口進行掃描和自動化登錄測試。基于同樣的原因，作者也未對美團云進行網絡、存儲、客服等方面的測試。
UCloud啟用的公網IP地址有8個B段。通過ip-tracker.org進行查詢，僅有一個B段可以確認屬于UCloud。
2016年3月，從公網對全部8個B類IP地址段針對22（SSH）和3389（RDP）端口進行掃描，有24,000個IP地址可以通過22端口創建網絡連接，有9,000個IP地址可以通過3389端口創建網絡連接。UCloud給每個用戶均缺省地提供了一個私有網絡，用戶在自己的私有網絡上創建云主機，無法掃描到不屬于用戶自己的云主機。
2016年9月，從公網對全部8個B類IP地址段針對22（SSH）、80（HTTP）、443（HTTPS）和3389（RDP）端口進行掃描。有43,100個IP地址可以通過22端口創建網絡連接，有54,200個IP地址可以通過80端口創建網絡連接，有27,500個IP地址可以通過443端口創建網絡連接，有22,800個IP地址可以通過3389端口創建網絡連接。
UCloud給每個用戶均缺省地提供了一個私有網絡，用戶在自己的私有網絡上創建云主機，無法掃描到不屬于用戶自己的云主機。由于UCloud的規模相對較小（相對于阿里云而言），作者未對1433、3306和11211等端口進行掃描和自動化登錄測試。
測試編號節點1節點2節點3節點4節點5節點6節點7節點8節點9節點10節點11節點12節點13節點14
1175175
2175175175170
3175175170175175165
4170165165175165175165165
5175175175175175165165165
6175175175130175180170160165170180
7175175165180190175185155150190170190190150
上表所示是在UCloud北京D區（PEK-D）進行網絡帶寬探測的結果。測試中使用了7對云主機，所有云主機都部署在同一個區域內。我們首先使用同樣的測試程序對不同的云主機實例類型進行測試，發現不同的云主機實例類型所能夠達到的內網帶寬是一樣的。考慮到批量測試的費用問題，如上測試使用的云主機實例類型為“SSD高性能主機”，配置1顆vCPU和2GB內存。在參與測試的14臺云主機中，1號云主機在一個用戶帳號中，2～14號云主機在另外一個用戶帳號中。1號云主機和2號云主機配為一對，3號云主機和4號云主機配為一對，以此類推。在編號為1的測試中，只有第一對云主機產生網絡流量，其他云主機處于空閑狀態；在編號為2的測試中，第一對和第二對云主機產生網絡流量，其他云主機處于空閑狀態，以此類推。如上測試在一個月中的不同時段進行了多次，不同批次的測試結果之間基本一致。基于如上測試，可以認為UCloud云的網絡質量相對較好，具體表現在：
似乎對云主機采取了限流措施，但是吞吐量指標存在一定范圍的抖動；
在小規模測試中，未探測到網絡性能明顯惡化的跡象；
在小規模測試中，未觀察到單個用戶大量占用網絡帶寬對其他用戶使用網絡產生影響。
基于現象（1），作者傾向于認為UCloud尚未實現以云主機為單位進行精準限流。在小規模測試中觀察到現象（2）和（3）的根本原因是因為UCloud的規模較大（相對于青云而言），其網絡資源總量足以消化小規模測試所產生的網絡流量。
測試編號節點1節點2節點3節點4節點5節點6節點7節點8節點9節點10
1280
2280260
3200260240
4200250210220
5200230250200200
6200200210230160180
7140220140140140170140
8140190140140140140140180
9140180140140140140140140140
10120160120120120140140140140120
上表所示是在UCloud北京C區（PEK-C）進行存儲帶寬探測的結果。測試中使用了10臺云主機，所有云主機都部署在同一個區域內。
首先，我們使用不同的云主機實例類型掛載單塊云硬盤進行測試，發現存儲帶寬上限在100MB/s上下波動，但是并不穩定。這個存儲帶寬上限既與云硬盤的容量無關，也與云主機實例類型無關。
其次，我們在同一臺云主機上掛載多塊云硬盤創建RAID0磁盤陣列進行同樣測試。與單塊云硬盤相比，用兩塊云硬盤創建的RAID0磁盤陣列可以獲得200MB/s的存儲帶寬。用三塊或者四塊云硬盤創建的RAID0磁盤陣列，則可以獲得300MB/s和400MB/s的存儲帶寬。用六塊云硬盤創建的RAID0磁盤陣列，最高可以獲得580MB/s的存儲帶寬，但是均值只有400MB/s。
考慮到批量測試的費用問題，如上測試使用的云主機實例類型為“SSD高性能主機”，配置1顆vCPU和2GB內存，掛載四塊50GB的云硬盤配置成RAID0磁盤陣列。在參與測試的10臺云主機中，1號云主機在一個用戶帳號中，2～10號云主機在另外一個用戶帳號中。在編號為1的測試中，只有1號云主機產生存儲流量，其他云主機處于空閑狀態；在編號為2的測試中，1號和2號對云主機產生存儲流量，其他云主機處于空閑狀態，以此類推。如上測試在一個月中的不同時段進行了多次，不同批次的測試數據存在較大差別，但是所觀察到的現象基本一致。基于如上測試，可以認為UCloud的存儲質量相對較低，具體表現在：
沒有對云主機或者云硬盤采取限流措施，吞吐量指標存在大規模抖動；
在小規模測試中，僅用4臺云主機即可探測到存儲性能惡化的跡象；
隨著參與測試的云主機數量的增加，存儲性能惡化極快；
在小規模測試中，可以觀察到單個用戶大量占用存儲帶寬對其他用戶使用存儲產生影響；
在被測試區域中可能存在其他用戶運行的磁盤I/O密集型應用，并且其磁盤I/O資源使用模式隨時間發生變化。
注：在針對青云的測試中，并未觀察到同類現象。青云的可觀測規模不足UCloud的1/3，如果青云上存在其他用戶運行的磁盤I/O密集型應用，應該比UCloud更容易觀察到。因此，作者傾向于認為在青云的被測試區域中存在其他用戶運行的磁盤I/O密集型應用的可能性較小。
針對存儲帶寬的測試結果，也從側面驗證了作者在網絡帶寬測試中所做的判斷。UCloud尚未實現以云主機為單位對網絡和存儲流量進行精準限流。在網絡帶寬測試中，UCloud的網絡資源總量足以消化小規模測試所產生的網絡流量，從測試結果中僅能觀察到網絡帶寬的波動。在存儲帶寬測試中，UCloud的存儲資源總量不足以消化小規模測試所產生的存儲流量，從測試結果中可以觀察到顯著的性能惡化。
在針對客服能力的測試中，作者通過UCloud的Web控制臺里提交了多個工單。所有工單的響應時間均在30分鐘以內。不同工單分別涉及配額上調、使用方法、缺陷報告等等內容，處理所需要的時間也有不同。工單所咨詢的問題，大部分得到很好的解決，小部分工單沒有得到解決。
騰訊集團在自治域AS45090、AS132203、AS132591、AS134103中一共聲明了12個B類IP地址段以及多個C類IP地址段。
2016年3月，從公網對全部12個B類IP地址段針對22（SSH）和3389（RDP）端口進行掃描，有40,000個IP地址可以通過22端口創建網絡連接，有40,000萬個IP地址可以通過3389端口創建網絡連接。
2016年9月，從公網對全部12個B類IP地址段針對22（SSH）、80（HTTP）、443（HTTPS）和3389（RDP）端口進行掃描。有65000個IP地址可以通過22端口創建網絡連接，有90,000個IP地址可以通過80端口創建網絡連接，有20,000個IP地址可以通過443端口創建網絡連接，有50,000個IP地址可以通過3389端口創建網絡連接。
需要說明的是，如上所述12個B類IP地址段并非全部用于騰訊云的公有云服務。騰訊集團下的其他業務譬如QQ和微信所使用的IP地址也都在這12個B類IP地址段中。根據華為集團2014年發布的成功案例《華為服務器助力騰訊構建十萬級高效部署》[21]的成功案例，騰訊集團現網服務器超過30萬臺，其中華為服務器超過10萬臺。假設騰訊集團所使用的服務器當中只有10%配置公網IP，需要占用的IP地址數量就超過3萬個。考慮到騰訊集團本身對計算資源的需求還在增長，同時也會占用更多的IP地址。因此，騰訊云的公有云服務所使用的IP地址（包括物理機和虛擬機）只占如上所述活躍IP地址中的一小部分。
由于騰訊云的規模相對較小，作者未對1433、3306和11211等端口進行掃描和自動化登錄測試。基于同樣的原因，作者也未對騰訊云進行網絡、存儲、客服等方面的測試。
騰訊云使用QQ的帳號管理體系，可能是騰訊云用戶最大的風險之一。眾所周知，QQ用戶在密碼丟失、手機停機、切換地理位置的時候，均有QQ號碼被騰訊集團回收的可能。作者于2000年成為QQ早期用戶，十多年如一日地使用同一個QQ號碼。在此期間，作者從美國伊利諾州移居加州，又從加州移居北京，再從北京移居海南，從未放棄過使用該QQ號碼與親朋好友進行聯系。2014年2月，作者從海南移居悉尼，QQ以登錄地理位置可疑為由拒絕作者登錄。由于作者居住在北京時向騰訊登記的密碼保護手機號碼已經停用，作者選擇通過早期好友確認的方式找回QQ號碼。盡管所有三位早期好友均向騰訊作出了確認，騰訊方面依然拒絕作者繼續使用該QQ號碼。作者先前設置了QQ郵件轉發，盡管作者已經不再擁有該QQ號碼的使用權，但是發向該QQ號碼的電子郵件依然被轉發到作者的常用郵箱里。假設一家創業公司選擇在騰訊云部署服務，而其所使用的QQ號碼由于某種已知或者未知的原因被騰訊回收，必定會對其業務產生不可知的重大影響。創業者最不愿意看到的情形之一，可能是你所提供的服務還在正常運行，但是你已經不再擁有運行這些服務的計算資源的使用權和管理權了。
作者蔣清野是悉尼大學信息技術學院的博士研究生，同時也是AWS悉尼技術支持中心的員工。他于1999年獲得清華大學學士學位（土木工程），2000年獲得伊利諾伊大學香檳分校碩士學位（土木工程），2015年獲得悉尼大學碩士學位（計算機科學）。他的研究興趣包括分布式與高性能計算、開源社區的社會學行為、信息技術領域的微觀經濟學分析。他是美國電子電氣工程師學會（IEEE）的高級會員。
在接受InfoQ方面的邀請準備規劃這篇報告的時候，作者的內心是興奮的。在獲得所有測試數據準備撰寫這篇報告的時候，作者的內心是矛盾的。一方面，作為并行與分布式計算領域的學生，作者希望為業界提供一些有用的信息和觀點；另一方面，作為公有云服務領域的從業人員，作者深知發表一份涉及多家友商的報告會帶來諸多爭議。在InfoQ方面的鼓勵下，作者選擇以真實的身份發布這些的數據和觀點，希望能夠對國內云計算從業人員有所幫助。
本文轉載自infoQ
