CloudFoundry是一個標桿性的項目，架構設計上有很多值得借鑒之處。從CloudFoundry官網摘了一張圖，我們以此剖析各個組件的作用。

Router

Router是整個平臺的流量入口，負責分發所有的請求到對應的組件，包括來自外部用戶對app的請求和平臺內部的管理請求。

Router是PaaS平臺中至關重要的一個組件，它在內存中維護了一張路由表，記錄了域名與實例的對應關系，所謂的實例自動遷移，靠得就是這張路由表，某實例宕掉了，就從路由表中剔除，新實例創建了，就加入路由表。

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

Authentication

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

Cloud Controller

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

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

Health Manager

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

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

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

Application Execution(DEA)

DEA，即Droplet Execution Agent，部署在所有物理節點上，管理app實例，將狀態信息廣播出去。比如我們創建一個app，實例的創建命令最終會下發到DEA，DEA調用warden的接口創建container，如果用戶要刪除某個app，實例的銷毀命令最終也會下發到DEA，DEA調用warden的接口銷毀對應的container。

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

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

LXC是另一個Linux Container。那為什么不使用它，而開發了Warden呢。因為LXC的實現是和Linux綁死的，CloudFoundry希望warden能運轉在各個不同的平臺，而不只是Linux。另外Warden提供了一個Daemon和若干Api來操作，LXC提供的是系統工具。還有最重要的一點是LXC過于龐大，Warden只需要其中的一點點功能就可以了，更少的代碼便于調試。

Service Brokers

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

Message Bus

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

我們以向router注冊路由為例來說明NATS的作用。不管是外部用戶對平臺上的應用發起的請求，還是對內部組件（比如Cloud Controller、UAA）發起的請求，都是經由router做的轉發，要能讓router轉發則首先需要向router注冊路由。大體邏輯實現如下：

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

Logging and Statistics

Metrics Collector會從各個模塊收集監控數據，運維工程師可以據此來監控CloudFoundry，出了問題及時發現并處理。物理機的硬件監控則可以采用傳統的一些監控系統來做，比如zabbix之類的。

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

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