2015年中国公有云服务发展报告—



 写点什么

背景介绍

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），并非严谨的基准测试（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 端口的测试中，测试程序仅进行计数而不记录任何可以识别对方主机的数据。

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

测试编号节点 1 节点 2 节点 3 节点 4 节点 5 节点 6 节点 7 节点 8 节点 9 节点 10 节点 11 节点 12 节点 13 节点 14 1 60 60 2 60 60 60 60 3 60 60 60 60 60 60 4 60 60 60 60 60 60 60 60 5 60 60 60 60 60 60 60 60 60 60 6 60 60 60 60 60 60 60 60 60 60 60 60 7 60 60 60 60 60 60 60 60 60 60 60 60 60 60 上表所示是在阿里云杭州区域进行网络带宽探测的结果。测试中使用了 7 对云主机，所有云主机都部署在同一个可用区内。我们首先使用同样的测试程序对不同的云主机实例类型进行测试，发现不同的云主机实例类型所能够达到的内网带宽是一样的。

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

以云主机为单位进行精确限流，吞吐量指标基本没有发生抖动；
在小规模测试中，未能探测到单个用户能够使用的网络带宽上限；
在小规模测试中，未能探测到单个用户大量占用网络带宽对其他用户使用网络产生影响。

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

测试编号节点 1 节点 2 节点 3 节点 4 节点 5 节点 6 节点 7 节点 8 节点 9 节点 10 1 400 2 400 400 3 400 400 400 4 400 400 400 400 5 400 400 400 400 400 6 400 400 400 400 400 400 7 400 400 400 400 400 400 400 8 400 400 400 400 400 400 400 400 9 400 400 400 400 400 400 400 400 400 10 400 400 400 400 400 400 400 400 400 400 上表所示是在阿里云杭州区域进行存储带宽探测的结果。测试中使用了 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 等端口进行扫描和自动化登录测试。同时，考虑到青云在国内云计算行业具有很高的知名度，作者也对青云进行了网络、存储、客服等方面的测试。

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

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

没有对云主机采取限流措施，吞吐量指标存在大规模抖动；
在小规模测试中，仅用 6 台云主机即可探测到网络性能恶化的迹象；
随着参与测试的云主机数量的增加，网络性能恶化极快；
单个用户可以使用的网络带宽上限低于 700MB/s；
在小规模测试中，可以观察到单个用户大量占用网络带宽对其他用户使用网络产生影响。

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

测试编号节点 1 节点 2 节点 3 节点 4 节点 5 节点 6 节点 7 节点 8 节点 9 节点 10 1 800 2 800 800 3 800 800 800 4 330 800 800 350 5 320 770 730 360 800 6 330 800 800 360 800 800 7 320 800 800 350 330 780 300 8 380 800 400 340 320 800 300 300 9 340 800 360 380 330 280 320 270 620 10 340 350 350 380 330 290 330 270 670 350 上表所示是在青云北京 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

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）

测试编号节点 1 节点 2 节点 3 节点 4 节点 5 节点 6 节点 7 节点 8 节点 9 节点 10 节点 11 节点 12 节点 13 节点 14 1 175 175 2 175 175 175 170 3 175 175 170 175 175 165 4 170 165 165 175 165 175 165 165 5 175 175 175 175 175 165 165 165 6 175 175 175 130 175 180 170 160 165 170 180 7 175 175 165 180 190 175 185 155 150 190 170 190 190 150 上表所示是在 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 的规模较大（相对于青云而言），其网络资源总量足以消化小规模测试所产生的网络流量。

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

测试编号节点 1 节点 2 节点 3 节点 4 节点 5 节点 6 节点 7 节点 8 节点 9 节点 10 1 280 2 280 260 3 200 260 240 4 200 250 210 220 5 200 230 250 200 200 6 200 200 210 230 160 180 7 140 220 140 140 140 170 140 8 140 190 140 140 140 140 140 180 9 140 180 140 140 140 140 140 140 140 10 120 160 120 120 120 140 140 140 140 120 上表所示是在 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 方面的鼓励下，作者选择以真实的身份发布这些的数据和观点，希望能够对国内云计算从业人员有所帮助。

参考文献

工业和信息化部电信研究院（中国信通院，CAICT），《云计算白皮书（2014 年）》，2014 年 5 月
中国电子信息产业发展研究院工业和信息化部赛迪智库，《云计算发展白皮书（2015 版）》，2015 年 4 月
工业和信息化部电信研究院（中国信通院，CAICT），《云计算白皮书（2016 年）》，2016 年 9 月
Peter Mell and Timothy Grance, “ The NIST Definition of Cloud Computing ”, NIST Special Publication 800-145, September 2011
William Stanley Jevons, “ The Coal Question ”, 1866
蒋清野，《虚拟化、云计算、开放源代码及其他》，2012 年 10 月
蒋清野，《从王博士说起》，2013 年 12 月
蒋清野，《浅谈“中国”语境下的公有云发展》，2015 年 5 月
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
章文嵩，《淘宝软件基础设施构建实践》，第三届中国云计算大会，2011 年 5 月
高山渊，《阿里巴巴系统运维实践分享》，QClub 深圳站，2012 年 6 月
Netcraft, “ Aliyun cloud growth makes Alibaba largest hosting company in China ”, May 2015
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
Reynold Xin, Parviz Deyhim, Ali Ghodsi, Xiangrui Meng, Matei Zaharia, “ GraySort on Apache Spark by Databricks “, Databricks Inc., October 2014
Michael Conley, Amin Vahdat, George Porter, “ TritonSort 2014 “, University of California at San Diego, 2014
Intel Xeon E5-2630 基准测试数据
Intel Xeon E5-2650 基准测试数据
Intel Xeon E5-2670 基准测试数据
Thomas Graves, “ GraySort and MinuteSort at Yahoo on Hadoop 0.23 “, Yahoo!, May 2013
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.
华为集团，《华为服务器助力腾讯构建十万级高效部署》，2014 年 7 月
陈海泉，《下一代超大规模软件定义网络技术实践》，2016 年 1 月
高旭磊，《招商银行关于金融云的思考》，中国金融电脑，2016 年 8 月
阿里云，《阿里云生态路线图》，2015 年 7 月