深度剖析CloudFoundry的架構設計

1、深度剖析CloudFoundry的架構設計2011-10-27 13:23 來源:博客VMware在今年4月份突然發(fā)布了業(yè)內第一個開源的 PaaSCloudFoundry。發(fā)布至今 的這幾個月里，筆者一直關注它的演進， 并從它的架構設計中獲益良多， 覺得有必要寫出來 與大家分享一下。本文會分為兩個部份：第一部份主要介紹CloudFoundry的架構設計，從它所包含的模塊介紹起，到各部份的消息流向，各模塊如何協(xié)調合作；第二部份會在第一部份的基礎上， 以如何在你的數(shù)據(jù)中心里面用CloudFoundry部署一個私有PaaS為目標，把第一部分介紹到的架構知識使用起來。第一部份講的很多內容，會引用Pat

2、在10月12日的VMwareCloud Forum上面關于CloudFoundry架構的演講。Pat是CloudFoundry Core的負責人，他的那次演講很值得一聽。 如果你當時在場，并且理解他所說的內容，本部份可以選擇直接跳過。我除了會把說的內容講具體點外，不太可能可以講得比他好。從總體地看，CloudFoundry的架構如下、架構及模塊appsapp lifecycle managementapp executionservjceIrfecycleblQbstoreservice instancesrauth/:router1 t這個架構圖以及下文所用到的各模塊架構圖均來自Pat的PP

3、T從上圖能夠看到CloudFoundry主要有以下幾大組件組成：1、Router :顧名思義，Router組件在 CloudFoundry中是對所有進來的Request進行路由。進入 Router的request主要有兩類：首先是來自VMCClient或者STS的，由CloudFoundry使用者發(fā)出的，管理型指令。例如：列出你所有 apps的vmcapps,提交一個apps等等。這類request會被路由到 AppLife Management組件，又叫CloudController組件去；第二類是外界對你所部署的apps訪問的request。這部份requests 會被路由到 Appexe

4、cution，又或者叫做 DEAs的組件去。 所有進入CloudFoundry系統(tǒng)的requests都會經(jīng)過Router組件，看到這里可能會有朋友會 擔心Router成為單點，從而成為整個云的瓶頸。但是CloudFoundry作為云系統(tǒng)，其設計的核心就是去單點依賴，組件平行擴充，且可 替代的以保證擴展性，這是CloudFoundry，甚至所有云計算系統(tǒng)的設計原則，后文會討論CloudFoundry如何做到這點，目前只要知道，系統(tǒng)可以部署多個Routers共同處理進來的requests，但是 Router 上層的 LoadBalanee 不在 CloudFoundry 的實現(xiàn)范圍，CloudFo

5、undry 只保證所有的request是無狀態(tài)的，這樣就使上層均衡附載選擇面非常非常大了，例如可以通過DNS做，也可以部署硬件的LoadBalancer，或者簡單點，弄臺 ngnix作負載均衡器，都是可行的。Router組件，目前版本是對nginx的一個簡單封裝。熟悉ngnix的朋友應該知道，它可以一個套接字文件（.sock文件）作為輸入輸出。所有安裝CloudFoundry的Router組件服務器都會安裝一個nginx，其ngnix.conf 文件有以下配置：upstream vcp router server uniXT/tmo/route r sock；從整體的來看，Router組件的結

6、構如下:routerhttp reques-trequesl外界httprequest 進入CloudFoundry 服務器，nginx會首先接到request , nginx通過 sock與router.rb 進行交互，于是真正處理請求的是Router組件。router.rb 里面根據(jù)傳入的url ,用戶名密碼等，進行邏輯判斷，至UCloudController 組件或者DEA組件取數(shù)據(jù)并且返通過與niginx連接的.sock文件返回。router.rb 是對nginx進行了邏輯封裝。熟悉CloudFoundry的朋友肯定知道，CloudFoundry給每一個app分配了一個url訪問，如果

