演講實錄 :某大型股份制商業銀行的容器化探索之路

在剛剛結束的KubeCon2019上，靈雀雲售前工程師邢佳發表了「某大型股份制銀行的容器化探索之路」的主題演講，結合某大型股份制商業銀行落地容器PaaS的客戶案例，分享了目前容器雲在金融行業的落地實踐。如下爲演講實錄。

銀行數字化轉型兩大驅動因素

銀行數字化轉型主要有兩方面驅動因素，一是自己業務模型的驅動，二是技術轉型的驅動。什麼是業務模型的驅動呢？你們如今都不多去銀行櫃檯網點，不少生活和工做中的需求均可以經過線上應用去知足，好比微信、支付寶，或者經過一些快捷的方式完成臨時授信，這些金融服務已經深刻到咱們生活中的方方面面。

技術轉型的動力來自基於櫃檯的金融業務在隨着客羣的變化而發生業態的改變，這些金融服務的使用場景和行爲在發生變化。此外，各大銀行也有意願將自身的一些金融服務打包成科技產品或者技術服務的手段，深刻到生活的場景之中，這帶來了創新業務的激烈競爭。

銀行業務模式轉變帶來了對IT系統更高的要求，技術轉型勢在必行。好比，小額信貸之前是銀行很不看好的業務，由於產生的收入都不夠cover內部審批管理流程耗費的成本，如今基於敏捷交付、持續集成以及DevOps的能力，銀行能夠快速完成應用的上線、更新和迭代，小額信貸這樣的業務銀行就有能力去開展了。

對於銀行來講，開發模式經歷了從瀑布式轉向敏捷開發，一些走得快的銀行已經走向DevOps和雲原生；從應用架構來講，銀行從之前的單體架構向大中臺戰略轉型。大中臺建設把後端穩態的服務進行模塊化、組件化、能力化，前端保持必定的靈活性和敏捷性，將原子化的後臺業務接口靈活組裝，快速適應不一樣的場景和業務需求變化。

這也要求銀行基礎設施向更敏捷、更彈性轉變。銀行之前都是小型機、物理機，在前一個階段完成了虛擬化、IaaS改造，幫助銀行解脫了一些歷史包袱，解決了應用運行環境和硬件之間的緊耦合關係，容器化應用則進一步解放了應用和運行環境耦合的關係。

大型股份制商業銀行容器PaaS雲平臺概覽

如下是靈雀雲在某大型股份制商業銀行落地的容器PaaS雲平臺的總體框架。最底層把物理環境、虛擬化環境、託管專有云環境打包成資源池，上面去跑編排集羣，也就是Kubernetes。銀行運行環境分爲開發、測試、準生產和生產四大環境。它須要符合必定的安全管理規範，按照不一樣的安全等級劃分不一樣的業務區域，每一個業務區域都有單獨的Kubernetes集羣。對於銀行來講，如何集中管理各個安全區域的Kubernetes集羣，就變成了一個當下亟需解決的問題。

咱們在某大型商業銀行提供的平臺能夠跨區域管理多個Kubernetes集羣，基於這個平臺，構築了三方面能力：

首先，是容器化的投產能力，包括應用發佈、日誌採集、應用監控等，在此之上擴展DevOps和微服務場景，DevOps主要解決容器化技術如何與開發流程對接。在該大型商業銀行項目上，容器化技術應用主要分兩步：第一步，驗證容器化技術可否在生產環境中承載銀行金融類業務；第二步，開發流程和DevOps工具鏈的對接。應用基於容器底層技術進行開發、測試、投產，達到基於容器和雲原生開發的效果。

其次是微服務應用和業務架構的設計能力，容器化應用採用微服務框架，這些微服務面向彈性或者模塊化的應用設計，平臺須要提供微服務的集中治理功能等。

基於上述雲原生「黃金三角」之上，靈雀雲還提供企業級的IT治理能力。從一個平臺上不一樣的Kubernetes集羣統一去管理這些權限和角色。對於銀行來講，一個應用多是一個項目，這個應用可能會跨開發、測試、準生產、生產等不一樣的環境，那麼平臺就須要有一種能力——集中規劃應用在開發、測試、準生產和生產環境中須要的資源，對整個容器雲平臺進行資源的多租戶劃分。

靈雀雲平臺在這家大型商業銀行客戶的不一樣環境裏部署了多套，能夠同時管理多個Kubernetes集羣。例如開發側的平臺，管理開發、測試、準生產集羣，生產側的平臺管理不一樣安管區域的多個集羣。可是金融行業對於開發、測試、準生產以及生產，包括災備環境，要求是嚴格分離、單獨建設的。一些交易性質的業務，須要有兩地三中心的多活能力，對要承載這些業務的管理平臺來講，管理平臺本身也要具有相應的能力，銀行客戶纔有可能將業務投產到容器平臺上去。

