深入 Cloud Foundry（上）

XiNGRZ 發(fā)布于2019-04-25 17:28 / 1430人閱讀

引子

今年4月份，VMware突然發(fā)布了業(yè)內(nèi)第一個(gè)開(kāi)源的PaaS——CloudFoundry。幾個(gè)關(guān)鍵字：開(kāi)源、PaaS、VMware，如果你對(duì)云計(jì)算感興趣，就沖著它的ApacheV2協(xié)議，如果不去GitHub拿它的代碼好好研讀一下，真有點(diǎn)對(duì)不起自己。筆者當(dāng)時(shí)就是以這樣的心態(tài)去研究它的代碼，并把它部署在我們labs里面。發(fā)布至今的這幾個(gè)月里，筆者一直關(guān)注它的演進(jìn)，并從它的架構(gòu)設(shè)計(jì)中獲益良多，覺(jué)得有必要寫(xiě)出來(lái)與大家分享一下。由于個(gè)人知識(shí)、認(rèn)知等原因，其中有些看法難免不成熟，大家可以直接批評(píng)、指教。

本文會(huì)分為兩個(gè)部份：第一部份主要介紹CloudFoundry的架構(gòu)設(shè)計(jì)，從它所包含的模塊介紹起，到各部份的消息流向，各模塊如何協(xié)調(diào)合作；第二部份會(huì)在第一部份的基礎(chǔ)上，以如何在你的數(shù)據(jù)中心里面用CloudFoundry部署一個(gè)私有PaaS為目標(biāo)，把第一部分介紹到的架構(gòu)知識(shí)使用起來(lái)。在本文，我不想簡(jiǎn)單的介紹如何使用CloudFoundry，這方面的文章，在SpringSource的官方博客里面有具體的介紹。如果需要這方面的介紹，筆者強(qiáng)烈建議到SpringSource或者CloudFoundry的官博找資料。另外，本文也不會(huì)具體介紹如何“貢獻(xiàn)”Cloud Foundry，例如添加自己的Runtime，添加第三方的Service，這將會(huì)是兩個(gè)很大的話題，以后我們會(huì)有專門(mén)的文章介紹，本文更多的算是入門(mén)級(jí)的架構(gòu)介紹，可能會(huì)涉及到具體代碼，但是只為更好地理解架構(gòu)而服務(wù)。在第二部份，會(huì)簡(jiǎn)單介紹到如何用OrchestrationEngine來(lái)把CloudFoundry部署到IaaS上面，但是具體的實(shí)現(xiàn)方法將會(huì)放到介紹OrchestrationEngine的文章上面去，這里更多的是一種思想和BestPractice的分享。

第一部份講的很多內(nèi)容，會(huì)引用Pat在10月12日的VMwareCloud Forum上面關(guān)于CloudFoundry架構(gòu)的演講。Pat是CloudFoundry Core的負(fù)責(zé)人，他的那次演講很值得一聽(tīng)。如果你當(dāng)時(shí)在場(chǎng)，并且理解他所說(shuō)的內(nèi)容，本部份可以選擇直接跳過(guò)。我除了會(huì)把說(shuō)的內(nèi)容講具體點(diǎn)外，不太可能可以講得比他好。

一、架構(gòu)及模塊

從總體地看，CloudFoundry的架構(gòu)如下：

這個(gè)架構(gòu)圖以及下文所用到的各模塊架構(gòu)圖均來(lái)自Pat的PPT。從上圖能夠看到CloudFoundry主要有以下幾大組件組成：

1、? Router：顧名思義，Router組件在CloudFoundry中是對(duì)所有進(jìn)來(lái)的Request進(jìn)行路由。進(jìn)入Router的request主要有兩類：首先是來(lái)自VMCClient或者STS的，由CloudFoundry使用者發(fā)出的，管理型指令。例如：列出你所有apps的vmcapps，提交一個(gè)apps等等。這類request會(huì)被路由到AppLife Management組件，又叫CloudController組件去；第二類是外界對(duì)你所部署的apps訪問(wèn)的request。這部份requests會(huì)被路由到Appexecution，又或者叫做DEAs的組件去。所有進(jìn)入CloudFoundry系統(tǒng)的requests都會(huì)經(jīng)過(guò)Router組件，看到這里可能會(huì)有朋友會(huì)擔(dān)心Router成為單點(diǎn)，從而成為整個(gè)云的瓶頸。但是CloudFoundry作為云系統(tǒng)，其設(shè)計(jì)的核心就是去單點(diǎn)依賴，組件平行擴(kuò)充，且可替代的以保證擴(kuò)展性，這是CloudFoundry，甚至所有云計(jì)算系統(tǒng)的設(shè)計(jì)原則，后文會(huì)討論CloudFoundry如何做到這點(diǎn)，目前只要知道，系統(tǒng)可以部署多個(gè)Routers共同處理進(jìn)來(lái)的requests，但是Router上層的LoadBalance不在CloudFoundry的實(shí)現(xiàn)范圍，CloudFoundry只保證所有的request是無(wú)狀態(tài)的，這樣就使上層均衡附載選擇面非常非常大了，例如可以通過(guò)DNS做，也可以部署硬件的LoadBalancer，或者簡(jiǎn)單點(diǎn)，弄臺(tái)ngnix作負(fù)載均衡器，都是可行的。

