經(jīng)過了十個城市的路演，華為HDG線下沙龍終于來到了首都。在北京，開發(fā)人員之多，關(guān)注的技術(shù)領(lǐng)域之廣，討論的話題之深入，堪稱HDG歷屆參與討論者之最。

雖然同樣談PaaS，但是華為PaaS平臺資深架構(gòu)師張龍春則是另辟了一個角度。他來自中央軟件院PaaS架設(shè)部，所以他主要談?wù)勅A為設(shè)計這個系統(tǒng)的時候到底是怎么考慮初始架構(gòu)的，從這個角度看PaaS核心組建高效靈活的應(yīng)用調(diào)度和資源管理。

以下是他的現(xiàn)場演講實(shí)錄：

既然前面的專題我們基本上都已經(jīng)過一過了，我們就講一講這些問題背后的思想到底是什么。我是來自中央軟件院PaaS架設(shè)部的，我們平時設(shè)計這個系統(tǒng)的時候到底是怎么考慮這個問題的，大概從這個角度我們繼續(xù)來看一下PaaS的核心組建的高效靈活的應(yīng)用調(diào)度和資源管理。

我們上一個講題講的是DevOps，我就接著DevOps這個話題往下講。我們回顧一下剛才馬大師說的DevOps有什么收獲，就是他提到三點(diǎn)，他的一個理解，其實(shí)我也感受頗深的。他提到的***點(diǎn)是DevOps我們期望的是把所有的東西都組建化，第二個東西所有的組建是可流程化，第三個是所有的流程可自動化。是不是通過這個就把整個從Dev到Ops的所有過程都管理起來了。我們知道在一個開發(fā)過程之中，除了開發(fā)程序的研發(fā)要做的事情就是寫程序，我接到一個需求我要分析，我寫我的需求設(shè)計文檔，落到我具體的開發(fā)代碼的編寫制作之中，***我編譯成一個ese文件，可以執(zhí)行的文件。通常我們的工作就做完了。交給另一波人，另一波人就去裝機(jī)器，裝完機(jī)器做網(wǎng)絡(luò)設(shè)計。裝機(jī)器的過程，做網(wǎng)絡(luò)設(shè)計的過程，具體做安裝部署的工作是不是很多都是手工的工作，這個工作就是我們所謂的去部署上線的過程，部署完之后我們就去運(yùn)維這個東西，運(yùn)營這個東西。運(yùn)維這個東西的時候，我們不斷的看這個東西的情況是怎么樣的，如果有問題，比如一天早晨起來機(jī)器宕掉了，是不是再裝一臺機(jī)器，把這個再重新部署一下。

這個過程里面背后我們可以看到很多都是手工的，或者是跨不同組的這種工作。這種工作一旦手工工作很多的時候，我們不能把它流程化的時候，這個工作的可復(fù)制性就會比較差，大家會很辛苦。我相信一個事情做一遍不難，難的是你不停的做，這個道理同樣應(yīng)用于整個研發(fā)領(lǐng)域。我們裝一遍機(jī)器不難，難的是你天天裝機(jī)器，我安裝一次程序不難，難的是每次都安裝這個程序。而且你改一次參數(shù)可以，改10個、20個我可以做，你改100遍的時候，是不是難免有一次疏忽了。特別是越熟悉的人，越覺得這個東西容易疏忽，這時候越容易產(chǎn)生錯誤，這是人的因素。

所以DevOps的精髓就是，我***件事情就是把所有的東西都自動化，所有的東西都可操作。可操作之后就可以流程化和編程了，所以這是它的本質(zhì)。只有這樣子我所有的過程從Dev到Ops的所有過程都可以做到自動化，這是一脈相承的三個階段。

接著剛才說DevOps，我以前經(jīng)常說DevOps是管一個應(yīng)用系統(tǒng)的前半生的。什么叫前半生的?就是從調(diào)研接需求，到開發(fā)，一直到這個程序?qū)懗鰜恚麄€鏡像打開了，開始編譯部署，這是前半生。什么叫后半生呢?我部署上去了，我要運(yùn)營，我要監(jiān)控監(jiān)管，日常出報表，定期看結(jié)果，***到經(jīng)過五年十年這個程序下線了，這是它的后半生。我以前提過這樣一個話題，DevOps是管前半生的，而我們的PaaS運(yùn)營平臺是管后半生的。但是我一節(jié)課仔細(xì)聽了馬大師的演講，我新的感覺是其實(shí)DevOps是管一個應(yīng)用一生的，只不過它的后半生還用了DevOps的思想，把它放到了PaaS去管了它的后半生。所以我現(xiàn)在的觀點(diǎn)是DevOps是管整個應(yīng)用的一生，后半生是靠PaaS幫它一起實(shí)現(xiàn)的。我們站在這個思想上來想。

回過頭來看一下，***一個話題很多內(nèi)容，前面每一個話題里面都提到了，所以這個形式并不很重要，關(guān)鍵是你理清什么內(nèi)容，所以我們不一定非得看片子本身的內(nèi)容，包括挑戰(zhàn)啊，包括發(fā)展趨勢啊，大家都很了解了，我們就講講DevOps的后半生，PaaS是怎么幫它實(shí)現(xiàn)的。

