今年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啟動。

GPU云服務器 云服務器 cloud-foundry Cloud Foundry 部署解決方案 Foundry Cloud

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://m.specialneedsforspecialkids.com/yun/3976.html

• 上一篇：深入Cloud Foundry（下）
• 下一篇：中外對比：國內云計算平臺的三大特點