Router組件，目前版本是對(duì)nginx的一個(gè)簡(jiǎn)單封裝。熟悉ngnix的朋友應(yīng)該知道，它可以一個(gè)套接字文件（.sock文件）作為輸入輸出。所有安裝CloudFoundry的Router組件服務(wù)器都會(huì)安裝一個(gè)nginx，其ngnix.conf文件有以下配置：

從整體的來(lái)看，Router組件的結(jié)構(gòu)如下：

外界httprequest進(jìn)入CloudFoundry服務(wù)器，nginx會(huì)首先接到request，nginx通過(guò)sock與router.rb進(jìn)行交互，于是真正處理請(qǐng)求的是Router組件。router.rb里面根據(jù)傳入的url，用戶名密碼等，進(jìn)行邏輯判斷，到CloudController組件或者DEA組件取數(shù)據(jù)并且返通過(guò)與niginx連接的.sock文件返回。router.rb是對(duì)nginx進(jìn)行了邏輯封裝。熟悉CloudFoundry的朋友肯定知道，CloudFoundry給每一個(gè)app分配了一個(gè)url訪問(wèn)，如果直接使用VMware所托管的CloudFoundry.com的話，那你的app的url可能就是xxx.cloudfoundry.com，無(wú)論通過(guò)命令給你的app擴(kuò)展了多少個(gè)instances，都是從這個(gè)url訪問(wèn)的，這里面的url轉(zhuǎn)換路由就是由router.rb實(shí)現(xiàn)的。

2、? DEA(Droplet Execution Agency): 首先要解析下什么叫做Droplet。Droplet在CloudFoundry的概念里面是指一個(gè)把你提交的源代碼，以及CloudFoundry配套好的運(yùn)行環(huán)境，再加上一些管理腳本，例如Start/Stop這些小腳本全部壓縮好在一起的tar包。還有一個(gè)概念，叫做Stagingapp，就是指制作上面描述這個(gè)包，然后把它存儲(chǔ)好的過(guò)程。CloudFoundry會(huì)自動(dòng)保存這個(gè)Droplet，直到你start一個(gè)app的時(shí)候，一臺(tái)部署了DEA模塊的服務(wù)器會(huì)來(lái)拿一個(gè)Droplet的copy去運(yùn)行。所以如果你擴(kuò)展你的app到10個(gè)instances，那這個(gè)Droplet就被會(huì)復(fù)制十份，讓10個(gè)DEA服務(wù)器拿去運(yùn)行。

下圖是DEA模塊的架構(gòu)圖：

Cloud Controller模塊（下面會(huì)介紹）會(huì)發(fā)送start/stop等基本的apps管理請(qǐng)求給DEA，dea.rb接收這些請(qǐng)求，然后從NFS里面找到合適的Droplet。前面說(shuō)到Droplet其實(shí)是一個(gè)帶有運(yùn)行腳本的，帶運(yùn)行環(huán)境的tar包，DEA只需要把它拿過(guò)來(lái)解壓，并即行里面的start腳本，就可以讓這個(gè)app跑起來(lái)。到此，app算是可以訪問(wèn)，并start起來(lái)了，換句話說(shuō)就是有這臺(tái)服務(wù)器的某一個(gè)端口已經(jīng)在待命，只要有request從這個(gè)端口進(jìn)來(lái)，這個(gè)app就可以接收并返回正確的信息。接著dea.rb要做些善后的工作：1、把這個(gè)信息告訴Router模塊。我們前面說(shuō)到，所有進(jìn)入CloudFoundry的requests都是由Router模塊處理并轉(zhuǎn)發(fā)的，包括用戶對(duì)app的訪問(wèn)request，一個(gè)app起來(lái)后，需要告訴router，讓它根據(jù)loadbalance等原則，把合適的request轉(zhuǎn)進(jìn)來(lái)，使這個(gè)app的instance能夠干起活；2、一些統(tǒng)計(jì)性的工作，例如要把這個(gè)用戶又新部署了一個(gè)app告訴CloudController，以作quota控制等；3、把運(yùn)行信息告訴HealthManager模塊，實(shí)時(shí)報(bào)告該app的instance運(yùn)行情況。另外DEA還要負(fù)責(zé)部份對(duì)Droplet的查詢工作，譬如，如果用戶通過(guò)CloudController想查詢一個(gè)app的log信息，那DEA需要從該Droplet里面取到log返回等等。

