说三道四技术文摘-感悟人生的经典句子
说三道四 > 文档快照

PaaS乱局:Container的新机遇

HTML文档下载 WORD文档下载 PDF文档下载
在中关村丹棱街的某间办公室又见到了程显峰,他是《程序员》杂志的老朋友,2012年专门撰文详细介绍过国内外PaaS平台产品。接下来的一个多小时,程显峰从一个开发者的角度分享了对PaaS和Container技术的看法。

从技术上看,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工具非常多,有大放异彩的趋势。而Cloud Foundry几乎都是仰仗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的商业版本比Linux Container成熟得多,可以支持热迁移。OpenVZ的作者为Linux  Container提交了百十多个patch。已经有很多社区的活跃者对Linux  Container做贡献。

  • 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比Cloud Foundry要好一点。

OpenShift代码写的还算规矩,而Cloud Foundry的代码并不是社区的产物,很多地方都不像大公司的作品。我认为但凡是脱离社区单搞一套,从历史上看绝大多数都没好结果。

从我看的一些报告来看,VMware在虚拟化技术上的领先优势已经不明显。微软的平台与VMware看不出明显的差距。毕竟微软有操作系统和大量商用软件,这些技术积累是其他公司很难拥有的。同时微软有自己的商用的公有云Azure,对新技术是很好的试验场,VMware还没运营自己的公有云。

微软现在特别拥抱社区。Azure的命令行客户端已经没啥微软的味道了。微软想明白了,用不用微软技术无所谓,为微软的云付费就可以了。官方支持很多开发语言。微软还单独 成立了开放技术公司 Microsoft Open Technologies,专门配合社区,这实际上是一个非常大的事业部。(文/ 包研  审校/仲浩)

本文是PaaS/Container系列采访的第一篇,接下来还将发布对丛磊、用友PaaS负责人、Gerard Braad等采访。希望通过对PaaS各方玩家的沟通,勾勒出PaaS的现状和未来。如果你是一名PaaS玩家,可以通过邮件告诉我你的观点。

欢迎关注 @CSDN云计算微博,了解更多云信息。

备案号:鲁ICP备13029499号-2 说三道四 www.s3d4.cn 说三道四技术文摘