Kube-OVN：適合金融行業特性的網絡方案

銀行客戶自身有很強的科技能力，對於容器廠商的要求不是技術佈道，而是要來解決具體問題的。可是銀行真正關心的問題可能不是技術問題，而是這些技術如何應用起來，符合銀行的安全管理規範。只有能回答出這裏的全部問題，咱們認爲纔可以真正瞭解銀行客戶對容器技術落地的真正擔憂。

好比容器網絡，能夠分紅Underlay、Overlay、Routing、Routing+Overlay模型等，這些網絡容器模型Kubernetes都支持。銀行關注的是集羣能不能跨VLAN，集羣節點與節點之間、容器與容器之間的傳輸性能，哪一種模式有什麼樣的指標。

在這裏我重點說一下網絡方案Kube-OVN。咱們大量考察了開源社區以及國內一些大廠推出的網絡方案，沒有找到一種特別適合金融行業特性的網絡方案，因此靈雀雲選擇了自研。基於IaaS裏比較成熟的OVN虛擬網絡的底層，推出Kube-OVN開源項目， Kube-OVN提供了大量目前Kubernetes不具有的網絡功能，並在原有基礎上進行加強。經過將OpenStack領域成熟的網絡功能平移到Kubernetes，來應對更加複雜的基礎環境和應用合規性要求。

對於金融行業來講，除了限制服務帶寬，更高階的需求是，一些業務的優先級會更高，若是一旦網絡阻塞，這些業務的流量須要優先放行，這種控制也是金融行業的特性要求。還有內嵌的負載均衡或分佈式網關，基於NameSpace的網關，都比較適合金融行業。

「雙模」流水線，打造DevOps敏捷流程

作DevOps之前的思路是集中在工具鏈建設方面，從代碼存放、代碼構建、鏡像構建、推送到製品倉庫以及Kubernetes進行投產，咱們關心的都是工程層面的環節。但實際上在服務銀行客戶進行DevOps平臺的設計和落地時會發現，客戶對於DevOps的理解超越了工程層面，偏向項目管理層面，範圍更加廣義：

DevOps應該從需求導入開始，要可以管理到這個需求最終落地到什麼樣的開發項目，什麼樣的開發計劃，由哪一個開發團隊去承擔；項目經理要從DevOps平臺上能看到每個需求的迭代狀況、交付狀況以及交付效率。

因此，就有了雙模流水線這張圖。從需求導入開始，會有項目管理平臺，主要作需求的梳理以及排期，制定開發任務，作流水線定義；接下來，會有一個設計平臺系統，具體去分配需求應該交給哪一個開發團隊，相應要到這個設計平臺上制定它的開發計劃，整個開發或者交付過程當中須要涉及多少環境，開發中使用什麼開發工具；以後代碼纔會被在代碼倉庫裏開出一個屬於這個項目的代碼存放的空間，主要存放代碼、初始化的SQL腳本等等；在配置中心，須要把應用在不一樣環境的配置信息、元素進行存儲，從而能夠知道應用運行在什麼樣的環境時應該加載什麼樣不一樣的配置，去生成這些配置；持續集成主要是產出配置文件、代碼構建；以後採用鏡像同步，把製品同步到生產環境，一樣也是調用自動化平臺對容器平臺進行部署的任務發送和執行。

容器PaaS平臺價值與規劃

靈雀雲容器化平臺投產以後，一個最直接的效果就是幫助銀行提高容量規劃的水平，統一資源配給管理，提升新系統部署速度，縮短了新業務上線時間。

後邊這張圖是中間件標準化、平臺化以及知識管理。其實咱們接觸的銀行客戶在中間件方面，種類並非不少，可是因爲終年的積累，不一樣的開發團隊，不一樣的技術能力、系統和技術棧選型，帶來的問題更多表如今同一個中間件版本很是多，這其實給應用運維和軟件開發工程化的標準管理帶來了許多沒必要要的麻煩，不少中間件和技術能力也沒法在不一樣的項目中被繼承和複用。

咱們服務的該大型股份制銀行，在作完容器後，其架構辦和平臺處統一制定了中間件的規範和標準，並把它作成容器應用市場的模板。一些應用在開發過程當中，直接使用架構處和平臺處提供的標準化模板來一鍵生成中間件，開發人員能夠專一在業務層面進行開發，而中間件、支撐類環境標準的制定就交給技術管理部門統一管理，做爲一種標準的、規範的配置能力輸出，極大地簡化了行裏對中間件版本管理的難度。對於應用運維來講，它面向的環境會更加標準和統一，大幅度的減小了知識和技能的建設和傳遞成本。

最後，靈雀雲的願景是成爲數字化轉型引領者，咱們但願經過最早進的技術、最專業的服務、最可靠的合做，成爲傳統企業數字化轉型中最可信賴的雲原生技術合做夥伴。