1. 定義
Cloud Foundry是業界第一個開源PaaS雲平臺，它支持多種框架、語言、運行時環境、雲平臺及應用服務，使開發人員能夠在幾秒鐘內進行應用程序的部署和擴展，無需擔心任何基礎架構的問題。
2.PaaS
PaaS，平臺即服務。是雲計算的一種服務形式。其實並不是一個非常新的概念，像GAE、SAE很早就提供了類似這樣的服務。不過在很長一段時間內，PaaS接受程度不高，在跟客戶談及雲計算時，普遍都認爲雲計算就是IaaS，即基礎設施服務。但是隨着雲計算的不斷髮展，用戶發現光有IaaS，雖然簡化了對基礎設施資源的管理，但是對雲計算的終端用戶來說通過IaaS只是拿到了一個裸操作系統，要想開發一個軟件並部署到雲平臺上，還需要做很多工作。包括代碼的管理、持續集成、自動化測試、交付物管理、應用託管、中間件服務、自動化運維、監控報警、日誌處理等等。用戶希望通過一個平臺能夠真正簡化開發、測試、部署、運維等工作，使得企業能夠真正實現DevOps。
3. CloudFoundary基本介紹
Cloud Foundry是一個工業級開源PaaS，它可以部署爲一個雲，並對外提供多語言多框架、應用運行環境及服務。CF的社區相對還是比較活躍的，並且版本迭代比較快，一般1，2周就會發佈一個小版本。而且CF在不斷的改進和優化自身的架構，到目前爲止已經經歷了CF V1，CF V2以及CF V3。每一次大版本的發佈都對CF進行了性能和架構上的優化。
4.Cloudfoundry架構及相關組件
1、 軟件路由和軟負載均衡
Haproxy、Gorouter：
Router將平臺流量分發給特定的組件，通常爲Cloud Controller，或者運行在DEA節點上的應用。
2、 認證和授權
UAA、Login Server：
UAA與Login Server主要提供用戶身份認證管理服務
3、 應用生命週期管理
Cloud Controller、Health Manager：
當開發者將一個應用push到cloud foundry後，Cloud Controller會存儲應用文件，在數據庫中創建應用的元數據記錄，並指派DEA節點來stage及運行應用。Cloud Controller同時還維護了組織、空間、服務、服務實例、用戶角色等記錄信息。
監控應用以確認其運行狀態（例如running\stopped\crashed等）、版本以及實例個數。HM9000根據運行應用的DEA返回的心跳（heartbeats）及droplet.exited消息來更新應用的實際運行狀態。
確認應用的期望運行狀態、版本及實例個數。HM9000從CCDB中獲取應用的期望運行狀態。
使應用的期望運行狀態和實際運行狀態一致。例如，如果實際運行的實例個數少於期望運行的實例個數，HM9000就會指示Cloud Controller啓動準確的應用實例個數。
指示Cloud Controller修復任何應用狀態的差異。
4、 應用存儲和運行
Blob Store、Dea：
DEA負責管理應用實例，跟蹤已啓動的應用實例，並廣播其運行狀態的消息。
Blob store保存了應用代碼、Buildpacks（應用依賴的runtime、web server、framework等的集合）以及Droplets（已完成stage的可直接在DEA上運行的應用包）。
5、 服務
Service Broker：
應用往往依賴於數據庫或第三方服務。
當開發者需要創建一個服務實例並將其與某個應用綁定，該服務的Service Broker負責提供這個服務實例。
例如應用需要使用MySQL數據庫服務，MySQL服務的Service Broker負責創建一個MySQL服務實例，並將該服務實例與應用綁定。
6、 消息
Nats：
Cloud Foundry使用NATS進行組件間的內部通信。
NATS是一種輕量級的、基於發佈-訂閱機制的分佈式隊列消息系統。
7、 日誌和監控數據
Metrics Collector、App Log Aggregator：
計量數據收集器從各組件收集計量數據。運維人員可以使用這些信息對整個Cloud Foundry平臺進行監控。
應用日誌彙集器（loggregator）可以將應用日誌輸出給開發者。
在Cloudfoundry平臺上，應用如何被部署運行的？
-
開發者切換到應用根目錄，使用命令行工具cf CLI提交“push”命令。
-
Cf CLI告知Cloud Controller創建一條該應用的記錄。
-
Cloud Controller將該應用的元數據存儲至CCDB（例如應用名、實例個數，以及指定的buildpack等信息）。
-
Cf CLI將應用文件上傳至Cloud Controller。
-
Cloud Controller將應用原始文件保存到blobstore中。
-
Cf CLI提交應用“start”命令。
-
由於應用尚未stage，因此Cloud Controller會從DEA池中選擇一個DEA對應用進行stage，負責stage的DEA會根據buildpack中的指令對應用進行stage（stage過程主要是爲應用配置相關的語言runtime、web服務器、框架等，最終得到一個可以獨立運行的應用包droplet）。
-
負責stage 的DEA會將stage過程的日誌同步輸出至cf CLI，開發者可以據此定位stage錯誤。
-
負責stage 的DEA將已完成stage的應用打包成一個稱爲droplet的壓縮包，並將該droplet存儲至blobstore。
-
負責stage的DEA向Cloud Controller報告stage工作已完成。
-
Cloud Controller根據應用配置從DEA池中選擇一個或多個DEA來運行已完成stage的應用（在DEA的warden容器中運行droplet）。
-
負責運行應用的DEA向Cloud Controller報告應用的運行狀態。
Buildpack:
Buildpacks爲應用提供框架及運行時支持。
Buildpacks通常會檢查用戶提供的應用代碼以確定需要下載哪些依賴，以及該如何配置應用使其能跟綁定的服務進行通信。
當你Push一個應用，Cloud Foundry會自動檢測（也可以在push時顯式指定）要使用哪個buildpack，並將其安裝至運行應用的DEA上。
表中所列爲Cloud Foundry system buildpack。
開發者可以通過以下方式使用上述所列之外的buildpack：
1. 改造已有的buildpack；
2. 自己編寫buildpack;
3. 使用Cloud Foundry社區提供的Buildpack；
4. 使用Heroku提供的第三方buildpack。
服務：
通過實現一組API被集成進Cloud Foundry 的服務稱爲受管理的服務。
用戶可以按需創建相應的服務實例，並獲取使用該服務實例的憑證。
ss
Service Broker標準APIs。
1. 獲取服務目錄
2. 創建服務實例
3. 綁定服務實例
4. 解綁服務實例
5. 刪除服務實例
References:
https://dbaplus.cn/news-72-232-1.html