cloud_controller_ng簡介
cloud_controller_ng是Cloud Foundry v2版本中的一個重要組件。其中cloud_controller_ng是cloud_controller的next generation（ng）的含義，而cloud_controller_ng的設計不兼容原先老版的cloud_controller。老版本的cloud_controller採用Rails的MVC框架來實現，而cloud_controller_ng則採用Sinatra框架來實現，從實現角度來講，更加輕量級。該版本的cloud_controller_ng還添加了很多重要的概念，比如app以及service必須使用的space和organization等。爲簡單起見，下文中以ccng代替cloud_controller_ng。
cloud_controller_ng架構圖
以下是筆者通過對ccng源碼的理解，自行描繪的ccng簡單架構圖。
從ccng架構圖中可以看出ccng可以分爲以下多個模塊：
- DEA模塊，主要負責與DEA組件進行交互；
- Stager模塊，主要負責與DEA組件的staging部分進行交互；
- Blobstore模塊，主要負責創建一個blobstore的存儲，以供Cloud Foundry存儲應用所需的靜態文件；
- HealthManager（HM）模塊，主要負責與HealthManager組件進行交互；
- CCDB模塊，負責維護cloud_controller的數據庫；
- collector_registrar模塊，負責作爲component向Collector組件註冊；
- router_registrar模塊，負責將cloud controller組件的域名註冊至Router組件；
- legacy_api部分，負責接管ccng關於info，bulk以及services等的RESTful請求；
- 其他部分。
下文將從以上提及的多個模塊，逐步剖析ccng的架構實現。
cloud_controller_ng之Stager模塊
Stager模塊的功能是負責管理應用的源碼和buildpack進行捆綁打包，而最終打包後的形式爲droplet。
在Cloud Foundry v1的版本中，對於一個Cloud Foundry雲平臺只有一個Stager組件。而在Cloud Foundry v2版本中，由於已經不存在原來獨立的Stager組件，而將和Stager功能類似的staging模塊設計成DEA的一個子模塊。因此，如果v2版本的Cloud Foundry部署了多個DEA的話，那麼該雲平臺中就會有多個Staging模塊。正是由於有多個Staging模塊的緣故，在ccng處設計了一個與這些Staging進行交互的模塊，可以姑且稱之爲ccng的stager模塊，該模塊維護了一個stager
資源池，即stager_pool，並通過stager_pool來接收和分發有關staging任務的請求。
當有staging任務需要完成時，需要創建一個staging_request,該方法的實現位於：/cloud_controller_ng/lib/cloud_controller/app_stager_task.rb,代碼如下:
# We never stage if there is not a start request
def staging_request
{ :app_id => @app.guid,
:task_id => task_id,
:properties => staging_task_properties(@app),
# All url generation should go to blobstore_url_generator
:download_uri => @blobstore_url_generator.app_package_download_url(@app),
:upload_uri => @blobstore_url_generator.droplet_upload_url(@app),
:buildpack_cache_download_uri => @blobstore_url_generator.buildpack_cache_download_url(@app),
:buildpack_cache_upload_uri => @blobstore_url_generator.buildpack_cache_upload_url(@app),
:start_message => start_app_message,
:admin_buildpacks => admin_buildpacks
}
end- app_id:創建的應用的id；
- task_id:相應的staging_task的id；
- properties:應用的基本屬性等，比如使用資源，應用環境，使用服務等；
- download_uri:在blobstore中存儲的應用源碼app_package；
- upload_uri:最後打包成droplet之後，上傳該droplet所使用的uri；
- buildpack_cache_download_uri:在blobstore中存儲的該app所需要的buildpack的下載uri；
- buildpack_cache_upload_uri:buildpack上傳的uri；
- start_message:啓動該app所需要的基本信息，最終由DeaClient類的start_app_message方法來實現；
- admin_buildpacks:提供admin_bulidpack的下載uri。
除了創建staging_request，還需要從stager_pool中找出合適的stager來完成staging任務，找到合適的stager_id之後，即向該staging發送staging_request。
cloud_controller_ng之DEA模塊
DEA模塊的功能是負責ccng與衆DEA之間通信。
在ccng中，DEA模塊可以大致氛圍三個部分：dea_client,dea_pool和dea_respondent。
dea_client
dea_client主要負責作爲一個client，實現發送請求給DEA。當有請求到達ccng，ccng需要獲取dea上應用的信息時，ccng都需要通過dea_client來完成發送請求。比如說：需要啓動一個應用時，由dea_client來給DEA發送start請求；需要停止一個應用時，由dea_client來給DEA發送一個stop請求等。
dea_respondent
dea_respondent主要負責作爲一個響應者，實現完成由DEA主動發送過來的請求。這類請求主要是當DEA中的應用退出的時候，會由DEA通過NATS想ccng發送應用退出的消息，從而ccng可以做後續相應的善後工作。
dea_pool
dea_pool主要負責維護Cloud Foundry中所有DEA的資源池。當Cloud Foundry中有新的DEA啓動並開始工作時，都會通過NATS向ccng發佈advertise信息，而ccng則通過發來的該部分信息向dea_pool中註冊DEA信息。當有應用需要啓動的時候，ccng需要找到合適的DEA來完成啓動工作，這個時候則由dea_pool通過各DEA的資源使用情況等其他重要條件完成DEAs的篩選，找出符合條件的DEA。
cloud_controller_ng之blobstore模塊
blobstore模塊主要負責維護靜態文件的存儲，這部分文件主要分爲三部分：
- 應用源碼
- 應用buildpack
- staged應用，即droplet
cloud_controller_ng之HM模塊
HM模塊主要負責與health_manager建立通信，並完成有關應用健康狀態的監控。該部分也可以簡單分爲兩部分，一個爲client，一個爲respondent：- health_manager_client:主要負責充當ccng與health_manager進行通信的client端，通過messagebus初始化，並通過messagebus實現find_crashes,find_flapping_indices,health_instances三個功能。
- health_manager_respondent:主要負責接收ccng與health_manager通信過程中health_manager發來的信息，其中包含，health_manager要求ccng啓動某些擁有，停止某些應用等。
其中關於HM模塊，目前的ccng中包含有兩個不同形式的HM，一個health_manager模塊，另一個爲hm_9000模塊。
以上便是本文對cloud_controller_ng架構的簡單解析。
關於作者：
孫宏亮，DAOCLOUD軟件工程師。兩年來在雲計算方面主要研究PaaS領域的相關知識與技術。堅信輕量級虛擬化容器的技術，會給PaaS領域帶來深度影響，甚至決定未來PaaS技術的走向。
轉載請註明出處。
本文更多出於我本人的理解，肯定在一些地方存在不足和錯誤。希望本文能夠對接觸Cloud Controller架構的人有些幫助，如果你對這方面感興趣，並有更好的想法和建議，也請聯繫我。
我的郵箱：[email protected]
新浪微博：@蓮子弗如清
