Posts Tagged ‘ open source

开源云计算技术初探

云计算的大潮向我们奔涌而来。而国内的云计算却是乌云一片,搞云计算的多数是骗子,政客,核心学者,偶尔几个技术人有点儿实际研究也敝帚自珍,奉之如圭臬,搞点神秘主义,喜欢被别人崇拜,但又不喜欢与人分享。我是实在看不惯的,而且那些藏着掖着的技术多半不怎么样。这让我想起一个故事,我的很多同学还在航天系统服务,有次聚会他感慨:“我终于知道我们国家为啥要保密了,因为怕被美国人知道我们有多落后。”作为强烈的对比我们看看美帝的云计算,尤其是开源的云计算都已经有了哪些成熟的成果,有什么东西我们是可以轻而易举地借鉴的。

首先我们来看看云计算的三个层次:IaaS,PaaS,SaaS。其中SaaS比较特殊,因为你总不能做出的应用也和别人一模一样吧,除非你是企鹅公司,否则多多少少还是会不太一样的,所以构建完全一样的SaaS是没有意义的,但是可以通过很多有意义的组件快速地搭建你的SaaS,也就是应用。至于各种各样的组件,我想这已经是老生常谈了,毫无新意,也就不说了。那么这里我们就详细说说PaaS和IaaS吧。

IaaS

先说IaaS吧,这个可能对初学者比较好理解,就是可以按照需求弹性地提供计算和存储资源(狭义地讲:内存资源),比如EC2。很长时间除了Amazon提供的服务,我们别无选择。自然很多厂商是不甘心的,其中就有Rackspace,于是乎经过苦心寻找终于锁定了openstack。这个项目最早由NASA发起的,现在已经有很多公司入伙了,包括Citrix Systems, Dell, AMD, Intel, Canonical, SUSE Linux, HP, and Cisco等。发展势头正旺。想看更多的openstack内容请移步这里

openstack的官方网站在这里

当然openstack也有一个严重的问题,就是目前还不是很成熟,主要表现在部署很麻烦。这样就有了devstack,一个专门用于部署的脚本。让部署的工作轻松不少。openstack也有竞争对手的,比较有名的就是Eucalyptus官方网站在这里。不过相比于openstack的火爆,Eucalyptus真是门可罗雀。另外还有两种NimbusOpenNebula也有自己的特色,大家可以在选型时酌情参考。

当所有人都把目光聚集在Linux时,一个被人遗忘的骑士发出了他的吼声。这个贵族就是solaris,没错你没看错就是那个被oracle收购去的的solaris。个人觉得sun在被收购前做得最有意义的事儿就是做了open solaris,最大的遗憾就是没有开放sun studio,也就是sun的编译工具。当大家都热捧linux的时候不要忘了solaris的很多特性正是云计算尤其是多租环境特别需要的。在oracle无耻地绞杀了open solaris后,很多衍生版本应运而生,其中最著名的要算Illumos了,而Node.js背后的公司Joyent更是在其基础上发扬光大,加入了KVM支持,推出了SmartOS。SmartOS集各种武器于一身,在硬件虚拟化,操作系统虚拟化,安全存储和全面调试等方面都有很强的优势。

PaaS

下面讲讲PaaS。额外说一句为啥node会火呢,我发现所有开源的PaaS都支持Node。

Cloud Foundry

从前大家都认为VPS提供服务就可以了,至于怎么做的大可以不必告诉用户。这种思路貌似也延伸到了做PaaS上,当然不得不承认很多用户并不想知道PaaS究竟是什么,也不想知道机理,只不过想用而已。这也说明了目前处在第一阶段,先要满足用户的功能需求。但是对以PaaS为生的企业来说,往往情形就不那么简单了,是将PaaS作为服务还是将其作为平台,在商业模式上可是很不一样的啊。很多人都对服务和平台之间的区别不是很清楚。国内目前的环境也更是如此,比如国内很多微博产品,还是停留在做服务的简单路线上,缺少纵向合作,不能形成有力的产业上下游,虽然口口声声说是开放平台,但开不开放不是自己标榜的,而是开发者说的。这里要说的是,做PaaS,更要做成平台才有未来,要能集成各种第三方服务,想尽一切办法让开发者降低成本,还能让第三方服务提供商获得利益。这里我就不特别细说平台模式的细节了,感兴趣的同学可以买一本《商业模式新生代》自己研究一下。

