[PaaS] 深入 Cloud Foundry(一)构架 (转载)
轉載地址:http://qing.weibo.com/2294942122/88ca09aa330004r8.html
?
深入 Cloud Foundry(一)構架
?EMC中國研究院高級研究員 ?彭麟
引子
今年4月份,VMware突然發布了業內第一個開源的PaaS——CloudFoundry。幾個關鍵字:開源、PaaS、 VMware,如果你對云計算感興趣,就沖著它的ApacheV2協議,如果不去GitHub拿它的代碼好好研讀一下,真有點對不起自己。筆者當時就是以 這樣的心態去研究它的代碼,并把它部署在我們labs里面。發布至今的這幾個月里,筆者一直關注它的演進,并從它的架構設計中獲益良多,覺得有必要寫出來 與大家分享一下。由于個人知識、認知等原因,其中有些看法難免不成熟,大家可以直接批評、指教。
?
本文會分為兩個部份:第一部份主要介紹CloudFoundry的架構設計,從它所包含的模塊介紹起,到各部份的消息流向,各模 塊如何協調合作;第二部份會在第一部份的基礎上,以如何在你的數據中心里面用CloudFoundry部署一個私有PaaS為目標,把第一部分介紹到的架 構知識使用起來。在本文,我不想簡單的介紹如何使用CloudFoundry,這方面的文章,在SpringSource的官方博客里面有具體的介紹。如 果需要這方面的介紹,筆者強烈建議到SpringSource或者CloudFoundry的官博找資料。另外,本文也不會具體介紹如何“貢 獻”Cloud Foundry,例如添加自己的Runtime,添加第三方的Service,這將會是兩個很大的話題,以后我們會有專門的文章介紹,本文更多的算是入門 級的架構介紹,可能會涉及到具體代碼,但是只為更好地理解架構而服務。在第二部份,會簡單介紹到如何用OrchestrationEngine來把 CloudFoundry部署到IaaS上面,但是具體的實現方法將會放到介紹OrchestrationEngine的文章上面去,這里更多的是一種思 想和BestPractice的分享。
?
第一部份講的很多內容,會引用Pat在10月12日的VMwareCloud Forum上面關于CloudFoundry架構的演講。Pat是CloudFoundry Core的負責人,他的那次演講很值得一聽。如果你當時在場,并且理解他所說的內容,本部份可以選擇直接跳過。我除了會把說的內容講具體點外,不太可能可 以講得比他好。
?
一、架構及模塊從總體地看,CloudFoundry的架構如下:
?
?
這個架構圖以及下文所用到的各模塊架構圖均來自Pat的PPT。從上圖能夠看到CloudFoundry主要有以下幾大組件組成:
?
1、? Router:顧名思義,Router組件在CloudFoundry中是對所有進來的Request進行路由。進入Router的request主要有 兩類:首先是來自VMCClient或者STS的,由CloudFoundry使用者發出的,管理型指令。例如:列出你所有apps的vmcapps,提 交一個apps等等。這類request會被路由到AppLife Management組件,又叫CloudController組件去;第二類是外界對你所部署的apps訪問的request。這部份requests 會被路由到Appexecution,又或者叫做DEAs的組件去。所有進入CloudFoundry系統的requests都會經過Router組件, 看到這里可能會有朋友會擔心Router成為單點,從而成為整個云的瓶頸。但是CloudFoundry作為云系統,其設計的核心就是去單點依賴,組件平 行擴充,且可替代的以保證擴展性,這是CloudFoundry,甚至所有云計算系統的設計原則,后文會討論CloudFoundry如何做到這點,目前 只要知道,系統可以部署多個Routers共同處理進來的requests,但是Router上層的LoadBalance不在CloudFoundry 的實現范圍,CloudFoundry只保證所有的request是無狀態的,這樣就使上層均衡附載選擇面非常非常大了,例如可以通過DNS做,也可以部 署硬件的LoadBalancer,或者簡單點,弄臺ngnix作負載均衡器,都是可行的。
?
Router組件,目前版本是對nginx的一個簡單封裝。熟悉ngnix的朋友應該知道,它可以一個套接字文件(.sock文件)作為輸入輸出。所有安裝CloudFoundry的Router組件服務器都會安裝一個nginx,其ngnix.conf文件有以下配置:
?
?
從整體的來看,Router組件的結構如下:
?
?
?
外界httprequest進入CloudFoundry服務器,nginx會首先接到request,nginx通過sock 與router.rb進行交互,于是真正處理請求的是Router組件。router.rb里面根據傳入的url,用戶名密碼等,進行邏輯判斷,到 CloudController組件或者DEA組件取數據并且返通過與niginx連接的.sock文件返回。router.rb是對nginx進行了邏 輯封裝。熟悉CloudFoundry的朋友肯定知道,CloudFoundry給每一個app分配了一個url訪問,如果直接使用VMware所托管的 CloudFoundry.com的話,那你的app的url可能就是xxx.cloudfoundry.com,無論通過命令給你的app擴展了多少個 instances,都是從這個url訪問的,這里面的url轉換路由就是由router.rb實現的。
?
2、? DEA(Droplet Execution Agency): 首先要解析下什么叫做Droplet。Droplet在CloudFoundry的概念里面是指一個把你提交的源代碼,以及CloudFoundry配套 好的運行環境,再加上一些管理腳本,例如Start/Stop這些小腳本全部壓縮好在一起的tar包。還有一個概念,叫做Stagingapp,就是指制 作上面描述這個包,然后把它存儲好的過程。CloudFoundry會自動保存這個Droplet,直到你start一個app的時候,一臺部署了DEA 模塊的服務器會來拿一個Droplet的copy去運行。所以如果你擴展你的app到10個instances,那這個Droplet就被會復制十份,讓 10個DEA服務器拿去運行。
?
下圖是DEA模塊的架構圖:
?
?
?
Cloud Controller模塊(下面會介紹)會發送start/stop等基本的apps管理請求給DEA,dea.rb接收這些請求,然后從NFS里面找到 合適的Droplet。前面說到Droplet其實是一個帶有運行腳本的,帶運行環境的tar包,DEA只需要把它拿過來解壓,并即行里面的start腳 本,就可以讓這個app跑起來。到此,app算是可以訪問,并start起來了,換句話說就是有這臺服務器的某一個端口已經在待命,只要有request 從這個端口進來,這個app就可以接收并返回正確的信息。接著dea.rb要做些善后的工作:1、把這個信息告訴Router模塊。我們前面說到,所有進 入CloudFoundry的requests都是由Router模塊處理并轉發的,包括用戶對app的訪問request,一個app起來后,需要告訴 router,讓它根據loadbalance等原則,把合適的request轉進來,使這個app的instance能夠干起活;2、一些統計性的工 作,例如要把這個用戶又新部署了一個app告訴CloudController,以作quota控制等;3、把運行信息告訴HealthManager模 塊,實時報告該app的instance運行情況。另外DEA還要負責部份對Droplet的查詢工作,譬如,如果用戶通過 CloudController想查詢一個app的log信息,那DEA需要從該Droplet里面取到log返回等等。
?
?
?
3、CloudController:CloudController是CloudFoundry的管理模塊。主要工作包括:
?
a) 對apps的增刪改讀;
b) 啟動、停止應用程序;
c) Staging apps(把apps打包成一個droplet);
d) 修改應用程序運行環境,包括instance、mem等等;
e) 管理service,包括service與app的綁定等;
f) Cloud環境的管理;
g) 修改Cloud的用戶信息;
h) 查看Cloud Foundry,以及每一個app的log信息。
?
?
?
這似乎有點復雜,但簡單的說,可以很簡單:就是與VMC和STS交互的服務器端。VMC和STS與CloudFoundry通信 采用的是restful接口,另一方面CloudController是一個典型的Rubyon Rails項目,從VMC或者STS接到JSON格式的協議,然后寫入CloudController Database,并發消息到各模快去控制管理整個云。和其他ROR項目一樣,CloudController的所有API可以從 conf/routes.rb里看到。開放的Restful接口好處在于第三方應用開發和集成,企業在用CloudFoundry部署私有云的時候,可以 通過這些接口來自動化控制管理整個Cloud環境。這部份內容將在第二部份論述。
?
下圖是Cloud Controller的架構圖:
?
?
?
?
圖中Health Manager和DEA是外部模塊,CCDatabase就是CloudController Database,這個是整個CloudFoundry不能做HP的地方。CloudController Database的并發性不會很多,應用級別的數據庫訪問是由底下的Service模塊處理的,這個數據庫存的是Cloud的配置信息。讀操作主要來自 DEA啟動,作為初始化DEA的依據;以及healthmanager模塊會從這里讀取預期的狀態信息,這部份數據會與從DEA得到的實際狀態信息進行比 對。NFS是多個CloudController的共享存儲,CloudController其中一個重要工作就是StagingApps。 Droplets的存儲是在集群環境的唯一的。而CloudController是集群運行,換言之,就是每一個控制Request可能由不同的 CloudController處理,假設一個簡單的用戶場景:我們需要部署一個app到CloudFoundry中。我們在敲完那條簡單的push命令 后,VMC開始工作,在做完一輪的用戶鑒權、查看所部署的apps數量是否超過預定數額,問了一堆相關app的問題后,需要發4個指令:
?
1.發一個POST到”apps”,創建一個app;
2.發一個PUT到”apps/:name/application”,上傳app;
3.發一個GET到”apps/:name/”,取得app狀態,看看是否已經啟動;
4.如果沒有啟動,發一個PUT到”apps/:name/”,使其啟動。
?
?
如果第2和第4步由不同的Cloud Controller來處理,而又無法保證他們能找到同一個Droplet,那第4步將會因為找不到對應的Droplet而啟動失敗。如何保證這一連串指 令過來所指向的Droplet都是同一個呢?使用NFS,使CloudController共享存儲是最簡單的方法。但是這個方法在安全性等方面并不完 美。在10月12日的VMwareCloud Forum上,Pat告訴我們下一版本的CloudFoundry這里將會有大調整,但是在那部份代碼公開前,我不方便在這評價太多。
?
?
4、? HealthManager: 做的事情不復雜,簡單的說是從各個DEA里面拿到運行信息,然后進行統計分析,報告等。統計數據會與CloudController的設定指標進行比對, 并提供Alert等。HealthManager模塊目前還不是十分完善,但是CloudManage棧里面,自動化health管理、分析是一個很重要 的領域,而這方面可以擴展的地方也很多,結合OrchestrationEngine可以使云自管理、自預警;而與BI方面技術結合,可以統計運營情況, 合理分配資源等。這方面CloudFoundry還在發展之中。
?
5、? Services:Cloud Foundry的Service模塊從源代碼控制上看就知道是一個獨立的、可Plugin的模塊,以方便第三方把自己的服務整合入 CloudFoundry生態系統。在Github上看到service是與CloudFoundry Core項目vcap獨立的一個repository,為vcap-service。Service模塊其中設計原則是方便第三方服務提供商提供服務。在 這方面CloudFoundry做得很成功,從Github上看,已經有以下服務提供:a)MongoDB; b) mysql; c) neo4j; d) PostgreSql; e) RabbitMQ; f) Redis; g)vBlob。基類都是放在base文件夾中。 第三方如果需要自己開發CloudFoundry的服務,需要繼承改寫它里面的兩個基礎類:Node和Gateway;而里面一些操作, 如:Provision,可以在base的provisioner.rb基礎上加入自己的邏輯,同樣的還有Service_Error和 Service_Message等。關于如何寫自己的Service,ELC的博客會推出相應文章詳細論述,并不在本文的討論范圍里面,從架構了解上來 說,只要知道服務間的關系,知道個服務與base間透過繼承關系來橫向擴充,而CloudFoundry與apps調用Service是通過base來完 成這一簡單的架構方法即可。
?
6、? NATS(Message bus): 從CloudFoundry的總架構圖看,位于各模塊中心位置的是一個叫nats的組件。NATS是由CloudFoundry的架構師Derek開發的 一個輕量級的,支持發布、訂閱機制的消息系統。Github開源地址是:https://github.com/derekcollison/nats。 其核心基于EventMachine開發,代碼量不多,可以下載下來慢慢研究。CloudFoundry是一個多模塊的分布式系統,支持模塊自發現,錯誤 自檢,且模塊間低耦合。其核心原理就是基于消息發布訂閱機制。每個臺服務器上的每個模塊會根據自己的消息類別,向MessageBus發布多個消息主題; 而同時也向自己需要交互的模塊,按照需要的信息內容的消息主題訂閱消息。譬如:一個DEA被加入CloudFoundry集群中,它需要向大家吼一下,以 表明它已經準備好服務了,它會發布一個主題是”dea.start”的消息:
?
?
@ hello_message_json中包括DEA的UUID,ip, port, 版本信息等內容。
?
再例如,CloudController需要啟動一個Droplet的instance:
a) ?首先一個DEA在啟動的時候,會首先會對自己UUID的消息主題進行訂閱。
??其他模塊需要通過’’dea.#{uuid}.start”這個主題發送消息來使它啟動,一旦這個DEA接收到消息,就會觸發process_dea_start(msg)這個方法來處理啟動所需要的工作。
?
b) ?Cloud Controller或者其他模塊發送消息,讓UUID為xxx的DEA啟動。
?
?
?
c)??DEA模塊接收到消息后,就會觸發process_dea_start(msg)方法。msg是由其他模塊發送過來的消 息內容,包括:droplet_id,instance_index, service, runtime等內容,process_dea_start會取得這些啟動DEA必須的信息,然后進行一系列操作,例如從NFS中取得Droplet,解 壓,修改必要環境配置,運行啟動腳本等等。等一切都準備好后,然后需要給Router發個消息,告訴它這個Droplet已經隨時準備好報效國家,以后有 相應的request記得讓它來處理。
?
?
?
d) ?Router模塊在啟動時就已經訂閱”router.register”消息主題。
?
?
收到前面DEA發出的信息后,會觸發register_droplet方法,去綁定Droplet。到此啟動一個Droplet的instance工作完成。
?
我們可以看到整個CloudFoundry的核心就是一套消息系統,如果想了解CloudFoundry的來龍去脈,去跟蹤它里 面復雜的消息機制是非常好的方法。另一方面,CloudFoundry是一套基于消息的分布式系統,面向消息的架構是它節點橫向擴展,組件自發現等云特性 的基礎。
?
?
?
?
?
Cloud Foundry的架構簡單介紹至此,其實作為第一款開源的PaaS,CloudFoundry架構有很多可以學習借鑒的地方,很多細節上的處理是很精妙 的,這些內容如果有可能會在后續文章繼續探討,本文題雖為深入CloudFoundry,其實也只是淺嘗即止,把總體架構介紹一下,目標在于使我們有足夠 的背景知識去用CloudFoundry搭建企業內部的私有PaaS。總結一下,筆者從CloudFoundry的結構中學到的東西:
?
1、? 基于消息的多組件架構是實現集群的簡單、且有效方法。消息可以使集群節點間解耦,使自注冊,自發現這些在大規模數據中心中很重要的功能得到實現;
2、? 適當的抽象層,模板模式的使用,方便第三方可以方便在CloudFoundry開發擴展功能。CloudFoundry在DEA及Service層都做了 抽象層處理,相對應地使開發者可以容易地為CloudFoundry開發Runtime和Service。例如,在CloudFoundry剛推出的時 候,只支持Node.js,Java, Ruby,但第三方提供商、開源社區快速跟進,為CloudFoundry添加了PHP,Python的支持。這得益于CloudFoundry精巧的 DEA架構設計,如何開發新的Runtime支持,會在后續博文中有所論述.
?
?
二、源碼導讀
?
筆者一直覺得深入理解一個技術的最好方法就是讀它的源碼,而CloudFoundry是完全開源的PaaS平臺,而因為剛發展起 來,代碼量不多,主要作者們的代碼功力也相當不錯,讀起來很舒服,很適合研讀。而不得不再次表揚一下它完全基于消息機制的架構設計,對組件擴展性,第三方 接入等方面做得很好,讀者可以從中學到不少思想性的東西。筆者很推薦大家去讀一下它的源代碼。你可以在Github上找到CloudFoundry的全部 代碼:https://github.com/cloudfoundry,你會看到幾個不同的Repositories,它們分別是:
?
1、vcap: Cloud Foundry的Core,又或者稱作Kernel;
2、vcap-service: Cloud Foundry的Service組件。Cloud Foundry的service是作為插件提供的,這出于它方便第三方開發service而設計的;
3、vmc: VMware Cloud CLI. 是一個Ruby應用,與Cloud Foundry的CLI交互。主要通過分析用戶輸入的CLI,向CloudFoundry發送Restful請求;
4、vcap-java: 如果你的app是用java開發,且需要與Cloud Foundry交互,例如取得當前serviceserver的ip地址等,你可能需要這個jar,里面對我們Java開發常用框架有所支持,它底層也是 對CloudFoundry的Restful請求的包裝;
5、vcap-java-client: Cloud Foundry的Restful API的Java封裝,與上面的項目不一樣,它只是個簡單的讀取CloudFoundry信息,并放如JavaBean中;
6、vcap-test: Cloud Foundry的test cases;
7、vcap-test-assets: Cloud Foundry一些apps示例。
轉載于:https://www.cnblogs.com/licheng/archive/2012/03/07/2383380.html
總結
以上是生活随笔為你收集整理的[PaaS] 深入 Cloud Foundry(一)构架 (转载)的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: check_mk自定义监控实践之powe
- 下一篇: (转)ubuntu 文件系统