在这个部分，我们以用户体验为主线，对不同公有云服务提供商的产品进行一些小规模测试。这些测试旨在探测客户关心的几个关键参数：

（1）服务规模；

（2）网络与存储吞吐能力；

（3）资源隔离状况；

（4）客服能力。

需要说明的是，这些测试仅仅是试探性的探测（probe），并非严谨的基准测试（benchmark），测试结果反映的只是测试当时的用户体验。作者本人的技术背景与云主机类产品比较接近，对云存储领域的了解相对有限。因此，这些测试仅针对设施层面的云主机类产品，并且没有完整覆盖所有国内的 IaaS 服务提供商。（在此作者谨向七牛云和又拍云这两家公有云服务提供商致以诚挚的歉意。）

服务规模

针对服务规模的测试，是通过端口扫描进行的。针对一个特定的 IaaS 服务提供商，这个测试分为两个步骤进行：

1、在所有区域分不同时段（时间跨度长达一个月）大量创建云主机，通过枚举得出云主机所用公网IP所在的B段列表，并通过公开的信息进行矫正；

2、对所有的 B 段针对22、80、443、3389端口进行扫描，将扫描结果记录到数据库。

有些 B 段 IP 地址，可能超出了 IaaS 服务提供商所拥有 IP 资源范围。譬如某些服务提供商使用了运营商提供的IP地址，在同一个B段里面还有用于其它用途的 IP 地址。有些 B 段 IP 地址，虽然由某个服务提供商拥有，但是并非用于 IaaS 服务。因此，端口扫描得到的结果，反映的是从外界可以探测到的服务规模上限。考虑到防火墙、安全组、部分云主机未配置公网等等多种因素，端口扫描的结果是小于实际服务规模的。

网络与存储吞吐能力

针对网络吞吐能力的测试，是在同一个区域内启动N对云主机。在所有的云主机内安装 Apache 服务，提供一个100 MB 大小的文件下载。在每一对云主机之间，在每台云主机上启动多个线程从对方下载如上所述100 MB 大小的文件，单次测试持续时间15分钟。由于供下载的文件是同一个，该文件在第一次被读取之后便驻留在内存当中，不再产生新的磁盘 I/O。因此，这个测试探测的是两台云主机之间的内网带宽。N 的取值范围，从1逐渐增加到10，目的在于探测单个用户可以使用的网络带宽边界。测试中使用的第一对云主机，一台在用户账号 A 中，一台在用户账号B中，目的在于测试网络资源隔离状况。针对一个特定的 IaaS 服务提供商，这个测试在不同时段进行多次，以了解不同时段对网络性能的影响。

针对存储吞吐能力的测试，是在同一个区域内启动N台云主机。在每台云主机上挂载 M 块云硬盘创建一个 RAID0 磁盘阵列。在云主机上启动多个线程，分别往磁盘阵列上写入多个远大于云主机物理内存的大文件。单次测试持续15分钟，记录测试过程中的磁盘写入带宽。这个测试分为三个步骤进行：

1、M 的取值为1，探测单台云主机上单块云硬盘的存储带宽上限；

2、M 的取值在2到4之间，探测单台云主机上一个磁盘阵列的存储带宽上限；

3、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月在第三届中国云计算大会上的演讲，淘宝网的生产服务器大约为20,000台。根据高山渊2012年6月在 QClub 深圳站上的演讲，阿里巴巴集团的服务器规模接近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端口的测试中，测试程序仅进行计数而不记录任何可以识别对方主机的数据。

阿里云内网带宽测试（MB/s）

上表所示是在阿里云杭州区域进行网络带宽探测的结果。测试中使用了7对云主机，所有云主机都部署在同一个可用区内。我们首先使用同样的测试程序对不同的云主机实例类型进行测试，发现不同的云主机实例类型所能够达到的内网带宽是一样的。

考虑到批量测试的费用问题，如上测试使用的云主机实例类型为“系列二：通用型 n1”，配置1颗 vCPU 和 1GB 内存。在参与测试的14台云主机中，1号云主机在一个用户帐号中，2～14号云主机在另外一个用户帐号中。1号云主机和2号云主机配为一对，3号云主机和4号云主机配为一对，以此类推。在编号为1的测试中，只有第一对云主机产生网络流量，其他云主机处于空闲状态；在编号为2的测试中，第一对和第二对云主机产生网络流量，其他云主机处于空闲状态，以此类推。如上测试在一个月中的不同时段进行了多次，不同批次的测试结果之间高度一致。作者将云主机的总量增加到10对（共20台），可以得到同样的测试结果。基于如上测试，可以认为阿里云的网络质量达到了较高的水平，具体表现在：

1、以云主机为单位进行精确限流，吞吐量指标基本没有发生抖动；

2、在小规模测试中，未能探测到单个用户能够使用的网络带宽上限；

3、在小规模测试中，未能探测到单个用户大量占用网络带宽对其他用户使用网络产生影响。

阿里云存储带宽测试（MB/s）

上表所示是在阿里云杭州区域进行存储带宽探测的结果。测试中使用了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台，可以得到同样的测试结果。基于如上测试，可以认为阿里云的存储质量达到了较高的水平，具体表现在：

1、以云主机和云硬盘为单位进行精确限流，吞吐量指标基本没有发生抖动；

2、在小规模测试中，未能探测到单个用户能够使用的存储带宽上限；

3、在小规模测试中，未能探测到单个用户大量占用存储带宽对其他用户使用存储产生影响。

