甘泉：青云QingCloud 产品 Insight_云资讯

7月28日，以“科技，洞见未来”为主题的青云QingCloud Insight 2016大会在北京国际饭店隆重召开，在28日上午的全体大会上青云QingCloud CTO 甘泉发布了重要的研发成果以及产品。

文章2

青云QingCloud CTO 甘泉

以下是演讲实录：

甘泉： 大家好，非常感谢各位今天来参加大会！没想到会有这么多人。我要特别感谢市场部团队，为了筹备本次会议，他们非常辛苦，谢谢他们。我今天的演讲主题是产品Insight。

青云的公有云从2013年7月正式商用，至今整整三年。在我介绍2015-2016年度的产品之前，先来回顾青云研发团队这三年到底做了哪些事情。

This is a seed, 这是一个云计算的种子。虚拟化是云计算的起点，是最初的形态，也是最简单的形态。青云最初从虚拟化开始，但虚拟化对于青云而言是起点，绝对不是终点。

我们开发第一个产品上线后，除了虚拟化外，附加了几个重要的功能:包括SDN 1.0、SDS 1.0和IaaS API。在当时中国云计算领域，这三个功能都是青云率先提出并加以实现的。SDN的功能是要在公有云上实现网络隔离。SDS是我们第一版的分布式存储系统。IaaS API是用于把资源管理通过可编程的方式提供出来。这三个功能的发布，青云的技术优势在中国云计算市场上取得了一席之地。

2014-2015年度我们做了两方面的事情。一是对青云存储系统的加强。我们发现很难用一种维度，或者单一维度单一产品满足用户对存储的需求。用户对存储的需求是非常多样化，所以我们除了提供性能型硬盘，也提供了容量型硬盘。我们还开发了QingStor对象存储系统、以及NAS和SAN。这是我们对于存储系统的加强。

另一方面，我们开始着手进行应用（Application）方面的建设。这时我们也是摸着石头过河。在我们开发第一个应用MySQL时，一个团队开发了近5个月时间。不能说我们的工程师不努力，他们非常努力，但实际上的效果并不好，但实际上不能怪他们，怪我们的方式有问题。我们开发这一版应用（Application）的时候，是直接在IaaS API上开发。IaaS API是对资源的一种抽象，而直接用资源的抽象去开发Application是非常不合适的，对于Application的接入，门槛非常高。我们从最初一个产品要花5个月时间研发，到目前一个熟练的工程师可以用一个半月开发出一个产品，这在业内属于非常领先的地位。即使如此，我们依然觉得太慢了。如果我们自己的工程师都需要一个半月，我们的合作伙伴怎么办。

所以在今年（2015-2016年度），我们研发上要做的事主要是要贯彻以应用（application）为中心的战略。以应用为中心的战略面对两个主要的问题：一是IaaS到底对于复杂应用的支撑，也就是承载程度是怎样的，够不够强壮。有时候我跟内部的开发人员说，现在青云好像变成云计算市场唯一还在IaaS领域继续探索和追求的公司。我们认为IaaS对上层平台的发展具有至关重要的作用，所以我们矢志不渝，会持续对基础设施进行探索和研究。对于IaaS平台而言，我们引以为傲的SDN 1.0和SDS 1.0在前两年发挥了很重要的作用，对于青云的发展功不可没。但是到第三年，当我们要贯彻以应用中心的发展战略时，发现它确实显得力不从心。问题主要是面对超大规模的复杂应用部署，1.0存在很多瓶颈，之后我会细说瓶颈在哪里（见后面SDN 2.0 及SDS 2.0 详述部分）。所以，我们在不断提高IaaS层的承载能力。从2015年7月开始，我们将IaaS系统几乎重写了一遍。最早重写的是网络系统SDN，后半年重写分布式存储系统SDS。

