摘要：在谷歌不是這樣，谷歌不會(huì)把特定的應(yīng)用裝在某臺(tái)服務(wù)器上，業(yè)務(wù)應(yīng)用和服務(wù)器的強(qiáng)綁定對(duì)于谷歌這種量級(jí)的數(shù)據(jù)中心的維護(hù)難度太高了。但是金融機(jī)構(gòu)的數(shù)據(jù)中心規(guī)模不像谷歌這么大，所以能做到業(yè)務(wù)應(yīng)用和硬件的強(qiáng)綁定。

復(fù)雜的基礎(chǔ)IT架構(gòu)是傳統(tǒng)金融的現(xiàn)狀，如何快速響應(yīng)用戶需求，加快新業(yè)務(wù)上線速度，縮短產(chǎn)品的迭代周期? 數(shù)人云在容器落地金融云的2年實(shí)踐中，實(shí)現(xiàn)金融核心業(yè)務(wù)技術(shù)WebLogic、J2EE、Oracle中間件的容器生產(chǎn)標(biāo)準(zhǔn)，已在證券交易所、股份制銀行落地生根發(fā)芽。服務(wù)編排、服務(wù)發(fā)現(xiàn)、持續(xù)集成、大數(shù)據(jù)容器化、高性能容器環(huán)境等多方面為業(yè)界提供參考實(shí)施標(biāo)準(zhǔn)，真正構(gòu)建動(dòng)態(tài)靈活的金融IT。以下是數(shù)人云 創(chuàng)始人兼CEO王璞在2016@Container容器技術(shù)大會(huì)·上海站發(fā)表主題演講的實(shí)錄分享：

首先我們一起看三個(gè)問(wèn)題，這三個(gè)問(wèn)題不僅困擾著金融行業(yè)，很多傳統(tǒng)行業(yè)的企業(yè)也同樣面臨著這些挑戰(zhàn)。

首先，新應(yīng)用上線速度已經(jīng)從月縮短到天，如何快速響應(yīng)用戶需求？新的應(yīng)用上線對(duì)速度要求很高，在國(guó)內(nèi)，互聯(lián)網(wǎng)行業(yè)發(fā)展非常迅速，互聯(lián)網(wǎng)給傳統(tǒng)行業(yè)帶來(lái)了很大的沖擊和影響。傳統(tǒng)行業(yè)的很多業(yè)務(wù)也需要快速上線，這對(duì)他們已有的IT架構(gòu)提出了很大的要求。第二，新技術(shù)層出不窮，如何以標(biāo)準(zhǔn)化的方式進(jìn)行應(yīng)用交付及運(yùn)維？這個(gè)問(wèn)題也非常典型，是很多傳統(tǒng)行業(yè)的企業(yè)都會(huì)碰到的問(wèn)題。新技術(shù)該如何選擇、如何落地、如何交付？最后，秒殺、紅包等高并發(fā)應(yīng)用增長(zhǎng)，如何應(yīng)對(duì)彈性應(yīng)用突發(fā)增長(zhǎng)？秒殺、紅包這樣的高并發(fā)業(yè)務(wù)非常具有互聯(lián)網(wǎng)的特征，金融機(jī)構(gòu)這樣的傳統(tǒng)企業(yè)要如何應(yīng)對(duì)？

這三個(gè)問(wèn)題共同反應(yīng)出的一個(gè)現(xiàn)象是，傳統(tǒng)行業(yè)的企業(yè)業(yè)務(wù)形態(tài)已經(jīng)發(fā)生了變化。眾所周知，金融行業(yè)具有大量面向個(gè)人用戶提供的服務(wù)，2C的場(chǎng)景和互聯(lián)網(wǎng)的結(jié)合是一個(gè)不可逆轉(zhuǎn)的趨勢(shì)，而正是2C服務(wù)的互聯(lián)網(wǎng)化、在線化，導(dǎo)致了金融行業(yè)業(yè)務(wù)形態(tài)的變化。在今天，金融行業(yè)的很多業(yè)務(wù)本身具有了互聯(lián)網(wǎng)業(yè)務(wù)、互聯(lián)網(wǎng)場(chǎng)景的特征，這就要求金融行業(yè)結(jié)合互聯(lián)網(wǎng)場(chǎng)景去解決新的業(yè)務(wù)問(wèn)題。同時(shí)，安全可控信息技術(shù)的需求，也給金融機(jī)構(gòu)的IT架構(gòu)帶來(lái)新的挑戰(zhàn)。

第一條跟其它行業(yè)非常不一樣，即合規(guī)是紅線，零事故是要求。銀監(jiān)會(huì)、保監(jiān)會(huì)、證監(jiān)會(huì)對(duì)金融行業(yè)有很多要求，很多規(guī)則都是不能觸碰的紅線。金融行業(yè)對(duì)穩(wěn)定性的要求非常高。