我們想一個應(yīng)用程序，我們作為一個開發(fā)人員做一個應(yīng)用程序，一個應(yīng)用系統(tǒng)的時候，我們期望一個什么模式是大家比較理想的模式。我們一直說附用，能夠把以前任的結(jié)果沿襲下來，不要發(fā)明文字。其實(shí)說這些東西的背后我們都希望，我作為一個開發(fā)者可能希望的是，***是不是有現(xiàn)成的代碼，現(xiàn)成的應(yīng)用，現(xiàn)有的功能，我可以拿來就用，不需要自己再做一遍了。第二現(xiàn)有的安裝，現(xiàn)有的調(diào)試，現(xiàn)有的部署，是不是都是現(xiàn)成的，我拿來就可以用了。我要做的事情就是把業(yè)務(wù)邏輯開發(fā)往上一部署就OK了。包括將來運(yùn)維的時候，現(xiàn)在很多應(yīng)用會碰到波峰波谷的情況，雙十一的秒殺啊，或者是有些時候特殊的公關(guān)事件，或者是公共事件出現(xiàn)時候的流量的沖擊。類似在這種情況下，我的系統(tǒng)也可以很靈活的處理這種背后的對于資源的需求，如果這些東西都可以有一個現(xiàn)有的系統(tǒng)幫我們承載，我們的工作只做應(yīng)用邏輯、業(yè)務(wù)邏輯就可以了。當(dāng)然這是很理想的，我相信理想的情結(jié)還是要有的，雖然實(shí)際上不一定完全能做到這一步。

在這種理想的情況下，我們期望能夠讓一個平臺幫我們把編譯、測試、運(yùn)維的東西都實(shí)現(xiàn)掉，這就是一個比較理想的場景了。所以我們期望PaaS核心的模塊也能達(dá)到這一步，才能達(dá)到我們理想中的目的。這就是我們設(shè)計PaaS，或者是PaaS存在的一個意義。經(jīng)常有人會問這么一個問題，你們做PaaS的，PaaS到底是干什么的，能給我?guī)? 好處呢。我通常會這樣想，得看問的這個人是誰。問的這個人如果是一個偏研發(fā)的同事，我通常會這么說，PaaS里面有很多服務(wù)，你寫程序的時候，這些東西都是現(xiàn)成的，而且都是很好的，你點(diǎn)一點(diǎn)，布一布就可以了，這些功能都是現(xiàn)成的。

但是如果是偏運(yùn)維的同事，我們可以這么說，PaaS可以把你日常的工作都涵蓋掉。舉個例子，你部署的時候安裝機(jī)器，還要調(diào)操作系統(tǒng)，還要裝程序，還要配參數(shù)，環(huán)境變量，各種變量的東西。現(xiàn)在的做法是，有一個表述包，把你所有的事情開發(fā)人員都幫你表述好了，你要做的事情就是看一下機(jī)器的總量夠不夠，物理總量是夠的，一臺機(jī)器有了，你把這個包放上去，點(diǎn)一下安裝，等一下喝杯水，回來這個東西做完了。你再看看日常的工作，會給你發(fā)一個報告，你看一看結(jié)果，你可能要做的事情是根據(jù)業(yè)務(wù)的需要，制定一定自動化的策略，比如說彈性伸縮的策略等等。你告訴系統(tǒng)，當(dāng)我的負(fù)載到什么程度的時候，你是不是幫我破一點(diǎn)節(jié)點(diǎn)，當(dāng)負(fù)載到什么程度的時候你是不是把節(jié)點(diǎn)降下來，這種狀態(tài)是不是比較理想。

如果一個客戶問我的時候，大概會有這樣一個回答。客戶說你們PaaS到底能做什么，特別是像企業(yè)的客戶。PaaS通常能做到這一塊，***這個PaaS里面有現(xiàn)成的很多現(xiàn)有的服務(wù)，你的應(yīng)用開發(fā)就非常的簡單。而部署和維護(hù)的成本會非常的低，能夠減少你的應(yīng)用開發(fā)，就是你來了新需求，到最終上線的這個時間會減少很多，這是***個。第二個是過去你作為一個個的很獨(dú)立的開發(fā)的系統(tǒng)，都是獨(dú)立采購硬件資源的，在這種情況下你就會發(fā)現(xiàn)每一個資源池可能都不飽滿，但是你每一個資源池又得考慮峰值情況，肯定得把提前的余量預(yù)留好。這時候你整個機(jī)器的管理、運(yùn)維，包括資源的平均利用率都不會高。所以有這個PaaS，除了剛才說的你的業(yè)務(wù)溝通市場的時間縮短以外，還可以把資源重新的利用起來。你可以把一組的應(yīng)用部署到一套的平臺里面去，這樣你整個資源利用率提高了，你的運(yùn)營運(yùn)維的效果也好了。這是站在業(yè)務(wù)的角度看待問題。