上面这几部分是如何解决应用接入到青云平台的高门槛问题，也就是我们在不断降低接入门槛。另一方面，我们也改变以前Application直接在IaaS API上进行开发的模式。我们在中间引入了很多的抽象：第一层抽象是PaaS SDK，第二层抽象是AppCenter 2.0。经过这两层抽象后，我们API和接口终于对Application是友好的，接入速度将会变得非常快，后面也会详细介绍。

首先来详细看一下SDN 2.0。在年初发布会上已经做过介绍，它主要解决的核心问题是把传统树状网络变成网状网络。树状网络的问题在于它存在根节点的瓶颈，而网状网络会把所有所谓根节点的瓶颈变成分布式的结构，从而也就不存在单节点的瓶颈。而我们要去应对的问题，是实现超大规模的部署，还有接近物理硬件的虚拟网络性能。另外一点，我们现在的SDN已经可以和网络设备厂商做集成。第一个接入的是Cisco的D9000系列。也就是说我们除了可以跟青云SDN Controller （控制器）进行接驳外，也能跟网络设备厂商的硬件控制器进行接驳。这个在中行已经投入使用了。

下一个是SDS 2.0，是对分布式存储的重写，并不是优化，而是真正的重写。在青云刚发布SDS的时候，SDN的概念非常火。它掩盖了分布式存储的优势和其带给我们青云的价值。我个人认为SDS所带来的价值远远比SDN大得多，因为它在低成本的情况下实现了高I/O，让青云在激烈的云计算市场竞争中能够在夹缝中求生存。有些人总问我说为什么巨头没有像碾死一只蚂蚁一样把我们碾死（有些人总问我面对与巨头激烈的竞争如何应对），我回答可以了解一下青云的分布式存储，它对我们功不可没。虽然如此，在我们三年的实践中也显示出它的弱点。主要的弱点有两个：一方面是性能，毕竟是虚拟化硬盘，虚拟化始终有损耗，在后面讲到容器化实例（Container Instance）的时候，会跟大家细说性能到底差在哪里。

另外一方面是所谓的副本，replication。Replication对于云计算而言非常重要，IaaS层中一个很重要的方面是实现数据的高可用和稳定性。Replication是实现高可用的重要手段。我们在SDS 1.0的时候，我们的高可用和Replication是基于一种静态的关系。这种关系一旦确立是不能更改的，或者更改起来非常麻烦。静态的Replication会带来两个问题，一是我们发现所谓的集群应用（Cluster Software），比如Hadoop或MySQL，他们自己应用本身就已经有Replication。如果应用本身已经有Replication，就不需要IaaS层提供Replication。那么能否帮我去掉？为什么要去掉，一方面没必要有这样的overhead，这也可以成本会相对更便宜。这种场景下用户对副本的需求是零；而在另一类场景下，用户可能不仅仅需要一个副本或者一个数据中心之内的副本，而还需要跨数据中心，有一个远程副本。综合来看，对副本的需求，可能是0、1、2或者3，事情变得非常复杂。也许对一个用户而言，一台主机挂了三块硬盘，而根据数据的重要程度，很可能这三块盘的副本策略都不一样，这是我们在客户那边遇到的十分切实的需求。

我们的SDS 2.0就是为了应对上面这些SDS 1.0做不到的事情。第一点，同时支持虚拟化和非虚拟化硬盘，硬盘不再只是虚拟化一种方式。另外是允许以硬盘为粒度，进行动态复制，每一块硬盘都可以制定独特的副本策略。另外我们还计划实现一点，目前看到可能性很大，就是用全闪存代替机械硬盘。大家一定觉得全闪存一定很贵，但随着我们新技术的应用，这次我们能做到用全闪存代替机械硬盘后，每GB存储售价会维持不变。性能提高很多的同时，价格是不变的，这是技术给我们带来的优势。

