以 Docker 爲代表的容器技術正在以一種不可阻擋的趨勢席捲全球，但真正的落地過程依然十分坎坷。6月20日北京，在2019企業容器創新大會上，業內首家覆蓋業務全流程、運營全體系的移動信貸整體技術服務商飛貸金融科技的副總裁陳定瑋分享了飛貸的數據庫生產容器化及 Istio 應用的經驗。基於飛貸金融科技容器化道路的實踐與經驗，InfoQ 記者也專訪了陳定瑋，並將其分享和思考整理如下。
傳統的 IT 流程、基礎架構和運維模式已經無法滿足金融行業的業務發展需求，傳統銀行早已意識到轉型的迫切性，但如何落地，其實對銀行的智慧挑戰很大。同時，客戶對於金融服務的期望和要求日益增加，對於銀行在全渠道體驗、定製化內容、智能數據、實時、便捷及移動等方面的服務，不斷提出更高要求。
傳統金融行業的痛點
如何快速響應用戶需求
金融行業信息化建設的關鍵是及時響應業務需求，適應不同商業環境的 IT 架構，滿足不同部門、客戶和合作伙伴的各種需求。然而，傳統的研發模型已經成爲應用交付和迭代速度的瓶頸。
煙囪式架構如何向分佈式架構無痛轉型
在 IT 基礎架構層面，很多金融企業都是「煙囪式」架構，「煙囪式」架構帶來的最大問題是數據孤島， 不同的應用系統之間的數據無法實現共享。並且，在金融走向普惠、擁抱長尾市場的過程中，傳統金融 IT 架構無法支撐巨量涌入的長尾客戶。
高複雜環境下如何確保系統的高可用性
金融 IT 運維人員的壓力之大衆所周知，這源於金融行業對業務連續性和可用性的嚴苛要求。隨着金融信息化的不斷髮展，金融 IT 環境正在變得越來越複雜：應用紛繁複雜、IT 架構異構、系統規模日益增大……這些都導致運維的難度越來越大，運維部門需要全新的思路來應對複雜環境下IT系統運維的壓力。
以 Docker 爲代表的容器技術正在以一種不可阻擋的趨勢席捲全球，其最大的過人之處在於它統一了雲的交付件，從而給企業 IT 轉型帶來變革性的思路，賦予企業 IT 快速響應和持續創新的能力。
容器技術的不斷髮展和成熟爲傳統金融企業的容器化建設提供了新思路，但真正的落地過程依然十分坎坷。正如飛貸金融科技副總裁陳定瑋在接受 InfoQ 記者採訪時提到的，“其實，現在任何行業對容器的看法基本一致，都是非常認可的。從金融行業的角度，認可歸認可，但大部分的實踐還是基於邊緣系統，而真正的核心繫統想要落實容器化建設，中間要經歷一段時間的陣痛。這就導致雖然大家都看好容器的發展趨勢，但由於金融行業本身的特殊性，還是有很多企業不敢貿然行動。”
不敢貿然進行容器化建設的原因有幾點：
一是人的因素。銀行的科技人員是否足夠了解並掌握容器技術，如果運維人員不具備這樣的技術能力，是沒辦法在進行容器化建設的。
二是金融行業的特殊性。銀行對於新技術的引入非常審慎，由於追求安全第一的行業特殊性，金融行業與互聯網行業相比，即使對新技術的“熱情”很高漲也無法很快推行到核心系統。現在一些比較大的銀行，渴望嘗試新的技術和應用，但目前仍處在經驗積累階段，還是只能在邊緣系統嘗試。只有當容器及相關技術在邊緣系統運用得非常成熟和完善以後，纔有可能慢慢地去取代核心系統，進而將新技術推廣到核心部分。而且由於傳統銀行系統體量大，複雜度高，“包袱”重，探索出真正適合金融行業的技術方案和路線，需要經過一個很長的時間技術迭代。
陳定瑋提到，“金融企業做容器化建設是一種必然趨勢，但是整個進程的速度關鍵在於技術決策者，也就是CTO或者科技主管。他們對於新技術的運用以及怎麼運用這件事情如果想得比較清楚，那麼新技術的推動速度就會大大加快。”
飛貸的容器化之路
飛貸的容器化建設，起點很特別——公司內部所有的系統都是自研開發。容器化建設其實是對基礎架構層的重新打造，自研系統的優勢就在於對原系統和架構的改動不用經過第三方。陳定瑋提到，“如果飛貸是採用第三方系統，那麼每次新技術引進都需要跟合作方去談，但問題是傳統的軟件系統對於基礎架構這一層的事情並不太關注，這會在一定程度上阻礙基礎架構層的技術改進。另外，飛貸的技術基因與其他公司有些不同，我們非常看重基礎架構層的建設，因爲這是整個飛貸金融科技賴以生存的一部分。從業務層面來看，飛貸本身有 C 端業務，並且是在解決 C 端用戶遇到的問題和痛點的過程中，形成了最佳的解決方案，然後賦能給金融客戶，這是飛貸與其他軟件企業的不同，我們的商業模式裏是有實體運作的經驗，經過了生產歷練且成效不錯。”
容器化建設有兩點顯著的好處：一是彈性伸縮，二是容器化建設後，架構變小，這樣系統恢復部署/運維速度會加快。
飛貸對於整個容器技術的理解和做法是：通過容器化去改變 RD 整個開發模式。有些企業在做容器化時，往往只是把虛擬化的技術替換成容器而已，但是實質上裏面的東西沒有變，這樣容器技術根本起不到效用。比如，如果僅僅是將虛擬機換爲容器，雖然系統容器啓動時間會大幅縮短，由幾分鐘變爲幾十秒，但是系統的容器化構建編排需要幾個小時，這樣整個系統的交付體系效率並沒有提升，甚至是變得更慢。整體效率考量纔是企業做容器化想要達成的目的和結果。
飛貸的容器化建設不只是把 CloudStack 換成容器，而是把整個應用程序及研發流程，根據容器的規範和要求也做了大量的調整與重構，所以整個分佈式系統的應用與部署才能變得更加高效。
陳定瑋提到，“我們的容器化建設其實相當於重新開發了一套系統，之所以付出這麼多努力去做這件事，除了看重容器化對於系統整體效率的提升以外，還在於通過容器技術可以解決很多實際問題，比如最重要的一點是節省了成本，這裏麪包括人力成本、效率以及硬件投入成本等，這往往是技術管理者最關注的地方。對於新技術是否採用的出發點，都是以成本去考量。飛貸整個容器化建設完成之後，物理資源成本相比私有云節省40%，人力成本可以再節約60%，研發投入可以再節省40%，還有容器本身快速應用部署帶來的效率的提升，比如可以在短時間內快速搭建出上百套現有環境，更快地服務 B 端用戶。容器化對於飛貸而言意義重大。”
飛貸容器化建設的痛點
飛貸的客戶主要由 B 端和 C 端構成，而促使飛貸進行容器化建設的動力來自於 B 端客戶的需求。
飛貸採用混合雲結構，私有云用 CloudStack 搭建，現有虛擬機規模在3000~4000臺，如果沒有做容器雲平臺，那麼幫助 B 端客戶搭建一套框架體系大概要花費1~2 周的時間。當容器雲平臺搭建成以後，一天時間就可以部署上百套系統。同樣的環境下，效益提升了10倍以上，物理資源也節省了40%——也就是說，用原來的做法需要100臺服務器，但是用容器之後只需要60臺。
陳定瑋提到，“B 端客戶要在飛貸的平臺上運行業務，就相當於將飛貸整個技術平臺租給企業客戶，由飛貸負責運維。這裏面有兩種模式：一種是我們提供金融雲的服務，根據客戶需求去定製化流程和服務；另一種是將飛貸的系統部署在 B 端。但這會存在一個問題，由於是分佈式部署上百或上千臺服務器，我們幫客戶部署完，除了網路調通以外，他們後續的運維會非常複雜，不僅浪費資源，而且效率很低，但痛點就在於 B 端客戶對資源的管控非常嚴格，導致後續在運維上比較棘手。”
做容器化以後，可以實現統一管理、統一調度，並且容器本身具有非常高的彈性伸縮的能力，因而在資源投入上會減少很多，這就滿足了 B 端客戶管控資源的需求。而且在容器化以後，不僅部署速度極大提升，也可以在一個管控界面上去追蹤所有的應用與服務，從而節省人力的投入，這是B 端客戶的技術人員也比較認可的方式。
飛貸容器雲平臺建設思路
對於飛貸的容器雲平臺的建設思路，陳定瑋坦言，其實任何新技術的引入都要從三點來考慮：
是否勇於嘗試新技術；
新技術能否結合實際來運用；
評估技術成熟度和技術團隊掌握能力，這裏麪包括兩點，一是評估新技術是否足夠成熟；二是判斷技術團隊是否有能力掌握。
早在2015年，陳定瑋和他的技術團隊開始研究容器技術，並做了相應的調研評估。2016年開始試點，把容器1.0版本上到研發和測試環境。2017年，開始調研和使用 K8S ，“其實在2016年的時候，我們也嘗試了很多方案，但是當時容器技術在大規模應用編排管理上不夠成熟，所以那個時候我們不太敢上生產，而且那時候容器運維、安全防護方面也不是很完善，這兩個原因導致容器技術遲遲沒有開始上生產”。
到了2017年， K8S 迅速成爲容器集羣管理的主流平臺。陳定瑋和團隊於是開始去調研和使用K8S。“我們一定要對新技術有一定的掌握度，到了2018年，基於K8S和容器2.0版本，我們做了MySQL容器化測試。2018-2019年，我們一直在做的就是改造所有的系統，要打造容器化平臺生態圈，以容器爲主導，慢慢替換 CloudStack 的環境。”
不要爲了容器化而做容器化
很多公司聲稱要做容器化，其實只是“換湯不換藥”，不是說把平臺換成容器就能解決所有問題。陳定瑋說，“我們不是爲了容器化而容器化，整個飛貸的代碼質量和產品都要符合容器的要求和規範。因此我們做了大量重寫，才能達到容器標準，不然秒級容災、秒級恢復怎麼實現呢？如果DB 啓動時間要5分鐘，不管用容器還是傳統的虛擬機部署，整套系統的啓動時間還是5分鐘，這個安全級別達不到金融行業的標準。容器最大的好處是能夠實現秒級啓動和秒級恢復，但是容器只是對應用做封裝，而不是提供一個環境（這跟虛擬機不同），所以應用也要隨之修改，才能達到容器的標準，實現快速啓動。其實我們背後做了非常多的改造。”
金融企業非常重視代碼質量，飛貸因此開發了一個代碼質量的管理體系，建立代碼質量審查體系，只要 RD 代碼的撰寫與風格不符合規範，代碼是沒有辦法提交的，這也是DevOps流程的一部分。同時飛貸也研發了基於容器的代碼流程自動化系統，也就是RD從開發代碼到打包、發佈、到生產和測試環境，全流程由系統自動化生成。同時將自研中間件與微服務整合在一起，實現類似於“ Service Mesh ”的“ DB Mesh ”。據瞭解，業界在 DB 容器化實踐上還沒有比較成功的核心生產系統案例，飛貸是目前爲止第一個擁有成熟解決方案的公司。
容器化建設的坑與經驗
在談及飛貸做容器化建設過程中踩過的坑時，陳定瑋還是感慨萬千，“容器技術在早期沒有完善的運維部署和管理體系，導致從金融領域的行業標準的角度來看，我們是不達標的。雖然我們一直在前進，但底層技術不支持，無論我們在上層應用做什麼都無濟於事。這是我覺得飛貸在容器化這條路上遇到的一個坑點。其實根源還是金融行業的特殊性，對於數據安全、信息安全的要求非常高，所以每一步都必須達到高標準。在2018年以前，我們都只是在RD環境和測試環境使用。因此我需要花費大量的精力平衡人力成本，去處理效率低下和代碼質量等等問題。後來隨着技術和時機的成熟，我們的容器化才真正開始上生產，實現了系統部署和快速交付，我可以騰出時間去抓代碼質量、代碼規範、減少Bug率，整個容器化建設和容器化生態也有條不紊地快速落地。”
MySQL容器化DB Mesh的創造性實踐
從應用層來看，容器化發展得很好，但是數據庫仍然存在很多問題。如果數據庫中斷，重新恢復數據庫和業務生產需要花很長時間。如果數據庫非常大，那麼啓動時間會非常久。這就是爲什麼銀行或大型金融機構不敢用開源數據庫 MySQL或 MongoDB 等的原因，因爲他們要保證安全和持續運作。
飛貸要做數據庫容器化的原因，一是爲了要實現標準化快速部署。如果應用快速部署完，而數據庫部署慢，那麼系統的整體效率還是慢。二是飛貸現有系統已經全部實現微服務化，在這種場景下數據庫實例如果不能做微服務，它就會成爲業務彈性伸縮以及管理的短板。三是爲了更長遠的目標，就是真正實現網格化（DB Mesh）。
MySQL 容器化 DB Mesh 架構如下圖所示。可以看到，多個不同的應用服務對應多個不同的中間件，每個中間件對應一個單獨的數據庫節點，形成一種類似於 Service Mesh 的 DB Mesh 架構，可以靈活調度遷移數據庫節點。爲了數據庫容器化穩定，對業務數據實現分庫分表存儲，並限制單個分庫節點的容量。在數據庫遭遇故障時，可以多節點並行迅速恢復。可以說，飛貸在整體業務運作上擁有強大的數據分庫分表、讀寫分離的技術能力，這些能力是由飛貸自研中間件完成的，中間件是實現 MySQL DB Mesh 的關鍵所在。
飛貸不是第一個做數據庫容器化的公司，之前一些公司也嘗試過，但都失敗了。飛貸做數據庫容器化可借鑑的一些思路是：
限制 DB 的容量
只有單個 DB 容量進行限制，有了標準，才能夠快速部署交付。但是對於銀行和一些傳統金融機構，一般採用 Oracle 數據庫，數據全部堆在那兒，就很難做數據庫的容器化，因爲“牽一髮而動全身”，如果改變數據庫，那勢必上層就要做很多的調整，這是數據庫容器化的難點之一。
結合中間件演化 DB Mesh
飛貸在數據庫容器化實踐中，通過自研中間件，一箇中間件對應一個DB，下面對應不同的服務。在數據處理上，中間件可以讓數據存儲變得簡單可控，這是數據庫容器化的核心，形成一個類似 Service Mesh的 DB Mesh 架構，DB 與 Service 解耦，使得DB的彈性調度非常靈活。
改變傳統的思維模式
飛貸做數據庫容器化，整套體系用於服務生產環境上的一切應用。但其實這套體系不利於分析和報表，因爲做了很多分庫，那麼在做數據分析和報表的時候效率會非常低。陳定瑋和團隊想到了解決方案——用大數據做分析，把所有的報表、分析等等這些文獻，全部實時同步到大數據去，讓大數據來處理。 這樣既保證了 B 端客戶的處理數據的秒級體驗，又能快速高效地做數據分析。
MySQL 容器化，透過Istio生成可視化圖形界面，可以去做自動追蹤，判斷庫的健康狀況。但也存在一個問題，當數據庫中斷，再把它恢復的時候，Istio追蹤服務就不見了，需要手工注入。陳定瑋提到，“這個問題我們進行了研究，沒有找到很好的解決方案，可能還是要手工去處理一下，沒有辦法做到自動恢復。 但是在應用與服務管理這部分，飛貸已經做到了完全自動化的Istio注入，實現了微服務訪問、安全加固、控制、觀察、服務追蹤、限速、熔斷、調度、負載等。”
飛貸容器化平臺成果
飛貸做容器化平臺以後，生產力得到了提升：80%的基礎運維實現自動化；交付能力大幅提升，1小時可以交付100套；實現極致的彈性容器化調度、灰度升級、預發佈、藍綠部署、持續交付。在安全/敏捷/高效率上，實現業務數據全量備份分鐘級；在災難故障方面，業務應用一鍵恢復分鐘級；數據快照秒級；資源利用率提升10倍，數據庫交付能力提升百倍。
對於飛貸容器化平臺，Rancher Labs大中華區總經理秦小康這樣評價：在容器時代，飛貸金融科技仍然保持了領先的創新，並通過業界領先的數據庫容器化技術，提升數據庫服務交付效率，大規模的容器化分佈式數據庫集羣部署開業界先河，值得大家參考學習。
開源初心
談及飛貸容器化建設的未來規劃，陳定瑋提到由 DevOps 向 AIOps 發展。“比如現在做了一個飛貸自動化運維App，實現監控及消息告警，對接運維機器人，這其實就是大家一直在談的 AI 概念，只是我們把 AI 的概念變到運維體系裏面，結合容器化提高效率，實現更穩定的系統服務。這樣，以後在這個App上面可以看到生產資源上所有的體系或者設備的狀況；另外，我們會做很多自動化的策略，包含機器學習，就能快速知道問題發生後的處理辦法，減少RD或者運維人員的壓力，提升整個平臺的自動化和智能化的能力，由 DevOps 發展到 AIOps ，就是往智能化運維去發展。”
未來，飛貸金融科技希望把整個應用放到開源社區裏，因爲目前很少有這種整套的解決方案作爲開源的技術去開放出來。這是飛貸未來努力的一個目標，陳定瑋說，“我希望在明年能夠實現。”
嘉賓介紹：
陳定瑋，飛貸金融科技副總裁，主要負責公司 IT 方面工作。帶領公司 IT 技術團隊打造的“神算”科技體系，通過全體系分佈式架構，自建中間件平臺，接口化對接無限個應用服務，支持負載均衡和線性擴展，滿足業務高併發和信息秒級交互需求，可應對破億次的日交互量，日數據處理能力達PB級，保障整個系統應用的高效運營。