7、直接使用VMware所托管的CloudF 的話，那你的 app的url可能就是 ，無論通過命 令給你的app擴展了多少個instances，都是從這個url訪問的，這里面的url轉換路由就 是由router.rb 實現(xiàn)的。2、DEA(Droplet Execution Agency):首先要解析下什么叫做Droplet 。 Droplet 在CloudFoundry的概念里面是指一個把你提交的源代碼，以及CloudFoundry配套好的運行環(huán)境，再加上一些管理腳本，例如 Start/Stop 這些小腳本全部壓縮好在一起的 tar包。還有 一個概念，叫做 Stagingapp ,就是指制作上面描

8、述這個包，然后把它存儲好的過程。CloudFoundry會自動保存這個 Droplet，直到你start 一個app的時候，一臺部署了 DEA模塊的服務器會來拿一個Droplet的copy去運行。所以如果你擴展你的 app到10個instances，那這個Droplet就被會復制十份，讓10個DEA服務器拿去運行。下圖是DEA模塊的架構圖：fetch dropletsstart/top rnsianceadirectcommunicationwith servicesCloud Controller 模塊（下面會介紹）會發(fā)送 start/stop等基本的apps管理請求給DEA dea.rb接

9、收這些請求，然后從NFS里面找到合適的 Droplet。前面說到 Droplet其實是一個帶有運行腳本的，帶運行環(huán)境的tar包，DEA只需要把它拿過來解壓，并即行里面的start腳本，就可以讓這個 app跑起來。到此，app算是可以訪問，并 start起來了，換句 話說就是有這臺服務器的某一個端口已經(jīng)在待命，只要有request從這個端口進來，這個app就可以接收并返回正確的信息。接著dea.rb要做些善后的工作：1、把這個信息告訴 Router模塊。我們前面說到，所有進入CloudFoundry的requests都是由Router模塊處理并轉發(fā)的，包括用戶對app的訪問request，一個a

10、pp起來后，需要告訴 router，讓它根據(jù)loadbalanee 等原則，把合適的 request轉進來，使這個app的instanee能夠干起活；2、一些統(tǒng)計性的工作，例如要把這 個用戶又新部署了一個app告訴CloudController ，以作quota控制等；3、把運行信息告訴HealthManager模塊，實時報告該 app的instanee 運行情況。另外 DEA還要負責部份對 Droplet的查詢工作，譬如，如果用戶通過CloudController想查詢一個 app的log信息,那DEA需要從該Droplet里面取到log返回等等。3、CloudController : Cl

11、oudController是 CloudFoundry 的管理模塊。主要工作包括：a）對apps的增刪改讀；b）啟動、停止應用程序；c）Staging apps（把 apps 打包成一個 droplet ）;d）修改應用程序運行環(huán)境，包括instanee、mem等等；e）管理 service，包括 service 與 app 的綁定等；f）Cloud 環(huán)境的管理；g）修改Cloud的用戶信息；h）查看Cloud Foundry，以及每一個 app的log信息。這似乎有點復雜，但簡單的說，可以很簡單：就是與VMC和STS交互的服務器端。VMC和STS與CloudFoundry通信采用的是 res

12、tful 接口，另一方面 CloudController是一個典型的Rubyon Rails項目，從VMC或者STS接到JSON格式的協(xié)議，然后寫入 CloudController Database，并發(fā)消息到各?？烊タ刂乒芾碚麄€云。和其他 RO顧目一樣，CloudController 的所有API可以從conf/routes.rb里看到。開放的 Restful接口好處在于第三方應用開發(fā)和集成，企業(yè)在用CloudFoundry部署私有云的時候，可以通過這些接口來自動化控制管理整個Cloud環(huán)境。這部份內容將在第二部份論述。F圖是Cloud Controller的架構圖:starVslop in

13、stancesfetch droplets圖中 Health Manager 和 DEA是外部模塊，CCDatabase 就是 CloudController Database， 這個是整個 CloudFoundry 不能做HP的地方。CloudController Database的并發(fā)性不會很多，應用級別的數(shù)據(jù)庫訪問是由底下的Service模塊處理的，這個數(shù)據(jù)庫存的是 Cloud的配置信息。讀操作主要來自DEA啟動，作為初始化DEA的依據(jù)；以及healthmanager模塊會從 這里讀取預期的狀態(tài)信息，這部份數(shù)據(jù)會與從DEA得到的實際狀態(tài)信息進行比對。NFS是多個CloudControll