第二，互聯(lián)網(wǎng)場(chǎng)景業(yè)務(wù)面臨高并發(fā)壓力。這也是金融機(jī)構(gòu)在傳統(tǒng)的業(yè)務(wù)中不曾面對(duì)的挑戰(zhàn)。傳統(tǒng)業(yè)務(wù)的特點(diǎn)是具有穩(wěn)定的峰值，白天的工作時(shí)間有一定的峰值，會(huì)達(dá)到一定的高峰，而到了晚上又回落下來(lái)，第二天的高峰和前一天的高峰非常接近，而互聯(lián)網(wǎng)場(chǎng)景業(yè)務(wù)則是突發(fā)的、不可預(yù)測(cè)的。

第三，已有應(yīng)用快速部署難以實(shí)現(xiàn)，緩慢的升級(jí)流程。這也是金融行業(yè)已有業(yè)務(wù)特點(diǎn)決定的，由于穩(wěn)定壓倒一切，這就需要經(jīng)過(guò)全面的測(cè)試，全方位的集成等等，而這延緩了上線的速度。金融業(yè)通過(guò)降低業(yè)務(wù)上線的速度保證穩(wěn)定性，與互聯(lián)網(wǎng)公司的做法剛好相反。

第四，多套環(huán)境相互隔離，測(cè)試環(huán)境搭建極其耗時(shí)。金融行業(yè)的IT環(huán)境是互相隔離的，舉例來(lái)說(shuō)，銀行的開(kāi)發(fā)、測(cè)試、生產(chǎn)至少有三個(gè)環(huán)境，三者之間基本上都是物理隔絕的。而環(huán)境的物理隔絕，則導(dǎo)致了測(cè)試環(huán)境搭建的難度，很難復(fù)現(xiàn)生產(chǎn)環(huán)節(jié)。我之前在谷歌，谷歌只有一套生產(chǎn)環(huán)境，開(kāi)發(fā)、測(cè)試以及生產(chǎn)都在一個(gè)大的數(shù)據(jù)中心混合聚集。以谷歌為代表的互聯(lián)網(wǎng)公司的開(kāi)發(fā)、測(cè)試、生產(chǎn)環(huán)境不是物理隔絕的，三個(gè)環(huán)境混合搭建，這樣的話，測(cè)試、復(fù)現(xiàn)整個(gè)生產(chǎn)環(huán)境就變得非常方便。但是，出于合規(guī)的要求，金融行業(yè)是做不到的。

第五，大版本升級(jí)不可回滾。這和上一條各環(huán)境互相隔離是有關(guān)聯(lián)的。因?yàn)榄h(huán)境很復(fù)雜，金融機(jī)構(gòu)很難回滾，因?yàn)槊看紊暇€都會(huì)對(duì)已有環(huán)境做修改，回滾就需要撤銷此前的修改，所以回滾在金融行業(yè)是也很難實(shí)現(xiàn)的。

第六，各種異構(gòu)設(shè)備，硬件資源利用率極低。最后一點(diǎn)可謂金融行業(yè)的一個(gè)歷史包袱，在金融機(jī)構(gòu)中各種各樣的異構(gòu)設(shè)備非常的多。十年前很多金融機(jī)構(gòu)都大量采用大型機(jī)、小型機(jī)，這些設(shè)備一直沿用至今。另外，這些設(shè)備的資源利用率并不是很高。因?yàn)椋瑐鹘y(tǒng)業(yè)務(wù)并不具有突發(fā)性的特點(diǎn)，非常有規(guī)律，比如白天是高峰，到了晚上就是低谷，利用晚上的時(shí)間還可以跑各種批量的業(yè)務(wù)。此外，金融行業(yè)很多的業(yè)務(wù)都是跟硬件綁定的，很多業(yè)務(wù)應(yīng)用都是靜態(tài)部署的，每個(gè)業(yè)務(wù)都是由特定的硬件去支撐的。在谷歌不是這樣，谷歌不會(huì)把特定的應(yīng)用裝在某臺(tái)服務(wù)器上，業(yè)務(wù)應(yīng)用和服務(wù)器的強(qiáng)綁定對(duì)于谷歌這種量級(jí)的數(shù)據(jù)中心的維護(hù)難度太高了。谷歌有兩百多萬(wàn)臺(tái)服務(wù)器，如果業(yè)務(wù)應(yīng)用都要和服務(wù)器進(jìn)行強(qiáng)綁定，那運(yùn)維人員在上線的時(shí)候，就要記住每臺(tái)服務(wù)器上跑了什么應(yīng)用，這顯然是不可能的。但是金融機(jī)構(gòu)的數(shù)據(jù)中心規(guī)模不像谷歌這么大，所以能做到業(yè)務(wù)應(yīng)用和硬件的強(qiáng)綁定。但是強(qiáng)綁定就意味著資源利用率不高，因?yàn)闃I(yè)務(wù)不可能7*24小時(shí)都處于繁忙狀態(tài)，在閑的時(shí)候，計(jì)算資源就無(wú)法得到充分的利用。

