深入CloudFoundry一周年

篇前语

本文在《程序员》杂志2013年1月刊刊登过，但由于篇幅排版等原因，部份内容被删除。研究院博客这次发表的版本是原稿版。可能文笔措辞有些许粗糙，但希望能给大家带来更详尽的信息。

前言

去年4月份，VMware突然发布了业内第一个开源的PaaS，Cloud Foundry；紧接着5月，Redhat发布了另外一个开源的PaaS，OpenShift。从此PaaS不再神秘，开始成为技术圈内的热议话题。我们 研究院在CloudFoundry发布时就开始投入研究，在实验室内部署了基于Cloud Foundry私有的PaaS。到了10月份，我们总结部份研究成果，整理成博客发表在研究院的轻微博上。

Cloud Foundry经过一年多的发展，文章内很多内容都已经不合时宜，这篇一周年特别版的结构重新整理，文章内容部份借鉴我的同事颜开所写的《新版 CloudFoundry揭秘》以及一些同行的文章、演讲进行改写；加入部份笔者在OpenStack APAC会议上所作报告《ElasticArchitecture in Cloud Foundry and Deploy with OpenStack》内容，而CloudFoundry的安装配置、扩展运行时、自定义服务等内容，本专栏会有后续专文介绍，这里就不再重复。

正文

​一、什么是PaaS？

PaaS这个话题已经不再新鲜，但是与云计算的其他概念一样，让人感觉云里雾里的。在所有让人摸不着头脑的定义里面，笔者最喜欢下面这张EMC World 2012展示的图，它从使用角度介绍了PaaS的含义。

从开发者的角度来看，如果我们开发了一个应用程序，需要部署。传统的IT需要为你准备网络、存储、服务器、虚拟化、操作系统、中 间件、应用运行环境等一系列设施；而如果你的企业上了IaaS，例如OpenStack，那这些IaaS套件就会帮你把网络到操作系统全包办了，你可以避 免走冗长的流程去申请机器，公网IP的这些活；但是这时还没完，因为IaaS只能帮你到给你若干台装好Linux或者Windows，但是你不能按需得到 运行环境，也不可以在资源不够的时候把你的应用进行横向扩展，而PaaS就接管剩下的工作，为你提供中间件和运行环境。在企业上了PaaS后，开发者只需 要管理自己的应用及应用数据即可，所有设施相关的都可以包办给PaaS平台。这里可以看到三点：

1、PaaS基于IaaS之上的；

2、PaaS为应用开发者提供中间件及运行环境；

3、PaaS管理应用的部署，扩展等生命周期。

其实上面第三点很重要，如果没有第三点，IaaS也可以通过一些技巧提供中间件和运行环境。譬如我有一个Ruby on Rails的应用，需要用到Mysql，那系统管理员完全可以把Ruby环境和Mysql集成到IaaS的模板里面。但是这样的设计无法满足下面的场景： 我目前应用有10个节点，由于访问压力增加，应用资源不够了，现需要动态增加为20个节点，但我提供的服务不可以接受中断。

当然，一定要较真的话，结合一些DevOp的知识也可以做到，但开发这些DevOp的脚本可以认为是一个最小化的PaaS了。

二、PaaS的基本架构

为了抽象出，PaaS的架构，我们先来看看下图：

这是三个非常著名的PaaS平台的高层架构图，从左到右分别是：CloudFoundry，Heroku和OpenShift。没个架构图，笔者都加了两条分隔线，我们可以看到它们拥有相似的三层架构：

a)     Router，主要负责找到相对硬的App访问点。在Heroku中叫做Routing Mesh，在OpenShift中叫做HA Proxy；

b)     App的运行容器，它必须是同构可互相替代的。在CloudFounry中叫作App Exec Engine，也就是下文所说的DEA，在Heroku中叫Dyna Grid，在OpenShift中就是上图画有”PHP”的gear；

c)      系统服务节点。

