​新版CloudFoundry揭秘

原文链接：http://qing.weibo.com/2294942122/88ca09aa33001753.html

原文作者：EMC中国研究院 颜开

 

 

　　CloudFoundry距离发布已经一年多了。在这一年里CloudFoundry不论是社区还是代码日臻成熟，拥有了众多合作伙伴。现在他迈开了更大的脚步，新的CloudFoundry已经逐渐浮出水面。

 

 

　　新版的CloudFoundry对于开发者来说，除了可以支持给多的Framework，提供更多类型的Service之外，没有太多变化。但是CloudFoundry本身的架构做了很多改进，可靠性，扩展性和安全性都有了质的提升，而所有的一切都发生在背后。

 

一、新的功能

　　CloudFoundry提供了一些开发者们期冀的新功能。

 

　　可以和Service直接通信的Tunnel。作为开发者的我们往往希望可以使用客户端工具直接连接到DB上调试。但是在CloudFoundry将DB作为Service隐藏在背后，这样可以提供了诸多方便服务，却让我们无法直接连接到DB。CloudFoundry已经解决了这个问题，可以使用vmctunnel工具，直接访问云后的服务。

　　遗留系统的接入支持。如果你有自己的DB或者已经有一个遗留系统不想让CloudFoundry托管，但是又想获得CloudFoundry的PaaS服务。现在有了一个完善的解决方案。开发者可以将DB或者遗漏系统包装成一个Service。然后可以在CloudFoundry中注册，这样就可以自由的访问了。

　　更多的Framework支持。CloudFoundry之前已经支持很多的框架。有Spring forJava, Rails and Sinatra for Ruby, and Node.js。现在CloudFoundry将支持更多的Framework。有

　　o－>  Java平台

　　　>  Grails模仿Rails的Java平台实现

　　　> Java_web 普通Java web程序

　　　>  Lift基于Scale的web框架

　　　>  Spring 流行的Java框架

　　o－>  Ruby平台

　　　>  Rack  最小化的Ruby Web框架

　　　>  Rails3 一站式的Ruby Web框架

　　　>  Sinatra 极简主义的Ruby Web框架

　　o－>  Python平台

　　　>  Django 最流行的PythonWeb框架

　　　>  Wsgi Python的CGI

　　o－>   其他平台

　　　>  Static page 静态页面

　　　>   node.js 异步Web框架

　　　>  Erlang

　　　>  php

　　　>  standalone 独立的程序

　　随着时间的推移，支持的框架将越来越多。你也可以自定义自己的框架，只需要实现不多的代码。其中Standalone是比较特殊的。开发者的程序只要能启动并监听一个端口，就可以作为一个程序运行在CloudFoundry上。提供了非常大的灵活性。

 　　更多的Service支持。除了更多的框架 支持，CloudFoundry增加了更多的服务。现在除了支持MySQL, MongoDB和 Redis外。还支持很多服务。

　　×－>   DB

　　　－  Mongodb 最流行的Nosql数据库

　　　－  Mysql传统开源关系数据库

　　　－  Neo4j图数据库

　　　－  Postgresql Mysql的有力竞争者

　　　－  Redis极快的内存KV数据库

　　×－>  存储

　　　－  Atmos EMC专业存储

　　　－ FileSystem 远程NFS支持

　　　－  Vblob 提供Amazon S3支持

　　×－>  其他

　　　－  RabbitMQ 出色的Erlang队列系统

　　现在服务逐渐完善，覆盖主流的数据库和存储。也可以通过上文提到的ServiceBroker来接入任何一个外部服务。没有做不到，只有想不到。

 

 

 

上面主要是将新的CloudFounry多了些什么。事实上，新的版本80%的工作在于对基础架构的改进。下面仔细阐述，CloudFoundry做了什么让他的架构更可靠。如果不熟悉前代的架构的话，可以参见《深入Cloud Foundry》

 

 二、ROUTER

 　　上个版本中。Router作为一个nginx脚本存在。所以的请求都必须经过Ruby代码，然后加以转发。这个设计干净利落，不过Ruby也因此转发了大量的数据，容易引起性能问题，所以下个版本中做了如下的改进。

 

 

 

　　在新版本的设计中，他们使用Lua脚本来代替原先的Ruby脚本。而Lua脚本会对请求加以分析，转发给Ruby程序，然后Ruby程序再将分析的结果返回。这样一来，proxied request已经不再经过Ruby代码。逻辑和数据完美分离。性能和稳定性都大幅提高了。

　　在前版设计中，当Router接收到请求后，会随机分配一个Droplet来处理这个请求，这种方式使得用户没有办法使用Session，因为连续的HTTP请求会被分发到不同的应用实例上处理。新版本设计中增加了对SESSION的支持，当Router发现用户的请求中带了cookie信息，它会在Cookie里暗藏一个Droplet的host,port地址。当有新的请求进来，Router通过解析Cookie得到上次的应用实例，然后尽量转发到同一台Droplet上。

 