以上是金融行業(yè)IT現(xiàn)狀的一些介紹，不能說(shuō)很全面，這是數(shù)人云接觸到的金融客戶的表現(xiàn)，尤其是它們和互聯(lián)網(wǎng)公司差異性非常大的地方。

這里列了三個(gè)方面——新容量、新速度、新效率，總結(jié)了金融行業(yè)IT發(fā)展的一些新的需求。

首先是新的容量，容量指的是業(yè)務(wù)的容量。金融行業(yè)的業(yè)務(wù)規(guī)模發(fā)生了很大的變化，紅包、秒殺這樣的業(yè)務(wù)需要瞬間橫向擴(kuò)容的能力，金融行業(yè)需要秒級(jí)橫向擴(kuò)容能力扛住搶紅包等突發(fā)性流量。同時(shí)金融行業(yè)還需要屏蔽底層的異構(gòu)，實(shí)現(xiàn)混合云無(wú)縫部署。

另外一點(diǎn)新的速度，互聯(lián)網(wǎng)快速的業(yè)務(wù)迭代給傳統(tǒng)行業(yè)帶來(lái)了很大的影響，傳統(tǒng)行業(yè)也在不停地提升自己的業(yè)務(wù)迭代速度。在保證穩(wěn)定性的前提下，像互聯(lián)網(wǎng)公司那樣做到每個(gè)月或每周都能有新的版本的迭代，這對(duì)于金融行業(yè)是非常困難的。因此，金融行業(yè)需要實(shí)現(xiàn)無(wú)手工操作，從代碼到線上環(huán)境持續(xù)集成，將上線時(shí)間縮短到小時(shí)級(jí)別。金融機(jī)構(gòu)需要靈活提供全真的測(cè)試和開(kāi)發(fā)環(huán)境，并通過(guò)灰度發(fā)布、A/B測(cè)試降低快速發(fā)布帶來(lái)的風(fēng)險(xiǎn)。

再一個(gè)就是新的效率，金融行業(yè)需要將傳統(tǒng)物理機(jī)的資源利用率提高2-3倍，底層實(shí)現(xiàn)小規(guī)模錯(cuò)誤自動(dòng)容錯(cuò)，同時(shí)還要有效管理不同基礎(chǔ)設(shè)施上的多個(gè)集群，使他們不受業(yè)務(wù)規(guī)模擴(kuò)張影響。

這三點(diǎn)既是金融行業(yè)IT發(fā)展的挑戰(zhàn)，也是需求，這是我們簡(jiǎn)單總結(jié)的金融行業(yè)IT的期望。前面說(shuō)到，金融行業(yè)的業(yè)務(wù)發(fā)生了很大的變化，2C的業(yè)務(wù)越來(lái)越具有互聯(lián)網(wǎng)的特征。因此，支撐2C相關(guān)互聯(lián)網(wǎng)場(chǎng)景的業(yè)務(wù)需要盡量做到一體化，也就是說(shuō)，從需求的提出、到開(kāi)發(fā)、測(cè)試、發(fā)布上線，再到后續(xù)的運(yùn)維、監(jiān)控等等，所有的流程都要盡量使用一個(gè)流程。

統(tǒng)一的流程可以使整個(gè)應(yīng)用的生命周期變得平滑，而這也是Docker技術(shù)帶來(lái)的巨大便利。Docker屏蔽了環(huán)境的異構(gòu)，使開(kāi)發(fā)寫(xiě)好的程序到測(cè)試也同樣能夠跑起來(lái)，測(cè)試跑通的程序再到生產(chǎn)環(huán)境也同樣適用，這樣一體化、平滑的流程就貫穿了應(yīng)用的整個(gè)生命周期。

下面舉了一兩個(gè)特定需求，比如在測(cè)試環(huán)境里如何基于容器技術(shù)快速搭建各種各樣的測(cè)試環(huán)境；在測(cè)試的時(shí)候如何基于容器技術(shù)快速生成組件，測(cè)完了還可以快速回收。這些都還是期望，的確是一個(gè)很大的藍(lán)圖，現(xiàn)階段金融行業(yè)還無(wú)法實(shí)現(xiàn)這么平滑的流程，但是整個(gè)金融業(yè)都在朝著這個(gè)方向努力，開(kāi)發(fā)、測(cè)試和運(yùn)維部門(mén)都在積極的擁抱Docker技術(shù)，擁抱容器技術(shù)來(lái)對(duì)他們的IT架構(gòu)進(jìn)行換代升級(jí)。

容器技術(shù)可以為金融行業(yè)打造平滑、一體化的IT系統(tǒng)，同時(shí)，它也會(huì)給已有IT架構(gòu)帶來(lái)很多的變化。我們一起看容器是如何與金融機(jī)構(gòu)已有架構(gòu)來(lái)對(duì)應(yīng)的。