PaaS主要为了大规模访问而设计，所以要求每一层都支持Failover，也就是说任何一个部份都有多节点运行，任何一个节点 都可以挂掉，但要求其他的同组件节点可以替代已挂节点的工作；每一个层都可以扩展，以满足大并发需求；资源非独占性，如果某一组件资源有富裕，可以回收资 源供给其他组件使用。后面两点就是我们常说的弹性。后文我们将可以看到CloudFoundry是如何做到以上几点的。

三、CloudFoundry的架构及模块​

从总体地看，CloudFoundry的架构如下：

如果看过《深入CloudFoundry》原文，我们可以发现CloudFoundry的组件增加了很多。但是它的核心组件并没 有变化，增加的组件可以认为是原架构基础上的细化和专门化。譬如Stager组件是为了解决打包（Stage）过程需要操作大量文件，操作时间长的问题。 所以Stager模块作为独立进程，接受这些工作逐个运行，而不阻塞作为核心组件的CloudController。

CloudFoundry的核心组件有：

1、Router：顾名思义，Router组件在CloudFoundry中是对所有进来的Request进行路由。进入 Router的request主要有两类：首先是来自VMC Client或者STS的，由CloudFoundry使用者发出的，管理型指令。例如：列出你所有apps的vmc apps，提交一个apps等等。这类request会被路由到App Life Management组件，又叫Cloud Controller组件去；第二类是外界对你所部署的apps访问的request。这部份requests会被路由到App execution，又或者叫做DEAs的组件去。所有进入CloudFoundry系统的requests都会经过Router组件，看到这里可能会有 朋友会担心Router成为单点，从而成为整个云的瓶颈。但是CloudFoundry作为云系统，其设计的核心就是去单点依赖，组件平行扩充，且可替代 的以保证扩展性，这是CloudFoundry，甚至所有云计算系统的设计原则，后文会讨论CloudFoundry如何做到这点，目前只要知道，系统可 以部署多个Routers共同处理进来的requests，但是Router上层的Load Balance不在CloudFoundry的实现范围，CloudFoundry只保证所有的request是无状态的，这样就使上层均衡附载选择面非 常非常大了，例如可以通过DNS做，也可以部署硬件的Load Balancer，或者简单点，弄台ngnix作负载均衡器，都是可行的。

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

a)     使用Nginx的Lua扩展，在Lua中加入URL查询逻辑和统计逻辑；

b)     如果Lua不知道当前的URL应该对应到底下哪一个DEA，则会发一个Request到router_uls_server.rb（也就是上图的”Upstream LocatorSVC”）；

c)      router_uls_server.rb是一个简单的Sinatra应用，它存储了所有URL与DEA IP:Port对应数据。另外它也管理了访问Session数据（这个后面会说）。

这样一来，大量的业务请求在Lua查询过一次位置后，变成了nginx直连下属业务，而不再经过router。逻辑和数据完美分离。性能和稳定性都大幅提高了。

另外一个大改进在于在前版设计中，当Router接收到请求后，会随机分配一个Droplet来处理这个请求，这种方式使得用户 没有办法使用Session，因为连续的HTTP请求会被分发到不同的应用实例上处理。新版本设计中增加了对SESSION的支持，当Router发现用 户的请求中带了cookie信息，它会在Cookie里暗藏一个Droplet的host, port地址。当有新的请求进来，Router通过解析Cookie得到上次的应用实例，然后尽量转发到同一台Droplet上。而这部份信息与上面的查 询类似，会先存在于router_uls_server.rb，当Lua知道后会保存在Nginx内部提高效率。

还有一点可以利用的是，router_uls_server.rb作为一个基于Sinatra的服务，并且知道PaaS内所有映射、会话关系，是我们二次开发一个很有用的切入点。

2、DEA (Droplet ExecutionAgent): 首先要解析下什么叫做Droplet。Droplet在CloudFoundry的概念里面是指一个把你提交的源代码，以及CloudFoundry配套 好的运行环境，再加上一些管理脚本，例如Start/Stop这些小脚本全部压缩好在一起的tar包。还有一个概念，叫做Staging app，就是指制作上面描述这个包，然后把它存储好的过程。CloudFoundry会自动保存这个Droplet，直到你start一个app的时候， 一台部署了DEA模块的服务器会来拿一个Droplet的copy去运行。所以如果你扩展你的app到10个instances，那这个Droplet就 被会复制十份，让10个DEA服务器拿去运行。

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

