遮天辰东小说,小说阅读网,《完美世界》txt全集

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案

詳解CloudFoundry中各個組件的作用

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

10年積累的做網(wǎng)站、成都網(wǎng)站制作經(jīng)驗，可以快速應對客戶對網(wǎng)站的新想法和需求。提供各種問題對應的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡服務。我雖然不認識你，你也不認識我。但先網(wǎng)站設計后付款的網(wǎng)站建設流程，更有虞城免費網(wǎng)站建設讓你可以放心的選擇與我們合作。

Router

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

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

CloudFoundry1.0中的router是用nginx+lua嵌入腳本實現(xiàn)的，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，在數(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)度相應的DEA節(jié)點部署運行該droplet。另外，Cloud Controller還維護了用戶組織關系org、space，以及服務、服務實例等等。

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，要求啟動相應數(shù)目的實例。HM9000本身，不會要求DEA做些什么。它只是收集數(shù)據(jù)，比對，再收集數(shù)據(jù)，再比對
用戶通過cf命令行工具是可以控制app各個實例的啟停狀態(tài)的，如果app的狀態(tài)發(fā)生變化，HM9000就會命令Cloud Controller做出相應調(diào)整

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

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的接口銷毀對應的container。

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

Warden在Linux上的實現(xiàn)是將Linux內(nèi)核的資源分成若干個namespace加以區(qū)分，底層的機制是CGROUP。這樣的設計比虛擬機性能好，啟動快，也能夠獲得足夠的安全性。在網(wǎng)絡方面，每一個Warden實例有一個虛擬網(wǎng)絡接口，每個接口有一個IP，而DEA內(nèi)有一個子網(wǎng)，這些網(wǎng)絡接口就連在這個子網(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在運行的時候通常需要依賴外部的一些服務，比如數(shù)據(jù)庫服務、緩存服務、短信郵件服務等等。Service Broker就是app接入服務的一種方式。比如我們要接入MySQL服務，只要實現(xiàn)CloudFoundry要求的Service Broker API即可。但實際情況是在我們使用CloudFoundry之前，MySQL服務已經(jīng)由DBA做了服務化、產(chǎn)品化，用起來已經(jīng)很方便了。有必要實現(xiàn)其Service Broker API，按照CloudFoundry這套規(guī)則出牌么？筆者認為沒有這個必要。app仍然按照之前訪問MySQL服務的方式去做即可，沒有任何問題。

Message Bus

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

我們以向router注冊路由為例來說明NATS的作用。不管是外部用戶對平臺上的應用發(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)絡打出來，比如syslog、scribe之類的。

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

分享題目：詳解CloudFoundry中各個組件的作用
當前地址：http://fisionsoft.com.cn/article/coopooe.html