用類比的角度來(lái)看，很多金融行業(yè)客戶現(xiàn)有的企業(yè)級(jí)IT架構(gòu)大多是基于Java的，是右面這套構(gòu)架。最下面是資源層，以前右邊都是基于IBM、惠普這些高端的硬件，像大型機(jī)、小型機(jī)。左邊是采用云構(gòu)架以后，更多的都是偏X86，PC機(jī)的服務(wù)器，基于X86做虛擬化或者是采用私有云、公有云服務(wù)，這是資源這一層。再上面對(duì)應(yīng)到中間件這層，此前金融行業(yè)大量使用基于Java的中間件，像Weblogic、WebSphere。中間件要提供標(biāo)準(zhǔn)的Java運(yùn)行的環(huán)境，用J2EE等等開(kāi)發(fā)的Jar包都會(huì)跑到中間件上。尤其是像Java的中間件，包括Weblogic、WebSphere提供的就是標(biāo)準(zhǔn)的Java程序的運(yùn)行環(huán)境。對(duì)應(yīng)到云這邊，基于容器技術(shù)的數(shù)據(jù)中心操作系統(tǒng)，也就是這個(gè)云計(jì)算的PaaS平臺(tái)，就是云時(shí)代的中間件，因此，它要提供標(biāo)準(zhǔn)的應(yīng)用運(yùn)行環(huán)境。這些應(yīng)用現(xiàn)在絕大部分都是容器化的應(yīng)用。中間件這一層要提供標(biāo)準(zhǔn)的運(yùn)行環(huán)境，以前的Weblogic、WebSphere等Java中間件提供標(biāo)準(zhǔn)的Java程序的運(yùn)行環(huán)境，而左邊的PaaS平臺(tái)則要提供標(biāo)準(zhǔn)的容器應(yīng)用的運(yùn)行環(huán)境。再往上一層就到業(yè)務(wù)封裝，業(yè)務(wù)應(yīng)用開(kāi)發(fā)這一層，傳統(tǒng)企業(yè)級(jí)IT都是用Java、J2EE，現(xiàn)在大家則更多的用容器去封裝。容器不是一個(gè)單純的編程語(yǔ)言，更多是應(yīng)用的封裝方式，容器里面可以是各種各樣的應(yīng)用，Java的、C++或PHP的。對(duì)應(yīng)用進(jìn)行封裝，J2EE是封裝成Jar包的形式，而到了云時(shí)代大家則用Docker進(jìn)行封裝，使之變成容器的形式。業(yè)務(wù)封裝再往上一層就是業(yè)務(wù)的架構(gòu)了，傳統(tǒng)企業(yè)級(jí)IT更多用SOA的構(gòu)架，到了云計(jì)算時(shí)代，使用了容器技術(shù)，大家就開(kāi)始過(guò)渡到微服務(wù)的構(gòu)架。微服務(wù)和SOA的構(gòu)架在本質(zhì)上是一脈相承的。首先SOA構(gòu)架是面向服務(wù)的，微服務(wù)也是面向服務(wù)的，只不過(guò)微服務(wù)對(duì)于服務(wù)的細(xì)粒度變得更細(xì)小了。微服務(wù)對(duì)每個(gè)服務(wù)都分別去進(jìn)行開(kāi)發(fā)、維護(hù)、上線。這和傳統(tǒng)的SOA是不太一樣的，SOA更多的是將開(kāi)發(fā)層面不同的業(yè)務(wù)邏輯抽象成不同的服務(wù)，再將不同的服務(wù)分派給不同的團(tuán)隊(duì)進(jìn)行開(kāi)發(fā)，最后整體上線。而微服務(wù)連上線都是碎片化的，不同的微服務(wù)各做各的運(yùn)維，這是業(yè)務(wù)構(gòu)架層面。最上層是開(kāi)發(fā)和運(yùn)維組織構(gòu)架的層面，傳統(tǒng)企業(yè)的開(kāi)發(fā)運(yùn)維是分離的，云時(shí)代的開(kāi)發(fā)運(yùn)維要做到持續(xù)集成、DevOps。其實(shí)持續(xù)集成、DevOps或者是再通俗一點(diǎn)的敏捷開(kāi)發(fā)，最根本的就是整個(gè)開(kāi)發(fā)運(yùn)維的一體化，這涉及很多組織構(gòu)架層面的調(diào)整。這就涉及到人事、組織方面的調(diào)整，這與IT架構(gòu)的調(diào)整是不同的，是很復(fù)雜的改變。

