CloudFoundry距離發(fā)布已經(jīng)一年多了。在這一年里CloudFoundry不論是社區(qū)還是代碼日臻成熟，擁有了眾多合作伙伴。現(xiàn)在他邁開了更大的腳步，新的CloudFoundry已經(jīng)逐漸浮出水面。

新版的CloudFoundry對(duì)于開發(fā)者來說，除了可以支持給多的Framework，提供更多類型的Service之外，沒有太多變化。但是CloudFoundry本身的架構(gòu)做了很多改進(jìn)，可靠性，擴(kuò)展性和安全性都有了質(zhì)的提升，而所有的一切都發(fā)生在背后。

一、新的功能

CloudFoundry提供了一些開發(fā)者們期冀的新功能。

可以和Service直接通信的Tunnel。作為開發(fā)者的我們往往希望可以使用客戶端工具直接連接到DB上調(diào)試。但是在CloudFoundry將DB作為Service隱藏在背后，這樣可以提供了諸多方便服務(wù)，卻讓我們無法直接連接到DB。CloudFoundry已經(jīng)解決了這個(gè)問題，可以使用vmctunnel工具，直接訪問云后的服務(wù)。

遺留系統(tǒng)的接入支持。如果你有自己的DB或者已經(jīng)有一個(gè)遺留系統(tǒng)不想讓CloudFoundry托管，但是又想獲得CloudFoundry的PaaS服務(wù)?，F(xiàn)在有了一個(gè)完善的解決方案。開發(fā)者可以將DB或者遺漏系統(tǒng)包裝成一個(gè)Service。然后可以在CloudFoundry中注冊(cè)，這樣就可以自由的訪問了。

更多的Framework支持。CloudFoundry之前已經(jīng)支持很多的框架。有Spring forJava, Rails and Sinatra for Ruby, and Node.js?，F(xiàn)在CloudFoundry將支持更多的Framework。有

o－> Java平臺(tái)

> Grails模仿Rails的Java平臺(tái)實(shí)現(xiàn)

> Java_web 普通Java web程序

> Lift基于Scale的web框架

> Spring 流行的Java框架

o－> Ruby平臺(tái)

> Rack 最小化的Ruby Web框架

> Rails3 一站式的Ruby Web框架

> Sinatra 極簡主義的Ruby Web框架

o－> Python平臺(tái)

> Django 最流行的PythonWeb框架

> Wsgi Python的CGI

o－> 其他平臺(tái)

> Static page 靜態(tài)頁面

> node.js 異步Web框架

> Erlang

> php

> standalone 獨(dú)立的程序

隨著時(shí)間的推移，支持的框架將越來越多。你也可以自定義自己的框架，只需要實(shí)現(xiàn)不多的代碼。其中Standalone是比較特殊的。開發(fā)者的程序只要能啟動(dòng)并監(jiān)聽一個(gè)端口，就可以作為一個(gè)程序運(yùn)行在CloudFoundry上。提供了非常大的靈活性。

更多的Service支持。除了更多的框架 支持，CloudFoundry增加了更多的服務(wù)。現(xiàn)在除了支持MySQL, MongoDB 和 Redis外。還支持很多服務(wù)。

×－> DB

－ Mongodb 最流行的NoSQL數(shù)據(jù)庫

－ Mysql傳統(tǒng)開源關(guān)系數(shù)據(jù)庫

－ Neo4j圖數(shù)據(jù)庫

－ PostgreSQL Mysql的有力競爭者

－ Redis極快的內(nèi)存KV數(shù)據(jù)庫

×－> 存儲(chǔ)

－ Atmos EMC專業(yè)存儲(chǔ)

－ FileSystem 遠(yuǎn)程N(yùn)FS支持

－ Vblob 提供Amazon S3支持

×－> 其他

－ RabbitMQ 出色的Erlang隊(duì)列系統(tǒng)

現(xiàn)在服務(wù)逐漸完善，覆蓋主流的數(shù)據(jù)庫和存儲(chǔ)。也可以通過上文提到的ServiceBroker來接入任何一個(gè)外部服務(wù)。沒有做不到，只有想不到。

上面主要是將新的CloudFounry多了些什么。事實(shí)上，新的版本80%的工作在于對(duì)基礎(chǔ)架構(gòu)的改進(jìn)。下面仔細(xì)闡述，CloudFoundry做了什么讓他的架構(gòu)更可靠。如果不熟悉前代的架構(gòu)的話，可以參見《深入Cloud Foundry》

