摘要：在谷歌不是這樣，谷歌不會把特定的應用裝在某臺服務器上，業務應用和服務器的強綁定對于谷歌這種量級的數據中心的維護難度太高了。但是金融機構的數據中心規模不像谷歌這么大，所以能做到業務應用和硬件的強綁定。

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

首先我們一起看三個問題，這三個問題不僅困擾著金融行業，很多傳統行業的企業也同樣面臨著這些挑戰。

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

這三個問題共同反應出的一個現象是，傳統行業的企業業務形態已經發生了變化。眾所周知，金融行業具有大量面向個人用戶提供的服務，2C的場景和互聯網的結合是一個不可逆轉的趨勢，而正是2C服務的互聯網化、在線化，導致了金融行業業務形態的變化。在今天，金融行業的很多業務本身具有了互聯網業務、互聯網場景的特征，這就要求金融行業結合互聯網場景去解決新的業務問題。同時，安全可控信息技術的需求，也給金融機構的IT架構帶來新的挑戰。

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

第二，互聯網場景業務面臨高并發壓力。這也是金融機構在傳統的業務中不曾面對的挑戰。傳統業務的特點是具有穩定的峰值，白天的工作時間有一定的峰值，會達到一定的高峰，而到了晚上又回落下來，第二天的高峰和前一天的高峰非常接近，而互聯網場景業務則是突發的、不可預測的。

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

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

第五，大版本升級不可回滾。這和上一條各環境互相隔離是有關聯的。因為環境很復雜，金融機構很難回滾，因為每次上線都會對已有環境做修改，回滾就需要撤銷此前的修改，所以回滾在金融行業是也很難實現的。

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

以上是金融行業IT現狀的一些介紹，不能說很全面，這是數人云接觸到的金融客戶的表現，尤其是它們和互聯網公司差異性非常大的地方。

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

首先是新的容量，容量指的是業務的容量。金融行業的業務規模發生了很大的變化，紅包、秒殺這樣的業務需要瞬間橫向擴容的能力，金融行業需要秒級橫向擴容能力扛住搶紅包等突發性流量。同時金融行業還需要屏蔽底層的異構，實現混合云無縫部署。

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

再一個就是新的效率，金融行業需要將傳統物理機的資源利用率提高2-3倍，底層實現小規模錯誤自動容錯，同時還要有效管理不同基礎設施上的多個集群，使他們不受業務規模擴張影響。

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

統一的流程可以使整個應用的生命周期變得平滑，而這也是Docker技術帶來的巨大便利。Docker屏蔽了環境的異構，使開發寫好的程序到測試也同樣能夠跑起來，測試跑通的程序再到生產環境也同樣適用，這樣一體化、平滑的流程就貫穿了應用的整個生命周期。

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

容器技術可以為金融行業打造平滑、一體化的IT系統，同時，它也會給已有IT架構帶來很多的變化。我們一起看容器是如何與金融機構已有架構來對應的。

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

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

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

系統的集中監控有很多層面，包括機房設備的監控、拓撲的監控等等。自動化的操作平臺，包括任務的上線，權限的管理等等，下面有機房、網絡等系統不同的操作，這兩個模塊對于很多金融行業數據中心部門的同事不會覺得陌生，他們每天的日常工作就在這兩部分里面。監控和自動化操作稱之為操控，上面就是管理的部分。管理部分更多的是流程化的東西，比如數據中心運行管理調度出了問題如何去處理，變更如何去處理，發布如何去處理，配置如何去管理等等。管理是整個數據中心外延的部分。

那么，容器云要如何與已有的數據中心運維的工作結合呢？數人云更多是從自動化的操作切入的。因為在管理層面，金融企業介于合規的紅線，管理流程不是在短期內能夠改變的。數人云考慮的是落地，也就是說如何用容器這項新技術快速幫助到金融客戶。因此，我們更多的是從操控的點落進去，因為從這個層面切入不會影響金融客戶已有的管理流程。基于容器云的很多操作就會變得非常方便，像應用的快速部署、快速上線、任務的管理，以及權限資源方面配額的管理都會變的很方便，這些都屬于自動化操控部分。但是只做到應用的快速上線、彈性部署這些還不夠，因為生產環節還需要大量的監控，因此我們會把容器云與客戶已有的監控平臺進行對接，使監控、日志、報警等都沿用客戶已有的流程去處理。數人云從這個點切入，幫助數據中心的運維操控變得更加的自動化，降低運維的復雜度。

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

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

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

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

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

開發的流程是不變的，Docker并不能幫助到開發的效率。也就是說，以前怎么寫代碼，怎么做代碼審查這些跟Docker的關系并不大。但是有了Docker以后，進到代碼倉庫之后，從代碼倉庫打包，就可以自動構建出新的程序。比如用Java程序構建出Jar包，然后構建鏡像，這些鏡像就可以從開發環境自動推到鏡像倉庫，再從鏡像倉庫到測試環境，這樣兩個環境就可以比較輕松地打通。然而，在鏡像倉庫里也會有一些鏡像無法通過測試，這就需要返回通知開發人員繼續進行業務迭代，做好Docker鏡像，測試完全通過了以后，再保存到鏡像倉庫，標記這時最新的完全通過測試的業務應用鏡像。在拿給運維人員做生產部署時會涉及很多的環節，中間的物理網絡可能是不通的，運維人員從測試環節拿Docker鏡像去生產和交付等都是待打通的環節。

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

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

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

數人云基于容器搭的數據中心操作系統的簡單構架，我們要做的是面向私有云或者混合云的輕量級PaaS平臺。這個PaaS平臺的理念非常簡單，就是把各種各樣的應用，基于互聯網的應用也好，基于傳統架構的應用也好，或者是分布式開源的一些組件、消息隊列這些各種各樣的組件，把它們統一抽象為容器化的應用。針對這些標準的容器化的應用，PaaS平臺就可以提供標準的容器運行環境，包括應用的部署、持續集成、彈性擴容、服務發現、日志、權限，以及關于持久化、網絡這方面對接。這就是標準的PaaS平臺，這些都得益于容器技術將應用層進行了標準化的處理，在此基礎上，所有的應用都是容器化的應用，不再區分是業務應用還是組件級應用，或是處理大數據的應用，它們都是容器的應用，PaaS平臺只需把容器應用的運行時需求管理好就可以了。

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

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

第二個例子是同城災備，金融行業出于合規性的要求，要做兩地三中心，這并不是那么容易實現的。基于容器云就可以實現兩地三中心，容器的管理節點是跨網絡的，高可用的，它們幾個互為備份，下面是不同的集群，可能是生產集群、備份集群、開發集群等等各種各樣的集群，這些跨物理節點的集群都通過數人云節點去管理。當某一個集群宕了，上面的很多應用就可以自動且快速地遷移過來，比如說生產宕了馬上備用就切進來了，基于容器這些都可以很容易的實現。

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