“这是中国第一份全面的云计算报告！旨在让读者一窥国内公有云服务发展之真实面貌。
▋编者注：
本报告共包括团队建设篇、产品研发篇、 服务运营篇、用户体验篇，以及其他讨论篇，因为篇幅关系，这里仅发布“用户体验篇+其他讨论篇”，有删节。如想阅读完整报告，请移步「细说云计算」公众号，ID：CloudNote。
在文章的准备过程中，作者系统地阅读了国内较为知名的几份云计算白皮书[1，2，3]。在本文的范畴内，“公有云”一词泛指面向公众开放服务的平台即服务和设施即服务。除此之外，各种名义的私有云（Private Cloud）、专有云（Dedicated Cloud）、托管云（Managed Cloud）均未包括在本文的范畴之中。
本文仅讨论中国本土的公有云服务提供商。Amazon Web Services(AWS)、Microsoft Azure、Google Cloud Platform等等进入或者未进入中国市场的外资企业不在本文的讨论范围之内。
▋老司机简介：
蒋清野，悉尼大学信息技术学院博士研究生，同时也是AWS悉尼技术支持中心的员工。他于1999年获得清华大学学士学位（土木工程），2000年获得伊利诺伊大学香槟分校硕士学位（土木工程），2015年获得悉尼大学硕士学位（计算机科学）。
他的研究兴趣包括分布式与高性能计算、开源社区的社会学行为、信息技术领域的微观经济学分析。他是美国电子电气工程师学会（IEEE）的高级会员。
▋用户体验：
在这个部分，我们以用户体验为主线，对不同公有云服务提供商的产品进行一些小规模测试。这些测试旨在探测客户关心的几个关键参数：
•服务规模；
•网络与存储吞吐能力；
•资源隔离状况；
•客服能力。
‖服务规模
针对服务规模的测试，是通过端口扫描进行的。针对一个特定的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分钟，记录测试过程中的磁盘写入带宽。这个测试分为三个步骤进行：
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月在第三届中国云计算大会上的演讲[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操作系统的云主机已经沦为肉鸡。
作者还注意到，在阿里云各个区域进行内网扫描获得的端口数量是高度一致的。深圳、杭州、青岛、北京、上海、香港、美西这七个区域的活跃端口数量，精确到千位数都是完全相同的。唯一的一个例外是新加坡区域，原因不明。
阿里云内网带宽测试（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.在小规模测试中，未能探测到单个用户大量占用存储带宽对其他用户使用存储产生影响。
▋金山云
金山云对客户的挑选比较苛刻。作者自主在金山云的网站上注册帐号，可以完成注册但是无法激活帐号。未激活帐号依然可以对帐号进行充值，但是充值完成之后无法创建云主机，也无法使用金山云提供的任何其他资源。
作者通过在线客服功能联系到金山云的客服人员，客服人员提供了一个激活帐号的连接，但是依然无法成功激活帐号。（注：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]。与青云的实际规模相比，这样的宣传未免名不副实。
青云内网带宽测试（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密集型应用的可能性较小。
▋腾讯云
腾讯集团在自治域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地址中的一小部分。
▋其他讨论
‖弹性计算
弹性计算的核心，是负载均衡与自动伸缩的有机结合。负载均衡这个概念出现得比较早，在整个IT行业都已经被广泛接受和广泛应用。本文中所讨论的几家公有云服务提供商，基本上都提供了负载均衡的功能或者特性。自动伸缩则是云计算“按需获取、按量计费”理念的具体实现，最早的实现是AWS针对其EC2服务所提供的AutoScaling Group（ASG）功能。
本文中讨论的几家公有云服务提供商，只有阿里云（2014年9月）、青云（2015年3月）和UCloud（2016年6月）提供了类似于ASG的自动伸缩功能。
对于一个正常的Web应用，其负载通常可以划分成三个档次：长期平均负载，长期高峰负载，短期爆发负载。在每秒只有数百个请求的情况下，云主机集群具备每秒处理一万个请求的能力是没有必要的。在每秒达到数万个请求的情况下，云主机集群只有每秒处理一万个请求的能力是远远不够的。
自动伸缩的目的，就是在应用负载降低时自动将多余的云主机从负载均衡上移除并销毁以节省成本，在应用负载升高时自动启动更多的云主机并加入负载均衡以应对压力。通过自动伸缩，用户自动地按照实际负载购买计算资源，既不存在处理能力不足的问题，也不存在浪费计算资源的问题。
显而易见，自动伸缩要求云主机集群中的每一台云主机都能够稳定地提供一定的处理能力。当云主机数量增加时，集群处理能力随之增加；当云主机数量减少时，集群处理能力随之减少。集群处理能力与云主机数量之间的关系不一定是线性的，但必须是正相关的。
在理想的情况下，这种关系应该是可预测的。假设我们有一个网络I/O密集型应用，每处理1万个请求会产生100MB的内网流量，但是对CPU、内存、存储的要求不高。当应用的负载为每秒1万个请求时，要求内网带宽大于100MB/s。在阿里云上应对这样的负载，要求在云主机集群中部署2台云主机。在青云上应对这样的负载，要求云主机集群中部署1台云主机。
当应用的负载为每秒10万个请求时，要求内网吞吐量大于1,000MB/s。在阿里云应对这样的负载，需要在云主机集群中部署17台云主机。在青云上应对这样的负载，不管在云主机集群中部署多少台云主机都无能为力，因为需要的内网带宽超出了单个用户所能够使用的带宽上限。
因此，在弹性计算这个场景中，用户需要了解的不是某个产品最高可以达到什么性能，而是最低可以达到什么性能。在云主机网络带宽测试中，阿里云两台云主机之间的网络带宽只有60MB/s，青云两台云主机之间的网络带宽达到115MB/s。
看起来似乎青云的网络性能要好得多，但是阿里云的网络性能是不随着用户使用量的增加而发生恶化的，青云的网络性能则是随着用户使用量的增加而发生恶化的。在云主机存储带宽测试中，阿里云单台云主机的存储带宽只有400MB/s，青云单台云主机的存储带宽达到800MB/s。
看起来似乎青云的存储性能要好得多，但是阿里云的存储性能是不随着用户使用量的增加而发生恶化的，青云的存储性能则是随着用户使用量的增加而发生恶化的。
阿里云给所有配置的云主机提供相同的网络带宽，并不符合“按需获取、按量计费”的理念。目前阿里云所提供的内网带宽可能可以满足中小型Web应用的需求，但是尚远远不能满足大型Web应用和科学计算应用的需求。
作者曾经试图在阿里云上运行一些对网络I/O和磁盘I/O同时有较高需求的科学计算应用，但是由于网络I/O方面的限制未能取得预期的效果。作者注意到阿里云团队在2015年10月高调发布了新的100TB数据排序世界记录[13]，但是这个世界纪录不是在阿里云上获得的，而是阿里云团队在物理机上获得的。
出于好奇，作者将阿里云团队于2015年取得的进展与Spark团队于2014年报告的成绩[14]（基于AWS EC2服务，使用i2.8xlarge实例）以及加州大学圣地亚哥分校（UC San Diego，UCSD）和Google团队于2014年报告的成绩[15]（基于AWS EC2服务，使用i2.8xlarge实例）进行了对比。
下表是UCSD团队、Spark团队、阿里云团队在100TB排序中的各项参数：
作者发现，同样是100TB数据排序，Spark团队使用了50TB内存，UCSD团队使用了45TB内存，阿里云使用了332TB内存。打个极度简化的比喻，Spark团队和UCSD团队需要5个手指头来做0到9这十个数字的排序，而阿里云团队需要33个手指头来做0到9这十个数字的排序。
学习过算法的从业人员都知道，在内存富余的情况下进行数据排序，其算法复杂度远低于在内存不足的情况下进行数据排序。在内存不足的情况下，需要先将中间数据写入磁盘，再分批从磁盘读出进行排序操作。
在100TB数据排序中，内存不足的情况产生100TB的网络I/O以及200TB的磁盘I/O（读和写操作都是200TB），内存富余的情况则产生100TB的网络I/O和100TB的磁盘I/O（读和写操作都是100TB）。
在这种情况下，Spark团队单颗CPU核心平均每秒钟处理的数据量（以MB计算）是阿里云团队的1.72倍，UCSD团队单颗CPU核心平均每秒钟处理的数据量（以MB计算）是阿里云团队的1.91倍。
我们也注意到阿里云团队所使用的处理器相对较老，其处理能力相对较低。就裸机单线程处理能力而言，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实例使用的是虚拟处理器核心，存在一定的虚拟化损失。
基于如上两点，可以推测如果阿里云同样采用Intel Xeon E5-2670 v2 @2.50GHz处理器的话，则其单颗CPU核心平均每秒钟处理的数据量（以MB计算）表面上看来可以与Spark团队和UCSD团队所报告的成绩持平。
问题在于，Spark团队和UCSD团队所处理的是一个比较复杂的场景（数据量是内存的2倍），其算法复杂度较高；而阿里云所处理的是一个比较简单的场景（内存是数据量的3.3倍），其算法复杂度较低。
因此，阿里云所报告的成绩只是集群规模增长的自然结果，其系统和算法远远不如Spark团队和UCSD团队的系统和算法。(阿里云所处理的场景与Yahoo团队于2013年所处理的场景[19]是类似的，并且其系统和算法优于Yahoo团队的系统和算法。)
阿里云所报告的100TB数据排序成绩，证明的是阿里云作为一家公司已经具备了管理和使用超大型集群的能力。这个能力与阿里云于2014年在VLDB上发布的关于伏羲的论文[20]所报告的能力是类似的。但是，这个能力与阿里云所提供的产品和服务的能力并不直接相关。譬如说，阿里云的ECS（云主机）服务所提供的计算、网络和存储能力，尚远远不足以满足运行这个100TB数据排序的要求。
作者认为，阿里云尚需加强其ECS服务所提供的计算、网络和存储能力。什么时候阿里云的用户能够自地主在阿里云所提供的ECS服务上运行这个100TB数据排序并且达到Spark团队于2014年所取得的成绩，那么阿里云的ECS服务就真的是达到AWS的EC2服务在2014年的水平了。
‖区域间网络状况
为了了解各个公有云服务提供商的不同区域间的网络状况，我们在阿里云、青云和UCloud的华南和华北区域各启动云主机一台，并在两台云主机之间进行MTR测试。这部分测试数据，是在2016年8月底获得的。
上图所示为阿里云华南1区到华北2区的测试结果，数据包经过11跳抵达目标云主机。在这个路由当中，有5跳（4～8）经过的设备使用公网IP地址，其余6跳经过的设备使用阿里云内网IP。
值得说明的是，上图所示的4个公网IP全部属于阿里云（属于自治域AS37963），说明从阿里云华南1区到华北2区的整个数据链路层都在阿里云的掌控之下。
上图所示为青云北京2区到广东1区的测试结果，数据包经过23跳抵达目标云主机。在这个路由当中，有16跳（3～18）经过公网，其余7跳在青云自己的内网。在整个数据链路上，没有任何一个公网IP属于青云。
因此，青云不同区域间的互联互通，完全依赖于数据中心服务提供商之间的互联互通。从从这个测试结果来看，青云“1跳进入全球任何网络运营商的主干网”这个目标可能还需要很长时间方可达成。
上图为UCloud广东B区到北京C区的测试结果，数据包经过19跳抵达目标云主机。在这个路由当中，有8跳（6～13）经过公网，其余11跳在UCloud自己的内网。在整个数据链路上，没有任何一个公网IP属于UCloud。因此，UCloud不同区域间的互联互通，也完全依赖于数据中心服务提供商之间的互联互通。
从网络拓扑来看，国内互联网可以分为主干网（公网）、地区网（广域网）、主节点（城域网）几个层次。在计算系统可靠度的时候，又可以进一步将其简化成一个串行系统来处理。
我们知道，串行系统的可靠度等于系统中各个组件的可靠度的乘积。串行系统中包含的组件越多，则整个系统的可靠性越低。假设一个串行系统中包含100个组件，每个组件的可靠度为0.999，则整个系统的可靠度为0.999100=0.905。
我们知道，中国ChinaNet骨干网的拓扑结构在逻辑上分为两层，即核心层和大区层。核心层由北京、上海、广州、沈阳、南京、武汉、成都、西安等8个城市的核心节点组成，其功能主要是提供与国际互联的接口以及大区之间互联的通路。全国31个省会城市按照行政区划，以上述8个核心节点为中心划分为8个大区网络。这8个大区网共同构成了大区层，大区之间通信必须经过核心层。
基于这样一个极度简化的模型，云服务提供商某个区域所在的数据中心与核心层之间的串行系统的组件数量，约等于如上所述MTR测试结果中数据包经过公网的跳数除以二。
以此估算，阿里云的串行系统组件数量为2，青云的串行系统组件数量为8，UCloud的串行系统组件数量为4。假设这个串行系统中每个组件的可靠度是相同的（实际上并不相同），则阿里云数据链路的可靠度大于UCloud，而UCloud数据链路的可靠度大于青云。
‖市场规模
公有云作为一种新型服务，其市场规模尚有相当程度的自然增长空间。因此，五年之后的公有云可能达到的规模只会比这个数字更大。基于这些估算，我们可以根据其规模将一家公有云创业企业的成长分为五个阶段：
•概念阶段，小于5,000台虚拟机。公司的终极目标相对模糊，在私有云解决方案提供商和公有云服务提供商之间摇摆不定。在战术层面，缺乏明确的技术路线图，产品形态相对原始并且没有明确的技术指标。
•原型阶段，小于10,000台虚拟机。公司基本上将其终极目标定位为公有云服务提供商。由于公有云和私有云之间的巨大差异，必然要放弃私有云解决方案服务提供商的身份。在战术层面，基本形成相对清晰的技术路线图，基础产品（云主机）基本定型，在宕机时间和产品性能方面均有明确的技术指标。在云主机的基础上，提供能够承担中低负载的负载均衡、数据库、缓存等等周边产品。
•成长阶段，小于50,000台虚拟机。基础产品（云主机）能够满足高性能计算的要求，同时发展出一系列模块化的周边产品。普通用户完全依靠云服务提供商所提供的不同模块即可自主创建大规模可伸缩型应用（无需云服务提供商进行干预）。
•成熟阶段，小于100,000台虚拟机。在技术方面，资源利用率开始提高，规模效应开始出现。在市场方面，客户忠诚度开始提高，马太效应开始出现。这标志着公司在公有云领域已经获得了较有份量的市场份额，其产品和技术获得了一个或者多个细分市场的广泛认可。
•产业阶段，大于100,000台虚拟机。只有进入这一阶段，才能够认为一个服务提供商已经站稳了脚跟，可以把公有云当作一个产业来做了。至于最后能够做多大，一个好看国内的大环境，另外一个还得看公司自身的发展策略。
公有云服务的未来还远远不止于此。作者于2012年在《虚拟化、云计算、开放源代码及其他》[6]]这篇博客里面提到了英国经济学家威廉杰文斯（William Stanley Jevons，1835-1882）在《煤矿问题》（The Coal Question）[5]一书中指出的一个似乎自相矛盾的现象：
蒸汽机效率方面的进步提高了煤的能源转换率，能源转换率的提高导致了能源价格降低，能源价格的降低又进一步导致了煤消费量的增加。这种现象称为杰文斯悖论，其核心思想是资源利用率的提高导致价格降低，最终会增加资源的使用量。
在过去150年当中，杰文斯悖论在主要的工业原料、交通、能源、食品工业等多个领域都得到了实证。基于同样的原理，作者在这篇博客里面又进一步断言：“公共云计算服务的核心价值，是将服务器、存储、网络等等硬件设备从自行采购的固定资产变成了按量计费的公共资源。虚拟化技术提高了计算资源的利用率，导致了计算资源价格的降低，最终会增加计算资源的使用量。”
‖用户习惯
根据作者的观察，目前国内大部分公有云用户还是把云主机当作传统物理服务器的替代品来使用。这个观察在作者与各个公有云服务提供商负责人的访谈中也得到了验证。
在传统的IT架构中，操作系统是安装在物理服务器上的。由于重新安装操作系统需要造成很长的宕机时间，出现软件层面故障时运维或者开发人员往往倾向于寻找问题来源并予以排除。
很多时候，运维或者开发人员需要花费很长时间来寻找一些不易发觉的输入或者拼写错误（例如四个空格和一个tab）。在弹性计算这个场景中，操作系统是通过映像模板创建的，获得一台全新的包含正确配置的云主机只需要数分钟甚至更短的时间。
在这个时间优势的基础上，云计算服务提供商终于可以直面长期以来被传统IT服务提供商所刻意回避的两个事实。第一个事实是组件的失效是必然的，是不可避免的；第二个事实是组件的失效是随机的，是不可预测的。
用AWS首席技术长官Werner Vogels的原话来说，就是“任何组件可在任何时刻失效”（Everything fails, all the time.）。一个集群中任意云主机均可以在任意时刻由于任意原因（底层硬件、网络环境、操作系统、应用软件）发生失效。
有了负载均衡与自动伸缩后，一台云主机发生失效时，自动伸缩功能自动地将其从负载均衡上移除并进行销毁，同时自动地启动一台新的云主机并加入负载均衡。
因此，用户可以将云主机视为“即用即抛型”一次性资源。忽略云主机的失效，不仅不会牺牲应用服务质量，还可以将宝贵的资源集中投入到公司的关键业务。
可惜的是，由于缺乏对弹性计算的理解，大量系统管理员延续了在使用物理服务器时期培养的习惯。他们在云主机等计算资源失效时惊慌失措，并且热衷于寻找所谓的“根本原因分析”（root cause analysis）。
他们在潜意识里还是将基础设施视为公司的资产，试图去了解和掌握云主机之下每一个层面的信息。他们没有意识到在弹性计算这个场景里这些努力不仅没有必要而且会阻碍整个公司技术进步。
解决这个问题，需要所有的公有云服务提供商持之以恒地对用户进行教育。用户的认知水平提高了，也会进一步促进公有云市场的发展。除了对用户进行教育之外，公有云服务提供商也需要加强对员工的教育。
‖安全问题
在“用户体验”这个小节的网络测试部分，作者仅报告了针对阿里云的1433、3306和11211端口扫描情况。主要的考虑在于小型公有云服务提供商更加需要保护，因此不宜对小型公有云服务提供商进行同类测试；次要的考虑在于公有云服务提供商无法独立承担安全重任，因此需要向从业人员披露公有云服务中存在的安全隐患。
需要说明的是，作者在阿里云内网和外网获得的端口扫描结果，并非阿里云独有的现象。任何一个刚刚学会运行bash脚本的从业人员，都可以通过类似方法在AWS所在的IP段扫描到类似的结果。
阿里云和AWS的不同之处，在于阿里云教育客户“选择云盾，让您的业务安全性如同阿里巴巴一般”，AWS则教育客户“安全共担”（shared responsibility）模型。云盾的产品介绍页面宣称“每天防御超过958万次暴力破解攻击”，但是作者基于社会工程数据库的自动化登录测试也获得了部分成功。这样的结果，可以有三个解释：
•大部分被成功登录的云主机没有使用云盾服务；
•少部分被成功登录的云主机虽然使用了云盾服务但是其密码设置过于薄弱，因此在云盾未被激活之前就已经被成功登录；
•类似于Memcached这样免登录的服务，云盾目前是完全无能为力的。在阿里云内网，作者还探测到大量其他免登录或者仅使用弱口令保护的网络服务，例如RabbitMQ。
因此，不管用户是否使用服务提供商所提供的云安全服务，均应对客户进行“安全共担”的教育，引导客户采取必要的措施保护其所使用的计算资源。遗憾的是，阿里云作为国内规模最大的公有云服务提供商，向用户传达了完全错误的信息。
作者建议阿里云安全团队针对阿里云内网进行常规性的分布式端口扫描，充分了解安全隐患的严重程度，并在此基础上向阿里云的用户提出针对性的改进建议。
▋结语：
在接受InfoQ方面的邀请准备规划这篇报告的时候，作者的内心是兴奋的。在获得所有测试数据准备撰写这篇报告的时候，作者的内心是矛盾的。一方面，作为并行与分布式计算领域的学生，作者希望为业界提供一些有用的信息和观点；
另一方面，作为公有云服务领域的从业人员，作者深知发表一份涉及多家友商的报告会带来诸多争议。在InfoQ方面的鼓励下，作者选择以真实的身份发布这些的数据和观点，希望能够对国内云计算从业人员有所帮助。
作者丨蒋清野
▋参考文献：
1.工业和信息化部电信研究院（中国信通院，CAICT），《云计算白皮书（2014年）》，2014年5月
2、中国电子信息产业发展研究院工业和信息化部赛迪智库，《云计算发展白皮书（2015版）》，2015年4月
3.工业和信息化部电信研究院（中国信通院，CAICT），《云计算白皮书（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.蒋清野，《虚拟化、云计算、开放源代码及其他》，2012年10月
7.蒋清野，《从王博士说起》，2013年12月
8.蒋清野，《浅谈“中国”语境下的公有云发展》，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.章文嵩，《淘宝软件基础设施构建实践》，第三届中国云计算大会，2011年5月
11.高山渊，《阿里巴巴系统运维实践分享》，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基准测试数据
17.Intel Xeon E5-2650基准测试数据
18.Intel Xeon E5-2670基准测试数据
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.华为集团，《华为服务器助力腾讯构建十万级高效部署》，2014年7月
22.陈海泉，《下一代超大规模软件定义网络技术实践》，2016年1月
23.高旭磊，《招商银行关于金融云的思考》，中国金融电脑，2016年8月
24.阿里云，《阿里云生态路线图》，2015年7月