上面主要是将新的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:secret@db.xyzcorp.com:5432/xyz_hr_db 的URL来访问到服务。