雲端計算前沿—詳解PaaS之Cloudfoundry

隨著雲端計算的不斷髮展，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同時還維護了組織、空間、服務、服務例項、使用者角色等記錄資訊。

監控應用以確認其執行狀態（例如runningstoppedcrashed等）、版本以及例項個數。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平臺上，應用如何被部署執行的？

1. 開發者切換到應用根目錄，使用命令列工具cf CLI提交“push”命令。

2. Cf CLI告知Cloud Controller建立一條該應用的記錄。

3. Cloud Controller將該應用的後設資料儲存至CCDB（例如應用名、例項個數，以及指定的buildpack等資訊）。

4. Cf CLI將應用檔案上傳至Cloud Controller。

5. Cloud Controller將應用原始檔案儲存到blobstore中。

6. Cf CLI提交應用“start”命令。

7. 由於應用尚未stage，因此Cloud Controller會從DEA池中選擇一個DEA對應用進行stage，負責stage的DEA會根據buildpack中的指令對應用進行stage（stage過程主要是為應用配置相關的語言runtime、web伺服器、框架等，最終得到一個可以獨立執行的應用包droplet）。

8. 負責stage 的DEA會將stage過程的日誌同步輸出至cf CLI，開發者可以據此定位stage錯誤。

9. 負責stage 的DEA將已完成stage的應用打包成一個稱為droplet的壓縮包，並將該droplet儲存至blobstore。

10. 負責stage的DEA向Cloud Controller報告stage工作已完成。

11. Cloud Controller根據應用配置從DEA池中選擇一個或多個DEA來執行已完成stage的應用（在DEA的warden容器中執行droplet）。

12. 負責執行應用的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技術並從事相關研發的工作者之一

本文來自雲棲社群合作伙伴”DBAplus”，原文釋出時間：2016-01-28