<b></b>
随着雲計算的不斷發展，iaas已經不能滿足使用者的需求。作為一個能夠簡化開發、測試、部署、運維的平台，pass受到了越來越多的關注。今天沈閱斌老師将為我們分享關于paas的一些親身經驗和體會，同時詳細介紹paas技術中的cloudfoundry。
目錄
paas基本介紹
paas的價值在哪裡
paas的技術選型
cloudfoundry基本介紹
cloudfoundry架構及相關元件
基于cloudfoundry擴充paas功能
diego介紹
一．paas基本介紹
paas，平台即服務。是雲計算的一種服務形式。其實并不是一個非常新的概念，像gae、sae很早就提供了類似這樣的服務。不過在很長一段時間内，paas接受程度不高，在跟客戶談及雲計算時，普遍都認為雲計算就是iaas，即基礎設施服務。但是随着雲計算的不斷發展，使用者發現光有iaas，雖然簡化了對基礎設施資源的管理，但是對雲計算的終端使用者來說通過iaas隻是拿到了一個裸作業系統，要想開發一個軟體并部署到雲平台上，還需要做很多工作。包括代碼的管理、持續內建、自動化測試、傳遞物管理、應用托管、中間件服務、自動化運維、監控報警、日志處理等等。使用者希望通過一個平台能夠真正簡化開發、測試、部署、運維等工作，使得企業能夠真正實作devops。
二．paas的價值在哪裡
在我們接觸paas之前，我們做開發時需要自己搭建各種環境，包括開發環境、測試環境，上線的時候需要搭建生産環境以及進行各種配置，上線之後還需要進行人工運維。有時候搭建環境是一件很麻煩的事情，比如搭建一個tomcat的叢集或者是mysql主從等。由于各種環境都是人工搭建，難免會出現環境的不一緻，導緻系統在某個環境下運作地好好的，但是部署到其他環境就無法正常運作的情況。
paas可以提供各種标準化或非标準的環境以及各種運維管理功能，使用者可以在秒級按需擷取各類資源和環境。是以paas最大的價值在于解放開發、測試、運維人員。雖然目前還不能完全做到這個程度，但它實實在在地降低了使用者對應用軟體的傳遞成本及時間。
通常我們所說的paas，包括mopaas，主要提供應用部署和托管服務。平台服務涵蓋的範圍包括，應用開發部署運作環境(如應用開發測試管理/工具等)，服務元件池和管理(資料庫、消息隊列、緩存等)，應用資源管理(開發運作管理應用、彈性伸縮等)。
三．paas的技術選型
其實我們剛接觸paas的時候，并沒有多少可以選擇的paas技術，是以當cloudfoundry推出的時候，我們毫不猶豫地選擇了cloudfoundry作為我們建構mopaas的基礎架構。
最近幾年，随着容器技術的飛速發展，比如docker，目前建構paas的技術方案非常多，比如cloudfoundry、openshift、docker+k8s、docker+mesos+marathon、cloudify等等，目前這些方案或多或少都在被企業采用。
至于哪種方案最優，個人覺得還是根據使用者的具體需求來決定的。比如cloudfoundry，雖然很多人認為比較重量級，但是在成熟度以及paas功能提供方面優于其他方案。再比如要建構一個基于docker建構paas平台，那麼像docker+mesos+marathon就是很好的選擇。
四．cloudfoundry基本介紹
cloud foundry是一個工業級開源paas，它可以部署為一個雲，并對外提供多語言多架構、應用運作環境及服務。個人認為，cf的社群相對還是比較活躍的，并且版本疊代比較快，一般1，2周就會釋出一個小版本。而且cf在不斷的改進和優化自身的架構，到目前為止已經經曆了cf v1，cf v2以及cf v3。每一次大版本的釋出都對cf進行了性能和架構上的優化。
我們接觸paas的時候，cloudfoundry還不是很成熟，需要我們自己對cloudfoundry源碼進行修改和bug修複。比如那時候還沒有引入容器進行資源隔離，隻能通過對應用程序監控以及作業系統使用者使用者組的方式進行隔離，在這些方面我們需要做很多定制工作。
後來cloudfoundry v2版本的推出，在穩定性、安全性方面做了大量提升，并且引入容器warden(cf自帶的)進行資源的隔離。這時候容器技術docker也開始興起，docker在某些方面确實可以彌補cf的不足，是以我們在mopaas後來的版本中大量使用docker等容器技術。比如一些輕量級服務的提供，可以通過docker實作自動化部署及資源隔離和監控。
cloudfoundry v3版本将推出新的運作時diego，提供的容器叫garden，将支援運作docker鏡像。
五．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. 删除服務執行個體
六．基于cloudfoundry擴充paas功能
雖然cloudfoundry已經提供了paas平台的基礎架構，但是如果我們想要基于cf建構一個paas平台，并且能夠給使用者提供paas服務的話，還是需要我們做很多的定制化的工作，接下去我就簡單介紹一下相關内容:
1、 應用運作環境擴充
通過修改和增加buildpack實作，我們可以對buildpack進行相關定制，包括修改中間件的版本、配置資訊以及buildpack代碼來實作更多的功能，比如安裝apm的探針。然後将buildpack打成離線包上傳到cloudfoundry。
如果需要擴充.net運作環境，可以使用一個開源的.net插件ironfoundry，因為.net跟其他運作環境不一樣，需要運作在windows作業系統上面，是以要單獨安裝一個windows的dea（ironfoundry提供），并且将.net buildpack添加至cloudfoundry之後完成擴充。
2、 服務中間件擴充
cloudfoundry對服務中間件內建提供一種标準的接入方式broker，對中間件部署、運維、監控，cloudfoundry并沒有提供很好的方式解決方案，需要我們自己實作。一些輕量級的中間件服務，如緩存，可以采用docker進行部署和管理，資料庫服務可以采用vm方式部署，然後通過broker将服務注冊到cloudfoundry。
3、 可視化操作界面
cloudfoundry提供了一套标準的rest api，包括認證授權、組織空間管理、應用服務管理等功能。我們可以通過cloudfoundry提供的sdk可以非常友善的完成對cf的調用。
4、 應用/服務監控
cloudfoundry對應用的監控還是做了一些工作的，包括像health_manager，會實時采集應用的監控資訊。通過dea的varz接口也可以采集到應用的監控資訊。如果應用出現不健康的狀态，cf會對其進行自動重新開機。對應用通路日志資料，cloudfoundry在gorouter節點上有進行記錄，但是如果我們需要采集分析這些日志資料，那麼我們需要修改gorouter，将日志打到日志伺服器上。對服務的監控，完全需要我們自己來做，如果隻是一般的監控需求，可以采用對容器或者vm監控，如果需要擷取服務中間件更加詳細的監控資料，可以通過內建apm來實作。
5、 彈性伸縮
cloudfoundry提供了對托管的應用進行彈性伸縮，包括縱向和橫向的伸縮，但是隻能通過手動的方式，如果需要根據規則和門檻值進行自動伸縮，需要我們進行定制開發，通過對應用采集的通路資料、監控資料進行分析，滿足門檻值條件則進行伸縮。
6、 持續內建
cloudfoundry對開發測試這塊并沒有提供太多的功能，不過我們可以采用目前比較通用的方案來實作持續內建。
采用git/svn托管代碼；采用nexus/artifactory作為制品倉庫；采用jenkins作為持續內建工具，通過jenkins提供的插件，可以将代碼托管、制品倉庫以及paas平台進行內建，實作從代碼送出到部署上線一整套自動化流程。
7、 tcp協定的支援
cloudfoundry預設隻支援http(s)協定，如果需要部署一個tcp協定的應用，那麼我們需要定制一個tcp_router。
七．diego介紹
diego。（dea in go），cloud foundry的下一代容器管理系統。
在沒有diego的cloud foundry平台中，由cloud controller負責排程并管理dea上的應用。
而diego取代了dea以及hm9000，并從cloud controller那接手排程及管理應用的職責。
cloud foundry v3具有全新的 runtime, diego。cloud foundry（v3) 主要由 cc, uaa, diego, loggregator, gorouter, buildpacks, 和services和 bosh等元件構成。新的cloud foundry可以無縫地提供docker容器服務；在原有支援 linux 平台的基礎上，也将支援 windows應用。
在新版cloud foundry中diego将取代目前的dea 。diego解決了原cloud foundry架構功能上的的一些局限，包括：
1）功能間的強耦合。
2）dea、hm和cloud controller之間的三角依賴關系。
3）應用範圍隻局限于linux平台，對windows不原生支援。我們也将在mopaas新版中采用cloudfoundry v3版本。
講師介紹：
魔泊雲産品研發總監 。
11年it從業經驗，j2ee技術背景。
2011年加入魔泊雲負責mopaas産品研發和管理工作，是國内較早接觸cloudfoundry等paas技術并從事相關研發的工作者之一
<b>本文來自雲栖社群合作夥伴"dbaplus"，原文釋出時間：2016-01-28</b>