14、er的共享存儲，CloudController其中一個重要工作就是StagingApps 。 Droplets 的存儲是在集群環(huán)境的唯一的。而CloudController是集群運行，換言之，就是每一個控制Request可能由不同的CloudController 處理，假設一個簡單的用 戶場景：我們需要部署一個app到CloudFoundry中。我們在敲完那條簡單的push命令后，VMC開始工作，在做完一輪的用戶鑒權、查看所部署的apps數(shù)量是否超過預定數(shù)額，問了一堆相關app的問題后，需要發(fā) 4個指令：1 .發(fā)一個 POST到” apps”，創(chuàng)建一個 app;2. 發(fā)一個 PUT至apps/

15、:name/application”，上傳 app;3. 發(fā)一個GET到apps/:name/ ”，取得app狀態(tài)，看看是否已經(jīng)啟動；4. 如果沒有啟動，發(fā)一個PUT到” apps/:name/ ”，使其啟動。如果第2和第4步由不同的Cloud Controller來處理，而又無法保證他們能找到同一個Droplet，那第4步將會因為找不到對應的Droplet而啟動失敗。如何保證這一連串指令過來所指向的Droplet都是同一個呢？使用 NFS使CloudController共享存儲是最簡單的方法。但是這個方法在安全性等方面并不完美。在10月12日的VMwareCloud Forum上，Pat告訴

16、我們下一版本的CloudFoundry這里將會有大調整，但是在那部份代碼公開前，我不方便在這評價太多。4、HealthManager:做的事情不復雜，簡單的說是從各個 DEA里面拿到運行信息，然后進行統(tǒng)計分析，報告等。統(tǒng)計數(shù)據(jù)會與 CloudController的設定指標進行比對，并提供Alert等。HealthManager模塊目前還不是十分完善，但是CloudManage棧里面，自動化 health管理、分析是一個很重要的領域，而這方面可以擴展的地方也很多，結合OrchestrationEngine可以使云自管理、自預警；而與 BI方面技術結合，可以統(tǒng)計運營情況，合理分配資源等。這方面Cl

17、oudFoundry還在發(fā)展之中。5、 Services:Cloud Foundry的Service模塊從源代碼控制上看就知道是一個獨立的、可Plugin的模塊，以方便第三方把自己的服務整合入CloudFoundry生態(tài)系統(tǒng)。在 Github上看至U service 是與 CloudFoundry Core 項目 vcap 獨立的一個 repository ，為 vcap-service 。 Service模塊其中設計原則是方便第三方服務提供商提供服務。在這方面CloudFoundry做得很成功，從 Github上看，已經(jīng)有以下服務提供：a)MongoDB; b) mysql; c) neo4

18、j; d)PostgreSql; e) RabbitMQ; f) Redis; g)vBlob?；惗际欠旁?base 文件夾中。第三方如果需要自己開發(fā)CloudFoundry的服務，需要繼承改寫它里面的兩個基礎類：Node 和 Gateway;而里面一些操作，如：Provision ，可以在 base 的 provisioner.rb 基礎上加入自己的邏輯，同樣的還有 Service_Error 和Service_Message等。關于如何寫自己的Service , ELC的博客會推出相應文章詳細論述，并不在本文的討論范圍里面，從架構了解上來說，只要知道服務間的關系，知道個服務與base間透

19、過繼承關系來橫向擴充，而CloudFoundry與apps調用Service是通過base來完成這一簡單的架構方法即可。6、NATS(Message bus):從CloudFoundry的總架構圖看，位于各模塊中心位置的是一 個叫nats的組件。NATS是由CloudFoundry的架構師Derek開發(fā)的一個輕量級的，支持發(fā) 布、訂閱機制的消息系統(tǒng)。Github 開源地址是： 其核心基于EventMachine開發(fā)，代碼量不多，可以下載下來慢慢研究。CloudFoundry是一個多模塊的分布式系統(tǒng)，支持模塊自發(fā)現(xiàn)，錯誤自檢，且模塊間低 耦合。其核心原理就是基于消息發(fā)布訂閱機制。每個臺服務器上的

