CloudFoundry是一個標(biāo)桿性的項(xiàng)目，架構(gòu)設(shè)計(jì)上有很多值得借鑒之處。從CloudFoundry官網(wǎng)摘了一張圖，我們以此剖析各個組件的作用。

Router

Router是整個平臺的流量入口，負(fù)責(zé)分發(fā)所有的請求到對應(yīng)的組件，包括來自外部用戶對app的請求和平臺內(nèi)部的管理請求。

Router是PaaS平臺中至關(guān)重要的一個組件，它在內(nèi)存中維護(hù)了一張路由表，記錄了域名與實(shí)例的對應(yīng)關(guān)系，所謂的實(shí)例自動遷移，靠得就是這張路由表，某實(shí)例宕掉了，就從路由表中剔除，新實(shí)例創(chuàng)建了，就加入路由表。

CloudFoundry1.0中的router是用nginx+lua嵌入腳本實(shí)現(xiàn)的，2.0用golang重寫，更名為gorouter，性能有所提升，并聲稱試圖解決websocket請求和tcp請求（雖然這在筆者看來是沒用的），它的代碼在https://github.com/cloudfoundry/gorouter，大家可以研究一下。

Authentication

這塊包含兩個組件，一個是Login Server，負(fù)責(zé)登錄，一個是OAuth2 Server(UAA)，UAA是個Java的項(xiàng)目，如果想找一個OAuth2開源方案，可以嘗試一下UAA

Cloud Controller

Cloud Controller負(fù)責(zé)管理app的整個生命周期。用戶通過命令行工具cf與CloudFoundry Server打交道，實(shí)際主要就是和Cloud Controller交互。

用戶把a(bǔ)pp push給Cloud Controller，Cloud Controller將其存放在Blob Store，在數(shù)據(jù)庫中為該app創(chuàng)建一條記錄，存放其meta信息，并且指定一個DEA節(jié)點(diǎn)來完成打包動作，產(chǎn)出一個droplet（是一個包含Runtime的包，在任何dea節(jié)點(diǎn)都可以通過warden run起來），完成打包之后，droplet回傳給Cloud Controller，仍然存放在Blob Store，然后Cloud Controller根據(jù)用戶要求的實(shí)例數(shù)目，調(diào)度相應(yīng)的DEA節(jié)點(diǎn)部署運(yùn)行該droplet。另外，Cloud Controller還維護(hù)了用戶組織關(guān)系org、space，以及服務(wù)、服務(wù)實(shí)例等等。

Health Manager

Health Manager最初是用Ruby寫的，后來用golang寫了一版，稱為HM9000，HM9000主要有四個核心功能：

• 監(jiān)控app的實(shí)際運(yùn)行狀態(tài)（比如：running, stopped, crashed等等），版本，實(shí)例數(shù)目等信息。DEA會持續(xù)發(fā)送心跳包，匯報(bào)它所管轄的實(shí)例信息，如果某個實(shí)例掛了，會立馬發(fā)送“droplet.exited”消息，HM9000據(jù)此更新app的實(shí)際運(yùn)行數(shù)據(jù)
• HM9000通過dump Cloud Controller數(shù)據(jù)庫的方式，獲取app的期望狀態(tài)、版本、實(shí)例數(shù)目
• HM9000持續(xù)比對app的實(shí)際運(yùn)行狀態(tài)和期望狀態(tài)，如果發(fā)現(xiàn)app正在運(yùn)行的實(shí)例數(shù)目少于要求的實(shí)例數(shù)目，就發(fā)命令給Cloud Controller，要求啟動相應(yīng)數(shù)目的實(shí)例。HM9000本身，不會要求DEA做些什么。它只是收集數(shù)據(jù)，比對，再收集數(shù)據(jù)，再比對
• 用戶通過cf命令行工具是可以控制app各個實(shí)例的啟停狀態(tài)的，如果app的狀態(tài)發(fā)生變化，HM9000就會命令Cloud Controller做出相應(yīng)調(diào)整

說到底，HM9000就是保證app可用性的一個基礎(chǔ)組件，app運(yùn)行時超過了分配的quota，或者異常退出，或者DEA節(jié)點(diǎn)整個宕機(jī)，HM9000都會檢測到，然后命令Cloud Controller做實(shí)例遷移。HM9000的代碼在這里：https://github.com/cloudfoundry/hm9000，有興趣的同學(xué)可以研究一下

Application Execution(DEA)

DEA，即Droplet Execution Agent，部署在所有物理節(jié)點(diǎn)上，管理app實(shí)例，將狀態(tài)信息廣播出去。比如我們創(chuàng)建一個app，實(shí)例的創(chuàng)建命令最終會下發(fā)到DEA，DEA調(diào)用warden的接口創(chuàng)建container，如果用戶要刪除某個app，實(shí)例的銷毀命令最終也會下發(fā)到DEA，DEA調(diào)用warden的接口銷毀對應(yīng)的container。