所以我們站在不同的維度看PaaS，就能看到不同的PaaS。所以PaaS就是有不同的面，我們這么來看，這就是我們看PaaS的來源，從每一個角度來看PaaS。

docker大家都知道這個概念，docker里有一個很重要的概念，叫打包概念。打包的意思，就是把所有的東西都打在一起。不要小看打包這個概念，有時候量變會引起質(zhì)變，當(dāng)你把所有的依賴都壓縮在一個包里的時候，當(dāng)你所有應(yīng)用的啟停都簡單到一個機(jī)器的啟和停的時候，一個東西才會發(fā)生變化。舉個例子，我們過去部署應(yīng)用程序的時候，我們知道通常部署一個應(yīng)用程序需要把一個應(yīng)用程序安裝到一個目錄上去，需要去配各種各樣的配置文件，是不是有時候還需要看環(huán)境變量，有時候我們的應(yīng)用程序還會寫一些start up或者start stop的腳本，或者(16：54)的腳本，這些腳本還要和其他的應(yīng)用程序交互。這些東西雖然看起來不是很復(fù)雜，但是往往都是每一個應(yīng)用程序很個性化的東西。當(dāng)這種個性化的東西沒有形成一個標(biāo)準(zhǔn)的時候，這個應(yīng)用程序的啟和停就變成個性化的事情了。

所以我們知道為什么過去那些PaaS平臺會定一系列的標(biāo)準(zhǔn)，我需要一個什么東西，把程序的啟停封裝起來，來達(dá)到我對外提供統(tǒng)一的啟停和應(yīng)用管理的目的。但是容器化之后就不一樣了，容器化之后你所有的東西都放在了容器里面，這個時候所有的啟停都被認(rèn)為是容器的啟停，所以整個應(yīng)用的啟停簡單的就變成一個程序的啟停，就是容器的啟停。這樣一下子就把應(yīng)用程序?qū)ν獾慕涌谧兊梅浅８蓛簟?/p>

我們剛才最早的時候也提到一個觀點(diǎn)，我們期望我們應(yīng)用后半生的管理都變成，***是組件化的，第二是可編排的，第三所有的編排都是自動化的。如果按照這個角度來看，***件事情就是要求我們寫出來的應(yīng)用程序，至少有一個很合適的界面給我們提供出來，讓它可以很容易的被編排，被使用。因?yàn)镻aaS這個概念出來的并不是剛剛這一年、兩年才有的，很多年前都有。但是有了容器化之后，就是docker只是容器的一種標(biāo)準(zhǔn)，有了容器化之后，才發(fā)展的更快起來，這也是有一定的相輔相成的作用。容器化之后，就是我們應(yīng)用程序的管理有了一個標(biāo)準(zhǔn)，這是***個。

第二個sefe，就是交付。過去的交付也有通過集中的或者軟件倉庫的方式交付，但是以容器化的角度的交付，現(xiàn)在是正式的把這個問題變成一個業(yè)界的常態(tài)了。過去可能是有些應(yīng)用做，有些應(yīng)用不做。但是你有了容器化的概念以后，交付就是基本上大家都會選用這種集中的注冊中心交付的模式，或者是集中的軟件交付的模式。這種模式使我們的交付也變得標(biāo)準(zhǔn)和單一了。再加上我們說的所謂的隔離，針對這個事情我也談?wù)勔粋€理解。

我們做PaaS的時候，一方面做PaaS平臺本身，另外我們也在研究另外一個話題，到底傳統(tǒng)的應(yīng)用是怎么能夠搬到PaaS上來的。一般我們說***件事情我要建云，第二件事情是要遷云，就是把東西遷上來。當(dāng)我們建一個PaaS平臺，沒有人來用的時候，那就只是技術(shù)上的一個先進(jìn)性而已，我說來說去沒有人用。但是又有多少應(yīng)用是新建的呢，很多是從傳統(tǒng)的應(yīng)用遷移到云上來的。遷移到云上來的時候，我們知道傳統(tǒng)的應(yīng)用，我們過去看到的很多應(yīng)用在前幾年，在容器化發(fā)展之前，那些應(yīng)用基本都是以虛機(jī)化的應(yīng)用比較多。我們知道虛機(jī)化的應(yīng)用，那時候通常是以虛擬機(jī)為單位進(jìn)行隔離。所以它的隔離性只能體現(xiàn)在虛擬機(jī)上，應(yīng)用如果享用隔離，就必須建不同的虛擬機(jī)。所以通常的做法就是一個應(yīng)用會啟一個虛擬機(jī)，或者一個集中的應(yīng)用啟一個虛擬機(jī)。

