精品久久av无码蜜桃,无码不卡的中文

?1 輕訴架構(gòu)

1.1 應(yīng)用之云飄啊飄

我們知道Cloud Foundry （CF）是一個(gè)PaaS平臺(tái)。? CF命令行（CLI）作為開始部署使用CF云平臺(tái)的用戶來說，一個(gè)輕度的CF CLI的解釋會(huì)是一個(gè)比較好的入門選擇。所以飄在我們最前面的，目前很多企業(yè)工業(yè)云平臺(tái)背后就是Cloud Foundry云平臺(tái)。

那為什么很多企業(yè)云后面還有CF云呢？為什么選Cloud Foundry呢？因?yàn)槠髽I(yè)工業(yè)云是要將一個(gè)可以綁定工業(yè)數(shù)字化模型的PaaS云，那么底層需要選擇一個(gè)通用的PaaS云，而CF就是一個(gè)極好的PaaS云。 PaaS是要幫屏蔽了管理中間件和運(yùn)行部分，讓你集中在應(yīng)用和數(shù)據(jù)。底層還有IaaS云，幫你屏蔽了管理操作系統(tǒng)。

其實(shí)除了這三層之外，還有SaaS層，但是為了適應(yīng)不同的工業(yè)領(lǐng)域的應(yīng)用開發(fā)，不能走到SaaS層，固定好數(shù)據(jù)和應(yīng)用，所以只能到PaaS層：

那為什么選Cloud Foundry，而不選其他的PaaS平臺(tái)呢？首先我們看一下目前有哪些知名的PaaS平臺(tái)，不知名的，肯定不太靠譜了。我們看到在PaaS層面上，除了Docker和Cloud Foundry，其他的分布式Amazon， IBM， Microsoft，RedHat和SAP的平臺(tái)。相比較而言， Amazon， IBM， Microsoft和SAP都有自己的工業(yè)業(yè)務(wù)，一定程度是也可以是很多企業(yè)的競爭對手。所以大部分企業(yè)工業(yè)云不能選由競爭對手主導(dǎo)的平臺(tái)作為主流。再比較Docker，Cloud Foundry，和RedHat的OpenShift。那么Cloud Foundry在可擴(kuò)展，穩(wěn)定性方面的優(yōu)勢就比較明顯了。所以選用了EMC投資的Pivotal Software。

CF是方便你管理應(yīng)用和數(shù)據(jù)的PaaS云平臺(tái)。那么，一般一個(gè)在線服務(wù)，會(huì)有三層：用戶層，服務(wù)層，和資源層（數(shù)據(jù)層）。

1.2 不同架構(gòu)高呀高

那么對應(yīng)到三層里面的服務(wù)層，要做好用戶層的需求，有個(gè)經(jīng)典的MVC模型，劃分出模型Model，來搞業(yè)務(wù)邏輯，視圖View來搞展示界面，還有控制器Controller，來匹配模型和視圖。這樣，控制器就顯得尤為重要。

這樣我們對應(yīng)不同的URL訪問，就需要匹配不同的Controller (MVC實(shí)例)。

舉個(gè)例子，一個(gè)訂單應(yīng)用里面，你要提供展示訂單和添加訂單的功能。

時(shí)候，人們把這個(gè)匹配的功能獨(dú)立出來，提出了路由Route的功能。

隨著路由功能的增強(qiáng)，他成為了新型MVC模型的一部分，使得不同服務(wù)可以使用相同的Controller，同一個(gè)服務(wù)也可以使用不同的Controller。

很快，人們又發(fā)現(xiàn)，一個(gè)Controller需要的有些子功能還需要其他服務(wù)Service的支持。

那么如何把Controller和后臺(tái)一些服務(wù)綁定，這就需要有服務(wù)代理Service Broker。

最明顯的是數(shù)據(jù)服務(wù)Data Service：

這樣，我們把上面的應(yīng)用，除了Controller之外的路由Router，服務(wù)代理Service Broker，引入了Application的體系里面。

其實(shí)， Controller還是會(huì)有相應(yīng)的日志輸出的，這里用于經(jīng)常服務(wù)日志Log的一個(gè)組件就是信息總線Message Bus。

其實(shí)在Cloud Foundry里面，一般情況下， Controller通過Message Bus，把狀態(tài)發(fā)給Health Manager，然后由Health Manager把日志信息發(fā)給總線的。

