【IT168技术】使用Cloud foundry(以下简称CF)接近一年时间，一直缺少时间写些东西与大家探讨。最近，打算写一下。目前使用经历主要包括：

　　1. 搭建CF运行环境并维护;

　　2. 部分代码修改和新功能扩充的工作;

　　3. 大量的应用部署测试，主要是rails/Java两类应用;

　　4. 支持新的Service尝试;

　　5. 其它待做事宜。。。

　　由于CF是PAAS平台，这里面先介绍个人对paas的粗略理解。Paas, Platform as a Service, 其主要目的是提供一个应用运行的平台，有了这个平台，开发者无需搭建应用运行环境和服务(Mysql/mongodb/Rabbitmq等)，包括硬件和软件(os/应用软件如tomcat/rails等)环境，开发者可专注代码开发，最终提供源码(或war包之类的)信息，上传至PAAS，即可运行，并可创建DNS直接提供服务，甚至可提供auto-scale，monitor，loadbalance等等运行webservice需要的一切功能。

　　简而言之，有了paas，开发者只需要提供源码，即可瞬间启动一个企业级的web service。

　　Paas主要为server级的应用提供运行平台，而不是提供强大的云计算能力，或者说不是提供分布式计算能力。当然，提供分布式计算能力也会被称为云计算，但不是我现在的方向。

　　CF做为一个PAAS平台，目前已支持了以上理解的大多数基础功能。但仍然有很多地方需要完善，比如router的负载均衡策略还很简单，对应用的监控还比较有限。但它的确给我们提供了一个非常漂亮的架构，使得我们有机会走近paas，而不是仍然不知道它该是什么样的状态。尽管，这个架构在性能方面表现的还有待推敲。

　　与CF一样类似的产品，比较火热的有heroko/openshift, 其它还有beantalk、google app engine等。

　　参见http://www.vmware.com/files/pdf/cloud/VMware-Taneja-Group-An-Overview-Of-The-Cloud-Market.pdf?

　　还可参见：http://socialcompare.com/en/comparison/platform-as-a-service-paas-for-cloud-applications-scalable-cluster-of-services?

　　基于Cloud Foundry的PaaS实践之： Cloud Foundry集群部署

　　单结点的部署由于vmware提供的安装脚本，使用简单不再陈述，大家参照一下官网即可，在此主要谈谈多结点集群部署的要点。 (关于Cloud Foundry 的整体介绍，大家可参阅 深入 Cloud Foundry(上)?及 深入Cloud Foundry(下)?先 )

　　2011年7月时，搭建Cloud Foundry 集群时，一篇国外的博文给了两个建议：一种是在每个结点上分别安装各个组件;一种是在每个结点上安装全部组件，然后在每个结点仅启动部分组件，组件间通过配置相连，实践证明这是最方便的方法。如果是在AWS-EC2部署集群，可以将一个结点安装好后，做成AMI，然后用AMI瞬间launch一个集群，再配置一个各个组件的配置文件，一会功夫就可以建立起一个集群。

　　下面说一个组件互联的配置。

　　Cloud Foundry整体架构的核心是基于消息机制的组件互联(未必得当)，所有组件的互联通讯依靠nats-server, 这是一个用ruby实现A lightweight publish-subscribe and distributed queueing messaging system. 使用极其简单，大家参考下https://github.com/derekcollison/nats。了解了nats，就抓住了Cloud Foundry的总线，然后大家再逐个熟悉各个组件的功能，当然构建一个多结点的Cloud Foundry也就简单的多了。nats的单结点安装，只要安装好ruby运行环境后，执行gem install nats安装，再执行nats-server启动，默认监听4222。

　　所有组件的config目录下都有“组件名.yml”文件，将其中的"mbus: nats://10.134.226.8:4222/ "中的IP地址调整成启动nats-server的主机地址，如果是部署一个只有一个cloud_controller+health_manager结点，任意多个dea/router结点的集群的话，集群就配置完成了。

　　如果想启动多个cloud_controller和health_manager结点，还有两个工作要做：

　　创建文件存储共享和可跨主机访问的数据库。

　　数据库存储可使用rails框架支持的任何数据库，笔者推荐使用mysql，运行在两个主机上并配置Replication功能，将cloud_controller和health_manager的数据库配置均指向mysql-master;

　　文件存储共享，可选用NFS，但当云中主机数量很多的时候，NFS可能 效率不是最优，建议其它支持FUSE的分布式存储解决方案，比如moosefs;多个cloud_controler需要共享 droplets: /var/vcap/shared/droplets和