基于云計(jì)算重塑新一代企業(yè)級(jí)IT，不僅僅是技術(shù)層面的改變，也是組織架構(gòu)方面的改變。這其中會(huì)包括開(kāi)發(fā)和運(yùn)維的協(xié)作方式，多部門(mén)間的融合，職能劃分的變更等等。在谷歌，開(kāi)發(fā)大概能達(dá)到兩萬(wàn)名左右，而運(yùn)維人員也就一兩千名，數(shù)量非常少。但是谷歌的運(yùn)維人員管理服務(wù)器的數(shù)量卻是很大的，幾百萬(wàn)臺(tái)服務(wù)器全部由運(yùn)維來(lái)管。谷歌的運(yùn)維部門(mén)和金融行業(yè)運(yùn)維人員做的事情是不一樣的。谷歌的運(yùn)維人員做的更多是資源的規(guī)劃，以及開(kāi)發(fā)流程的規(guī)約等。谷歌的運(yùn)維把很多傳統(tǒng)行業(yè)運(yùn)維做的事情下放給開(kāi)發(fā)，比如說(shuō)業(yè)務(wù)的上線，谷歌的運(yùn)維人員是不管開(kāi)發(fā)的。

敏捷開(kāi)發(fā)絕對(duì)不是形式上的東西，它會(huì)有很深的組織架構(gòu)和職能上的轉(zhuǎn)變。這張PPT介紹，如何從傳統(tǒng)的企業(yè)級(jí)IT角度理解基于云的IT構(gòu)架。它包含三個(gè)部分，監(jiān)控部分、管理部分和操控部分。中間通過(guò)CMDB配置管理數(shù)據(jù)庫(kù)把幾個(gè)模塊連通起來(lái)，這張圖對(duì)于傳統(tǒng)企業(yè)級(jí)IT業(yè)內(nèi)人士比較容易理解。

系統(tǒng)的集中監(jiān)控有很多層面，包括機(jī)房設(shè)備的監(jiān)控、拓?fù)涞谋O(jiān)控等等。自動(dòng)化的操作平臺(tái)，包括任務(wù)的上線，權(quán)限的管理等等，下面有機(jī)房、網(wǎng)絡(luò)等系統(tǒng)不同的操作，這兩個(gè)模塊對(duì)于很多金融行業(yè)數(shù)據(jù)中心部門(mén)的同事不會(huì)覺(jué)得陌生，他們每天的日常工作就在這兩部分里面。監(jiān)控和自動(dòng)化操作稱之為操控，上面就是管理的部分。管理部分更多的是流程化的東西，比如數(shù)據(jù)中心運(yùn)行管理調(diào)度出了問(wèn)題如何去處理，變更如何去處理，發(fā)布如何去處理，配置如何去管理等等。管理是整個(gè)數(shù)據(jù)中心外延的部分。

那么，容器云要如何與已有的數(shù)據(jù)中心運(yùn)維的工作結(jié)合呢？數(shù)人云更多是從自動(dòng)化的操作切入的。因?yàn)樵诠芾韺用?，金融企業(yè)介于合規(guī)的紅線，管理流程不是在短期內(nèi)能夠改變的。數(shù)人云考慮的是落地，也就是說(shuō)如何用容器這項(xiàng)新技術(shù)快速幫助到金融客戶。因此，我們更多的是從操控的點(diǎn)落進(jìn)去，因?yàn)閺倪@個(gè)層面切入不會(huì)影響金融客戶已有的管理流程。基于容器云的很多操作就會(huì)變得非常方便，像應(yīng)用的快速部署、快速上線、任務(wù)的管理，以及權(quán)限資源方面配額的管理都會(huì)變的很方便，這些都屬于自動(dòng)化操控部分。但是只做到應(yīng)用的快速上線、彈性部署這些還不夠，因?yàn)樯a(chǎn)環(huán)節(jié)還需要大量的監(jiān)控，因此我們會(huì)把容器云與客戶已有的監(jiān)控平臺(tái)進(jìn)行對(duì)接，使監(jiān)控、日志、報(bào)警等都沿用客戶已有的流程去處理。數(shù)人云從這個(gè)點(diǎn)切入，幫助數(shù)據(jù)中心的運(yùn)維操控變得更加的自動(dòng)化，降低運(yùn)維的復(fù)雜度。

最重要的一點(diǎn)就是不破壞，不改變上層的管理流程，這正是數(shù)人云切入的角度。但是就像上面講的，未來(lái)如果真的要做到完全基于云、實(shí)現(xiàn)敏捷開(kāi)發(fā)、DevOps的話，那企業(yè)的組織構(gòu)架，以及管理上的調(diào)整肯定是避免不了的。我們作為容器技術(shù)廠商，更多是從技術(shù)落地的角度去考慮問(wèn)題，所以我們主要落地是從自動(dòng)化操控去切入。

下來(lái)簡(jiǎn)單介紹一下容器云在金融行業(yè)落地的部分場(chǎng)景。