二、ROUTER

上個(gè)版本中。Router作為一個(gè)nginx腳本存在。所以的請(qǐng)求都必須經(jīng)過Ruby代碼，然后加以轉(zhuǎn)發(fā)。這個(gè)設(shè)計(jì)干凈利落，不過Ruby也因此轉(zhuǎn)發(fā)了大量的數(shù)據(jù)，容易引起性能問題，所以下個(gè)版本中做了如下的改進(jìn)。

在新版本的設(shè)計(jì)中，他們使用Lua腳本來代替原先的Ruby腳本。而Lua腳本會(huì)對(duì)請(qǐng)求加以分析，轉(zhuǎn)發(fā)給Ruby程序，然后Ruby程序再將分析的結(jié)果返回。這樣一來，proxied request已經(jīng)不再經(jīng)過Ruby代碼。邏輯和數(shù)據(jù)完美分離。性能和穩(wěn)定性都大幅提高了。

在前版設(shè)計(jì)中，當(dāng)Router接收到請(qǐng)求后，會(huì)隨機(jī)分配一個(gè)Droplet來處理這個(gè)請(qǐng)求，這種方式使得用戶沒有辦法使用Session，因?yàn)檫B續(xù)的HTTP請(qǐng)求會(huì)被分發(fā)到不同的應(yīng)用實(shí)例上處理。新版本設(shè)計(jì)中增加了對(duì)SESSION的支持，當(dāng)Router發(fā)現(xiàn)用戶的請(qǐng)求中帶了cookie信息，它會(huì)在Cookie里暗藏一個(gè)Droplet的host,port地址。當(dāng)有新的請(qǐng)求進(jìn)來，Router通過解析Cookie得到上次的應(yīng)用實(shí)例，然后盡量轉(zhuǎn)發(fā)到同一臺(tái)Droplet上。

三、STAGE

下面的新版CloudFoundry的架構(gòu)圖。

可以看到在新的CloudFoundry架構(gòu)中多出了很多組件。新架構(gòu)中將用戶驗(yàn)證從Controller中剝離，提供更好的驗(yàn)證服務(wù)。同時(shí)多出了一個(gè)多帶帶Stager。

在原有的架構(gòu)中，用戶上傳代碼后，Cloud Control會(huì)將這部分代碼結(jié)合CloudFoundry打包成DEA可以運(yùn)行的格式，并上傳到一個(gè)NFS中，當(dāng)DEA啟動(dòng)的時(shí)候，會(huì)從NFS取到需要相應(yīng)的包，然后再運(yùn)行。

由于打包(Stage)的過程，比較復(fù)雜還需要操作大量的文件，需要的時(shí)間比較長，單薄的CloudController不堪重負(fù)，所以將其移出，成為一個(gè)多帶帶的進(jìn)程。每當(dāng)CloudController需要打包的時(shí)候，就會(huì)向Stage隊(duì)列中發(fā)送一個(gè)請(qǐng)求，Stage收到請(qǐng)求后，逐個(gè)處理之。

眾所周知，不管是Java,Python還是Ruby程序都會(huì)有一系列的依賴，例如Ruby的Gem。每次打包的時(shí)候，都需要下載很多Gem，這是費(fèi)時(shí)費(fèi)力不討好的。所以開發(fā)了PackageCache模塊來緩存常用的依賴包。這樣的話，打包的過程會(huì)順暢很多。

原先性能問題算是解決了。但CloudFoundry還是個(gè)注重高可用的系統(tǒng)，按照原先的設(shè)計(jì)，存放運(yùn)行包的NFS是一處單點(diǎn)，一旦Crash，整個(gè)CloudFoundry的部署功能都將癱瘓。這是不能容忍的，而且越來越大的規(guī)模，一臺(tái)機(jī)器遲早無法容納全部的運(yùn)行包。所以使用了BlobStore模塊，來替代原先的NFS，提供高可用可擴(kuò)展的存儲(chǔ)服務(wù)。

四、SERVICE BROKER

Service Broker可以讓Cloudfoundry輕松的支持遺留系統(tǒng)或者不愿意讓CloudFoundry托管的系統(tǒng)。他究竟是如何操作的呢？

首先，我們必須準(zhǔn)備好系統(tǒng),例如postgress。我們配置好程序和防火墻，讓CloudFoundry能通過類似

