摘要：在谷歌不是這樣，谷歌不會把特定的應(yīng)用裝在某臺服務(wù)器上，業(yè)務(wù)應(yīng)用和服務(wù)器的強(qiáng)綁定對于谷歌這種量級的數(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年實踐中，實現(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è)界提供參考實施標(biāo)準(zhǔn)，真正構(gòu)建動態(tài)靈活的金融IT。以下是數(shù)人云 創(chuàng)始人兼CEO王璞在2016@Container容器技術(shù)大會·上海站發(fā)表主題演講的實錄分享：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

那么，容器云要如何與已有的數(shù)據(jù)中心運(yùn)維的工作結(jié)合呢？數(shù)人云更多是從自動化的操作切入的。因為在管理層面，金融企業(yè)介于合規(guī)的紅線，管理流程不是在短期內(nèi)能夠改變的。數(shù)人云考慮的是落地，也就是說如何用容器這項新技術(shù)快速幫助到金融客戶。因此，我們更多的是從操控的點(diǎn)落進(jìn)去，因為從這個層面切入不會影響金融客戶已有的管理流程?；谌萜髟频暮芏嗖僮骶蜁兊梅浅７奖?，像應(yīng)用的快速部署、快速上線、任務(wù)的管理，以及權(quán)限資源方面配額的管理都會變的很方便，這些都屬于自動化操控部分。但是只做到應(yīng)用的快速上線、彈性部署這些還不夠，因為生產(chǎn)環(huán)節(jié)還需要大量的監(jiān)控，因此我們會把容器云與客戶已有的監(jiān)控平臺進(jìn)行對接，使監(jiān)控、日志、報警等都沿用客戶已有的流程去處理。數(shù)人云從這個點(diǎn)切入，幫助數(shù)據(jù)中心的運(yùn)維操控變得更加的自動化，降低運(yùn)維的復(fù)雜度。

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

下來簡單介紹一下容器云在金融行業(yè)落地的部分場景。

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

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

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

開發(fā)的流程是不變的，Docker并不能幫助到開發(fā)的效率。也就是說，以前怎么寫代碼，怎么做代碼審查這些跟Docker的關(guān)系并不大。但是有了Docker以后，進(jìn)到代碼倉庫之后，從代碼倉庫打包，就可以自動構(gòu)建出新的程序。比如用Java程序構(gòu)建出Jar包，然后構(gòu)建鏡像，這些鏡像就可以從開發(fā)環(huán)境自動推到鏡像倉庫，再從鏡像倉庫到測試環(huán)境，這樣兩個環(huán)境就可以比較輕松地打通。然而，在鏡像倉庫里也會有一些鏡像無法通過測試，這就需要返回通知開發(fā)人員繼續(xù)進(jìn)行業(yè)務(wù)迭代，做好Docker鏡像，測試完全通過了以后，再保存到鏡像倉庫，標(biāo)記這時最新的完全通過測試的業(yè)務(wù)應(yīng)用鏡像。在拿給運(yùn)維人員做生產(chǎn)部署時會涉及很多的環(huán)節(jié)，中間的物理網(wǎng)絡(luò)可能是不通的，運(yùn)維人員從測試環(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寫好War包程序，那么這個Weblogic也需要容器里面的基礎(chǔ)環(huán)境，假定是個Ubuntu Linux，以及各種各樣的配置文件，基于xml的配置文件。在Docker做交付的時候，如何處理War包還有配置文件有很多不同的方法。從開發(fā)測試最方便的方法，是把Docker里面所有的東西都打包進(jìn)去，把這個程序和配置文件一起放進(jìn)去，通過這種方法，Docker鏡像就完完全全是自我依賴的，也會有麻煩的小插曲，比如程序改了一行就要重新做一個War包，重新打包一個Docker鏡像；或者說配置文件更改一個地方，整個鏡像也需要重新的打包。企業(yè)級IT的應(yīng)用有很多各種各樣的依賴，因此整個打包的流程不見得能在幾秒鐘內(nèi)做完。在這個時候，相對恒定的部分是Ubuntu和Weblogic，這部分是偏依賴的，因此，可以把它們放在Docker容器里面作為一個基礎(chǔ)的鏡像。然后每當(dāng)應(yīng)用發(fā)布的時候，War包的變化最頻繁，但可以將程序和鏡像進(jìn)行分離。這樣每次上線的時候，基礎(chǔ)鏡像都保持不變，新的應(yīng)用可以重用已有的Docker基礎(chǔ)鏡像，只替換War包。這樣的話，仍然能夠利用Docker帶來的一些隔離，資源限制等輕量部署的特點(diǎn)。

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

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

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

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

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

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

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