第一個(gè)場(chǎng)景是彈性擴(kuò)容的場(chǎng)景，比如秒殺、紅包這樣的場(chǎng)景，它們都有彈性擴(kuò)容的需求。讓?xiě)?yīng)用具有彈性能力，具有彈性擴(kuò)張和收縮的能力會(huì)很好的提升數(shù)據(jù)中心的資源利用率。當(dāng)某個(gè)業(yè)務(wù)計(jì)算量很大的時(shí)候，就可以彈性地把業(yè)務(wù)應(yīng)用進(jìn)行擴(kuò)張，占用更多的計(jì)算資源。而當(dāng)這個(gè)業(yè)務(wù)規(guī)模降下來(lái)的時(shí)候，后臺(tái)的業(yè)務(wù)應(yīng)用也能相應(yīng)的收縮回來(lái)，把計(jì)算資源釋放給其他應(yīng)用用，讓業(yè)務(wù)應(yīng)用具有彈性、擴(kuò)縮的能力，這也是應(yīng)對(duì)業(yè)務(wù)容量的一種變化。

彈性擴(kuò)縮用容器，用Docker來(lái)做是會(huì)非常方便的。比如通過(guò)監(jiān)控網(wǎng)絡(luò)的延遲或其他業(yè)務(wù)相關(guān)的指標(biāo)對(duì)業(yè)務(wù)的接口速度進(jìn)行監(jiān)控。當(dāng)這個(gè)業(yè)務(wù)指標(biāo)發(fā)現(xiàn)網(wǎng)絡(luò)延遲增加了，某個(gè)服務(wù)的網(wǎng)絡(luò)延遲增加了，或者某個(gè)服務(wù)的請(qǐng)求數(shù)到了一定閾值，就開(kāi)始進(jìn)行自動(dòng)擴(kuò)展的關(guān)系性邏輯。自動(dòng)擴(kuò)展對(duì)于Docker來(lái)講是非常方便的，其實(shí)就是增加很多Docker的應(yīng)用實(shí)例。這里指的是web實(shí)例，每個(gè)web實(shí)例封裝在Docker容器里面，需要擴(kuò)張的時(shí)候用調(diào)度平臺(tái)把這個(gè)容器的實(shí)例調(diào)度開(kāi)，就可以迅速擴(kuò)張應(yīng)用的實(shí)例。同時(shí)，對(duì)于資源層面來(lái)講，如果企業(yè)下面做了一層私有云的IaaS的管理，那么這個(gè)容器云就可以調(diào)度IaaS的接口，調(diào)度OpenStack或者VMware，生成更多的虛擬機(jī)請(qǐng)求更多的計(jì)算資源，然后計(jì)算資源上再把容器分配和調(diào)度過(guò)去。彈性擴(kuò)容其實(shí)是很好理解的，就是調(diào)度更多的實(shí)例。

第二個(gè)場(chǎng)景，相對(duì)復(fù)雜一些，對(duì)應(yīng)新的速度，業(yè)務(wù)應(yīng)用從代碼到生產(chǎn)，做持續(xù)集成、持續(xù)交付。復(fù)雜的地方在哪兒呢，首先不同的環(huán)境需要用Docker打通，這也是Docker非常擅長(zhǎng)的地方。開(kāi)發(fā)和測(cè)試環(huán)境相對(duì)比較容易打通，在網(wǎng)絡(luò)上是可達(dá)的。但是測(cè)試和生產(chǎn)環(huán)境就比較難打通，網(wǎng)絡(luò)上一般是不可達(dá)的，這就要求傳遞的東西要更加標(biāo)準(zhǔn)。因此，從測(cè)試到生產(chǎn)環(huán)境，傳遞過(guò)去最好都是Docker化的應(yīng)用。

開(kāi)發(fā)的流程是不變的，Docker并不能幫助到開(kāi)發(fā)的效率。也就是說(shuō)，以前怎么寫(xiě)代碼，怎么做代碼審查這些跟Docker的關(guān)系并不大。但是有了Docker以后，進(jìn)到代碼倉(cāng)庫(kù)之后，從代碼倉(cāng)庫(kù)打包，就可以自動(dòng)構(gòu)建出新的程序。比如用Java程序構(gòu)建出Jar包，然后構(gòu)建鏡像，這些鏡像就可以從開(kāi)發(fā)環(huán)境自動(dòng)推到鏡像倉(cāng)庫(kù)，再?gòu)溺R像倉(cāng)庫(kù)到測(cè)試環(huán)境，這樣兩個(gè)環(huán)境就可以比較輕松地打通。然而，在鏡像倉(cāng)庫(kù)里也會(huì)有一些鏡像無(wú)法通過(guò)測(cè)試，這就需要返回通知開(kāi)發(fā)人員繼續(xù)進(jìn)行業(yè)務(wù)迭代，做好Docker鏡像，測(cè)試完全通過(guò)了以后，再保存到鏡像倉(cāng)庫(kù)，標(biāo)記這時(shí)最新的完全通過(guò)測(cè)試的業(yè)務(wù)應(yīng)用鏡像。在拿給運(yùn)維人員做生產(chǎn)部署時(shí)會(huì)涉及很多的環(huán)節(jié)，中間的物理網(wǎng)絡(luò)可能是不通的，運(yùn)維人員從測(cè)試環(huán)節(jié)拿Docker鏡像去生產(chǎn)和交付等都是待打通的環(huán)節(jié)。