　　resources: /var/vcap/shared/resources。以使用NFS为例，每个cloud_controller需要将nfs-server上的存储，mount到本机。PaaS系统真正运行起来，这两个目录增长会很快，因为存储着整个集群的应用程序副本和droplet副本，所以存储一定要大些。另外，整个集群，我们可以任意毁掉任何一台主机(当然大多数时候不是故意的)，再重新启动一个新的主机替代。但只要共享的文件存储和数据库数据不丢，整个集群就没有任何变化。所以，相信同学们一定会重视这两部分数据，定期备份到AWS-S3上，会HA啥的都不为过噢。

　　集群中多个router启动后，负载均衡是必不可少的，笔者使用过两个方案，一个是用Nginx，考虑到一个nginx并发功能支撑能力有限，可部署多个nginx;另外一种方案，可使用AWS的ELB，不过ELB给我们可配置的东西太少，好在AWS很专业，不妨一试，不过最好给几个留几个nginx混着用免得AWS再停电了，整个系统都挂了。大家有别的方案欢迎推荐哈。

　　另外一个需要特别关注的配置是本机IP，Cloud Foundry各个组件再向router注册时是根据配置提取本机IP，默认是127.0.0.1，必须改成实际IP，相关配置有：

　　cloud_controller.yml:local_route: 10.134.226.8

　　dea/config/dea.yml:local_route: 127.0.0.1

　　health_manager/config/health_manager.yml:local_route: 10.134.226.8

　　最新的代码最近未来得及看，但考虑到代码不断更新，但本文无法时时更新，建议大家以此类推。

　　对于配置文件的其它项，不影响集群的建立，在此不再多说，如果有问题可以与我联系。

　　介绍源码前，先介绍两个重要的内容。了解整个Cloud Foundry需要熟悉的内容很多，但最核心的东西是nats和event-machine. 关于nats上一篇已经做了介绍，大家可参考基于Cloud Foundry的PaaS实践(二) Cloud Foundry集群部署 ，安装一下执行个小示例程序便可一目了然。关于event-machine，大家可参考EventMachine-scalable-non-blocking-i-o-in-ruby 和 eventmachine_introduction_10.pdf 。简而言之，就是一个用很牛的算法(reactor)写的一个非阻塞的socket通信框架，有多种语言的实现，nats也用到。同样的，照着上面资料中的示例执行一下，就明白了。

　　有了以上的基础，我们可以开始共同看一下Cloud Foundry的核心，cloud_controller.

　　Cloud_Controller负责整个Cloud Foundry的用户管理/应用管理/服务管理，基于rails框架对外提供RESTFUL接口服务。我们可以通过分析一般rails应用的方法加以分析。rails应用的掌握个人喜欢通过MVC框架和RESTFUL接口把握。

　　首先，看一下cloud_controller/config/routes.rb:

　　按列从左至右依次为：http方法/访问路径/代码文件和函数信息/略。以第一行为例，如果cloud_controller接收到http get请求info路径信息，将使用cloud_controller/app/default_controller.rb文件中的info函数响应。以上供刚刚接触rails的同学参考。

　　了解了routers.rb的路由方法后，还可以使用wireshark工具，安装vmc(安装ruby后执行gem install vmc)，通过vmc help帮助执行vmc 命令的同时，用wireshark抓取http包，刚cloud_controller RESTFUL接口可完全把握。下面使用LINUX的curl工具，显示示例包如下：

　　当然，这个应答信息显示的不够全面，大家还是wireshark，我这台电脑没装，暂时就不能截图了。另外，大家也可以使用Advance RESTclient，示例：

　　到此，我们已经可以把握全部restful接口，以及每个接口执行的路径，再列一下cloud_controller/app目录下的文件，一目了然。

　　在看代码之前，最好再看一下数据模型。我曾经画了个模型图，可惜暂时找不到了，先做个文字介绍吧。

　　cloud_controller的主要数据模型包括:

　　(临时画的简表，抱歉未添加表关系和示例数据，过两天要是翻到我写的手册就补上)。

　　表的内容不难，此处列出的只是比较主要的，可能会有变化，但相信这里的大部分东西不会大变。特别说明，service在Cloud Foundry中指的是System Service，比如Cloud Foundry会根据用户的需要，由用户执行vmc create-server mysql后，为用户创建一个mysql，然后执行vmc bind-service mysql-name app-name后，就将此服务和应用绑定，即应用可以访问VCAP_SERVICES环境变量，得到这个mysql实例的连接信息，包括用户名/密码/IP/端口啥的。这块目前Cloud Foundry支持API，用法更加简单，但原理如是。实现的信息会保存在services表中，连接信息会保存在binding_tokens表中，服务绑定信息会放在service_bindings表中，服务版本信息会保存service_configs中。大家可以执行一下命令，看看表中数据的变化即可顿悟。

　　另外，就是最配置文件，cloud_controller/config/cloud_controller.yml，这里面注释较清楚，需要细看一下不再多说，有问题私信我。