但是我們知道虛擬機(jī)的啟停和容器的啟停級別肯定不在一個級別上的，容器其實(shí)就是一個啟一個進(jìn)程，容器如果還能提供隔離機(jī)制的話，我們就能產(chǎn)生***個好處，我們可以在一臺機(jī)器上布很多的容器。而每一個容器之間是互相隔離的，因?yàn)檫@個技術(shù)大家都很了解，我只是談?wù)勀芙o大家?guī)淼暮锰帲瑐鹘y(tǒng)應(yīng)用的不同組件就可以核設(shè)到一臺機(jī)器上去。核設(shè)到一臺機(jī)器上的好處就是，我不需要很多很小的虛擬機(jī)。舉個例子，我現(xiàn)在的物理機(jī)規(guī)模都很大，48核，128的，256內(nèi)存的機(jī)器。過去畫10個虛擬機(jī)或者20個虛擬機(jī)。但是一旦畫完虛擬機(jī)之后，虛擬化本身的消耗也很牛，而且這個管理也很麻煩。在這種情況下，如果我們可以把一個應(yīng)用的不同組件核設(shè)到一臺機(jī)器，同時又能夠做到一定的隔離性，這樣我應(yīng)用的部署是不是也會變得相對的簡單起來了，這也是一個站在虛擬化和容器化角度來看應(yīng)用部署革新性的變化。就是我程序的核設(shè)部署變得非常簡單，而虛擬機(jī)的用度可以不需要畫的非常的小，這樣我應(yīng)用的管理也會變得非常的容易。所以從這些角度來看的話，應(yīng)用這個層面，將來的管理就會有新的不同的理解和突破。

剛才提到應(yīng)用本身的變革之后，回到剛才這個話題上我們可以簡單的說一下。容器化來了之后，讓我們的應(yīng)用程序的啟停變得非常的簡單，它對外的接口變成單一化、容易化去處理。第二它整個的遞送變得非常簡單，我們不需要手工做各種各樣的拷貝。第三它在一臺機(jī)器上可以核設(shè)很多的應(yīng)用程序，讓我們的程序管理變得簡單。

在這種情況下我們再想PaaS再往上的能力，我們剛才說了有了容器化的特點(diǎn)之外，是不是離我們剛才最早說的理想的模式到底還差多遠(yuǎn)呢。剛才說了一個應(yīng)用的后半生我們希望***做到的是，***個它的安裝、部署、管理、彈性伸縮全變成自動化了，全是可編排的，我的應(yīng)用寫什么，應(yīng)用程序運(yùn)用什么功能，也都是平臺自己給我提供的，這是一個理想的模式。要達(dá)到這個理想的模式，是不是剛才說的docker的那三個特征，就能滿足我們所有的需求了呢，現(xiàn)在看還是差一些。

會差哪些呢?我們做一個應(yīng)用的時候，分析一個應(yīng)用的時候，往往一個應(yīng)用并不都是一個簡單的應(yīng)用，一個應(yīng)用并不是簡單的，甚至連最簡單的應(yīng)用，我要做一個高可用的外部的BBS的應(yīng)用，或者一個blood的應(yīng)用，是不是都有一個前端，一個緩存，一個數(shù)據(jù)庫，再加一個什么東西，都是相對復(fù)雜的幾個節(jié)點(diǎn)或者幾類東西組成的。這幾個節(jié)點(diǎn)，幾類東西，我們單獨(dú)拿一個節(jié)點(diǎn)，或者一類程序，拿docker來做，好像都能夠提升部署的效率或者效果。

但是作為一個整體的應(yīng)用，我是不是還得把這幾個東西單獨(dú)手工的弄一遍呢?還有一個機(jī)制能夠把一個應(yīng)用不同的組件，或者是不同的部分，能夠把它編串起來，形成一個整體。我們以這個整體為單位，來看應(yīng)用，是不是這樣就會比較理想一些。所以我們就希望另外一個概念，有一個機(jī)制是跨不同的，每一個應(yīng)用程序，組成一個虛擬整體的應(yīng)用的角度。這個時候我們通常會說，當(dāng)然這個調(diào)度的核心有很多，我們可能會選Kuberentes，因?yàn)榻裉焐衔缙渌膶ｎ}也都提到了我們有Kuberentes，有很多很多的平臺做這件事情。不管是哪個平臺都要解決這些問題。

舉個例子，一個應(yīng)用的不同節(jié)點(diǎn)它的關(guān)系是什么，它啟停的順序有沒有要求。上一個應(yīng)用的不同節(jié)點(diǎn)之間要不要理解對方的存在，這個應(yīng)用程序給外部提供服務(wù)的時候，別人怎么能找得到它。這個應(yīng)用如果做擴(kuò)縮容的時候，到底是整個應(yīng)用做擴(kuò)縮容，還是某個節(jié)點(diǎn)是瓶頸的時候做擴(kuò)縮容。這些東西怎么做，如果這些東西都不能組件化或者做好的話，我們只看docker自身是沒有意義的。所以我們總需要這些東西，把這些東西都做掉。所以我們就希望有另外一個更全面的系統(tǒng)來覆蓋這些內(nèi)容。僅僅是單機(jī)的容器往往是不夠的，所以一個生態(tài)環(huán)境里面還需要很多其他的內(nèi)容。

