摘要：基于的實踐一綜述參見還可參見基于的實踐之集群部署單結(jié)點的部署由于提供的安裝腳本，使用簡單不再陳述，大家參照一下官網(wǎng)即可，在此主要談?wù)劧嘟Y(jié)點集群部署的要點。關(guān)于，大家可參考和。

　　1. 搭建CF運行環(huán)境并維護;

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

　　3. 大量的應(yīng)用部署測試，主要是rails/Java兩類應(yīng)用;

　　4. 支持新的Service嘗試;

　　5. 其它待做事宜。。。

　　由于CF是PAAS平臺，這里面先介紹個人對paas的粗略理解。Paas, Platform as a Service, 其主要目的是提供一個應(yīng)用運行的平臺，有了這個平臺，開發(fā)者無需搭建應(yīng)用運行環(huán)境和服務(wù)(MySQL/mongodb/Rabbitmq等)，包括硬件和軟件(os/應(yīng)用軟件如tomcat/rails等)環(huán)境，開發(fā)者可專注代碼開發(fā)，最終提供源碼(或war包之類的)信息，上傳至PAAS，即可運行，并可創(chuàng)建DNS直接提供服務(wù)，甚至可提供auto-scale，monitor，loadbalance等等運行webservice需要的一切功能。

　　簡而言之，有了paas，開發(fā)者只需要提供源碼，即可瞬間啟動一個企業(yè)級的web service。

　　Paas主要為server級的應(yīng)用提供運行平臺，而不是提供強大的云計算能力，或者說不是提供分布式計算能力。當(dāng)然，提供分布式計算能力也會被稱為云計算，但不是我現(xiàn)在的方向。

　　CF做為一個PAAS平臺，目前已支持了以上理解的大多數(shù)基礎(chǔ)功能。但仍然有很多地方需要完善，比如router的負載均衡策略還很簡單，對應(yīng)用的監(jiān)控還比較有限。但它的確給我們提供了一個非常漂亮的架構(gòu)，使得我們有機會走近paas，而不是仍然不知道它該是什么樣的狀態(tài)。盡管，這個架構(gòu)在性能方面表現(xiàn)的還有待推敲。

　　與CF一樣類似的產(chǎn)品，比較火熱的有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集群部署

　　單結(jié)點的部署由于vmware提供的安裝腳本，使用簡單不再陳述，大家參照一下官網(wǎng)即可，在此主要談?wù)劧嘟Y(jié)點集群部署的要點。 (關(guān)于Cloud Foundry 的整體介紹，大家可參閱 深入 Cloud Foundry(上)?及 深入Cloud Foundry(下)?先 )

　　2011年7月時，搭建Cloud Foundry 集群時，一篇國外的博文給了兩個建議：一種是在每個結(jié)點上分別安裝各個組件;一種是在每個結(jié)點上安裝全部組件，然后在每個結(jié)點僅啟動部分組件，組件間通過配置相連，實踐證明這是最方便的方法。如果是在AWS-EC2部署集群，可以將一個結(jié)點安裝好后，做成AMI，然后用AMI瞬間launch一個集群，再配置一個各個組件的配置文件，一會功夫就可以建立起一個集群。

　　下面說一個組件互聯(lián)的配置。

　　Cloud Foundry整體架構(gòu)的核心是基于消息機制的組件互聯(lián)(未必得當(dāng))，所有組件的互聯(lián)通訊依靠nats-server, 這是一個用ruby實現(xiàn)A lightweight publish-subscribe and distributed queueing messaging system. 使用極其簡單，大家參考下https://github.com/derekcollison/nats。了解了nats，就抓住了Cloud Foundry的總線，然后大家再逐個熟悉各個組件的功能，當(dāng)然構(gòu)建一個多結(jié)點的Cloud Foundry也就簡單的多了。nats的單結(jié)點安裝，只要安裝好ruby運行環(huán)境后，執(zhí)行g(shù)em install nats安裝，再執(zhí)行nats-server啟動，默認監(jiān)聽4222。

　　所有組件的config目錄下都有“組件名.yml”文件，將其中的"mbus: nats://10.134.226.8:4222/ "中的IP地址調(diào)整成啟動nats-server的主機地址，如果是部署一個只有一個cloud_controller+health_manager結(jié)點，任意多個dea/router結(jié)點的集群的話，集群就配置完成了。

　　如果想啟動多個cloud_controller和health_manager結(jié)點，還有兩個工作要做：

　　創(chuàng)建文件存儲共享和可跨主機訪問的數(shù)據(jù)庫。

　　數(shù)據(jù)庫存儲可使用rails框架支持的任何數(shù)據(jù)庫，筆者推薦使用mysql，運行在兩個主機上并配置Replication功能，將cloud_controller和health_manager的數(shù)據(jù)庫配置均指向mysql-master;

