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

Router

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

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

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

Authentication

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

Cloud Controller

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

用戶把a(bǔ)pp push給Cloud Controller，Cloud Controller將其存放在Blob Store，在數(shù)據(jù)庫中為該app創(chuàng)建一條記錄，存放其meta信息，并且指定一個(gè)DEA節(jié)點(diǎn)來完成打包動(dòng)作，產(chǎn)出一個(gè)droplet（是一個(gè)包含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主要有四個(gè)核心功能：

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

說到底，HM9000就是保證app可用性的一個(gè)基礎(chǔ)組件，app運(yùn)行時(shí)超過了分配的quota，或者異常退出，或者DEA節(jié)點(diǎn)整個(gè)宕機(jī)，HM9000都會(huì)檢測(cè)到，然后命令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)建一個(gè)app，實(shí)例的創(chuàng)建命令最終會(huì)下發(fā)到DEA，DEA調(diào)用warden的接口創(chuàng)建container，如果用戶要?jiǎng)h除某個(gè)app，實(shí)例的銷毀命令最終也會(huì)下發(fā)到DEA，DEA調(diào)用warden的接口銷毀對(duì)應(yīng)的container。

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

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

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

Service Brokers

app在運(yùn)行的時(shí)候通常需要依賴外部的一些服務(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)為沒有這個(gè)必要。app仍然按照之前訪問MySQL服務(wù)的方式去做即可，沒有任何問題。

Message Bus

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

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

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

Logging and Statistics

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

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

原文出自：http://my.oschina.net/morflameblog/blog/340728