1. 程式人生 > >喬融:“Docker容器雲在金融行業的運用” – 運維派

喬融:“Docker容器雲在金融行業的運用” – 運維派

由工業和資訊化部指導,中國資訊通訊研究院主辦,業界知名組織雲端計算開源產業聯盟(OSCAR)承辦的2017全球雲端計算開源大會於4月19日-20日在北京國家會議中心順利召開。本文為本屆大會嘉賓分享的大會演講速記內容,敬請瀏覽。

嘉賓介紹:喬融

公司職務:成都精靈雲科技有限公司CTO

大會演講速記

Docker

今天四個方面開始講。

Docker應用

第一個是金融業對容器雲的需求和目前的痛點,第二個是解決方案,第三個是容器PaaS平臺,第四個是案例分享。

容器雲

金融業轉向雲的話有一些需求,首先是政策的需求,金融雲的監管機構要求在十三五規模末期所有的網際網路相關業務必須上雲,傳統業務至少50%上雲,這是一些政策要求,還有外部因素。

首先就是網際網路,比如阿里、京東這些對傳統金融挑戰是很大的,他們的特點是快速擴容、快速上線、快速迭代,目前有一個說法叫去IOE,就相當於把以前的IDM這些慢慢的去掉,逐漸用開源的產品,這就是一波新的私有云建設的浪潮,目前不管是從單體或者面向服務的應用都有一個趨勢,要轉向微服務的應用。

IT行業

傳統金融IT行業的痛點,首先是現在目前很多金融行業他們的應用都還是一個單體應用,剛才我也聽有些嘉賓說了,一個應用可能達3G或者4G的樣子,這樣一個大的應用部署效率是非常慢的,與其說你要對這個應用進行升級,或者部署,以及要維穩效率是非常差的。

還有傳統開發模式,一般單體的傳統開發模式都是有瀑布式模式,特點首先是做設計,設計完以後開發,研發人員開發按照以後交給測試人員測試,這樣有一個問題,研發的時候測試人員沒有什麼事兒幹,交給測試人員以後研發的人員沒有什麼事兒,最後有問題大家一起,變成一團亂的感覺。

傳統開發模式還有風險,很多都是你開發一個功能,等你這個要功能都好了,在一起整合到一個主分支上,週期性有點長,而且會把其他已有的功能破壞掉,傳統的模式可能你測試是再一個環境,真正的生產環境部署又是性外一個環境,不可避免有些環境會有問題,還有你搭建也比較費事。

還有一個問題,是業務的需求動態變化,比如說我們春節搶紅包,平時搶紅包沒有春節大,但是突然一個時候需求訪問量猛增,如果你以前部署到一個傳統的架構上,它以前的物理裝置以及演算法可能不能滿足同時的需求,為了解決這些問題,就提出了這個解決方法,去解決剛才的痛點。

雲平臺

三種方法去解決問題,一個是微服務化,還有一個是DevOps,還有一個容器雲平臺,那我們倒過來看一下怎麼解決問題的,單體部署效率,升級與回滾,我們劃分成微服務,這個後面會詳細講。

傳統的開發模式有一些問題,完全可以通過DevOps解決,DevOps其實就是一個持續整合持續部署的過程,業務需求動態變化如果現在採用微服務以及容器變化工具,我們一般容器變化工具都有一個動態伸縮的功能,也很好解決這個問題。我們來詳細的看一下DevOps到底是什麼東西,怎麼解決這些問題。

DevOps最早的概念就是持續整合,持續釋出,其實是早於微服務的概念,其實現在目前這個流程相當於是結合了容器的流程,就說當一個研發人員把程式碼提交以後,然後再後臺就會自動的執行靜態檢查,比如檢查它的程式碼有沒有什麼語法格式以及他的格式是不是正確,這是最基本的檢查,還有測試,之後會編譯進行打包映象,生成映象以後會放到測試的映象倉庫裡,會觸發一輪新的測試環境的部署。