我們提到了Kuberentes，這是編排方案的一種，我們其實(shí)在這上面做了一些擴(kuò)展和擴(kuò)充，也會把這些回饋到社區(qū)去，希望這個東西能夠做的更好，業(yè)界有其他的。只不過Kuberentes現(xiàn)在看，在社區(qū)的發(fā)展上這一塊發(fā)展的比較紅火。我們知道技術(shù)上沒有絕對的先進(jìn)和落后性，這是***。第二開源的世界里面大家都能互相看到對方技術(shù)的實(shí)現(xiàn)，就算我今天比你差一點(diǎn)，不代表我明天會比你差，所以絕對的好和差我認(rèn)為是在一個瞬間存在的，但是長時間看是不存在的。但是一個東西是不是能發(fā)展的好，得看社區(qū)的紅火程度。如果說人多，眾人拾柴火焰高，只有人多了，這個事情才能發(fā)展的起來。所以我們可以看Kuberentes社區(qū)的熱度還是非常高的。

我們往下看，基本概念就不說了，說了很多遍了，而且大家到網(wǎng)上隨便一搜都能知道這些基本的概念。這是它整體的架構(gòu)，我也不怎么說了。這是一個典型應(yīng)用創(chuàng)建的流程，這是調(diào)度器的分析過程。我就提到一個調(diào)度器的算法，剛才我們也提到了一個應(yīng)用不是被拆解成很多單一的應(yīng)用組件，一個大的應(yīng)用會看成是很多組件的一個組合。一個應(yīng)用布下之后，我們過去的做法是說，我要布一個應(yīng)用，部署在哪臺機(jī)器上去，通常我們過去的想法都是這樣操作這件事情。我布一個應(yīng)用到這臺機(jī)器上去，這個機(jī)器的IP假設(shè)是192 168.1.1的節(jié)點(diǎn)，我要把這個應(yīng)用部署到這個節(jié)點(diǎn)。請注意，我說的我要把應(yīng)用部署到這個節(jié)點(diǎn)。因?yàn)檫@個節(jié)點(diǎn)是我知道的，它能夠滿足用戶的或者這個應(yīng)用需求的。這種做法，當(dāng)然做肯定是沒有問題，這叫命令式的一種做法，就是我做這件事情。

倒過來我們可以看，是不是還有另一種不同的做法。另外一種做法就是，我要布一個應(yīng)用，我希望有一個CPU，2G內(nèi)存的機(jī)器布它就夠了，我有這樣一個需求。我把這個需求下下去，反正你這個系統(tǒng)幫我能找到這樣一個東西，你能按照我的需求提供這樣一個資源，就把我的應(yīng)用給部好了，這是不是也是一個做法。

這個做法和剛才那個做法的區(qū)別是什么呢?剛才那個做法是命令式的，我要做這件事情。第二個做法是我有這個需求，請你幫我做這件事。這兩個是有區(qū)別的，對于我們一個理想的模式而言，我們應(yīng)用程序的將來運(yùn)營和運(yùn)維理想的模式，***種和第二種最終結(jié)果并沒有什么區(qū)別。但是好處在什么地方呢?當(dāng)我提出是一個需求的時候，這個需求的滿足是有系統(tǒng)幫我去想怎么去做的，就有一定的主動性。當(dāng)它有了主動性的時候，它的主動性是不是可以復(fù)制。我現(xiàn)在告訴它我需要部署一個1C2G的資源就夠了。當(dāng)這個1C2G的資源出錯了，這臺機(jī)器壞掉了。因?yàn)樗牢业男枨螅€可以再找一個1C2G的資源，是不是它有了主動性之后，可以幫我做更多的事情。如果我告訴他部署在192.168.1.1的機(jī)器上，如果這臺機(jī)器壞掉了，平臺能幫我們干什么呢。它只能說抱歉這臺機(jī)器壞掉了，我還有一個1.2的能不能用，我還得告訴它1.2的我看看能用，你再用。就是當(dāng)我指定到動作本身的時候，這個時候系統(tǒng)的主動性就降低了。我們期望的是我們只提需求，讓平臺幫我們做決策和調(diào)度。這時候當(dāng)系統(tǒng)出問題，或者系統(tǒng)沒有出問題，將來壓力變大的時候，我需要做擴(kuò)縮容的時候，這個時候它的主動性就可以繼續(xù)發(fā)揮作用，這就是我們調(diào)度系統(tǒng)需要做的事情。

調(diào)度系統(tǒng)就是把過去命令式的調(diào)度算法，變成我是需求，讓它主動幫我調(diào)度算法的過程。這就是很多調(diào)度器底層需要做的事情，我們來提要求，它來提實(shí)現(xiàn)。它來提實(shí)現(xiàn)的話有很多方法，一般我們會講一個例子，基本的調(diào)度器。***它得把排他性的元素給去掉。舉個例子，我不希望部在一個網(wǎng)絡(luò)很差的節(jié)點(diǎn)上，我不希望和那個應(yīng)用程序部一起，我不希望怎么怎么著，就是一些排他性的條件一定要先去執(zhí)行掉。因?yàn)檫@個排他性的條件一旦發(fā)揮作用，所有涉及到的可能的資源都要排他性的去掉。第二個階段如果所有排他性的都去掉了，所有剩下的都是侯選的了，都是可用的了。在都是可用的情況下我選一個***的，更合適的節(jié)點(diǎn)做這件事情。所以整個系統(tǒng)調(diào)度核心就是從這兩個角度看問題，***個是先做排他性的，第二再做***性的。所以在KBS里面也是有這套調(diào)度器的過程和不同的算法組成的，不同的算法我們都可以配的。這些算法都是我們可以插進(jìn)去的，當(dāng)然了它提供了一些默認(rèn)的基本的算法，可以讓我們使用預(yù)定義的算法做資源的調(diào)度，這是一個基本的調(diào)度的過程。

