深度剖析CloudFoundry的架構設計(4)

下圖是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文件夾中。億恩科技石頭 負責服務器租用和托管業務
聯系人：石頭
QQ：億恩石頭673606008
電話：0371-63322217
手機：18237160419
地址：鄭州市黃河路姚寨路天一大廈B座608室

服務器租用/服務器托管中國五強！虛擬主機域名注冊頂級提供商！15年品質保障！--億恩科技[ENKJ.COM]