3、CloudController：CloudController是CloudFoundry的管理模塊。主要工作包括：

a) 對(duì)apps的增刪改讀；

b) 啟動(dòng)、停止應(yīng)用程序；

c) Staging apps（把a(bǔ)pps打包成一個(gè)droplet）；

d) 修改應(yīng)用程序運(yùn)行環(huán)境，包括instance、mem等等；

e) 管理service，包括service與app的綁定等；

f) Cloud環(huán)境的管理；

g) 修改Cloud的用戶信息；

h) 查看Cloud Foundry，以及每一個(gè)app的log信息。

這似乎有點(diǎn)復(fù)雜，但簡(jiǎn)單的說(shuō)，可以很簡(jiǎn)單：就是與VMC和STS交互的服務(wù)器端。VMC和STS與CloudFoundry通信采用的是restful接口，另一方面CloudController是一個(gè)典型的Rubyon Rails項(xiàng)目，從VMC或者STS接到JSON格式的協(xié)議，然后寫(xiě)入CloudController Database，并發(fā)消息到各?？烊タ刂乒芾碚麄€(gè)云。和其他ROR項(xiàng)目一樣，CloudController的所有API可以從conf/routes.rb里看到。開(kāi)放的Restful接口好處在于第三方應(yīng)用開(kāi)發(fā)和集成，企業(yè)在用CloudFoundry部署私有云的時(shí)候，可以通過(guò)這些接口來(lái)自動(dòng)化控制管理整個(gè)Cloud環(huán)境。這部份內(nèi)容將在第二部份論述。

下圖是Cloud Controller的架構(gòu)圖：

圖中Health Manager和DEA是外部模塊，CCDatabase就是CloudController Database，這個(gè)是整個(gè)CloudFoundry不能做HP的地方。CloudController Database的并發(fā)性不會(huì)很多，應(yīng)用級(jí)別的數(shù)據(jù)庫(kù)訪問(wèn)是由底下的Service模塊處理的，這個(gè)數(shù)據(jù)庫(kù)存的是Cloud的配置信息。讀操作主要來(lái)自DEA啟動(dòng)，作為初始化DEA的依據(jù)；以及healthmanager模塊會(huì)從這里讀取預(yù)期的狀態(tài)信息，這部份數(shù)據(jù)會(huì)與從DEA得到的實(shí)際狀態(tài)信息進(jìn)行比對(duì)。NFS是多個(gè)CloudController的共享存儲(chǔ)，CloudController其中一個(gè)重要工作就是StagingApps。Droplets的存儲(chǔ)是在集群環(huán)境的的。而CloudController是集群運(yùn)行，換言之，就是每一個(gè)控制Request可能由不同的CloudController處理，假設(shè)一個(gè)簡(jiǎn)單的用戶場(chǎng)景：我們需要部署一個(gè)app到CloudFoundry中。我們?cè)谇猛昴菞l簡(jiǎn)單的push命令后，VMC開(kāi)始工作，在做完一輪的用戶鑒權(quán)、查看所部署的apps數(shù)量是否超過(guò)預(yù)定數(shù)額，問(wèn)了一堆相關(guān)app的問(wèn)題后，需要發(fā)4個(gè)指令：

1．發(fā)一個(gè)POST到”apps”，創(chuàng)建一個(gè)app;

2．發(fā)一個(gè)PUT到”apps/:name/application”，上傳app;

3．發(fā)一個(gè)GET到”apps/:name/”，取得app狀態(tài)，看看是否已經(jīng)啟動(dòng)；

4．如果沒(méi)有啟動(dòng)，發(fā)一個(gè)PUT到”apps/:name/”，使其啟動(dòng)。