其實(shí)親和性和反親和性的也是調(diào)度的一個過程而已，親和性和反親和性就是剛才算法的一些特例，但是為什么單獨(dú)提出來呢?因?yàn)樵诤芏嗨惴ɡ锩妫诤芏嗟膶?shí)際場景里面，親和性和反親和性的作用還是非常大的。舉個例子，我們在做應(yīng)用的，剛才說我們過去是命令式的，現(xiàn)在是需求式的，提需求，去定義的方式去做的。我的需求定于的方式去做的時候，其實(shí)我真的不知道底層到底能給我調(diào)度到什么地方去，因?yàn)椴皇俏抑付ǖ墓?jié)點(diǎn)。因?yàn)榘雅潘詶l件去掉之后，合適的節(jié)點(diǎn)可能還有幾十個，這種情況下我們有時候?yàn)榱藨?yīng)用的特別的需要，特別是高可用的需要，或者是一些其他的需要，會有一些特別的要求。這種特別的要求就要求有些應(yīng)用程序是希望離的越遠(yuǎn)越好，或者說它不希望在一個物理機(jī)器上存在。這樣就導(dǎo)致這一臺物理機(jī)器如果出了故障，它所有的節(jié)點(diǎn)都宕掉了。如果它在不同數(shù)據(jù)中心，你換一個，它的數(shù)據(jù)中心還在。這就有點(diǎn)類似于反親和的戰(zhàn)略。

親和性策略是什么意思呢?剛好這兩個應(yīng)用，一個應(yīng)用是白天忙的，一個應(yīng)用就是晚上忙的。本來它倆之間對資源的需求就是交叉的，它倆如果親和在一起是不是比較理想。如果我們指令性的告訴它，這兩個應(yīng)用***能放在一起。當(dāng)然我們所謂說的無論是親和性還是反親和性，都是一個建議，就是我對它的一個要求。它如果在滿足的情況下，盡量會幫我們鋪在一起。當(dāng)兩個應(yīng)用程序剛好對資源的需求有波峰、波谷差異的時候，我們?nèi)绻o它一個親和性需求的話，就會盡量的把這兩個應(yīng)用鋪在一起，這就是親和性和反親和性。其實(shí)親和性和反親和性也是上一頁說的這些調(diào)度算法的一類，只不過我單獨(dú)拎出來的意思是，這些東西其實(shí)是我們真正業(yè)務(wù)使用之后需要著重考慮的算法。

有了這些之后，我們應(yīng)用的部署過程就變成了我只需要告訴你，我要部一個應(yīng)用了，需要什么樣的資源，你大概按照我的標(biāo)準(zhǔn)部就可以了，是不是把部的過程交給了一個平臺了。交給這個平臺之后，剛才我們也提到這個應(yīng)用真正部的過程，就是它選到這個節(jié)點(diǎn)，真正部的過程也變成了。過去是我要把程序拷上來，還要安裝，還要執(zhí)行它的安裝腳本，啟動的時候要執(zhí)行啟動腳本。重啟的時候壓執(zhí)行重啟腳本。這樣一系列過程就變成一個容器的啟和停，是不是這個啟停的過程也標(biāo)準(zhǔn)化了。所以通過這兩層的概念，把我們應(yīng)用部署的過程就統(tǒng)一起來了。是不是離我們剛才說理想的模式又進(jìn)了一步。

我們再回過頭看一下，我們剛才說一個應(yīng)用后半生的理想模式大概是什么樣的，我再簡單重復(fù)一下。我們期望***我的應(yīng)用要使用的這些功能，現(xiàn)成的如果有，我拿現(xiàn)成的就OK了，這是***個我希望的模式。第二個我的程序只關(guān)心我的業(yè)務(wù)邏輯，我寫完之后我的應(yīng)用的部署、管理，生命周期所有的東西，是不是今天幫我們自動就完成了，這就是我理想的一個模式。所以如果做到剛才說的這兩點(diǎn)之后，是不是離我們理想的模式又近了一步。剛才說到理想模式的前一個問題，我希望是不是現(xiàn)有的這些應(yīng)用，現(xiàn)有的功能如果有，我直接利用就可以了，我不需要再開發(fā)了，我不需要把這個東西再發(fā)明一遍了。