這樣在CF里面， Health Manager就把狀態(tài)信息發(fā)給總線，而總線會(huì)把信息發(fā)給Heath Monitor進(jìn)行展示。

除了上面這些比較集中的功能， CF還提供對用戶登錄的管理，由兩部分組成，登錄服務(wù)器Login Server 和用戶賬戶認(rèn)證UAA User Account Authentication。

UAA比較好的解決了瀏覽器，用戶管理，應(yīng)用和服務(wù)之間一次認(rèn)證，全部授權(quán)的機(jī)制。

其中， OAuth2，SCIM， OpenID等技術(shù)還是可以單獨(dú)深挖的，就不做講解了。

這樣綜合上面三方面的內(nèi)容，我們可以大致得到CF提供了幾大模塊，這些模塊分成7層模型，路由層routing，用戶認(rèn)證層authentication，應(yīng)用生命期層app lifecycle，應(yīng)用存儲(chǔ)運(yùn)行層app storage & execution，服務(wù)層 services，信息層messaging，日志和性能儀表層metrics and logging。

他們之間的簡單通信，就得到了CF的架構(gòu)，譬如：

1.UAA Login和CloudController之間。

2.Cloud Controller和Health Manager（HM9000）和NATS Message Bus 和Metrics Controller之間。

3.Cloud Controller和Service Broker之間。

4.另外，運(yùn)行虛擬機(jī)也有細(xì)分， DEA Droplet Execution,Agent Warden Server等構(gòu)成了運(yùn)行虛擬機(jī)作為應(yīng)用執(zhí)行環(huán)境：

舉個(gè)PHP應(yīng)用的例子，我們結(jié)合架構(gòu)圖在看一把， DEA里面運(yùn)行好多節(jié)點(diǎn)，每個(gè)節(jié)點(diǎn)有個(gè)PHP的運(yùn)行，然后由Warden管理這些節(jié)點(diǎn)的生命周期，而他們的訪問由Router導(dǎo)入訪問，Cloud Controller （CC）把狀態(tài)發(fā)給Health Manager （HM9000），而每個(gè)Controller要訪問的數(shù)據(jù)庫服務(wù)有服務(wù)代理Broker管理。

1.3 ?應(yīng)用執(zhí)行Go吧Go

其實(shí)，在最新的CF架構(gòu)里面，對執(zhí)行架構(gòu)進(jìn)行了升級，從DEA Droplet Execution Agent架構(gòu)升級到了Diego架構(gòu)。 ?其中最大的升級就是把開發(fā)語言從Ruby換成了Go，同時(shí)更名了對應(yīng)的名稱。核心的，虛擬機(jī)的生命期管理，從Warden變成了Garden； Controller的運(yùn)行從DEA 節(jié)點(diǎn)Node 變成了 Diego Cell； Controller之間的協(xié)調(diào)器從DEA變成了Diego Brain。如下表所示：

還可以看到原來DEA是和Cloud Controller綁定的，限制Diego和Cloud Controller解耦合了。 ?這樣我們來看一下整個(gè)組件有哪些變化：

從上圖，我們看到，應(yīng)用運(yùn)行從DEA框架換成Diego框架之后，Message Bus 和 Health Manager 也對應(yīng)進(jìn)行了變化。直觀來說就是把Health Manager的功能進(jìn)一步獨(dú)立細(xì)分了，把一部分功能獨(dú)立成信息層的功能了。從Health Manager (HM9000) 變成了 nsync, BBS, 和 Cell Rep 更多組件了。

至此，我們再來詳細(xì)看一下，前面講的Controller， Router， Health Manager， Message Bus， Application Execution是如何變化的？

可以看到：

1.Controller不是再和Health Manager聯(lián)系了，是和nsync進(jìn)行交互。整個(gè)組成Controller API，CAPI模塊。

2.Router和Controller也不是和NATS Message Bus交互了，而是用bbs替換了NATS的功能。

3.引入auction機(jī)制到Diego Brain來作為協(xié)調(diào)機(jī)制

另外一個(gè)不太容易看到的特性是：

4.Warden只能運(yùn)行Linux容器，而Garden提供了各種操作系統(tǒng)的虛擬機(jī)。

綜上，我們把Cloud Foundry的架構(gòu)輕度解釋了一遍，這樣是為了后面我們把命令行和這些部分對應(yīng)起來。

2.輕訴命令行

