从技术上看，Container并非近几年的创新，OpenVZ、FreeBSD jails、Solaris Zones等都是Container技术（轻量级虚拟化技术，OS层虚拟化技术）的实现，而Fedora和Mozilla中国的区代表Gerard Braad在接受CSDN采访时进一步扩展了Container的概念：
浏览器的沙箱从资源隔离的角度，以及Java的J2EE Container从标准抽象化的角度，其实跟Container的概念是一致的。
当下，PaaS越来越多的和Container联系在一起，Container的高资源利用率等特性恰恰是PaaS需要的。
Container的优势
程显峰将Container的优势总结为以下四点：
提高计算密度
一个虚机占用的资源比一个Container占用的资源不止多十倍。在一个物理机上开一百个虚机是很困难的，但要实现100多个，甚至几百个Container是很正常的。腾讯在大量使用Container。某大型互联网公司上次升级发行版，主要就是为了使用Cgroups，方便限定资源，以充分利用CPU。要知道有能力维护自己版本内核的公司，做出这样的决定是非常不容易的，可见其好处是巨大的。
大互联网公司非常适合Container，Facebook一台虚机都没有，因为这些互联网公司要求充分利用计算资源。虚机起码还要再跑一个Guest系统，太耗资源。
同时，在这些大公司内部并没有很多操作系统，集群只有一种操作系统，甚至连版本号都是固定的。因此，不需要虚机的异构操作系统特性。
另外，在操作系统上还有Runtime Library，Container不需要重复加载，极大的节省内存占用。
最后，因为公用的资源更多，Container相对来讲更容易超售，实际出售量的和超过了物理机的量
更精细的资源控制
这里以目前最为热门的Linux Container（LXC）为例来说，Linux Container分为两个部分，Cgroups用来做资源限制，Namespace来做资源隔离。最近Linux内核对LXC相关改进非常多，其中3.8版对Namespace新增了user，未来的3.11会加入更好的CRIU支持，使得Container看上去可能更像一个虚拟机。
另外Container在数据库隔离方面也有着自身的优势。云化的数据库通常有两种思路：
第一，建立一个大数据库供所有人使用。但如何做资源隔离和安全隔离呢？SAE通过增加SQL过滤器（CSDN近期将对SAE首席架构师丛磊进行采访，详解SAE的资源隔离策略），将不合理的SQL全部过滤掉。盛大云的MongoDB服务也采用类似的策略，通过判断执行时间来限定不合理的请求。但这种方法存在弊端，首先不能穷举所有不合理的请求，这是一个典型的停机问题，即便是工程上实用的做法，维护巨量的规则库也会让管理员痛不欲生，看看杀毒软件要维护多少特征就知道了。其次需要修改数据库代码，而这些修改目前看不会被社区接受，因为社区认为资源隔离并不是数据库该做的事。
第二，把每个用户的数据库放一个Container里，用Container来做资源限制。不需要对数据库进行修改。每个用户的Container内有自己的数据库，用户之间的资源是完全隔离开的。不过有观点认为每个Container启动一个实例太浪费资源。其实，相同的Runtime并不会重复占用资源，而且还能更好的限制资源，操作简单。目前一些Heroku的第三方插件是用这种方式进行数据库隔离的。OpenShift通过Gear和Cartridges对资源进行隔离，每个应用有自己私有的小数据库。
更短的provisioning时间
虚机的provisioning时间在分钟级，而Container在秒级。设想在淘宝双十一的场景下，虚机需要几分钟时间启动显然太慢了。另外LXC目前还有个非常有趣的技术，叫做systemd，是下一代的启动器，可以极大加快启动速度，并且与LXC结合得十分完美，有些高级功能就是依赖LXC实现的。
这部分还有另外一个非常重要的技术就是文件系统。提高provisioning时间，需要文件系统配合，像ploop、aufs、overlayfs等文件系统都有一些非常有趣的技术可以用在Container的快照、复制等方面。
Container式的PaaS组装更灵活
用户根据自己的需要组装自己的PaaS，我认为这是趋势。不同的模块之间有不同的实现，可以替换。比如你认为Docker对LXC的封装不好，就可以换一个。
Cloud Foundry也开始重视LXC，通过Warden把Container进行封装，但是从技术的角度来讲Cloud Foundry的架构过于大，它想把PaaS所有事都做了，但每一块做得都不怎么好，耦合度又高。比如我想把Warden换成Docker就很难。
Cloud Foundry为代表的PaaS平台倾向做得很重，而像Docker是轻量的框架代表。我认为轻量的平台更好，更有前途，因为更加灵活。PaaS到底该长成什么样去年我还觉得比较清楚，但今年反而觉得变数会非常多，所以我更看好灵活的方案。
Docker项目在Github上发布不到两天，就在Go语言排行榜上排名第一，说明社区很认可。额外说一句Go语言写的PaaS工具非常多，有大放异彩的趋势。而CloudFoundry几乎都是仰仗VMware财大气粗。大家共同参与，项目才有生命力。Cloud Foundry的社区贡献度非常差，大部分都是VMware（Pivotal）自己的工程师贡献。
Container的趋势和挑战
和虚机相比，LXC的隔离做个并不彻底，而包括热迁移的等高级功能也正在完善中。程显峰将LXC的发展趋势和挑战总结为以下四点：
Container获得了更广泛的支持
OpenStack对LXC现在有很强的支持。当OpenStack支持Container了，这会导致该技术在互联网圈子里得到推广。同时，在OpenStack+LXC基础上还会有些创新。
另外，ActiveState Software早就把Cloud Foundry和LXC绑到一起，推出了商业版。
这一阵子比较火的CoreOS、dotCloud、PiCloud等公司都是LXC的坚定支持者，systemd的作者以及OpenVZ的开发团队都齐心协力支持LXC。
VPS就是Container典型的应用场景，基本上全球市场上90%的VPS平台都使用OpenVZ。它是一种Container，但是因为对Container的修改过大，不被社区接受。但OpenVZ的商业版本比LinuxContainer成熟得多，可以支持热迁移。OpenVZ的作者为Linux Container提交了百十多个patch。已经有很多社区的活跃者对LinuxContainer做贡献。
LXC在有些方面与虚机有差距
资源限定和隔离做得并不彻底，比如时间就隔离不了。现在LXC隔离也就几个方面，进程、挂载资源、用户，大概也就六点，实际上还远远不够。
虚机热迁移技术已经非常成熟，而LXC还有差距，也在改进中。据报道，在Linux kernel 3.11中会有很大改善。
调试工具逐步完善
云计算调试是个非常头疼的事情，如果应用跑在虚机里，管理员是很难进行管理的。而Container对操作系统有一些透明性，如process有异常调用，管理员可以看到。
大家为什么不用云计算？大部分人都说部署习惯不一样，调试部署不方便，大家为什么还愿意用虚拟机？虚拟机的调试方式跟他在实体机上调试方式没有任何差异，这种习惯是很难改变的。
Cloud Foundry、SAE、Azure的调试都解决的不彻底。仅仅通过本地模拟器进行调试，并不能解决根本问题。
调试工具近期也会有一些新的突破，语言级别的像Ruby2.0以后加了对DTrace支持。我很看好Dtrace和SystemTap之类的技术的，尤其是在PaaS调试上，大家可以关注一下章亦春、余锋的博客。
PaaS服务依然不够完善
尽管各种PaaS层出不穷，Cloud Foundry、OpenShift、Azure也在不遗余力的打造更易用的PaaS平台，但仍存在各种不足和挑战。无论自建还是使用第三方平台，PaaS还远未成熟。程显峰认为：
PaaS平台没有统一的认识
PaaS到底应该搭成什么样？什么样是成熟的PaaS？现在都没有统一的认识。微软Azure、Heroku以及Cloud Foundry，各家PaaS的边界和内容都不一样。
微软Azure有弹性的数据库、Service Bus。亚马逊也有类似的服务。这些服务到底属于IaaS还是PaaS呢？用户需要的是非常完整的服务，无论对于IaaS还是PaaS都有大量的工作需要去做。所以，现在看PaaS，要想在一个体系下提供服务，我认为是很难的。而Docker这种灵活的方案，只做某一块服务，再组装在一起可能是更好的方式。
从上面说的我们也可以看出，现在的云计算模型已经远远不是三层的IaaS、PaaS、SaaS那么简单的了。很多组件都能作为一个服务呢，这些组件应该放在什么位置呢？实际上这个关系非常复杂，各家都有各家的看法，这些看法随着时间改动也还是很大。我的一个观点是从单个技术上突破做成大家都认可的组件比较容易，总体结构要想达成一致比较难。
国内没有完善的公有云 自建IaaS也很麻烦
PaaS要底层基础资源必须弹性，如果采取自建私有云的方式，很可能需要去搭建OpenStack，工作量非常大。如果植根于公有云，国内没有美国那样成熟的亚马逊、Azure或Rackspace，阿里云的API还不够健全，无法支撑。在国内如果底层资源弹性问题无法解决，PaaS就是空中楼阁。
标准和互操作也是比较头痛的问题。国内互联网公司相互合作不够，对于标准和规范重视程度也远远不够。有人说云就是水电，但问题是水电是高度同质的，目前还没看到哪些云是同质的。国外还有些公司做跨平台云的管理，国内就更难了，这也是做一个公有PaaS的潜在风险。
当然，国内的网络割裂比较严重也是对云计算发展的不利影响。这些都本不该是一个PaaS提供商该考虑的问题，但是我们的国情就要求必须要考虑。
需要坚实的服务支持
PaaS还需要其他服务支撑，比如Cache、负载均衡、数据库、消息队列、日志，这些服务只有全部包含PaaS平台才有价值。当开发者在PaaS上运行了应用，如果还要自己搭建这些服务，然后做HA，这就背离了PaaS的设计初衷。因为，实际上应用并不是运维的重点，重点上面提到的那些周边的服务，这些服务的运维成本很高，而且还不体现开发者的核心价值。
京东做得更好。由于Cloud Foundry的服务并不是云化的，不提供HA。京东需要做云化，自己做了上面所说的基础服务。
展望Cloud Foundry、OpenShift、Azure
Cloud Foundry今年将推出商业版，Azure越来越重视开源社区，变的更加开放，OpenShift继续着云化战略。在采访结束前，程显峰进行了总结：
京东云底层使用了OpenStack + Cloud Foundry，从长远上看仍然会走互联网式的技术路线。也许再晚一个月做决策，京东就会选择OpenShift了，因为从技术角度来讲，OpenShift比CloudFoundry要好一点。
OpenShift代码写的还算规矩，而Cloud Foundry的代码并不是社区的产物，很多地方都不像大公司的作品。我认为但凡是脱离社区单搞一套，从历史上看绝大多数都没好结果。
从我看的一些报告来看，VMware在虚拟化技术上的领先优势已经不明显。微软的平台与VMware看不出明显的差距。毕竟微软有操作系统和大量商用软件，这些技术积累是其他公司很难拥有的。同时微软有自己的商用的公有云Azure，对新技术是很好的试验场，VMware还没运营自己的公有云。
微软现在特别拥抱社区。Azure的命令行客户端已经没啥微软的味道了。微软想明白了，用不用微软技术无所谓，为微软的云付费就可以了。官方支持很多开发语言。微软还单独成立了开放技术公司Microsoft Open Technologies，专门配合社区，这实际上是一个非常大的事业部。
浏览器的沙箱从资源隔离的角度，以及Java的J2EE Container从标准抽象化的角度，其实跟Container的概念是一致的。
当下，PaaS越来越多的和Container联系在一起，Container的高资源利用率等特性恰恰是PaaS需要的。
Container的优势
程显峰将Container的优势总结为以下四点：
提高计算密度
一个虚机占用的资源比一个Container占用的资源不止多十倍。在一个物理机上开一百个虚机是很困难的，但要实现100多个，甚至几百个Container是很正常的。腾讯在大量使用Container。某大型互联网公司上次升级发行版，主要就是为了使用Cgroups，方便限定资源，以充分利用CPU。要知道有能力维护自己版本内核的公司，做出这样的决定是非常不容易的，可见其好处是巨大的。
大互联网公司非常适合Container，Facebook一台虚机都没有，因为这些互联网公司要求充分利用计算资源。虚机起码还要再跑一个Guest系统，太耗资源。
同时，在这些大公司内部并没有很多操作系统，集群只有一种操作系统，甚至连版本号都是固定的。因此，不需要虚机的异构操作系统特性。
另外，在操作系统上还有Runtime Library，Container不需要重复加载，极大的节省内存占用。
最后，因为公用的资源更多，Container相对来讲更容易超售，实际出售量的和超过了物理机的量
更精细的资源控制
这里以目前最为热门的Linux Container（LXC）为例来说，Linux Container分为两个部分，Cgroups用来做资源限制，Namespace来做资源隔离。最近Linux内核对LXC相关改进非常多，其中3.8版对Namespace新增了user，未来的3.11会加入更好的CRIU支持，使得Container看上去可能更像一个虚拟机。
另外Container在数据库隔离方面也有着自身的优势。云化的数据库通常有两种思路：
第一，建立一个大数据库供所有人使用。但如何做资源隔离和安全隔离呢？SAE通过增加SQL过滤器（CSDN近期将对SAE首席架构师丛磊进行采访，详解SAE的资源隔离策略），将不合理的SQL全部过滤掉。盛大云的MongoDB服务也采用类似的策略，通过判断执行时间来限定不合理的请求。但这种方法存在弊端，首先不能穷举所有不合理的请求，这是一个典型的停机问题，即便是工程上实用的做法，维护巨量的规则库也会让管理员痛不欲生，看看杀毒软件要维护多少特征就知道了。其次需要修改数据库代码，而这些修改目前看不会被社区接受，因为社区认为资源隔离并不是数据库该做的事。
第二，把每个用户的数据库放一个Container里，用Container来做资源限制。不需要对数据库进行修改。每个用户的Container内有自己的数据库，用户之间的资源是完全隔离开的。不过有观点认为每个Container启动一个实例太浪费资源。其实，相同的Runtime并不会重复占用资源，而且还能更好的限制资源，操作简单。目前一些Heroku的第三方插件是用这种方式进行数据库隔离的。OpenShift通过Gear和Cartridges对资源进行隔离，每个应用有自己私有的小数据库。
更短的provisioning时间
虚机的provisioning时间在分钟级，而Container在秒级。设想在淘宝双十一的场景下，虚机需要几分钟时间启动显然太慢了。另外LXC目前还有个非常有趣的技术，叫做systemd，是下一代的启动器，可以极大加快启动速度，并且与LXC结合得十分完美，有些高级功能就是依赖LXC实现的。
这部分还有另外一个非常重要的技术就是文件系统。提高provisioning时间，需要文件系统配合，像ploop、aufs、overlayfs等文件系统都有一些非常有趣的技术可以用在Container的快照、复制等方面。
Container式的PaaS组装更灵活
用户根据自己的需要组装自己的PaaS，我认为这是趋势。不同的模块之间有不同的实现，可以替换。比如你认为Docker对LXC的封装不好，就可以换一个。
Cloud Foundry也开始重视LXC，通过Warden把Container进行封装，但是从技术的角度来讲Cloud Foundry的架构过于大，它想把PaaS所有事都做了，但每一块做得都不怎么好，耦合度又高。比如我想把Warden换成Docker就很难。
Cloud Foundry为代表的PaaS平台倾向做得很重，而像Docker是轻量的框架代表。我认为轻量的平台更好，更有前途，因为更加灵活。PaaS到底该长成什么样去年我还觉得比较清楚，但今年反而觉得变数会非常多，所以我更看好灵活的方案。
Docker项目在Github上发布不到两天，就在Go语言排行榜上排名第一，说明社区很认可。额外说一句Go语言写的PaaS工具非常多，有大放异彩的趋势。而CloudFoundry几乎都是仰仗VMware财大气粗。大家共同参与，项目才有生命力。Cloud Foundry的社区贡献度非常差，大部分都是VMware（Pivotal）自己的工程师贡献。
Container的趋势和挑战
和虚机相比，LXC的隔离做个并不彻底，而包括热迁移的等高级功能也正在完善中。程显峰将LXC的发展趋势和挑战总结为以下四点：
Container获得了更广泛的支持
OpenStack对LXC现在有很强的支持。当OpenStack支持Container了，这会导致该技术在互联网圈子里得到推广。同时，在OpenStack+LXC基础上还会有些创新。
另外，ActiveState Software早就把Cloud Foundry和LXC绑到一起，推出了商业版。
这一阵子比较火的CoreOS、dotCloud、PiCloud等公司都是LXC的坚定支持者，systemd的作者以及OpenVZ的开发团队都齐心协力支持LXC。
VPS就是Container典型的应用场景，基本上全球市场上90%的VPS平台都使用OpenVZ。它是一种Container，但是因为对Container的修改过大，不被社区接受。但OpenVZ的商业版本比LinuxContainer成熟得多，可以支持热迁移。OpenVZ的作者为Linux Container提交了百十多个patch。已经有很多社区的活跃者对LinuxContainer做贡献。
LXC在有些方面与虚机有差距
资源限定和隔离做得并不彻底，比如时间就隔离不了。现在LXC隔离也就几个方面，进程、挂载资源、用户，大概也就六点，实际上还远远不够。
虚机热迁移技术已经非常成熟，而LXC还有差距，也在改进中。据报道，在Linux kernel 3.11中会有很大改善。
调试工具逐步完善
云计算调试是个非常头疼的事情，如果应用跑在虚机里，管理员是很难进行管理的。而Container对操作系统有一些透明性，如process有异常调用，管理员可以看到。
大家为什么不用云计算？大部分人都说部署习惯不一样，调试部署不方便，大家为什么还愿意用虚拟机？虚拟机的调试方式跟他在实体机上调试方式没有任何差异，这种习惯是很难改变的。
Cloud Foundry、SAE、Azure的调试都解决的不彻底。仅仅通过本地模拟器进行调试，并不能解决根本问题。
调试工具近期也会有一些新的突破，语言级别的像Ruby2.0以后加了对DTrace支持。我很看好Dtrace和SystemTap之类的技术的，尤其是在PaaS调试上，大家可以关注一下章亦春、余锋的博客。
PaaS服务依然不够完善
尽管各种PaaS层出不穷，Cloud Foundry、OpenShift、Azure也在不遗余力的打造更易用的PaaS平台，但仍存在各种不足和挑战。无论自建还是使用第三方平台，PaaS还远未成熟。程显峰认为：
PaaS平台没有统一的认识
PaaS到底应该搭成什么样？什么样是成熟的PaaS？现在都没有统一的认识。微软Azure、Heroku以及Cloud Foundry，各家PaaS的边界和内容都不一样。
微软Azure有弹性的数据库、Service Bus。亚马逊也有类似的服务。这些服务到底属于IaaS还是PaaS呢？用户需要的是非常完整的服务，无论对于IaaS还是PaaS都有大量的工作需要去做。所以，现在看PaaS，要想在一个体系下提供服务，我认为是很难的。而Docker这种灵活的方案，只做某一块服务，再组装在一起可能是更好的方式。
从上面说的我们也可以看出，现在的云计算模型已经远远不是三层的IaaS、PaaS、SaaS那么简单的了。很多组件都能作为一个服务呢，这些组件应该放在什么位置呢？实际上这个关系非常复杂，各家都有各家的看法，这些看法随着时间改动也还是很大。我的一个观点是从单个技术上突破做成大家都认可的组件比较容易，总体结构要想达成一致比较难。
国内没有完善的公有云 自建IaaS也很麻烦
PaaS要底层基础资源必须弹性，如果采取自建私有云的方式，很可能需要去搭建OpenStack，工作量非常大。如果植根于公有云，国内没有美国那样成熟的亚马逊、Azure或Rackspace，阿里云的API还不够健全，无法支撑。在国内如果底层资源弹性问题无法解决，PaaS就是空中楼阁。
标准和互操作也是比较头痛的问题。国内互联网公司相互合作不够，对于标准和规范重视程度也远远不够。有人说云就是水电，但问题是水电是高度同质的，目前还没看到哪些云是同质的。国外还有些公司做跨平台云的管理，国内就更难了，这也是做一个公有PaaS的潜在风险。
当然，国内的网络割裂比较严重也是对云计算发展的不利影响。这些都本不该是一个PaaS提供商该考虑的问题，但是我们的国情就要求必须要考虑。
需要坚实的服务支持
PaaS还需要其他服务支撑，比如Cache、负载均衡、数据库、消息队列、日志，这些服务只有全部包含PaaS平台才有价值。当开发者在PaaS上运行了应用，如果还要自己搭建这些服务，然后做HA，这就背离了PaaS的设计初衷。因为，实际上应用并不是运维的重点，重点上面提到的那些周边的服务，这些服务的运维成本很高，而且还不体现开发者的核心价值。
京东做得更好。由于Cloud Foundry的服务并不是云化的，不提供HA。京东需要做云化，自己做了上面所说的基础服务。
展望Cloud Foundry、OpenShift、Azure
Cloud Foundry今年将推出商业版，Azure越来越重视开源社区，变的更加开放，OpenShift继续着云化战略。在采访结束前，程显峰进行了总结：
京东云底层使用了OpenStack + Cloud Foundry，从长远上看仍然会走互联网式的技术路线。也许再晚一个月做决策，京东就会选择OpenShift了，因为从技术角度来讲，OpenShift比CloudFoundry要好一点。
OpenShift代码写的还算规矩，而Cloud Foundry的代码并不是社区的产物，很多地方都不像大公司的作品。我认为但凡是脱离社区单搞一套，从历史上看绝大多数都没好结果。
从我看的一些报告来看，VMware在虚拟化技术上的领先优势已经不明显。微软的平台与VMware看不出明显的差距。毕竟微软有操作系统和大量商用软件，这些技术积累是其他公司很难拥有的。同时微软有自己的商用的公有云Azure，对新技术是很好的试验场，VMware还没运营自己的公有云。
微软现在特别拥抱社区。Azure的命令行客户端已经没啥微软的味道了。微软想明白了，用不用微软技术无所谓，为微软的云付费就可以了。官方支持很多开发语言。微软还单独成立了开放技术公司Microsoft Open Technologies，专门配合社区，这实际上是一个非常大的事业部。
回复 (0)
微信扫码 立即评论
