上面主要是將新的CloudFounry多了些什么。事實(shí)上，新的版本80%的工作在于對基礎(chǔ)架構(gòu)的改進(jìn)。下面仔細(xì)闡述，CloudFoundry做了什么讓他的架構(gòu)更可靠。如果不熟悉前代的架構(gòu)的話，可以參見《深入Cloud Foundry》
二、ROUTER
上個(gè)版本中。Router作為一個(gè)nginx腳本存在。所以的請求都必須經(jīng)過Ruby代碼，然后加以轉(zhuǎn)發(fā)。這個(gè)設(shè)計(jì)干凈利落，不過Ruby也因此轉(zhuǎn)發(fā)了大量的數(shù)據(jù)，容易引起性能問題，所以下個(gè)版本中做了如下的改進(jìn)。
在新版本的設(shè)計(jì)中，他們使用Lua腳本來代替原先的Ruby腳本。而Lua腳本會對請求加以分析，轉(zhuǎn)發(fā)給Ruby程序，然后Ruby程序再將分析的結(jié)果返回。這樣一來，proxied request已經(jīng)不再經(jīng)過Ruby代碼。邏輯和數(shù)據(jù)完美分離。性能和穩(wěn)定性都大幅提高了。
在前版設(shè)計(jì)中，當(dāng)Router接收到請求后，會隨機(jī)分配一個(gè)Droplet來處理這個(gè)請求，這種方式使得用戶沒有辦法使用Session，因?yàn)檫B續(xù)的HTTP請求會被分發(fā)到不同的應(yīng)用實(shí)例上處理。新版本設(shè)計(jì)中增加了對SESSION的支持，當(dāng)Router發(fā)現(xiàn)用戶的請求中帶了cookie信息，它會在Cookie里暗藏一個(gè)Droplet的host,port地址。當(dāng)有新的請求進(jìn)來，Router通過解析Cookie得到上次的應(yīng)用實(shí)例，然后盡量轉(zhuǎn)發(fā)到同一臺Droplet上。
三、STAGE
下面的新版CloudFoundry的架構(gòu)圖。
可以看到在新的CloudFoundry架構(gòu)中多出了很多組件。新架構(gòu)中將用戶驗(yàn)證從Controller中剝離，提供更好的驗(yàn)證服務(wù)。同時(shí)多出了一個(gè)單獨(dú)Stager。
在原有的架構(gòu)中，用戶上傳代碼后，Cloud Control會將這部分代碼結(jié)合CloudFoundry打包成DEA可以運(yùn)行的格式，并上傳到一個(gè)NFS中，當(dāng)DEA啟動的時(shí)候，會從NFS取到需要相應(yīng)的包，然后再運(yùn)行。
由于打包(Stage)的過程，比較復(fù)雜還需要操作大量的文件，需要的時(shí)間比較長，單薄的CloudController不堪重負(fù)，所以將其移出，成為一個(gè)單獨(dú)的進(jìn)程。每當(dāng)CloudController需要打包的時(shí)候，就會向Stage隊(duì)列中發(fā)送一個(gè)請求，Stage收到請求后，逐個(gè)處理之。
眾所周知，不管是Java,Python還是Ruby程序都會有一系列的依賴，例如Ruby的Gem。每次打包的時(shí)候，都需要下載很多Gem，這是費(fèi)時(shí)費(fèi)力不討好的。所以開發(fā)了PackageCache模塊來緩存常用的依賴包。這樣的話，打包的過程會順暢很多。
原先性能問題算是解決了。但CloudFoundry還是個(gè)注重高可用的系統(tǒng)，按照原先的設(shè)計(jì)，存放運(yùn)行包的NFS是一處單點(diǎn)，一旦Crash，整個(gè)CloudFoundry的部署功能都將癱瘓。這是不能容忍的，而且越來越大的規(guī)模，一臺機(jī)器遲早無法容納全部的運(yùn)行包。所以使用了BlobStore模塊，來替代原先的NFS，提供高可用可擴(kuò)展的存儲服務(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ù)。