postgres://xyzhr:secret@db.xyzcorp.com:5432/xyz_hr_db 的URL來訪問到服務(wù)。

然后，調(diào)用create service，系統(tǒng)會(huì)在ServiceBroker中記錄你的配置信息。這樣就算大功告成了。Bind和其他的過程都有ServiceBroker完成，其實(shí)僅僅就是記錄信息，沒有實(shí)際操作。使用這個(gè)新的Service的時(shí)候和使用CloudFoundry的內(nèi)部Service沒有兩樣，配置參數(shù)都會(huì)通過環(huán)境變量傳入。所以當(dāng)App訪問Service的時(shí)候，就與ServiceBroker無關(guān)了。

五、DEA

DEA是App的運(yùn)行環(huán)境，全稱是DropletExecution Agent。一臺(tái)虛擬機(jī)上會(huì)運(yùn)行一個(gè)或多個(gè)DEA。一個(gè)DEA可以啟動(dòng)多個(gè)App(又稱Droplet)。所以我們大家的App都會(huì)由DEA啟動(dòng)并管理。

當(dāng)CloudFoundry剛剛推出的時(shí)候， Droplet包含了應(yīng)用運(yùn)行時(shí)啟動(dòng)，停止等簡單命令。用戶應(yīng)用可以隨意訪問文件系統(tǒng)，也可以在內(nèi)網(wǎng)暢通無阻，跑滿CPU，占盡內(nèi)存，寫滿磁盤。你一切可以想到的破壞性操作都可以做到，太可怕了。CloudFoundry顯然不會(huì)放任這樣的情況太久，現(xiàn)在他們開發(fā)出了Warden，一個(gè)程序運(yùn)行容器。這個(gè)容器提供了一個(gè)孤立的環(huán)境，Droplet只可以獲得受限的CPU,內(nèi)存，磁盤訪問權(quán)限，網(wǎng)絡(luò)權(quán)限，再?zèng)]有辦法搞破壞了。

Warden在Linux上的實(shí)現(xiàn)是將Linux 內(nèi)核的資源分成若干個(gè)namespace加以區(qū)分，底層的機(jī)制是CGROUP。這樣的設(shè)計(jì)比虛擬機(jī)性能好，啟動(dòng)快，也能夠獲得足夠的安全性。在網(wǎng)絡(luò)方面，每一個(gè)Warden實(shí)例有一個(gè)虛擬網(wǎng)絡(luò)接口，每個(gè)接口有一個(gè)IP，而DEA內(nèi)有一個(gè)子網(wǎng)，這些網(wǎng)絡(luò)接口就連在這個(gè)子網(wǎng)上。安全可以通過iptables來保證。在磁盤方面，每個(gè)warden實(shí)例有一個(gè)自己的filesystem。這些filesystem使用aufs實(shí)現(xiàn)的。Aufs可以共享warden之間的只讀內(nèi)容，區(qū)分只寫的內(nèi)容，提高了磁盤空間的利用率。因?yàn)閍ufs只能在固定大小的文件上讀寫，所以磁盤也沒有出現(xiàn)寫滿的可能性。

LXC是另一個(gè)Linux Container。那為什么不使用它，而開發(fā)了Warden呢。因?yàn)長XC的實(shí)現(xiàn)是和Linux綁死的，CloudFoundry希望warden能運(yùn)轉(zhuǎn)在各個(gè)不同的平臺(tái)，而不只是Linux。另外Warden提供了一個(gè)Daemon和若干Api來操作，LXC提供的是系統(tǒng)工具。還有最重要的一點(diǎn)是LXC過于龐大，Warden只需要其中的一點(diǎn)點(diǎn)功能就可以了，更少的代碼便于調(diào)試。

六、結(jié)語

至此，我們已經(jīng)全面的瀏覽了CloudFoundry的新功能，新設(shè)計(jì)。云計(jì)算的大潮浩浩湯湯，CloudFoundry作為第一個(gè)開源的PaaS平臺(tái)日臻成熟，實(shí)用。但未來還會(huì)有更多更好設(shè)計(jì)等著我們發(fā)現(xiàn)，屆時(shí)我們?cè)僖黄鸱窒怼?/P>

關(guān)于作者

顏開，EMC中國研究院研究員，關(guān)注大數(shù)據(jù)，云計(jì)算等領(lǐng)域

博客: http://weibo.com/yankaycom