NAS／SAN的2.0版本。NAS和SAN我们也是很早就发布了，在1.0时的主要问题是容量不足。从架构图可以很容易看出，它的存储空间是不能突破单台物理机的限制。如果单台物理机最多提供50T，我最多只能分配50T给用户。但是我们经常从客户那里得到的需求是100T甚至是1PB的空间，那么如何满足？我们最初的建议是，好使用分布式存储，把硬盘分散。但很遗憾的是由于很多legacy（遗留）的软件不支持这个模式。也就是说，对于那些软件而言，我需要看到的只是一张盘，一张非常大的盘。我们最后还是选择支持这些legacy的应用。所以在NAS和SAN 2.0时，相对1.0一个非常重要的优势是可以突破单台物理机的限制。NAS支持PB级别的存储空间，SAN支持单块硬盘容量大于100T，当然200T和300T都可以。我们支持全闪存的模式，最后跟网络一样，我们也支持跟存储的设备厂商集成，把传统的存储柜接入青云系统中。

QingStor，我们盼了很久。去年用户大会就已经宣布了，但一直属于Beta版的状态。这几天我们会正式上线1.0。随着QingStor的正式商用，它在青云产品中的位置将会越来越重要，因为它基本是青云各个应用之间进行数据传输的媒介和渠道。它会变成一个总线，像大Bus的一样，会是一个非常重要的服务。另外，我们实现了AWS S3的adaptor，意味着如果以前的存储应用是基于AWS S3开发的话，可以无缝接入青云的对象存储。

Container Instance，相信大家都很感兴趣。这两年容器概念非常火。甚至容器火了之后，大家都在探讨虚拟机是不是死了。我个人不太赞同这样的观点，因为他们的优缺点非常明显，几乎A的优点就是B的缺点，B的优点就是A的缺点，每个都存在硬伤。对于传统虚拟主机（Virtual Instance）而言，它的好处非常明显。它是一种完整的硬件模拟，在上面可以跑任何基于X86或者ARM的操作系统。它的隔离性、安全性非常好，因为它把整个设备全部虚拟出来，用户是在一个被保护的很好的空间里运行程序，相互之间不受干扰。但是它的缺点，性能损耗大，虚拟化一定是有性能损耗。

我在PPT中列了一个表达式（CPU < MEM < NETWORK < DISK），让大家直观的看看损耗的大小。CPU和Memory的损耗其实非常小。网络我觉得青云已经做到了极致，但仍然有20%有损耗。我们的网络能发挥物理网络性能的80%。但是对于硬盘而言，损耗非常大。对于硬盘的损耗，如果放在机械硬盘的时代是不明显的，因为机械硬盘本来就慢。

今年对于云计算而言是闪存的元年，对于像PCIe的闪存或者SSD，损耗就非常大。我们测试了PCIe的闪存，写的IOPS（I/O per second）可以到15万，读的IOPS到50万，这是传统的机械硬盘不可想象。经过虚拟化后，写最多到3万，读最多到10万，这不是优化就能解决的，这与虚拟化技术的实现有非常大的关系。所以，从硬盘的角度而言，对于Virtual Instance，如果我们过渡到全闪存时代，那么性能损耗的问题会变得非常突出。即使是写3万读10万，对很多人来讲也够了。但在某些情况下，像对于私有云的客户，就是要求发挥硬盘的全部性能。

Container Instance就是针对这样的需求提出的一种解决方案，它所有的优点就是Virtual Instance的缺点，它所有的缺点是Virtual Instance的优点。所以我觉得他们之间实际上是一种相互补充的关系，而不是相互替代的关系。对于Container Instance而言，它有物理机的内核依赖，不能运行windows或者对内核有特殊要求的软件，它实际受很强的约束。另外隔离性和安全性差，因为你在跟物理主机共用内核和硬件，这是一件非常让人担心的事情。它的好处也非常明显，不管是网络性能还是存储性能，几乎没有损耗。

从青云的角度来看，我们觉得他对Virtual Instance是一个互补关系，我们可以做到在同一个平台上，Container Instance和Virtual Instance共存。不只是在不同的物理机上共存，在同一台物理机上也可以共存，完全取决于用户希望用什么方式来运行应用程序。同时我们的Container Instance和Virtual Instance(CI 和VI) 会共用同一套底层网络的存储和调度，他们的用法几乎一致。对于用户而言，使用界面不会有差别。