　　文件存儲共享，可選用NFS，但當(dāng)云中主機數(shù)量很多的時候，NFS可能 效率不是最優(yōu)，建議其它支持FUSE的分布式存儲解決方案，比如moosefs;多個cloud_controler需要共享 droplets: /var/vcap/shared/droplets和resources: /var/vcap/shared/resources。以使用NFS為例，每個cloud_controller需要將nfs-server上的存儲，mount到本機。PaaS系統(tǒng)真正運行起來，這兩個目錄增長會很快，因為存儲著整個集群的應(yīng)用程序副本和droplet副本，所以存儲一定要大些。另外，整個集群，我們可以任意毀掉任何一臺主機(當(dāng)然大多數(shù)時候不是故意的)，再重新啟動一個新的主機替代。但只要共享的文件存儲和數(shù)據(jù)庫數(shù)據(jù)不丟，整個集群就沒有任何變化。所以，相信同學(xué)們一定會重視這兩部分數(shù)據(jù)，定期備份到AWS-S3上，會HA啥的都不為過噢。

　　集群中多個router啟動后，負載均衡是必不可少的，筆者使用過兩個方案，一個是用Nginx，考慮到一個nginx并發(fā)功能支撐能力有限，可部署多個nginx;另外一種方案，可使用AWS的ELB，不過ELB給我們可配置的東西太少，好在AWS很專業(yè)，不妨一試，不過較好給幾個留幾個nginx混著用免得AWS再停電了，整個系統(tǒng)都掛了。大家有別的方案歡迎推薦哈。

　　另外一個需要特別關(guān)注的配置是本機IP，Cloud Foundry各個組件再向router注冊時是根據(jù)配置提取本機IP，默認是127.0.0.1，必須改成實際IP，相關(guān)配置有：

　　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

　　的代碼最近未來得及看，但考慮到代碼不斷更新，但本文無法時時更新，建議大家以此類推。

　　對于配置文件的其它項，不影響集群的建立，在此不再多說，如果有問題可以與我聯(lián)系。

　　介紹源碼前，先介紹兩個重要的內(nèi)容。了解整個Cloud Foundry需要熟悉的內(nèi)容很多，但最核心的東西是nats和event-machine. 關(guān)于nats上一篇已經(jīng)做了介紹，大家可參考基于Cloud Foundry的PaaS實踐(二) Cloud Foundry集群部署 ，安裝一下執(zhí)行個小示例程序便可一目了然。關(guān)于event-machine，大家可參考EventMachine-scalable-non-blocking-i-o-in-ruby 和 eventmachine_introduction_10.pdf 。簡而言之，就是一個用很牛的算法(reactor)寫的一個非阻塞的socket通信框架，有多種語言的實現(xiàn)，nats也用到。同樣的，照著上面資料中的示例執(zhí)行一下，就明白了。

　　有了以上的基礎(chǔ)，我們可以開始共同看一下Cloud Foundry的核心，cloud_controller.

　　Cloud_Controller負責(zé)整個Cloud Foundry的用戶管理/應(yīng)用管理/服務(wù)管理，基于rails框架對外提供RESTFUL接口服務(wù)。我們可以通過分析一般rails應(yīng)用的方法加以分析。rails應(yīng)用的掌握個人喜歡通過MVC框架和RESTFUL接口把握。

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

　　按列從左至右依次為：http方法/訪問路徑/代碼文件和函數(shù)信息/略。以第一行為例，如果cloud_controller接收到http get請求info路徑信息，將使用cloud_controller/app/default_controller.rb文件中的info函數(shù)響應(yīng)。以上供剛剛接觸rails的同學(xué)參考。

　　了解了routers.rb的路由方法后，還可以使用wireshark工具，安裝vmc(安裝ruby后執(zhí)行g(shù)em install vmc)，通過vmc help幫助執(zhí)行vmc 命令的同時，用wireshark抓取http包，剛cloud_controller RESTFUL接口可完全把握。下面使用Linux的curl工具，顯示示例包如下：

　　當(dāng)然，這個應(yīng)答信息顯示的不夠全面，大家還是wireshark，我這臺電腦沒裝，暫時就不能截圖了。另外，大家也可以使用Advance RESTclient，示例：

　　到此，我們已經(jīng)可以把握全部restful接口，以及每個接口執(zhí)行的路徑，再列一下cloud_controller/app目錄下的文件，一目了然。

　　在看代碼之前，較好再看一下數(shù)據(jù)模型。我曾經(jīng)畫了個模型圖，可惜暫時找不到了，先做個文字介紹吧。

　　cloud_controller的主要數(shù)據(jù)模型包括:

　　(臨時畫的簡表，抱歉未添加表關(guān)系和示例數(shù)據(jù)，過兩天要是翻到我寫的手冊就補上)。

　　表的內(nèi)容不難，此處列出的只是比較主要的，可能會有變化，但相信這里的大部分東西不會大變。特別說明，service在Cloud Foundry中指的是System Service，比如Cloud Foundry會根據(jù)用戶的需要，由用戶執(zhí)行vmc create-server mysql后，為用戶創(chuàng)建一個mysql，然后執(zhí)行vmc bind-service mysql-name app-name后，就將此服務(wù)和應(yīng)用綁定，即應(yīng)用可以訪問VCAP_SERVICES環(huán)境變量，得到這個mysql實例的連接信息，包括用戶名/密碼/IP/端口啥的。這塊目前Cloud Foundry支持API，用法更加簡單，但原理如是。實現(xiàn)的信息會保存在services表中，連接信息會保存在binding_tokens表中，服務(wù)綁定信息會放在service_bindings表中，服務(wù)版本信息會保存service_configs中。大家可以執(zhí)行一下命令，看看表中數(shù)據(jù)的變化即可頓悟。