金融行業如何使用容器，考慮到必須穩定高於一切！

標籤：

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

　　困擾金融行業的三個難題

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

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

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

　　金融行業 IT 現狀

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

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

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

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

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

　　第六，各種異構裝置，硬體資源使用率極低。最後一點可謂金融行業的一個曆史包袱，在金融機構中各種各樣的異構裝置非常的多。十年前很多金融機構都大量採用大型主機、小型機，這些裝置一直沿用至今。另外，這些裝置的資源使用率並不是很高。因為，傳統業務並不具有突發性的特點，非常有規律，比如白天是高峰，到了晚上就是低穀，利用晚上的時間還可以跑各種批量的業務。此外，金融行業很多的業務都是跟硬體綁定的，很多業務應用都是靜態部署的，每個業務都是由特定的硬體去支撐的。在Google不是這樣，Google不會把特定的應用裝在某台伺服器上，業務應用和伺服器的強綁定對於Google這種量級的資料中心的維護難度太高了。Google有兩百多萬台伺服器，如果業務應用都要和伺服器進行強綁定，那營運人員在上線的時候，就要記住每台伺服器上跑了什麼應用，這顯然是不可能的。但是金融機構的資料中心規模不像Google這麼大，所以能做到業務應用和硬體的強綁定。但是強綁定就意味著資源使用率不高，因為業務不可能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，不僅僅是技術層面的改變，也是組織架構方面的改變。這其中會包括開發和營運的協作方式，多部門間的融合，職能劃分的變更等等。在Google，開發大概能達到兩萬名左右，而營運人員也就一兩千名，數量非常少。但是Google的營運人員管理伺服器的數量卻是很大的，幾百萬台伺服器全部由營運來管。Google的營運部門和金融行業營運人員做的事情是不一樣的。Google的營運人員做的更多是資源的規劃，以及開發流程的規約等。Google的營運把很多傳統行業營運做的事情下放給開發，比如說業務的上線，Google的營運人員是不管開發的。

　　監控、管理、操控

　　敏捷開發絕對不是形式上的東西，它會有很深的組織架構和職能上的轉變。這張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平台去營運。

金融行業如何使用容器，考慮到必須穩定高於一切！