IaaS层经历了多年的发展，这里也只能以我自己所经历的来进行回顾，之所以要回顾，是为了通过过去的发展，来看这个领域发展的动力，从而更好的创新，引领未来。

物理机->虚拟化阶段

阿里大概是在2010年开始用Xen来做虚拟化，推动这件事的是另外一位同学，问了下他，当时推进这件事最大的动力是两个，一是资源管理方式，在虚拟化前，都是直接用物理机，物理机的规格会不同，这会导致在LB上配置起来非常麻烦（我印象中记得以前我们在LB上开启权重，导致了一次严重故障，后来就不太敢用了），另一个是成本，站在外围，我看到的最主要是成本，不过说实话，以当年阿里的机器规模而言，尽管通过虚拟化把1台物理机虚拟成3个虚拟机，节省的机器比例看起来是非常高的，但由于盘子就这么大，所以这点成本在当时很难成为推进演进的关键因素，但资源管理方式那个确实是个推动的非常好的动力，因为那个是会影响稳定性的。

这件事我印象中当时的推进还是比较顺利的，主要的原因应该还是虚拟机和物理机还是非常像的，当时因为虚拟化这件事推进，我还写了淘宝当时比较统一的一版Java应用启动参数，后来在进展了可能两年后，阿里尝试把Xen换成KVM，但当时上线碰到了些问题，后来就没去尝试了，直到后来阿里云做虚拟化，阿里在虚拟化的技术掌控能力才真正的开始变得非常深入。

这个阶段的演进动力主要是为了更好的屏蔽机型不同，资源归一化，次要的是成本，现在的云用虚拟化最主要的还是为了提供多种类型的资源规格。

虚拟化->容器化阶段

2011年，我看了《Web容量规划的艺术》这本书后，觉得运行成本对于一家公司是非常重要的，从自己的技术角度来看，降低机器数是一个有效的方法，于是就去想有什么办法可以降低机器总数，找人拿了机器的一些数据后，看到机器的整体利用率是非常低的，于是想既然一虚三利用率还很低，那能不能在一台机器上跑更多呢，了解了下，如果用虚拟化的方法的话，内存超卖不好弄，所以就得找另外的办法。

和多隆说了这个想法后，多隆也很感兴趣，于是就来摸索有什么办法，最早的时候尝试了直接在物理机上跑多个业务进程，结果碰到了各种冲突的问题，例如典型的监听端口冲突，更麻烦的是运维，因为出问题了，不知道哪个应用，查起来特别麻烦，于是觉得直接跑进程不行，还得有一定的隔离性，这个时候尝试了各种黑科技，例如自己改sshd、各种命令行对应的背后的函数，确保可见的隔离性，但这个方法的最大问题是无法穷举，所以总是有各种问题。

突然有一天多隆和我说有个叫Linux Containers（LXC）的东西，好像可以很好的满足需求，于是开始试验，基于LXC包装了我们自己的代号叫T4的容器，我们把这个东西改造的和虚拟机特别像，对于用户来说登录到T4的容器，所有的感受和虚拟机几乎是一样的，这个方案从落地执行角度来说就比较好推进了，毕竟对用户来说几乎是无感的，并且到了2012年，机器资源的申请也变的比较紧张，T4可以用更少的物理机提供更多的“虚拟化”资源，比较受用户的欢迎，到了2013年，交易的核心业务开始切换到T4后，后面的推进就越来越快了，于是阿里就此迈进了IaaS层主体是容器化的时代。

这个阶段的演进动力主要是对规模化后成本控制诉求的预判。

容器化阶段->容器+Docker镜像阶段

2015年，Docker火爆，我们也开始尝试将Docker的镜像+T4的容器进行结合，在这个尝试的过程中，我们切实的感受到了容器+镜像化给运维带来的巨大改变和帮助，这里要多说几句，当时我们对Docker的镜像机制能带来多大帮助一直存有质疑，争论非常大，所以从这件事来看很多东西还是得试试才知道，对于应用而言，在没有把容器+镜像结合起来以前，部署方式通常都是先申请机器资源，然后在机器资源里部署应用，但应用由于有各种语言、架构，所以部署的方式通常会有很大的区别，这个时候对运维类型的系统就非常复杂了，但容器+镜像这种方式使得交付应用这个过程标准化，把交付的这个概念从分离的机器资源到应用部署这两个过程合并了，这对实际业务而言才是更加合理的，有了容器+镜像这种方式后，运维的变更就可以用一套统一的运维平台来标准化了，当然，这也不是Docker首创的，Google家很早前就是这样，但可惜Google当年没开源，导致镜像的标准化现在基本是Docker的格式。