三、STAGE

　　下面的新版CloudFoundry的架构图。

 

 

 

　　可以看到在新的CloudFoundry架构中多出了很多组件。新架构中将用户验证从Controller中剥离，提供更好的验证服务。同时多出了一个单独Stager。

　　在原有的架构中，用户上传代码后，Cloud Control会将这部分代码结合CloudFoundry打包成DEA可以运行的格式，并上传到一个NFS中，当DEA启动的时候，会从NFS取到需要相应的包，然后再运行。

　　由于打包(Stage)的过程，比较复杂还需要操作大量的文件，需要的时间比较长，单薄的CloudController不堪重负，所以将其移出，成为一个单独的进程。每当CloudController需要打包的时候，就会向Stage队列中发送一个请求，Stage收到请求后，逐个处理之。

　　众所周知，不管是Java,Python还是Ruby程序都会有一系列的依赖，例如Ruby的Gem。每次打包的时候，都需要下载很多Gem，这是费时费力不讨好的。所以开发了PackageCache模块来缓存常用的依赖包。这样的话，打包的过程会顺畅很多。

　　原先性能问题算是解决了。但CloudFoundry还是个注重高可用的系统，按照原先的设计，存放运行包的NFS是一处单点，一旦Crash，整个CloudFoundry的部署功能都将瘫痪。这是不能容忍的，而且越来越大的规模，一台机器迟早无法容纳全部的运行包。所以使用了BlobStore模块，来替代原先的NFS，提供高可用可扩展的存储服务。

 

四、SERVICE BROKER

　　Service Broker可以让Cloudfoundry轻松的支持遗留系统或者不愿意让CloudFoundry托管的系统。他究竟是如何操作的呢？

 

 

 

　　首先，我们必须准备好系统,例如postgress。我们配置好程序和防火墙，让CloudFoundry能通过类似 

postgres://xyzhr:[e-mail]:5432/xyz_hr_db 的URL来访问到服务。

　　然后，调用create service，系统会在ServiceBroker中记录你的配置信息。这样就算大功告成了。Bind和其他的过程都有ServiceBroker完成，其实仅仅就是记录信息，没有实际操作。使用这个新的Service的时候和使用CloudFoundry的内部Service没有两样，配置参数都会通过环境变量传入。所以当App访问Service的时候，就与ServiceBroker无关了。

 

 五、DEA

　　DEA是App的运行环境，全称是DropletExecution Agent。一台虚拟机上会运行一个或多个DEA。一个DEA可以启动多个App(又称Droplet)。所以我们大家的App都会由DEA启动并管理。

 

 

 

　　当CloudFoundry刚刚推出的时候， Droplet包含了应用运行时启动，停止等简单命令。用户应用可以随意访问文件系统，也可以在内网畅通无阻，跑满CPU，占尽内存，写满磁盘。你一切可以想到的破坏性操作都可以做到，太可怕了。CloudFoundry显然不会放任这样的情况太久，现在他们开发出了Warden，一个程序运行容器。这个容器提供了一个孤立的环境，Droplet只可以获得受限的CPU,内存，磁盘访问权限，网络权限，再没有办法搞破坏了。

　　Warden在Linux上的实现是将Linux 内核的资源分成若干个namespace加以区分，底层的机制是CGROUP。这样的设计比虚拟机性能好，启动快，也能够获得足够的安全性。在网络方面，每一个Warden实例有一个虚拟网络接口，每个接口有一个IP，而DEA内有一个子网，这些网络接口就连在这个子网上。安全可以通过iptables来保证。在磁盘方面，每个warden实例有一个自己的filesystem。这些filesystem使用aufs实现的。Aufs可以共享warden之间的只读内容，区分只写的内容，提高了磁盘空间的利用率。因为aufs只能在固定大小的文件上读写，所以磁盘也没有出现写满的可能性。

　　LXC是另一个Linux Container。那为什么不使用它，而开发了Warden呢。因为LXC的实现是和Linux绑死的，CloudFoundry希望warden能运转在各个不同的平台，而不只是Linux。另外Warden提供了一个Daemon和若干Api来操作，LXC提供的是系统工具。还有最重要的一点是LXC过于庞大，Warden只需要其中的一点点功能就可以了，更少的代码便于调试。

 

 六、结语

　　至此，我们已经全面的浏览了CloudFoundry的新功能，新设计。云计算的大潮浩浩汤汤，CloudFoundry作为第一个开源的PaaS平台日臻成熟，实用。但未来还会有更多更好设计等着我们发现，届时我们再一起分享。