显然,一大批云计算业界的翘楚认识到这一点了。你看Salesforce旗下的heroku.com对如何做平台的思路非常清晰,路线明确。真是不看不知道,一看吓一跳。恍然间大悟,原来PaaS还可以这么玩。恍然大悟的不止我一个,VMware也在冥思苦想,作为业界虚拟化技术的霸主,怎能对PaaS不闻不问呢。平台构建好以后,后进者的门槛是非常高的,例如没有后进者可以撼动纽约证券交易所的地位,那么怎么开始呢?VMware想到了开源,以争取更多的开发者支持。当然借助VMware强大的资金支持,这个开源的PaaS一定会成为PaaS的一支重要的力量,尤其是构建私有云的环境中。

Cloud Foundry推出的时机非常好,对比较潮流的几个技术有内置的支持,比如Redis,MongoDB,RabbitMQ,MySQL,PostgeSQL。这些东东无异是现代互联网应用的必要组件,很难想象什么应用能够完全避开上述所有产品。同时CF对Java,Ruby,Node.js都有原生支持,对Python和PHP也有合作支持,这些都是它的优势。但从目前来看CF的缺点也是非常明显的。显然VMware对于如何做好社区产品是缺乏经验的,集市不是大教堂,很多做法是不一样的。开源和开放也不完全是同义词,缺少对应用开发者的真正理解是CF的头等硬伤。相比于Heroku的整体体验,CF太繁琐太重型了,那种复杂的企业级的思路用在做PaaS上,开发者买不买账还得时间来检验。不过什么东西都自己搞一套,最后吃亏的总是自己。想当年微软自己搞得版本控制系统,最后还不得放弃掉,集成了第三方的版本控制系统。CF目前有这种趋势,明显对于社区的一些PaaS理念置若罔闻,很多地方非常难用。

难用归难用,CF在设计上还是值得学习的,从VMware选用Ruby作为Cloud Foundry的主要开发语言,我觉得应该作为一个信号。Ruby的确是云时代的语言,这点下面会继续说。有个开源的PaaS可以学习,总归是件非常不错的事儿。Cloud Foundry也是业界的一个起点,其标志性的意义也非常重大。在此之后,很多PaaS项目都开放了源码。

Haibu

很多人看到这个名字都会感到非常陌生。不过它的东家nodejitsu在Node.js圈子里可是举足轻重的一家。Joyent虽然掌控着Node.js,但似乎并没有开源其Node PaaS的想法(或许真的没有PaaS也说不定),而nodejitsu则提供了很好的Node PaaS,不但能在Joyent的云上部署,也可以在EC2,Rackspace之类的地方部署。总的来说,Haibu的设计更加社区化,模块之间独立性更高。有很多组件被广泛用于其他项目。同时也使用了很多其他的开源组件,这点和Cloud Foundry完全不同,后者甚至连消息传递都是自己实现的一套。Haibu的代码不是很多,不用说基本上都是Node代码,所以有心的话,看一遍应该不是很困难。

当然haibu的缺点也是比较明显的。仅就只支持一种语言来说就不那么让人欢心鼓舞了。不过谁知道今后Node.js会不会成为诸如awk这样的经典之作呢?所以只做好一件事情也算符合KISS原则。至于对于其他相应的第三方组件,貌似不用担心,全交给Node.js本身去考虑了。但这些组件能不能有效的云化,能不能结合得好,只有使用者自己心里清楚了。所以说,haibu这种着眼点比较小的项目需要的是喜欢自己折腾的文艺青年,估计普通青年不会太喜欢。

Nodester

这是一个看上去不起眼的项目。但是我却越看越觉得十分有趣。个人感觉他们充分学习了heroku的精华,这点非常重要。可能有的朋友会说,为什么不学Google App Engine,我只能说,在玩PaaS这个领域,Google真的是有点烂泥扶不上墙的感觉。项目维护得非常活跃,也是学习PaaS的好材料。至少国内的几家觊觎PaaS的公司应该好好学学,说句真心话,你们目前做得PaaS或者严格讲叫做伪PaaS真心叫人反胃。个人觉得问人要钱的底线是提供一些比免费更好的产品或者服务,所以有了这些免费的产品应该大幅提高自身的质量,否则死的会很惨。历史上做编译器的故事大家可以自己找找,觉得和今天的一些事情非常类似。

彻底的RESTful设计,虽说只用到REST的第二层(关于哪一层,详见《REST实战》),但不得不说有这种想法的人设计的API就是令人赏心悦目。学习云时代的API设计的话,这个应该是一个不错的范本。PaaS的本质不就是把运维专业化,从而彻底分离,降低开发和运维的依赖性,从而使得运维专业化,甚至独立出来形成专门的公司。此处省略马克思关于分工合作的论述数千字。这种解耦的核心看点就在于接口的设计啊,所以各位看官,一定要好好留意这个REST。我知道这不是他们首创,也不是他们最先鼓吹的,但若是和我们自己的设计相比有优点就该学习嘛。

 