除了增加隔绝性外，DEA的基本运行原理并没有发生根本改变：Cloud Controller模块（下面会介绍）会发送start/stop等基本的apps管理请求给DEA，dea.rb接收这些请求，然后从NFS里面找到 合适的Droplet。前面说到Droplet其实是一个带有运行脚本的，带运行环境的tar包，DEA只需要把它拿过来解压，并即行里面的start脚 本，就可以让这个app跑起来。到此，app算是可以访问，并start起来了，换句话说就是有这台服务器的某一个端口已经在待命，只要有request 从这个端口进来，这个app就可以接收并返回正确的信息。接着dea.rb要做些善后的工作：1、把这个信息告诉Router模块。我们前面说到，所有进 入CloudFoundry的requests都是由Router模块处理并转发的，包括用户对app的访问request，一个app起来后，需要告诉 router，让它根据load balance等原则，把合适的request转进来，使这个app的instance能够干起活；2、一些统计性的工作，例如要把这个用户又新部署了一 个app告诉Cloud Controller，以作quota控制等；3、把运行信息告诉Health Manager模块，实时报告该app的instance运行情况。另外DEA还要负责部份对Droplet的查询工作，譬如，如果用户通过Cloud Controller想查询一个app的log信息，那DEA需要从该Droplet里面取到log返回等等。

3、CloudController:  Cloud Controller是CloudFoundry的管理模块。主要工作包括：

a)     对apps的增删改读；

b)     启动、停止应用程序（通过DEA）；

c)      Stagingapps（把apps打包成一个droplet，通过Stager）；

d)     修改应用程序运行环境，包括instance、mem等等；

e)     管理service，包括service与app的绑定等；

f)      Cloud环境的管理；

g)     修改Cloud的用户信息（通过UAA，ACM）；

h)     查看CloudFoundry，以及每一个app的log信息。

这似乎有点复杂，但简单的说，可以很简单：就是与VMC和STS交互的服务器端。VMC和STS与CloudFoundry通信 采用的是restful接口，另一方面Cloud Controller是一个典型的Ruby on Rails项目，从VMC或者STS接到JSON格式的协议，然后写入Cloud ControllerDatabase，并发消息到各模快去控制管理整个云。

我们以部署一个App到CloudFoundry为例，在我们在敲完那条简单的push命令后，VMC开始工作，在做完一轮的用户鉴权、查看所部署的apps数量是否超过预定数额，问了一堆相关app的问题后，需要发4个指令：

a)     发一个POST到“apps”，创建一个app;

b)     发一个PUT到“apps/:name/application”，上传app;

c)      发一个GET到“apps/:name/”，取得app状态，看看是否已经启动；

d)     如果没有启动，发一个PUT到“apps/:name/”，使其启动。

第一版的CloudController是基于Ruby On Rails的，在新版中，为了与CloudFoundry其他模块一致，并且让架构更加简单，CloudController用Sinatra进行了重 写，并且加入了更多的模块去细化CloudController的工作。

另外一个重要的改进是，第一个版本的Droplet是通过NFS共享的，但这样会带来安全、性能等问题，而新版中进行了两大改进：

a)     移除NFS，采用自己开发的，简单的blobstore来存放Droplet;

b)     为Ruby项目进行了优化，把常用的Gem保存在package cache里面。所以在打包Ruby项目的时候不需要到公网上下载Gem文件，而是从CloudFoundry内部的Cache获得，大大加速了Stage过程。

随着CloudFoundry的逐渐成熟，权限管理功能在新的版本进行了很大的加强，在原有的用户模型基础上，加入了组织、用户空间的概念。

用户模型的认证是由UAA模块实现的，它可以与企业已有的认证系统进行整合，例如LDAP，CAS等；鉴权是由ACM模块实现的。

上图示例了一个用户访问CloudController的API的过程。我们可以分别看到UAA与ACM模块在一套鉴权流程各自扮演的角色。