20、每個模塊會根據(jù)自己的消息類別，向MessageBus發(fā)布多個消息主題；而冋時也向自己需要交互的模塊，按照需要的 信息內容的消息主題訂閱消息。譬如：一個DEA被加入CloudFoundry集群中，它需要向大家吼一下，以表明它已經(jīng)準備好服務了，它會發(fā)布一個主題是”dea.start ”的消息：NATS.piiD!ishj dea.start'r 阻h巳 o vne5sage json) hello_message_json 中包括 DEA的 UUID,ip, port, 版本信息等內容。再例如，CloudController需要啟動一個 Droplet 的 instanee :a) 首先一

21、個DEA在啟動的時候，會首先會對自己UUID的消息主題進行訂閱。NATS.sutascrjbeCd&a.sfuuidlstdn") I I msg I process d電 startimsgj其他模塊需要通過dea.#uuid.start”這個主題發(fā)送消息來使它啟動，一旦這個DEA接收到消息，就會觸發(fā)process_dea_start(msg)這個方法來處理啟動所需要的工作。b) Cloud Controller或者其他模塊發(fā)送消息，讓UUID為xxx的DEA啟動。N ATS,pu bi I shf'de a tdea J d. start", ispn)

22、c) DEA模塊接收到消息后，就會觸發(fā)process_dea_start(msg) 方法。msg是由其他模塊發(fā)送過來的消息內容，包括：droplet_id,i nsta nce_i ndex, service, run time等內容，process_dea_start會取得這些啟動 DEA必須的信息，然后進行一系列操作，例如從 NFS中取得Droplet，解壓，修改必要環(huán)境配置，運行啟動腳本等等。等一切都準備好后，然后需 要給Router發(fā)個消息，告訴它這個 Droplet已經(jīng)隨時準備好報效國家，以后有相應的 request記得讓它來處理。NATS.publishs'rDut&

23、;cresister', :=> VCAP;:CompQnent,uurd.:host =? lot道 I ip,:port => instance:port|r刪options! 11 instance! :url5J,:tags 二鼻rframework -> inEtancerframeworkj:runtime => instance:runtime.to json)d) Router模塊在啟動時就已經(jīng)訂閱” router.register”消息主題。NATS.subscribe' router.register i ' |nnp has

24、h = Yail：!p3rser.par5e( itiEh ：5VEtx>li?o keys =>return *jui oris - riiifit hrtshhuris訓總丄則* 附蟄 1st 電匚由opl 電 tfmrl,Msg_h 的 h岀 ertpn 年:tagMU收到前面DEA發(fā)出的信息后，會觸發(fā)register_droplet 方法，去綁定 Droplet。到此啟動一個Droplet的instanee 工作完成。如果想了解 CloudFoundryCloudFoundry 是組件自發(fā)現(xiàn)等云特性的基PaaS CloudFoundry 架我們可以看到整個 CloudFou

25、ndry的核心就是一套消息系統(tǒng)，的來龍去脈，去跟蹤它里面復雜的消息機制是非常好的方法。另一方面, 一套基于消息的分布式系統(tǒng)，面向消息的架構是它節(jié)點橫向擴展, 礎。Cloud Fou ndry的架構簡單介紹至此，其實作為第一款開源的這些內容如果有可能會在后構有很多可以學習借鑒的地方，很多細節(jié)上的處理是很精妙的，續(xù)文章繼續(xù)探討，本文題雖為深入CloudFoundry，其實也只是淺嘗即止，把總體架構介紹一下，目標在于使我們有足夠的背景知識去用CloudFoundry搭建企業(yè)內部的私有 PaaS總結一下，筆者從 CloudFoundry的結構中學到的東西:1、基于消息的多組件架構是實現(xiàn)集群的簡單、且有效方法。消息可以使集群節(jié)點間解耦，使自注冊，自發(fā)現(xiàn)這些在大規(guī)模數(shù)據(jù)中心中很重要的功能得到實現(xiàn);2、適當?shù)某橄髮?，模板模式的使用，方便第三方可以方便在CloudFoundry開發(fā)擴展功能。CloudFoundry在DEA及Service層都做了抽象層處理，相對應地使開發(fā)者可以容易地 為CloudFoundry開發(fā)Runtime和Service。例如，在 CloudFoundry剛推出的時候，只支持Node.js,Java, Ruby，但第三方提供商、開源社區(qū)快速跟進，為CloudFoundry添加了PHP,Python的支持。這得益于 CloudFound