命令行操作的安裝就跳過了，可以參考https://docs.cloudfoundry.org/cf-cli/install-go-cli.html。

2.1 ?登錄進(jìn)入CF

你需要制定API ，然后再login：

你也可以把上面兩步，寫成一步，給cf login加一個(gè) -a 參數(shù)，之后，你可以把你自己的APP 推Push到云上去。

然后，你可以通過target來指定一個(gè)組織Organization和一個(gè)空間Space。

當(dāng)然，cf api本身如果沒有參數(shù)的話，就可以作為查詢當(dāng)前API。

登錄到空間小結(jié)：

2.2 ?空間Space管理

一般來說你需要注冊一個(gè)這個(gè)組織的用戶，然后獲得對應(yīng)Space的全新Permission。一旦進(jìn)入到Space，你就可以推送APP和創(chuàng)建服務(wù)了。

譬如下面定義了一個(gè)student1-org的組織，里面有development， production和test 三個(gè)空間，每個(gè)空間都有apps和services的兩大部分。

空間管理小結(jié)：

2.3 ?應(yīng)用APP管理

首先，你要部署一個(gè)APP，通過cfpush命令：

創(chuàng)建完成后，一般你需要調(diào)整硬盤和內(nèi)存大小，這時(shí)候你需要利用cf scale命令。

另外，你需要啟動(dòng)，重啟，停止app的命令。

當(dāng)然，萬一你忘記了app的名字和相關(guān)信息，你還需要查詢所有app，和單個(gè)app的詳細(xì)信息。

應(yīng)用管理小結(jié)：

2.4 ?服務(wù)Service管理

在每個(gè)Space里面，除了你可以創(chuàng)建管理APP之外，非常類似你可以創(chuàng)建Service。 ?你可以管理Service，更新和刪除。注意這里更新是使用update，而不是scale。你可以綁定或者解綁定某個(gè)服務(wù)到某個(gè)APP。

最后你也可以cf services查詢?nèi)糠?wù)列表和單個(gè)服務(wù)的信息。

不過Service和App最大的不同是， App是本地推送上去的。而Service是注冊使用的。 CF提供的服務(wù)來自Service marketplace，市場。只有市場上有的服務(wù)，你才能創(chuàng)建一個(gè)實(shí)例。?這樣你就要通過cf marketplace來查詢有哪些服務(wù)可以被創(chuàng)建實(shí)例。

理解service命令之后，我們可以將前面提到的Controller的component功能就可以和service broker 鏈接起來，這里我們可以看一下創(chuàng)建服務(wù)之后，查詢服務(wù)狀態(tài)的過程中， controller是怎么和service broker進(jìn)行交互的流程。

服務(wù)管理小結(jié)：

2.5 ?路由Route管理

路由管理就是把某個(gè)域名下，對應(yīng)的子域名 domain/subdomain （host + domain），或者路徑path映射到對應(yīng)的空間Space，同時(shí)還可以指定對應(yīng)的應(yīng)用apps和類型type。

譬如我們常用的空間有開發(fā)空間，測試空間，和產(chǎn)品空間。那么一旦創(chuàng)建了這個(gè)空間的路由之后，那么對應(yīng)的訪問就會(huì)映射到這個(gè)空間來。

如果再綁定路由和應(yīng)用之后，那么就可以根據(jù)應(yīng)用找到對應(yīng)的controller來處理請求了。當(dāng)然也可以刪除路由，或者解開對應(yīng)應(yīng)用的映射。

也可以查詢當(dāng)前空間下的所有的路由。

路由管理小結(jié)：

2.6 ?域名Domain管理

傳統(tǒng)意義上的域名是指DNS的不同級別。

但是這里的域名是指在一個(gè)組織org里面全面能夠識(shí)別的全部域名。

這里域名是對應(yīng)到組織org的，并且可以創(chuàng)建夸組織的域名。有創(chuàng)建域名，就必然有刪除域名。另外就是查詢所有的域名，如下圖所示。

域名管理小結(jié)：

2.7 ?環(huán)境變量Environment管理

除了上面空間，應(yīng)用，服務(wù)，路由，域名之外。還有很重要求的就是環(huán)境變量和日志的管理。

環(huán)境變量比較簡單，就是創(chuàng)建（set），刪除（unset）和查詢（list）。

日志有兩種，一種是logs，另外一種是events。他們的區(qū)別就是logs一般是對某些變量的值進(jìn)行輸出，記錄。而events一般對生命周期的變化進(jìn)行記錄。