UAA与ACM需要展开的内容很多，碍于篇幅原因，这里就不展开介绍了，有兴趣的朋友可以参考：https://github.com/cloudfoundry/uaa/tree/master/docs可能研究院后续会有专门的博客介绍相关技术。

4、Health Manager: 做的事情不复杂，简单的说是从各个DEA里面拿到运行信息，然后进行统计分析，报告等。统计数据会与CloudController的设定指标进行比对， 并提供Alert等。Health Manager模块目前还不是十分完善，但是Cloud Manage栈里面，自动化health管理、分析是一个很重要的领域，而这方面可以扩展的地方也很多，结合Orchestration Engine可以使云自管理、自预警；而与BI方面技术结合，可以统计运营情况，合理分配资源等。这方面CloudFoundry还在发展之中。

5、Services: 服务从上文的PaaS三层模型来看属于第三层，Cloud Foundry把Service模块设计成一个独立的、插件式的模块，第三方可以方便把自己的服务整合成Cloud Foundry服务。在Github上与服务相关，主要关注两个子项目：

a) vcap-services-base：顾名思义，包括Cloud Foundry服务的框架及核心类库。如果开发自定义的服务，我们需要引用到里面的类；

b) vcap-services：目前Cloud Foundry支持的，包括官方及大部份第三方贡献的服务。这个项目的根文件目录是以服务名称分的，我们可以选择感兴趣的去分别研究。

由此可见，Service模块的设计十分方便第三方提供自定义服务。从架构来说， Cloud Foundry服务部份使用了模板方法设计模式，我们通过重写钩子方法来实现自己的服务，如果不需要特别逻辑可以使用默认方法。从客户输入VMC命令开 始，一个完整的服务访问流程如下图：

 a)     开发人员通过VMC创建一个Service;

b)     VMC把其转为Restful接口到CloudController；

c)      CloudController通过Restful接口发送创建命令到Service Gateway；

d)     ServiceGateway通过NAT（下文会提到）发送provision命令道Service Node；

e)     ServiceNode创建Service；

f)      Service Node把返回创建的Service访问方法回Service Gateway；

g)     ServiceGateway返回访问方法到CloudController；

h)     CloudController把创建的Service访问放法注入到应用运行环境；

i)       最终用户可以直接访问其服务。

现实情况中，种种原因使有些系统服务难以，或者不愿意迁移到云端，为此Cloud Foundry 引入了Service Broker模块。

Service Broker可以使部署在Cloud Foundry上的应用可以访问本地的服务。ServiceBroker的使用方法如下：

a)     我们必须准备好系统,例如postgress。我们配置好程序和防火墙，让CloudFoundry能通过类似postgres://xyzhr:[email protected]:5432/xyz_hr_db 的URL来访问到服务。

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

对应上面的Service流程，Service Broker的访问流程如下，这里就不重复叙述了：

6、NATS (Message bus)： CloudFoundry的架构是基于消息发布与订阅的，联系各模块的是一个叫nats的组件。NATS是由CloudFoundry的架构师Derek 开发的一个基于事件驱动的轻量级支持发布、订阅机制的消息系统。它基于EventMachine开发，以事件驱动。第一版本CloudFoundry被人 诟病的一个问题就是NATS服务器是单节点，性能方面从实际应用情况看，是让人满意的；但HA方面的问题难以避免，成为整套系统HA的软肋。但新版 NATS终于支持多服务器节点，NATS服务器间通过THIN来做通信。NATS的Github开源地址是：https://github.com /derekcollison/nats。代码量不多但设计很精妙，推荐下载来慢慢研究。

CloudFoundry作为一个弹性设计的，多模块的分布式系统，且支持模块自发现，错误自检，保证模块间低耦合。其根本原理 就是基于消息发布订阅机制构建。每台服务器上的每个模块会根据自己的消息类别，向Message Bus发布多个消息主题；而同时也向自己需要交互的模块，按照需要的信息内容的消息主题订阅消息。

如前所说，CloudFoundry的核心是一套消息系统，如果想了解CloudFoundry的来龙去脉，去跟踪它里面复杂的 消息机制是非常好的方法。譬如：一个DEA被加入CloudFoundry集群中，它需要向大家吼一下，以表明它已经准备好服务了，它会发布一个主题 是”dea.start”的消息：