自動化

部署好以後會自動化的測試,測試好環境以後如果沒有什麼問題,通過率達到我們試點的要求,它會到生產環境的倉庫裡去,在生產環境的倉庫裡會在生產環境上進行部署,剛才我們說了即使測試環境部署以後,生態環境還是有必要測試一下,因為這個生產環境不管是不是容器,其實還是有可能有微笑的差別,負責的說生態環境還是需要進行一些測試的,如果生態環境沒有問題我們可以採用釋出的形式來升級某一個微服務,這樣可以在很快的頻率做一個小程度的升級,達到不停業務的作用。

剛才說了一個傳統的CICD的步驟,其實要實現CICD有一個重要的問題,就是智慧化,很多公司想做CICD,就是持續升級和釋出但是他們在這塊就被卡住了,因為持續整合是要求頻度很快的整合,如果沒有強大的制動化系統做是不可以的,自動化有一個原則,你是儘量把所有的操作都進行自動化,包括靜態檢查還有所有的測試都需要自動化,以及自動化的管理系統,因為我們在實踐中發現你的測試已經很完善了,但是工程師還是不願意去跑,就是你的測試管理系統不夠自動化,有可能是說你這個測試管理系統沒有做到夠智慧化,手動測試就不負責的提交了。交付的時候我們也可以自動化部署也可以自動化,最後是升級維穩也可以實現自動化。

工具很多了,這是我自己比較熟悉的,裡面有很多持續整合的工具,也是開源的,還有Pytohon自帶了很多的庫,開源的自動化也是基於它做的,還有Selenium,Ansible,還有容器編排工具。

持續整合

強調自動化以後你就可以做持續整合,持續整合一般的步驟就是提交以前自己要測一測,提交以後可以做靜態檢查,沒有問題以後可以構建,比如生成一個應用程式這些都是可以的,構建好以後可以部署到測試環境,然後對你的新功能進行測試,測試以後還要回歸測試,最後保證你這個新提交的程式碼不會把已有的功能破壞掉。

說到持續整合,跑這麼多的測試,有一個主要的目的就是不管誰的程式碼提交不要把你已有的主分支破壞掉,持續整合是你的主分支在任何情況都可以釋出,如果有一邊把你的主分支搞壞了,你就不是解決新開發的功能,而是解決已有的問題。

持續部署

一般生產環境還有一些條件,比如你的持續幾次的百分之百自動化通過率,還有系統整合測試,可能需要幾個部門的領導批准才能自動化的部署,我們現在有些客戶就覺得他的功能不是目前很重要的功能,而是可以先嚐試自動化部署,自動化持續整合釋出這幾塊做到以後,傳統的DevOps可以說是實現,可以快速的進行一個產品的迭代釋出,但是這樣其實可以解決一些效率的問題。

微服務

但是沒有完全解決,因為我們說了還有單體自己的問題,那麼單體的問題解決最好的辦法就是微服務化,大家可能聽的比較多了,我概括的起來說一下它的特點,什麼叫微服務化?就是一個服務只做一件事,每個微服務化是一個鬆耦和緊耦的東西,微服務可以部署在任何節點上,任何機器上,是沒有要求的。

當然他們之間通過API進行通訊,一般一個微服務只要定義好API以後就可以被分到一個小的器物上進行開發,開發的過程每個team可以開發多個微服務,但是不能說一個微服務可以流動的開發,如果你的庫檔案和你的微服務沒有什麼關係,你儘量的要把庫檔案去掉,要保持微服務的警惕性。

Docker

我們看,一個微服務有一些特點,一個特點是它可以被部署到不同的機器上,這是一個跨平臺的,以及它包含儘量少的檔案,這是第二個,微服務其實和目前的Docker容器結合是一個很好的結合點,看看什麼是Docker。