這件事情是怎么幫它做的呢?平臺希望提供一整套的服務(wù)目錄這個概念。我們知道在整個PaaS平臺里面會管兩大類的東西，其實(shí)兩大類的東西本質(zhì)是一類東西，都是應(yīng)用。但是我們還給這兩大類應(yīng)用稍微做了一下擴(kuò)展分類。一類東西叫做純的應(yīng)用程序，叫應(yīng)用，還有一類叫服務(wù)，其實(shí)服務(wù)也是一類應(yīng)用。但是服務(wù)和應(yīng)用稍微有一點(diǎn)點(diǎn)區(qū)別。這個服務(wù)是可以被自動化使用的應(yīng)用，叫服務(wù)。我們的應(yīng)用可以給人用，當(dāng)然也可以給外部用。而服務(wù)主要是給另一個應(yīng)用，或者另一個服務(wù)用的，這種東西其實(shí)也是一種應(yīng)用，只是我們把它給稍微的做了一下歸類。所有的服務(wù)系統(tǒng)都會有一個服務(wù)的目錄，目錄里面有我系統(tǒng)里面現(xiàn)存的，大家通常知道的redis服務(wù)，SEQ的服務(wù)，DDS的服務(wù)，有很多這種服務(wù)，這種都是大家都會用到的通用的服務(wù)。

這種服務(wù)應(yīng)用程序開發(fā)的時候我們用就行了，甚至我們過去說，我拿一個輪子的話，可能會編譯到我的代碼里面去，這是一種使用方法。再往后的使用方法，既然大家都耦合了，是不是說我要想用個redis，我就從平臺里面訂購一個事例就可以了。平臺只需要告訴我說你訪問的redis的地址是什么，你的用戶名密碼是什么，是不是就夠了。我們告訴系統(tǒng)說我需要一個redis服務(wù)，我需要10G的空間，我希望它高可用，我就是提這些要求。類似于剛才我部一個應(yīng)用的時候，我提一個要求，我需要1個CPU，2個G的內(nèi)存，或者我需要一個實(shí)際的網(wǎng)卡，或者我需要一個1G的網(wǎng)卡，或者我需要一個本地盤是什么，我需要一個遠(yuǎn)程盤是什么，你提要求就行了。

服務(wù)也是一樣的概念，你的應(yīng)用程序提一個要求，系統(tǒng)就會把服務(wù)給你找到這個服務(wù)，給你生成你需要的實(shí)例，然后把訪問信息給你，你就可以使用這個服務(wù)了。這個時候是不是離我們剛才的理想又近了一步。

我現(xiàn)在想用服務(wù)，系統(tǒng)也給我提供了，服務(wù)的在哪兒我不用管，服務(wù)的容量我只要提就行了，要求只要提就可以了。它就會告訴我訪問的地址和用戶名和密碼。而我的應(yīng)用，我只需要寫程序就可以了，我部署的時候只需要提要求，我需要什么CPU，什么內(nèi)存就可以了。到底這個機(jī)器的IP，部在哪兒，我都不需要case。是不是我們應(yīng)用程序離這個項(xiàng)目又近了一步，我們***只關(guān)注業(yè)務(wù)邏輯本身這件事情更理想化一點(diǎn)了。

實(shí)現(xiàn)剛才這個過程，我們PaaS里面完成了兩大件事情，一個就是整個應(yīng)用生命周期的管理，第二個就是與服務(wù)有關(guān)的管理。我們希望離理想模式再近一步，我們過去可能寫了很多的應(yīng)用程序，可能我寫很多的組件。如果我只寫一個簡單的應(yīng)用程序，就是web的，中間一個redis，下面就是一個mySQL，一個很簡單的應(yīng)用大概是這樣的模式構(gòu)成的。

所以我們PaaS還會提供另外一種能力，就是我現(xiàn)在已經(jīng)開發(fā)的應(yīng)用組件，我有一種編排的能力，我把這種已有的組件可以通過一種描述，把它編排起來。這個編排里面寫哪些信息呢?一個信息是我一個大的應(yīng)用，編排一個大的應(yīng)用，里面有多少個小的應(yīng)用組成，這些應(yīng)用之間的關(guān)系是什么，它們啟停的優(yōu)先順序是什么。如果這個東西都可以用一種描述語言描述出來之后，我們把這個描述語言打成包，是不是我以后部署直接把這個描述語言部下去就可以了。系統(tǒng)可以根據(jù)我的描述語言對它提供的要求，執(zhí)行我們描述性的一些語句，***能夠負(fù)責(zé)把整個應(yīng)用啟起來的目的。如果這個東西有的話，以后如果這個應(yīng)用架構(gòu)發(fā)生變化之后，我是不是簡單的改改描述語言就可以了。朝這個方向走的話，我們通常說PaaS還會提供一個能力，就是整個上面跨應(yīng)用的編排能力。這個編排能力有的話，就使我們應(yīng)用的部署和將來的變化，變得非常的容易。這個編排能力有的時候，就是一種描述語言，描述語言的好處是說，我寫完之后可以管理版本，每一次變化直接調(diào)調(diào)那個描述的東西就可以了。