@ hello_message_json中包括DEA的UUID, ip, port, 版本信息等内容。

再例如，Cloud Controller需要启动一个Droplet的instance：

a)      首先一个DEA在启动的时候，会首先会对自己UUID的消息主题进行订阅。

其他模块需要通过’’dea.#{uuid}.start”这个主题发送消息来使它启动，一旦这个DEA接收到消息，就会触发process_dea_start(msg)这个方法来处理启动所需要的工作；

b)      Cloud Controller或者其他模块发送消息，让UUID为xxx的DEA启动。

c)       DEA模块接收到消息后，就会触发process_dea_start(msg)方法。msg是由其他模块发送过来的消息内容，包 括：droplet_id, instance_index, service, runtime等内容，process_dea_start会取得这些启动DEA必须的信息，然后进行一系列操作，例如从NFS中取得Droplet，解 压，修改必要环境配置，运行启动脚本等等。等一切都准备好后，然后需要给Router发个消息，告诉它这个Droplet已经随时准备好报效国家，以后有 相应的request记得让它来处理。

d)      Router模块在启动时就已经订阅”router.register”消息主题，

收到前面DEA发出的信息后，会触发register_droplet方法，去绑定Droplet。到此启动一个Droplet的instance工作完成。

CloudFoundry的架构简单介绍至此，其实作为第一款开源的PaaS，CloudFoundry架构有很多可以学习借鉴 的地方，很多细节上的处理是很精妙的，本文题虽为深入CloudFoundry，其实也只是浅尝即止，如果真要做到深入恐怕上面提到的每个模块都需要立篇 详谈。一年后的今天重新审视CloudFoundry的学习资料，已经很丰富，网上有很多牛人已经写了很多东西探讨CloudFoundry的架构，文章 最后笔者会给大家推荐个人觉得比较好的一些中文资料。总结一下，笔者从CloudFoundry的结构中学到的东西：

1、 基于消息的多组件架构是实现集群的简单、且有效方法。消息可以使集群节点间解耦，使自注册，自发现这些在大规模数据中心中很重要的功能得到实现；

2、 适当的抽象层，模板模式的使用，方便第三方可以方便在CloudFoundry开发扩展功能。CloudFoundry在DEA及Service层都做了 抽象层处理，相对应地使开发者可以容易地为CloudFoundry开发Runtime和Service。例如，在CloudFoundry刚推出的时 候，只支持Node.js, Java, Ruby，但第三方提供商、开源社区快速跟进，为CloudFoundry添加了PHP, Python的支持。这得益于CloudFoundry精巧的DEA架构设计。

四、安装配置CloudFoundry

写《深入CloudFoundry》的时间比较早，那时候连dev_setup都没有，更不用说更为先进的、适合大规模部署 CloudFoundry使用的BOSH。原文介绍的是如何通过理解CloudFoundry各模块的关系，通过手工配置安装CloudFoundry 的，笔者认为那依然是让我们理解CloudFoundry工作原理的最好方法，而且过程很有乐趣，就如我们在习惯了使用自动相机“咔嚓”一下的时候，如果 有机会把玩一些老相机，躲进暗房尝试自己冲洗银盐底片，那种感受是难以言表的。如果你有这种雅兴，笔者推荐你可以参考原文，找旧的代码从头走一遍，那可以 让你对CloudFoundry的理解加深很多；如果你的目标是希望马上部署好一套私有PaaS，享受现代科技带来的便捷，笔者推荐 CloudFoundry中国的官网文档，里面很详细介绍了用dev_setup，以及用BOSH在vSphere安装CloudFoundry的具体步 骤：http://cndocs.cloudfoundry.com/deploy/vSphere.html 按照那套指南，估计不到一个小时就能拥有一套多节点的PaaS。

