CloudFoundry各個組件的作用是什么

本篇文章為大家展示了CloudFoundry各個組件的作用是什么，內(nèi)容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細介紹希望你能有所收獲。

Router

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

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

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

Authentication

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

Cloud Controller

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

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

Health Manager

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

• 監(jiān)控app的實際運行狀態(tài)（比如：running, stopped, crashed等等），版本，實例數(shù)目等信息。DEA會持續(xù)發(fā)送心跳包，匯報它所管轄的實例信息，如果某個實例掛了，會立馬發(fā)送“droplet.exited”消息，HM9000據(jù)此更新app的實際運行數(shù)據(jù)

• HM9000通過dump Cloud Controller數(shù)據(jù)庫的方式，獲取app的期望狀態(tài)、版本、實例數(shù)目

• HM9000持續(xù)比對app的實際運行狀態(tài)和期望狀態(tài)，如果發(fā)現(xiàn)app正在運行的實例數(shù)目少于要求的實例數(shù)目，就發(fā)命令給Cloud Controller，要求啟動相應(yīng)數(shù)目的實例。HM9000本身，不會要求DEA做些什么。它只是收集數(shù)據(jù)，比對，再收集數(shù)據(jù)，再比對

• 用戶通過cf命令行工具是可以控制app各個實例的啟停狀態(tài)的，如果app的狀態(tài)發(fā)生變化，HM9000就會命令Cloud Controller做出相應(yīng)調(diào)整

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

Application Execution(DEA)

DEA，即Droplet Execution Agent，部署在所有物理節(jié)點上，管理app實例，將狀態(tài)信息廣播出去。比如我們創(chuàng)建一個app，實例的創(chuàng)建命令最終會下發(fā)到DEA，DEA調(diào)用warden的接口創(chuàng)建container，如果用戶要刪除某個app，實例的銷毀命令最終也會下發(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，一個程序運行容器。這個容器提供了一個孤立的環(huán)境，Droplet只可以獲得受限的CPU，內(nèi)存，磁盤訪問權(quán)限，網(wǎng)絡(luò)權(quán)限，再沒有辦法搞破壞了。

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

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

Service Brokers

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

Message Bus

CloudFoundry使用NATS作為內(nèi)部組件之間通信的媒介，NATS是一個輕量級的基于pub-sub機制的分布式消息隊列系統(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注冊路由。大體邏輯實現(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)控數(shù)據(jù)，運維工程師可以據(jù)此來監(jiān)控CloudFoundry，出了問題及時發(fā)現(xiàn)并處理。物理機的硬件監(jiān)控則可以采用傳統(tǒng)的一些監(jiān)控系統(tǒng)來做，比如zabbix之類的。

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

上述內(nèi)容就是CloudFoundry各個組件的作用是什么，你們學(xué)到知識或技能了嗎？如果還想學(xué)到更多技能或者豐富自己的知識儲備，歡迎關(guān)注億速云行業(yè)資訊頻道。