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

雖然同樣談PaaS，但是華為PaaS平臺資深架構師張龍春則是另辟了一個角度。他來自中央軟件院PaaS架設部，所以他主要談談華為設計這個系統的時候到底是怎么考慮初始架構的，從這個角度看PaaS核心組建高效靈活的應用調度和資源管理。

以下是他的現場演講實錄：

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

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

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

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

接著剛才說DevOps，我以前經常說DevOps是管一個應用系統的前半生的。什么叫前半生的?就是從調研接需求，到開發，一直到這個程序寫出來，整個鏡像打開了，開始編譯部署，這是前半生。什么叫后半生呢?我部署上去了，我要運營，我要監控監管，日常出報表，定期看結果，***到經過五年十年這個程序下線了，這是它的后半生。我以前提過這樣一個話題，DevOps是管前半生的，而我們的PaaS運營平臺是管后半生的。但是我一節課仔細聽了馬大師的演講，我新的感覺是其實DevOps是管一個應用一生的，只不過它的后半生還用了DevOps的思想，把它放到了PaaS去管了它的后半生。所以我現在的觀點是DevOps是管整個應用的一生，后半生是靠PaaS幫它一起實現的。我們站在這個思想上來想。

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

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

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

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

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

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

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

所以我們知道為什么過去那些PaaS平臺會定一系列的標準，我需要一個什么東西，把程序的啟停封裝起來，來達到我對外提供統一的啟停和應用管理的目的。但是容器化之后就不一樣了，容器化之后你所有的東西都放在了容器里面，這個時候所有的啟停都被認為是容器的啟停，所以整個應用的啟停簡單的就變成一個程序的啟停，就是容器的啟停。這樣一下子就把應用程序對外的接口變得非常干凈。

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

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

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

但是我們知道虛擬機的啟停和容器的啟停級別肯定不在一個級別上的，容器其實就是一個啟一個進程，容器如果還能提供隔離機制的話，我們就能產生***個好處，我們可以在一臺機器上布很多的容器。而每一個容器之間是互相隔離的，因為這個技術大家都很了解，我只是談談能給大家帶來的好處，傳統應用的不同組件就可以核設到一臺機器上去。核設到一臺機器上的好處就是，我不需要很多很小的虛擬機。舉個例子，我現在的物理機規模都很大，48核，128的，256內存的機器。過去畫10個虛擬機或者20個虛擬機。但是一旦畫完虛擬機之后，虛擬化本身的消耗也很牛，而且這個管理也很麻煩。在這種情況下，如果我們可以把一個應用的不同組件核設到一臺機器，同時又能夠做到一定的隔離性，這樣我應用的部署是不是也會變得相對的簡單起來了，這也是一個站在虛擬化和容器化角度來看應用部署革新性的變化。就是我程序的核設部署變得非常簡單，而虛擬機的用度可以不需要畫的非常的小，這樣我應用的管理也會變得非常的容易。所以從這些角度來看的話，應用這個層面，將來的管理就會有新的不同的理解和突破。

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

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

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

但是作為一個整體的應用，我是不是還得把這幾個東西單獨手工的弄一遍呢?還有一個機制能夠把一個應用不同的組件，或者是不同的部分，能夠把它編串起來，形成一個整體。我們以這個整體為單位，來看應用，是不是這樣就會比較理想一些。所以我們就希望另外一個概念，有一個機制是跨不同的，每一個應用程序，組成一個虛擬整體的應用的角度。這個時候我們通常會說，當然這個調度的核心有很多，我們可能會選Kuberentes，因為今天上午其他的專題也都提到了我們有Kuberentes，有很多很多的平臺做這件事情。不管是哪個平臺都要解決這些問題。

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

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

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

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

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

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

其實親和性和反親和性的也是調度的一個過程而已，親和性和反親和性就是剛才算法的一些特例，但是為什么單獨提出來呢?因為在很多算法里面，在很多的實際場景里面，親和性和反親和性的作用還是非常大的。舉個例子，我們在做應用的，剛才說我們過去是命令式的，現在是需求式的，提需求，去定義的方式去做的。我的需求定于的方式去做的時候，其實我真的不知道底層到底能給我調度到什么地方去，因為不是我指定的節點。因為把排他性條件去掉之后，合適的節點可能還有幾十個，這種情況下我們有時候為了應用的特別的需要，特別是高可用的需要，或者是一些其他的需要，會有一些特別的要求。這種特別的要求就要求有些應用程序是希望離的越遠越好，或者說它不希望在一個物理機器上存在。這樣就導致這一臺物理機器如果出了故障，它所有的節點都宕掉了。如果它在不同數據中心，你換一個，它的數據中心還在。這就有點類似于反親和的戰略。

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

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

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

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

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

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

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

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

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

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

所以框到這兒之后，我們再回過頭看看我們的理想能實現到什么程度了。我們有這樣一個平臺，***是我們所有的應用，我先不講前半生，前半生里可能含的是我先寫代碼，我寫一個代碼。假設我一個應用有很多微服務組成，我先定義了微服務的IDL，上個話題。我寫了IDL，就把一個應用拆成很多很多的部件組成。把IDL編譯成一個組件，每一個組件裝代碼，我在每個組件里面寫我自己的應用程序，業務邏輯。寫完業務邏輯，提交到源代碼的倉庫上去。這個應用后面編譯和部署的流程，通過上個講期我們說的DevOps拖拉拽的環節，我給它制訂了一些標標準的拖拉拽的過程。***一個節點如果所有的編譯都OK，那么就是上鏡像，然后去部署。部署的時候，因為我們提前會設計好一個應用有多少組件組成的，這些組件之間的關系我就用一個圖形化的工具，假定我這些應用的鏡像都已經OK了，我就提前把這個自動化的工具，把應用各個的關系和部署的組件的關系畫成一個部署的圖，畫完之后存在系統里面作為一個模板放在那兒就可以了。

之后我就開始去開發，開發之后我只要一提交我的源代碼，是不是它的整個DevOps流程就開始往下走。走到***一步，是不是生成了各種各樣的鏡像。生成鏡像之后，又會觸發部署的過程，這個部署的過程就是我們剛剛說的用圖形化工具編排的那個應用的整個部署的關系描述。然后靠那個關系描述，因為那個關系描述里面并不規定我一定要部署在哪些機器上，我只需要資源需求就可以了。我下面只要有了足夠的資源，有系統幫我們去把每一個節點都挑一個很合適的資源，分配給它。分配給它之后，同時把它部下去。部下去之后，就完成了我們整個應用的代碼編寫，到***整個上線的過程。

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

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

(結束)