還有一點(diǎn)，Docker是要打包應(yīng)用所依賴的環(huán)境還有應(yīng)用程序本身，假定Docker應(yīng)用里面裝的是Weblogic，運(yùn)行Java寫(xiě)好War包程序，那么這個(gè)Weblogic也需要容器里面的基礎(chǔ)環(huán)境，假定是個(gè)Ubuntu Linux，以及各種各樣的配置文件，基于xml的配置文件。在Docker做交付的時(shí)候，如何處理War包還有配置文件有很多不同的方法。從開(kāi)發(fā)測(cè)試最方便的方法，是把Docker里面所有的東西都打包進(jìn)去，把這個(gè)程序和配置文件一起放進(jìn)去，通過(guò)這種方法，Docker鏡像就完完全全是自我依賴的，也會(huì)有麻煩的小插曲，比如程序改了一行就要重新做一個(gè)War包，重新打包一個(gè)Docker鏡像；或者說(shuō)配置文件更改一個(gè)地方，整個(gè)鏡像也需要重新的打包。企業(yè)級(jí)IT的應(yīng)用有很多各種各樣的依賴，因此整個(gè)打包的流程不見(jiàn)得能在幾秒鐘內(nèi)做完。在這個(gè)時(shí)候，相對(duì)恒定的部分是Ubuntu和Weblogic，這部分是偏依賴的，因此，可以把它們放在Docker容器里面作為一個(gè)基礎(chǔ)的鏡像。然后每當(dāng)應(yīng)用發(fā)布的時(shí)候，War包的變化最頻繁，但可以將程序和鏡像進(jìn)行分離。這樣每次上線的時(shí)候，基礎(chǔ)鏡像都保持不變，新的應(yīng)用可以重用已有的Docker基礎(chǔ)鏡像，只替換War包。這樣的話，仍然能夠利用Docker帶來(lái)的一些隔離，資源限制等輕量部署的特點(diǎn)。

另外是對(duì)于配置的管理，因?yàn)樯厦嬷v的配置還是放在Docker鏡像里面的。配置文件一般都不大，雖然不像程序改的這么多，但是配置文件也會(huì)發(fā)生改變。那么是不是每次修改配置文件的時(shí)候，整個(gè)Docker鏡像也要重新改呢？也不見(jiàn)得，我們可以多帶帶對(duì)配置文件進(jìn)行管理。配置文件的管理其實(shí)對(duì)于金融行業(yè)來(lái)講是不容易的，因?yàn)榄h(huán)境之間是隔絕的。配置服務(wù)器把不同環(huán)境的配置都生成好，當(dāng)程序運(yùn)行起來(lái)以后，有兩種方式，一種是拉的方式，容器啟動(dòng)時(shí)去配置中心拉取實(shí)時(shí)配置，無(wú)需修改代碼。另外一種是推的模式，配置更新會(huì)實(shí)時(shí)推送到特定容器，需要使用SDK。拉的模式，在程序啟動(dòng)以后，每次更新程序都要發(fā)一次配置靜態(tài)加載，配置修改程序也不會(huì)改，拉的模式相對(duì)容易實(shí)現(xiàn)。

再一個(gè)場(chǎng)景就是從新的效率方面，要提升整個(gè)數(shù)據(jù)中心運(yùn)維的效率，把運(yùn)維的復(fù)雜度降下去。使用容器云以后能把80%的重復(fù)性運(yùn)維工作做到自動(dòng)化。運(yùn)維部署就不太需要人力參與了，只需要運(yùn)維人員去觸發(fā)，設(shè)定應(yīng)用上線的時(shí)間，具體上線的邏輯都是基于容器去快速部署的?；旧现挥猩暇€新的物理服務(wù)器，或者組件虛擬機(jī)資源池的時(shí)候才需要人力，容器云底下的集群自動(dòng)搭建都可以基于容器技術(shù)自動(dòng)實(shí)現(xiàn)。CPU、內(nèi)存都可以實(shí)現(xiàn)自動(dòng)的分配和回收。還有應(yīng)用的橫向擴(kuò)展，應(yīng)用的容錯(cuò)自動(dòng)恢復(fù)等也都可以自動(dòng)實(shí)現(xiàn)。借此，80%的重復(fù)性的運(yùn)維都會(huì)變成自動(dòng)化的，這對(duì)數(shù)據(jù)中心的運(yùn)維效率來(lái)說(shuō)無(wú)疑是一個(gè)很大的提升。