最后一点，我们支持Unikernel，它比较奇怪，它的特点正好介于纯Container Instance和纯Virtual Instance之间，它的性能及功能介于之中间。我觉得也许有些人希望有这样的特性，所以我们也会支持。

据我所知，青云是第一个同时支持以上三种类型的云计算平台。Container Instance对我个人而言有特殊的意义，我在青云工作的这几年总是被人Challenge说，你看我的应用特别的耗性能，我绝对不允许我的应用跑到虚拟化上，虚拟化对于他们而言是一道不可逾越的鸿沟。我希望从今天开始，这种问题将不再是问题，因为我允许你将应用直接跑到物理机上，同时拥有云计算所有优势，何乐而不为呢。

刚才讲的是如何让IaaS层提高承载能力。IaaS对于我们青云而言就像一栋大楼的地基，如果只想盖5层楼的大楼，实际上不需要地基，这是很多人的做法。对于青云而言，我们的目标绝对不是5层楼的小洋房，我们的目标是100层的摩天大楼，所以地基一定要打的扎实。这是我们为什么要花这么多代价，花这么多人力物力投资在基础设施上的原因。

下一步，我们要降低应用（Application）接入青云平台的门槛。首先我们的第一步，是要对IaaS API进行第一层抽象，也就是PaaS SDK。PaaS SDK会简化对IaaS层的访问，同时也是AppCenter访问IaaS API的入口，它处于中间的位置。当然，我们支持图形化的访问和资源编排。资源编排是一个很酷的功能，大家可以尝试一下，可以通过拖拽的方式，把资源的拓扑变成模板，然后再去应用和部署，非常酷。

下面是今天的一个重点－AppCenter 2.0。我简单介绍一下AppCenter 2.0将会做什么？你可以认为我们刚才所做的一切都是为AppCenter 2.0做准备，因为今年的战略是以应用为中心，AppCenter 2.0则是我们应用的主要载体。1.0存在非常多的不足，我们觉得门槛太高。刚才也提到，自己开发人员都需要这么长时间完成研发，让合作伙伴情何以堪。所以在2.0，会将这一过程进行极大的简化。主要是三个开心。一是应用的开发者/提供商要开心，可以方便的接入青云平台，把Application构建完成；二是应用跑着要开心。实际上我知道一些应用中心的做法，哪怕是画一个LOGO link到另一个网站，这也是一种应用中心，当然我不否认这也是一种形态，但不是我们青云的目标。青云承载的应用一定是需要大规模部署，同时需要兼具高性能、高可用的严肃的企业应用，让这些应用在青云的平台上跑的非常开心，这才是我们真正的目标；三是用户用的开心，要能非常容易的使用它，它可以真正给用户带来价值，这才是评判应用中心是否成功的最重要的指标。

AppCenter 2.0会兼容和支持主流开源集群管理框架，包括Docker、Kubernetes、Mesos、Cloud Foundry。这是一个多维度的支持，如果是基于这些进行开发应用，可以以非常低的代价移植到青云的平台上。

在今年，青云平台上可提供的Application会达到100+，希望明年比会有更多。这里有大部分的Application都不是由青云开发，成功的形态应该是大部分由第三方开发，青云会专注于平台建设，而不是应用本身的开发。

Power、VMware。这个私有云用的得比较多，公有云基本上见不着。目前，我们支持在同一个青云标准API基础上支持三种Controller，既支持青云的Controller，也支持Power Controller、VMware Controller。这意味着用同一套API可以管理这三套系统。在我们私有云里，这样的情况会部署比较多。因为在私有云里有很多legacy的系统，有Power系统、VMware 系统，用户同时也想用青云。但用户并不想用三套系统，你能否帮助解决。我觉得现在世界上只有青云才能搞定这个事情。