對于這個描述語言再增強(qiáng)的需求是什么呢，有沒有一個可視化的方法，把這個描述語言給展示出來。我們很清楚的看到，過去從腦子里看到我有一個應(yīng)用，前面有一個web的應(yīng)用，中間一個redis或者什么，我都在嘴上說。是不是我可以畫出來，上面一個這個，這里一個，中間連一根線，這根線就描述了它的依賴關(guān)系。這根線的關(guān)系可能是代表了我依賴于一個redis的服務(wù)，這個服務(wù)我再講細(xì)一點(diǎn)，服務(wù)也算很多類型。這個服務(wù)可能因?yàn)槟氵@個應(yīng)用程序存在而部的一個服務(wù)，也可能是應(yīng)用公共的一個服務(wù)。

所以框到這兒之后，我們再回過頭看看我們的理想能實(shí)現(xiàn)到什么程度了。我們有這樣一個平臺，***是我們所有的應(yīng)用，我先不講前半生，前半生里可能含的是我先寫代碼，我寫一個代碼。假設(shè)我一個應(yīng)用有很多微服務(wù)組成，我先定義了微服務(wù)的IDL，上個話題。我寫了IDL，就把一個應(yīng)用拆成很多很多的部件組成。把IDL編譯成一個組件，每一個組件裝代碼，我在每個組件里面寫我自己的應(yīng)用程序，業(yè)務(wù)邏輯。寫完業(yè)務(wù)邏輯，提交到源代碼的倉庫上去。這個應(yīng)用后面編譯和部署的流程，通過上個講期我們說的DevOps拖拉拽的環(huán)節(jié)，我給它制訂了一些標(biāo)標(biāo)準(zhǔn)的拖拉拽的過程。***一個節(jié)點(diǎn)如果所有的編譯都OK，那么就是上鏡像，然后去部署。部署的時候，因?yàn)槲覀兲崆皶O(shè)計好一個應(yīng)用有多少組件組成的，這些組件之間的關(guān)系我就用一個圖形化的工具，假定我這些應(yīng)用的鏡像都已經(jīng)OK了，我就提前把這個自動化的工具，把應(yīng)用各個的關(guān)系和部署的組件的關(guān)系畫成一個部署的圖，畫完之后存在系統(tǒng)里面作為一個模板放在那兒就可以了。

之后我就開始去開發(fā)，開發(fā)之后我只要一提交我的源代碼，是不是它的整個DevOps流程就開始往下走。走到***一步，是不是生成了各種各樣的鏡像。生成鏡像之后，又會觸發(fā)部署的過程，這個部署的過程就是我們剛剛說的用圖形化工具編排的那個應(yīng)用的整個部署的關(guān)系描述。然后靠那個關(guān)系描述，因?yàn)槟莻€關(guān)系描述里面并不規(guī)定我一定要部署在哪些機(jī)器上，我只需要資源需求就可以了。我下面只要有了足夠的資源，有系統(tǒng)幫我們?nèi)グ衙恳粋€節(jié)點(diǎn)都挑一個很合適的資源，分配給它。分配給它之后，同時把它部下去。部下去之后，就完成了我們整個應(yīng)用的代碼編寫，到***整個上線的過程。

剛才我們也提到了因?yàn)槲覀冊谠O(shè)計那個圖的時候，會除了做部署上的策略以外，還會有一些其他策略。舉個例子，像彈性伸縮策略，灰度發(fā)布策略，這些策略都可以在那個圖里面描述出來。這些策略最終會結(jié)合什么呢，因?yàn)镻aaS底層有一定的兼并性。基本上這樣離我們期望的目標(biāo)就比較接近了，最終我們監(jiān)控的部分配合到彈性伸縮的策略，和我們灰度發(fā)布的策略，使我們的整個應(yīng)用，在將來運(yùn)營的過程之中，舉個例子，比如負(fù)荷很高的時候，可以增加一些節(jié)點(diǎn)，負(fù)荷很低的時候，在我的空檔的周期之后會把節(jié)點(diǎn)降下來。大概這樣整個的過程就OK了。

剛才我是站在研發(fā)角度去看PaaS給我們開發(fā)的過程帶來的好處，我再稍微總結(jié)一下，我們期望做到的是什么呢。***我們DevOps能夠把我整個應(yīng)用的生命周期前半生和后半生都管起來。第二我后半生管的時候，我只提一些要求，由平臺主動的幫我們進(jìn)行各種各樣的調(diào)度。第三我們運(yùn)維過程里面的這些東西，都是根據(jù)我們的調(diào)度策略和算法自動的幫我們完成，而不是我們手工要做的。能夠把這些東西都實(shí)現(xiàn)，我們的service可以提供讓我們能夠把現(xiàn)有應(yīng)用的能力整合起來，能夠把這些點(diǎn)都實(shí)現(xiàn)了之后，我們就希望關(guān)注于寫業(yè)務(wù)邏輯，使我們整個應(yīng)用的管理變得更加的簡單。這就是我們期望在做PaaS設(shè)計的過程里面，要做的這一點(diǎn)。所以我們所有的組件都是圍繞這些點(diǎn)去做的。剛才也提到一些問題，我們?nèi)プ稣{(diào)度的時候會有哪些問題，我的部分基本到這里就結(jié)束了。

(結(jié)束)