環(huán)境變量和日志管理小結(jié)：

除了上述重要的部署命令（deployment）還有很多管理的命令（admin），詳細(xì)可以參考：https://docs.cloudfoundry.org/cf-cli/cf-help.html

3 輕訴藍(lán)綠部署

3.1 ?藍(lán)綠之分

我們知道路由可以隨意和應(yīng)用綁定，解綁定的。這種便利帶來了部署上的藍(lán)綠之分。藍(lán)色是傳統(tǒng)的部署方式。就是我們把一個(gè)應(yīng)用創(chuàng)建之后，綁定好了對應(yīng)的路由和日志，等等。但是這樣，在線操作的時(shí)候，有個(gè)問題，線上的服務(wù)更新的時(shí)候，可能需要宕機(jī)。

而綠色部署就是先創(chuàng)建了另外一個(gè)應(yīng)有，這是一個(gè)更新應(yīng)有，當(dāng)我們需要更新，直接把路由改變到新的服務(wù)。然后再停止就的應(yīng)用。這樣就會(huì)帶來零宕機(jī)時(shí)間。

舉個(gè)例子，我們會(huì)把需要更新的應(yīng)用先映射的demo-time-temp的hostname上面去，然后再通過路由切換成demo-time，這樣就實(shí)現(xiàn)無宕機(jī)更替，更為綠色。

有了藍(lán)綠運(yùn)行方式之后，我們也很容易想想做A/B Test的時(shí)候，就會(huì)變得非常方便。我們不需要對用戶進(jìn)行區(qū)分了，直接在路由中把部分訪問路由到部署的服務(wù)，而不要把原服務(wù)停掉。

3.2 ?運(yùn)行虛擬之分

其實(shí)真正在運(yùn)行時(shí)候，還有一個(gè)staging的步驟。就是虛擬機(jī)準(zhǔn)備好容器開始跑運(yùn)行程序了。而具體到不同運(yùn)行環(huán)境/容器來staging的時(shí)候，又會(huì)不一樣。

例如利用buildpack和docker。buildpack就需要有metadata和運(yùn)行文件的準(zhǔn)備工作。

如果從DevOps的角度來看Buildpack和容器Container的對比，其實(shí)Container就需要開發(fā)者也提供。如果我們簡單來比較Buildpack和Docker的話:

1.從上傳維護(hù)的角度，上傳一個(gè)containerimage，要比上傳一堆代碼文件要更為簡單。

2.從配置的角度，由于buildpack和Cloudfoundry結(jié)合更為緊密，好多自動(dòng)化配置做的更為完善，但是docker和Cloudfoundry結(jié)合就沒有那么精密。

同時(shí)buildpack提供部分安全監(jiān)控的端口，但是docker就沒有。

3.從應(yīng)用的角度，如果一個(gè)獨(dú)立運(yùn)行的應(yīng)用，那么配置好了docker之后，獨(dú)立運(yùn)行，會(huì)比buildpack更為簡單，正如上圖所演示的，啟動(dòng)步驟也要少。

但是如果需要部署一個(gè)分布式，或者需要同步信息的時(shí)候，docker帶來的配置就會(huì)變得比buildpack麻煩。

4.從隨意遷移的角度， docker可能更為廣泛的被應(yīng)用，Buildpack主要是cloudfoundry在應(yīng)用。

5.從類比的角度， buildpack好比修好地面輕軌，什么都自動(dòng)化好了，你只要應(yīng)用就好了。 ?而docker好比開個(gè)SUV，就算路面不好，你也能翻山越嶺。

6.從開源的角度，不管是build pack還是docker，都不是一個(gè)標(biāo)準(zhǔn)的app容器，只有建立業(yè)界容器標(biāo)準(zhǔn)，這樣buildpack帶來自動(dòng)化配置的優(yōu)勢，和docker帶來的遷移優(yōu)勢就能都有了。但是，這還不在路上...

小結(jié)

這樣，我們再介紹命令行和運(yùn)行之后，又對應(yīng)的介紹了很多Cloud Foundry里面的概念，譬如組織Organization，空間Space，應(yīng)用App，路由Route，域Domain，服務(wù)Service。但是還有很多概念沒有介紹， Security Group， Cluster， Manager等等。希望大家在用到時(shí)候進(jìn)一步搞明白。