當(dāng)CloudFoundry剛剛推出的時候，Droplet包含了應(yīng)用的啟動、停止等簡單命令。用戶應(yīng)用可以隨意訪問文件系統(tǒng)，也可以在內(nèi)網(wǎng)暢通無阻，跑滿CPU，占盡內(nèi)存，寫滿磁盤。你一切可以想到的破壞性操作都可以做到，太可怕了。CloudFoundry顯然不會放任這樣的情況太久，現(xiàn)在他們開發(fā)出了Warden，一個程序運(yùn)行容器。這個容器提供了一個孤立的環(huán)境，Droplet只可以獲得受限的CPU，內(nèi)存，磁盤訪問權(quán)限，網(wǎng)絡(luò)權(quán)限，再沒有辦法搞破壞了。

Warden在Linux上的實(shí)現(xiàn)是將Linux內(nèi)核的資源分成若干個namespace加以區(qū)分，底層的機(jī)制是CGROUP。這樣的設(shè)計(jì)比虛擬機(jī)性能好，啟動快，也能夠獲得足夠的安全性。在網(wǎng)絡(luò)方面，每一個Warden實(shí)例有一個虛擬網(wǎng)絡(luò)接口，每個接口有一個IP，而DEA內(nèi)有一個子網(wǎng)，這些網(wǎng)絡(luò)接口就連在這個子網(wǎng)上。安全可以通過iptables來保證。在磁盤方面，每個warden實(shí)例有一個自己的filesystem。這些filesystem使用aufs實(shí)現(xiàn)的。Aufs可以共享warden之間的只讀內(nèi)容，區(qū)分只寫的內(nèi)容，提高了磁盤空間的利用率。因?yàn)閍ufs只能在固定大小的文件上讀寫，所以磁盤也沒有出現(xiàn)寫滿的可能性。

LXC是另一個Linux Container。那為什么不使用它，而開發(fā)了Warden呢。因?yàn)長XC的實(shí)現(xiàn)是和Linux綁死的，CloudFoundry希望warden能運(yùn)轉(zhuǎn)在各個不同的平臺，而不只是Linux。另外Warden提供了一個Daemon和若干Api來操作，LXC提供的是系統(tǒng)工具。還有最重要的一點(diǎn)是LXC過于龐大，Warden只需要其中的一點(diǎn)點(diǎn)功能就可以了，更少的代碼便于調(diào)試。

Service Brokers

app在運(yùn)行的時候通常需要依賴外部的一些服務(wù)，比如數(shù)據(jù)庫服務(wù)、緩存服務(wù)、短信郵件服務(wù)等等。Service Broker就是app接入服務(wù)的一種方式。比如我們要接入MySQL服務(wù)，只要實(shí)現(xiàn)CloudFoundry要求的Service Broker API即可。但實(shí)際情況是在我們使用CloudFoundry之前，MySQL服務(wù)已經(jīng)由DBA做了服務(wù)化、產(chǎn)品化，用起來已經(jīng)很方便了。有必要實(shí)現(xiàn)其Service Broker API，按照CloudFoundry這套規(guī)則出牌么？筆者認(rèn)為沒有這個必要。app仍然按照之前訪問MySQL服務(wù)的方式去做即可，沒有任何問題。

Message Bus

CloudFoundry使用NATS作為內(nèi)部組件之間通信的媒介，NATS是一個輕量級的基于pub-sub機(jī)制的分布式消息隊(duì)列系統(tǒng)，是整個系統(tǒng)可以松散耦合的基石。

我們以向router注冊路由為例來說明NATS的作用。不管是外部用戶對平臺上的應(yīng)用發(fā)起的請求，還是對內(nèi)部組件（比如Cloud Controller、UAA）發(fā)起的請求，都是經(jīng)由router做的轉(zhuǎn)發(fā)，要能讓router轉(zhuǎn)發(fā)則首先需要向router注冊路由。大體邏輯實(shí)現(xiàn)如下：

• router啟動時，會訂閱router.register這個channel，同時也會定時的向router.start這個channel發(fā)送數(shù)據(jù)
• 其他需要向router注冊的組件，啟動時會訂閱router.start這個channel。一旦接收到消息，會立刻收集需要注冊的信息（如ip、port等），然后向router.register這個channel發(fā)送消息。
• router接收到router.register消息后立即更新路由信息
• 以上過程不停循環(huán)，使router的狀態(tài)時刻保持最新

Logging and Statistics

Metrics Collector會從各個模塊收集監(jiān)控?cái)?shù)據(jù)，運(yùn)維工程師可以據(jù)此來監(jiān)控CloudFoundry，出了問題及時發(fā)現(xiàn)并處理。物理機(jī)的硬件監(jiān)控則可以采用傳統(tǒng)的一些監(jiān)控系統(tǒng)來做，比如zabbix之類的。

Log這塊是個大話題，CloudFoundry提供了Log Aggregator來收集app的log。我們也可以通過其他手段直接把log通過網(wǎng)絡(luò)打出來，比如syslog、scribe之類的。

參考資料

• 《CloudFoundry社區(qū)文檔》 http://docs.cloudfoundry.org/
• 《limengyun’s blog》 http://limengyun.com/
• 《新版CloudFoundry揭秘》 http://qing.blog.sina.com.cn/2294942122/88ca09aa33001753.html

本文出自：http://blog.ulricqin.com/article/cloudfoundry-component