穩定高於一切的金融行業如何用容器？

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

困擾金融行業的三個難題

首先咱們一塊兒看三個問題，這三個問題不只困擾着金融行業，不少傳統行業的企業也一樣面臨着這些挑戰。

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

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

金融行業 IT 現狀

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

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

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

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

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

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

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

金融行業 IT 發展新需求

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

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

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

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

金融行業 IT 的指望

這三點既是金融行業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平臺去運維。