容器+镜像这种站在交付的最终产物诉求的思想延伸到了后来接下去的一些产品的进一步创新中，例如Terraform、Helm等。

这个阶段的演进动力主要是更好的满足交付物的诉求，而这种的结果就是在下层的东西会越来越不可见。

容器+Docker镜像阶段->统一调度阶段

这几年阿里除了在继续推进容器+镜像化（这个产物已经开源：PouchContainer）外，另外一个很大的演进是推进统一调度，推进这个的诉求主要是成本，容器化后可以看到机器上就算能运行更多的容器，但成本下降的还是不够，因此继续进一步看，非常显然的问题还是资源利用率不够高，在做T4的阶段，就听说了Google的Borg，Borg最重要的是通过把资源都归拢在一个池里，并且通过在线任务和离线任务部署在同一台机器（混部）上来大幅提升资源利用率，统一调度可以用一个非常简单的指标去评估做的怎么样，就是平均的资源利用率，Google家大概应该在50%，阿里目前开启了混部的集群一个月下来的CPU平均利用率大概在40%上下，这个阶段的方向是非常清楚的，但要做到这样的程度，对基础设施、内核的改进、调度系统的建设都有很高的要求。

这个阶段的演进动力主要是成本的诉求。

IaaS的Next

以上的各个阶段的演进的具体技术细节在阿里系统软件的公众号里都有分享，感兴趣的同学们可以去找找看。

回顾上面几个阶段的发展，我们能够看到，IaaS的发展/创新主要有两个非常明显的点：

1. 成本

   IaaS层随着规模的不断增大，成本的优化动力会越来越大，从目前的状况来看，怎么更好的优化资源利用率仍然是IaaS层技术创新的核心动力，这个对于云厂商而言，一方面是优化自己的利用率，另一方面是给用户更好的提升资源利用率的产品；软硬件结合也是目前看到的另外一条很好的路径。

2. 被屏蔽

   从物理机->Xen/KVM->容器->K8S/Terraform/Helm，可以看到非常明显的趋势是IaaS越来越被标准化接口屏蔽，未来上层会越来越不关心IaaS的这个具体的运行单位是什么（但始终会需要安全、资源的隔离性，至少是可见的隔离，以及越来越强调的启动速度），从目前的状况来看呢，具体的运行单位在3-5年内应该还会是容器，但容器下面是什么就出现了非常大的优化机会，从硬件，到虚拟化，到操作系统，这两年无论是Google，还是AWS，都已经开始展现了下面这几层的优化创新（gVisor、Firecracker等），但现在并没有霸主出现，这种机会就像是虚拟化刚诞生的阶段，是多年才能一遇的。

按照这样的创新路线下去，技术门槛太高，未来IaaS这层大部分企业都没有能力自己做，不像以前弄个Xen或者KVM，大家差距就很小，以后还是直接用云就好了，毕竟人才也多数会被这些公司垄断掉，云的公司一定会在IaaS这层继续加速演进，并且由于动力大，我相信会比前面很多年IaaS层的技术演进速度快非常多，对云类型的公司而言，比拼对IaaS层方向的掌控力会至关重要，我的建议是围绕在优化资源利用率、软硬件结合、从成本/启动速度等角度思考彻底重写容器下的各层三大方向来进行IaaS的优化和创新，当然，其实方向很多人都能看到，但是否能坚定的在方向上走下去最终会成为分水岭，这也同样意味着方向的判断就非常重要了，毕竟技术的创新不像业务模式，它需要更长的时间。

最后用一张图总结上面所写的：

欢迎关注我的公众号hellojavacases，

聊聊编程能力的高级进阶，

聊聊系统设计，

聊聊技术方向，

聊聊职业生涯的发展。