Docker是一種容器技術,這個概念已經早就有了,只是最近兩年把它開源出來以後才變得這麼火,容器技術我們可以看這邊傳統的容器虛擬化技術,第一代虛擬化技術其實就是我們以前用的Hypervisor,這種虛擬化技術有它的好處,這種虛擬化技術有點衝,它佔的資源比較多,所以說我們看看  是容器虛擬化技術,它沒有自己的作業系統,你巨集觀的看其實你的容器技術可以看作是一個輕量級的虛擬機器。

由於說它的這些特性,那麼它佔的資源非常少,它其實也是跨平臺的,你可以說你在一個機器上做的映象,也可以跑到一個跨平臺的,剛才我們說你在生產和測試環節中平臺不一樣的問題,還是可以和它的配置檔案一起打包,容易實現高可用。

EcOS

我現在介紹一下我們公司的產品叫EcOS,我們自己開發了一個排程工具,市面上比較知名的開源編排工具有Dockers這些東西,我們考慮有一些使用者定製化比較強,我們整個是一個容器排程引擎的平臺,除了支援我們自己的開發引擎我們還支援K8S,是一個開源的容器引擎。

在我們容器雲平臺上我們實現哪些功能?我們有持續整合,持續釋出,我們自己開發的一個完全自己的持續整合釋出,還有儲存管理,儲存管理我們集成了EBS等這些儲存外掛,可以直接以塊巡視的方式訪問網路儲存,我們還有自己的監控系統,日誌系統以及服務編排,還有一些網路管理,網路管理我們也是基於開源的網路,做了一點點二次開發,我們做了以後我們效能測試中,如果你的裸機的網速155兆每秒,我們的測試結果135兆每秒。

我們這個環境可以跑在虛擬機器上,或者說你跑裸機也可以,都是沒有關係的,這是我們內部平臺的一些鏡面,第一頁是主機上的容器狀態等。今天我們的主題是說Docker容器在金融行業的應用,目前有很多的銀行要求做深度POC,其實我們也有一些客戶是完全落地的客戶。

架構

我給大家分享一下落地的客戶到底是什麼需求,它的需求其實就是比較通用的,需要把它所有的環境全部適應化,把單體服務放到容器裡,有可能有的時候它的訪問需求是變化的。有的時候可能它的訪問量很少,但是有的時候達到百萬級的訪問量,對於它的需求我們地區一些解決方案,我們把環境分為生產環境和測試環境,而且生產環境可以部署在兩個地方的生產環境,部署兩個地方以後用一個智慧的方式實現負載均衡。生產環境就是你下面儲存是Ceph儲存,你可以在同城或者同實驗室對它的ceph進行備份,遠端還需要一個備份,保證雙重備份,即使有一個實驗室完全掛掉對業務也沒有影響。

架構

這是解決方案的邏輯架構圖,最下面的是EcOS容器雲平臺,這一層是MySQL資料庫叢集,通過我們的儲存外掛直接訪問ceph,這裡面一套都是開源的,這一層是他們繼續跑的應用,這一層是以微服務的方式跑起來,跑起來以後就用我們的容器編排工具來對它的容器的使用進行實施的操控,每個容器,當你容器達到一定的使用率的時候,比如我們設了限制,你CPU達到80%,記憶體到80%。某一個資源達到這個消耗以後就會自動的擴容一個微服務的容器數量,這樣就達到剛才說的可以滿足動態的需求變化的一個問題。

我們使用etcdCantid,上面採用了雙重負載均衡的方式,右面是客戶自己使用的其他開源工具,有一些自動化恢復的管理。

這是我們產品的API來支援他們的持續整合持續釋出,這就是那幅圖的具體實現,當有程式碼提交以後,我們的環境監測到提交了這個就會自動的跑一些靜態檢查,去編譯部署,最後生產環境會升級,現在關心這個事情的很多,但是真正落地以後他們目前還沒有把太核心的跑上來,更多跑的是一些做試水的環節。謝謝大家。

文章來自微信公眾號:雲端計算開源產業聯盟