周边开源技术

puppet

这是一项现在很火的技术啦。管理大规模服务器的首选。国内很多同学管理server farm时都很挫的。有人用SecureCRT复制击键,有的人用bash写个循环。如果还这么个方式做云计算的话,恐怕会死得很惨的。云计算将一些原有的软件过程分工细化出来,其存在的意义无非是成本比原来要低。万事归一都在一个钱字上面,说什么功能,说什么服务,说什么扩展性,说白了都是因为成本。问问EC2的使用者为什么要用EC2,说来说去无非就是便宜。原来这种“非研发”成本不被人注意,主要是因为“研发”的浪费太多了,所以处在一个不引人注意的位置。现在到了第二个阶段,大家发现这部分还是挺混乱挺浪费钱的,于是就有了各种各样的方法。

其实在puppet之前还有一个类似的管理工具叫做cfengine,国内用的很少。因为这个东西配置起来比较麻烦,而且像我刚才说的,那时候很多人还没有意识到管理很多机器是个麻烦的事情。这些软件的目的就是让机器管理轻松一点儿,随着这些工具的出现,一些对运维层面深入的思考也不断涌现。其中有几条精华得以在各个工具中有所体现:

  • 故障是常态的,包括各个层面,硬盘的,内存的,整机的,网络的无所不包。
  • 迁移和部署应该是容易的
  • 机器的角色是动态调整的
  • 自动化的,完全自动化的
后来的一些思潮,比如Infrastructure as Code等等都是对这些理念的总结和提高。puppet是Ruby写的,相对于cfengine,性能不高。但这里的场景和Could Foundry一样,真正的问题是我们需要那么高的性能么。cfengine有着非常令人讨厌的语法,尽管其作者的文档能力十分彪悍,甚至还出版过专著,但cfengine依然很难用。puppet在概念上要好很多,据说算是cfengine的直接继承人,所以算是第二代。
统领一群机器不容易,想要高效统领就更困难了,如何用计算机解决一个貌似管理的问题十分有趣,看puppet代码一定要带着这一目的,要思考的是这么设计背后的原因。

chef

这个东西号称是第三代,也就是puppet的下一代,但是目前还不是很成熟。其借鉴了很多puppet成熟的思路,又有很多创新。比如配方(菜谱)的概念,比如配方托管的云化管理思路都是非常值得学习和借鉴的。但目前来看,还处于一个上升期,社区不如puppet那么强大,支持机器的种类也不如puppet那么多。而且puppet也学习很多他的理念,所以今后一段时间二者的相互争辉还是有的看的。

Lustre

哦,这是一个超级文件系统,全世界最牛的500强超级计算机有很多都是用的这个文件系统,开源的,对于学习文件系统还是挺有帮助的。这里我又要免不了八卦一下。这个技术本来是CMU的一个牛人做的,后来成立了公司,借着被sun收购。哎,后面的事儿你们都知道了。不过,当初sun的想法是将其精华融入ZFS,具体融合的怎样,还得进一步考证。不过在sun手里的这些年倒是挺发扬光大的。要知道美国无论是政府还是军方有好多超算中心,sun最愿意搞这些体现技术牛逼的工程了。但贵族以没落,被暴发户收购了。这项技术命运多舛,放在社区手里,我总觉得不放心。大家若是对存储有兴趣,多留意这个就好了,相对来讲资料非常全。

题外话

Ruby和JavaScript是云时代的主流编程语言,Python紧追,PHP应了那句话了“not even close”。heroku将matz叔挖过去的时候,明确放话Ruby是云时代的语言,heroku的整个工程实践也是按照Ruby的最佳工程实践来做的。另外一块那肯定是JVM平台了,云计算肯定会带来JVM平台的另一轮繁荣。至于.NET,本人毫无研究,就不妄加评论了。

网络虚拟化技术下一步会得到很大的发展。原有在多种操作系统下的独有技术将快速融合,比如DTrace,ZFS移植到Linux,KVM移植到Solaris。以DTrace为首的强大工具将会得到非常大发展,成为各种开源产品的标配,以增强在发杂环境下的调试能力。个人认为未来有经验的DTrace工程师会活得非常滋润,有点供不应求,请联想那么多云,尤其是国内的烂云,少不了要调试的人吧。

云计算红红火火,但繁荣的市场上也到处是骗子无赖,踏踏实实做点事情不容易。个人认为踏踏实实学好云计算的相关技术,比肤浅地开发几个手机应用有意思。国外很多大学也开设了相关的课程,大家可以多多关注。

还有些没有说完的话题今后会在补遗中写写。