CloudFoundry是一个PaaS，前面讨论到PaaS是基于IaaS之上的，上面CloudFoundry的部署指南是 以vSphere作为IaaS。但是无论是CloudFoundry本身，还是部署工具BOSH的设计都是以IaaS不相关的。正如一年前那篇《深入 CloudFoundry》所说，我们可以用OpenStack作为CloudFoundry的PaaS层。而CloudFoundry后来出现的部署系 统BOSH也和我们想得不谋而合，它对IaaS层做了一层抽象，叫做CPI（Cloud Provider Interface）。

而CPI里面就有专门为OpenStack准备的，叫做Piston，开源地址在：https://github.com/piston/openstack-bosh-cpi

如果从整体角度去理解BOSH ，其实可以发现这里面很简单。我们需要部署CloudFoundry，BOSH要做几件事情？

a)     向IaaS要一台虚拟机，导入image文件；

b)     向IaaS要存储空间，并attach到虚拟机上；

c)      配置这台虚拟机的网络，使它可以和其他CloudFoundry服务器相通；

d)     在这台虚拟机里面下载安装CloudFoundry的代码；

e)     配置CloudFoundry组件间的消息机制。

这里与IaaS相关的，就是a), b), c)三点，如果我们回到第一章什么是PaaS那张图来看，提供网络、存储、服务器，以及image中带有的OS就是IaaS所给我们提供的内容。而如果看 过《深入CloudFoundry》原文说过，由于由于CloudFoundry是完全模块化设计的，基于消息机制的分布式系统，所以安装配置 CloudFoundry就是把每个模块单独跑起来，然后配置其消息机制，也就是上面的d),e)两点。

我们回到BOSH，显而易见，CPI作为IaaS的facade，需要提供相对应的接口。任何一个IaaS，只需要实现以下接口即可以支持BOSH，并用来部署CloudFoundry：

a)     create_stemcell

b)     delete_stemcell

c)      create_vm

d)     delete_vm

e)     reboot_vm

f)      configure_network

g)     create_disk

h)     delete_disk

i)       attach_disk

j)       detach_disk

stemcell可以认为是我们常说的image，或者说是模板，。根据函数名，我们基本能知道每个接口的作用了吧？我们可以看到是和我们上面说的a), b), c)相对应的。

不少公司，都已经搭了自己的虚拟化平台，如这次笔者参加QCon，国内某著名电子商务公司内部就用LXC构建了一套虚拟化平台。如果他们再写个接口，暴露出上面10个接口，同样可以用来部署CloudFoundry。

总结

开篇的时候，笔者原本只想对原文进行适当的修改，没想到一年过去了，CloudFoundry发生了太多改变，全文基本都已经重 写，可见这一年来CloudFoundry社区的活跃。这篇文章属于新旧参半，如篇前所述，更多的是希望能把CloudFoundry的原理讲明白，讲得 简单，请不要把本文作为参考手册使用。

其实一年多来，CloudFoundry在国内已经很火，下面推荐一些自己觉得好，在写本文时参考过的资料：

·        CloudFoundry中文技术文档（http://cndocs.cloudfoundry.com/getting-started.html） 。现在CloudFoundry的文档化做得相当不错，尤其是部署云平台部份，本文多次引用提及；

·        @柳烟堆雪 的《以NATS为主线的CloudFoundry原理》（http://blog.csdn.net/resouer/article/details/8065795）。很好的一篇文章，可惜他发表时，本文已经写完，否则本文一定会有汲取不少养分；

·        著名博客五四科学院的CloudFoundry代码解读系列（http://www.54chen.com/?s=cloud+foundry）；

·        EMC中国研究院研究员颜开的《新版CloudFoundry揭秘》（http://qing.weibo.com/2294942122/88ca09aa33001753.html）。因为是同事，本文大段大段地拷他的这篇文章；

·        Cloudfoundry.org博客。另外要推荐的是Cloudfoundry.org的博客，我们知道Cloudfoundry的博客分.COM上的与.ORG上的，.COM上的大多是偏商业及应用，而.ORG的博客才是个牛人的园地；

·        代码还是代码。不用多说，作为一个开源项目，有什么比代码更直观？！

原文地址: http://qing.blog.sina.com.cn/2294942122/88ca09aa33003k2j.html