Could Foundry學習（二）——核心組件分析

標籤：blog   http   io   使用   ar   strong   檔案   sp   2014   

Cloud Foundry核心組件架構圖如下：

主要組件：

    Cloud Controller：實質上是VMC和STS互動的伺服器端，它收到指令後發訊息到各模快，管理整個雲的運行，相當於Cloud Foundry的大腦。

    DEA：負責處理對所部署的App的訪問請求，其實質是打包和訪問Droplet。其中Droplet是通過Stager組件將提交的原始碼及Cloud Foundry配置好的運行環境以及一些控制指令碼等，全部打包在一起形成的tar檔案。

    Routers：對所有進來的請求進行路由控制。Router組件是可擴充的，由多個 Router共同處理進來的請求。但如何對Router做負載平衡不屬於Cloud Foundry的實現範圍。

       進入Router的請求主要有兩類。

• 第一類是來自VMC Client或者STS的，由Cloud Foundry使用者發出，叫做管理請求。這類請求會被路由到Cloud Controller組件處理。
• 第二類是對所部署的App的訪問請求。這部分請求會被路由到App execution，即DEA組件中。

    Health Manager：負責從各個DEA獲得運行資訊，然後進行統計分析、報告、發出警示等。

    Services：負責提供雲平台的各種應用服務，是一個獨立的、外掛程式式的模組，便於第三方方便地把自己的服務整合成Cloud Foundry服務。

輔助組件：

    UAA：負責使用者模型的認證，使用組織和使用者空間等概念，利於使用者及許可權管理。另外UAA DB用於儲存使用者相關資訊。

    NATS：是一個基於事件驅動的、輕量級的訊息系統，用於訊息發布和訂閱，聯絡著各個模組。

    Stager：解決了打包（Stage）過程需要操作大量檔案且操作時間長的問題，所以它作為獨立進程，使打包工作非同步進行，不阻塞作為核心組件的Cloud Controller。

Could Foundry學習（二）——核心組件分析