數(shù)人云基于容器搭的數(shù)據(jù)中心操作系統(tǒng)的簡(jiǎn)單構(gòu)架，我們要做的是面向私有云或者混合云的輕量級(jí)PaaS平臺(tái)。這個(gè)PaaS平臺(tái)的理念非常簡(jiǎn)單，就是把各種各樣的應(yīng)用，基于互聯(lián)網(wǎng)的應(yīng)用也好，基于傳統(tǒng)架構(gòu)的應(yīng)用也好，或者是分布式開(kāi)源的一些組件、消息隊(duì)列這些各種各樣的組件，把它們統(tǒng)一抽象為容器化的應(yīng)用。針對(duì)這些標(biāo)準(zhǔn)的容器化的應(yīng)用，PaaS平臺(tái)就可以提供標(biāo)準(zhǔn)的容器運(yùn)行環(huán)境，包括應(yīng)用的部署、持續(xù)集成、彈性擴(kuò)容、服務(wù)發(fā)現(xiàn)、日志、權(quán)限，以及關(guān)于持久化、網(wǎng)絡(luò)這方面對(duì)接。這就是標(biāo)準(zhǔn)的PaaS平臺(tái)，這些都得益于容器技術(shù)將應(yīng)用層進(jìn)行了標(biāo)準(zhǔn)化的處理，在此基礎(chǔ)上，所有的應(yīng)用都是容器化的應(yīng)用，不再區(qū)分是業(yè)務(wù)應(yīng)用還是組件級(jí)應(yīng)用，或是處理大數(shù)據(jù)的應(yīng)用，它們都是容器的應(yīng)用，PaaS平臺(tái)只需把容器應(yīng)用的運(yùn)行時(shí)需求管理好就可以了。

PaaS平臺(tái)向下對(duì)各種計(jì)算資源，包括公有云或私有云，或是物理機(jī)，進(jìn)行統(tǒng)一管理，數(shù)人云目前更多的側(cè)重點(diǎn)在私有云的場(chǎng)景下。通過(guò)輕量級(jí)PaaS平臺(tái)，基于物理機(jī)和虛擬機(jī)就都有了可以統(tǒng)一管理的平臺(tái)，從應(yīng)用的快速發(fā)布、到整個(gè)資源利用率的提高，最后到大規(guī)模的部署，都是一體化的流程，數(shù)人云的PaaS平臺(tái)全部都可以支持。

舉一個(gè)秒殺的例子，這是我們的一個(gè)客戶，活動(dòng)晚上十點(diǎn)左右秒殺，因?yàn)閾?dān)心白天人太多。這的確是客戶的困境，因?yàn)樗麄兊腎T構(gòu)架很難適應(yīng)彈性擴(kuò)張，因此被迫在晚上做秒殺業(yè)務(wù)。之前我們也做過(guò)百萬(wàn)并發(fā)的壓測(cè)，每秒鐘有一百萬(wàn)個(gè)請(qǐng)求過(guò)來(lái)。壓力上來(lái)以后我們就開(kāi)始做彈性擴(kuò)張，對(duì)于這個(gè)來(lái)說(shuō)，Docker容器是非常方便的，另外還有監(jiān)控觸發(fā)自動(dòng)擴(kuò)容。

第二個(gè)例子是同城災(zāi)備，金融行業(yè)出于合規(guī)性的要求，要做兩地三中心，這并不是那么容易實(shí)現(xiàn)的?；谌萜髟凭涂梢詫?shí)現(xiàn)兩地三中心，容器的管理節(jié)點(diǎn)是跨網(wǎng)絡(luò)的，高可用的，它們幾個(gè)互為備份，下面是不同的集群，可能是生產(chǎn)集群、備份集群、開(kāi)發(fā)集群等等各種各樣的集群，這些跨物理節(jié)點(diǎn)的集群都通過(guò)數(shù)人云節(jié)點(diǎn)去管理。當(dāng)某一個(gè)集群宕了，上面的很多應(yīng)用就可以自動(dòng)且快速地遷移過(guò)來(lái)，比如說(shuō)生產(chǎn)宕了馬上備用就切進(jìn)來(lái)了，基于容器這些都可以很容易的實(shí)現(xiàn)。

再一個(gè)簡(jiǎn)單的小例子，剛才提到的，大數(shù)據(jù)的系統(tǒng)如果容器化了以后，就不需要再區(qū)分是大數(shù)據(jù)的應(yīng)用還是其他業(yè)務(wù)應(yīng)用，一律都是容器化的應(yīng)用。所以大數(shù)據(jù)的系統(tǒng)跑在容器里面，封裝后全部都是容器化的，包括Kafka，Zookeeper、Redis。容器化了以后，PaaS平臺(tái)并不區(qū)分這個(gè)應(yīng)用是什么樣的，全是基于容器的，只需把容器管理好，也就是說(shuō)，容器需要CPU就給CPU，需要內(nèi)存就分配內(nèi)存，需要網(wǎng)絡(luò)就分配網(wǎng)絡(luò)，需要隔離PaaS平臺(tái)就幫它做隔離，這樣的話，整個(gè)大數(shù)據(jù)平臺(tái)就能夠很方便地維護(hù)。應(yīng)用系統(tǒng)、數(shù)據(jù)系統(tǒng)都可以統(tǒng)一通過(guò)一個(gè)PaaS平臺(tái)去運(yùn)維。