如果第2和第4步由不同的Cloud Controller來(lái)處理，而又無(wú)法保證他們能找到同一個(gè)Droplet，那第4步將會(huì)因?yàn)檎也坏綄?duì)應(yīng)的Droplet而啟動(dòng)失敗。如何保證這一連串指令過(guò)來(lái)所指向的Droplet都是同一個(gè)呢？使用NFS，使CloudController共享存儲(chǔ)是最簡(jiǎn)單的方法。但是這個(gè)方法在安全性等方面并不完美。在10月12日的VMwareCloud Forum上，Pat告訴我們下一版本的CloudFoundry這里將會(huì)有大調(diào)整，但是在那部份代碼公開(kāi)前，我不方便在這評(píng)價(jià)太多。

4、? HealthManager: 做的事情不復(fù)雜，簡(jiǎn)單的說(shuō)是從各個(gè)DEA里面拿到運(yùn)行信息，然后進(jìn)行統(tǒng)計(jì)分析，報(bào)告等。統(tǒng)計(jì)數(shù)據(jù)會(huì)與CloudController的設(shè)定指標(biāo)進(jìn)行比對(duì)，并提供Alert等。HealthManager模塊目前還不是十分完善，但是CloudManage棧里面，自動(dòng)化health管理、分析是一個(gè)很重要的領(lǐng)域，而這方面可以擴(kuò)展的地方也很多，結(jié)合OrchestrationEngine可以使云自管理、自預(yù)警；而與BI方面技術(shù)結(jié)合，可以統(tǒng)計(jì)運(yùn)營(yíng)情況，合理分配資源等。這方面CloudFoundry還在發(fā)展之中。

5、? Services:Cloud Foundry的Service模塊從源代碼控制上看就知道是一個(gè)獨(dú)立的、可Plugin的模塊，以方便第三方把自己的服務(wù)整合入CloudFoundry生態(tài)系統(tǒng)。在Github上看到service是與CloudFoundry Core項(xiàng)目vcap獨(dú)立的一個(gè)repository，為vcap-service。Service模塊其中設(shè)計(jì)原則是方便第三方服務(wù)提供商提供服務(wù)。在這方面CloudFoundry做得很成功，從Github上看，已經(jīng)有以下服務(wù)提供：a)MongoDB; b) mySQL; c) neo4j; d) PostgreSQL; e) RabbitMQ; f) Redis; g)vBlob?；惗际欠旁赽ase文件夾中。第三方如果需要自己開(kāi)發(fā)CloudFoundry的服務(wù)，需要繼承改寫(xiě)它里面的兩個(gè)基礎(chǔ)類：Node和Gateway；而里面一些操作，如：Provision，可以在base的provisioner.rb基礎(chǔ)上加入自己的邏輯，同樣的還有Service_Error和Service_Message等。關(guān)于如何寫(xiě)自己的Service，ELC的博客會(huì)推出相應(yīng)文章詳細(xì)論述，并不在本文的討論范圍里面，從架構(gòu)了解上來(lái)說(shuō)，只要知道服務(wù)間的關(guān)系，知道個(gè)服務(wù)與base間透過(guò)繼承關(guān)系來(lái)橫向擴(kuò)充，而CloudFoundry與apps調(diào)用Service是通過(guò)base來(lái)完成這一簡(jiǎn)單的架構(gòu)方法即可。

6、? NATS(Message bus): 從CloudFoundry的總架構(gòu)圖看，位于各模塊中心位置的是一個(gè)叫nats的組件。NATS是由CloudFoundry的架構(gòu)師Derek開(kāi)發(fā)的一個(gè)輕量級(jí)的，支持發(fā)布、訂閱機(jī)制的消息系統(tǒng)。Github開(kāi)源地址是：https://github.com/derekcollison/nats。其核心基于EventMachine開(kāi)發(fā)，代碼量不多，可以下載下來(lái)慢慢研究。CloudFoundry是一個(gè)多模塊的分布式系統(tǒng)，支持模塊自發(fā)現(xiàn)，錯(cuò)誤自檢，且模塊間低耦合。其核心原理就是基于消息發(fā)布訂閱機(jī)制。每個(gè)臺(tái)服務(wù)器上的每個(gè)模塊會(huì)根據(jù)自己的消息類別，向MessageBus發(fā)布多個(gè)消息主題；而同時(shí)也向自己需要交互的模塊，按照需要的信息內(nèi)容的消息主題訂閱消息。譬如：一個(gè)DEA被加入CloudFoundry集群中，它需要向大家吼一下，以表明它已經(jīng)準(zhǔn)備好服務(wù)了，它會(huì)發(fā)布一個(gè)主題是”dea.start”的消息：