在针对客服能力的测试中，作者通过阿里云 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网络” 。与青云的实际规模相比，这样的宣传未免名不副实。

由于青云的规模相对较小，作者未对1433、3306和11211等端口进行扫描和自动化登录测试。同时，考虑到青云在国内云计算行业具有很高的知名度，作者也对青云进行了网络、存储、客服等方面的测试。

青云内网带宽测试（MB/s）

上表所示是在青云北京2区（PEK-2）进行网络带宽探测的结果。测试中使用了7对云主机，所有云主机都部署在同一个区域内。我们首先使用同样的测试程序对不同的云主机实例类型进行测试，发现不同的云主机实例类型所能够达到的内网带宽是一样的。考虑到批量测试的费用问题，如上测试使用的云主机实例类型为“超高性能主机”，配置1颗 vCPU 和 1GB 内存。在参与测试的14台云主机中，1号云主机在一个用户帐号中，2～14号云主机在另外一个用户帐号中。1号云主机和2号云主机配为一对，3号云主机和4号云主机配为一对，以此类推。在编号为1的测试中，只有第一对云主机产生网络流量，其他云主机处于空闲状态；在编号为2的测试中，第一对和第二对云主机产生网络流量，其他云主机处于空闲状态，以此类推。如上测试在一个月中的不同时段进行了多次，不同批次的测试结果之间基本一致。基于如上测试，可以认为青云的网络质量相对较低，具体表现在：

1、没有对云主机采取限流措施，吞吐量指标存在大规模抖动；

2、在小规模测试中，仅用6台云主机即可探测到网络性能恶化的迹象；

3、随着参与测试的云主机数量的增加，网络性能恶化极快；

4、单个用户可以使用的网络带宽上限低于 700MB/s；

5、在小规模测试中，可以观察到单个用户大量占用网络带宽对其他用户使用网络产生影响。

青云存储带宽测试（MB/s）

上表所示是在青云北京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号对云主机产生存储流量，其他云主机处于空闲状态，以此类推。如上测试在一个月中的不同时段进行了多次，不同批次的测试结果之间基本一致。基于如上测试，可以认为青云的存储质量相对较低，具体表现在：

1、没有对云主机或者云硬盘采取限流措施，吞吐量指标存在大规模抖动；

2、在小规模测试中，仅用4台云主机即可探测到存储性能恶化的迹象；

3、随着参与测试的云主机数量的增加，存储性能恶化极快；

4、单个用户可以使用的存储带宽上限为4000MB/s；

5、在小规模测试中，可以观察到单个用户大量占用存储带宽对其他用户使用存储产生影响。

在针对客服能力的测试中，作者通过青云 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

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等端口进行扫描和自动化登录测试。

UCloud 内网带宽测试（MB/s）

上表所示是在 UCloud 北京 D 区（PEK-D）进行网络带宽探测的结果。测试中使用了7对云主机，所有云主机都部署在同一个区域内。我们首先使用同样的测试程序对不同的云主机实例类型进行测试，发现不同的云主机实例类型所能够达到的内网带宽是一样的。考虑到批量测试的费用问题，如上测试使用的云主机实例类型为“SSD 高性能主机”，配置1颗 vCPU 和 2GB 内存。在参与测试的14台云主机中，1号云主机在一个用户帐号中，2～14号云主机在另外一个用户帐号中。1号云主机和2号云主机配为一对，3号云主机和4号云主机配为一对，以此类推。在编号为1的测试中，只有第一对云主机产生网络流量，其他云主机处于空闲状态；在编号为2的测试中，第一对和第二对云主机产生网络流量，其他云主机处于空闲状态，以此类推。如上测试在一个月中的不同时段进行了多次，不同批次的测试结果之间基本一致。基于如上测试，可以认为 UCloud 云的网络质量相对较好，具体表现在：

1、似乎对云主机采取了限流措施，但是吞吐量指标存在一定范围的抖动；

2、在小规模测试中，未探测到网络性能明显恶化的迹象；

3、在小规模测试中，未观察到单个用户大量占用网络带宽对其他用户使用网络产生影响。

基于现象（1），作者倾向于认为 UCloud 尚未实现以云主机为单位进行精准限流。在小规模测试中观察到现象（2）和（3）的根本原因是因为 UCloud 的规模较大（相对于青云而言），其网络资源总量足以消化小规模测试所产生的网络流量。

UCloud 存储带宽测试（MB/s）

上表所示是在 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 的存储质量相对较低，具体表现在：

1、没有对云主机或者云硬盘采取限流措施，吞吐量指标存在大规模抖动；

2、在小规模测试中，仅用4台云主机即可探测到存储性能恶化的迹象；

3、随着参与测试的云主机数量的增加，存储性能恶化极快；

4、在小规模测试中，可以观察到单个用户大量占用存储带宽对其他用户使用存储产生影响；

5、在被测试区域中可能存在其他用户运行的磁盘 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年发布的成功案例《华为服务器助力腾讯构建十万级高效部署》的成功案例，腾讯集团现网服务器超过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号码由于某种已知或者未知的原因被腾讯回收，必定会对其业务产生不可知的重大影响。创业者最不愿意看到的情形之一，可能是你所提供的服务还在正常运行，但是你已经不再拥有运行这些服务的计算资源的使用权和管理权了。

延伸阅读

2015年中国公有云服务发展报告（团队建设篇）

2015年中国公有云服务发展报告（产品研发篇）

来源：细说云计算