背景介绍
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
