一、技術選擇
新應用系統需要更加靈活快速上線，以客戶體驗為主要考量指標。私有云IaaS云平臺，能夠靈活提供虛擬機、容器服務。而基于虛擬機或物理機的緊耦合架構，軟件版本的細微更新就會造成牽一發而動全身的后果，一個新版本往往需要數月，甚至更長時間，這無法滿足業務快速迭代的需求。
容器技術是細粒度的虛擬化技術，比傳統虛擬化技術的資源利用率要高很多。容器技術的輕量化能給基礎架構帶來的另一好處，就是具備了靈活的擴展能力，具備了真正意義上的資源彈性，實現了快速自動的擴展和回收。也正是因為其輕量化的特征，讓業務具備了云內、云間的按需流動。
圖1：虛擬化與容器對比
二、容器需要存儲
微服務改造中，目標業務系統需要首先實現無狀態改造，將有狀態的數據分離到存儲系統。讓業務真正實現了無狀態的全自動伸縮，而有狀態的數據將由分布式數據庫來承載。
金融級的容器平臺需要提供一致性能力、彈性伸縮能力、灰度發布能力，和DevOps開發運維一體化以及微服務架構集成，以實現持續集成、監控、改進的優化循環。
容器平臺除了常規所需的計算、內存、網絡資源外，存儲資源也是不可缺失的關鍵能力之一。存儲作為容器平臺基礎資源，保證容器云數據安全和持久存儲。同時，容器對存儲服務種類除了標準的NFS掛載外，還需要對象存儲服務，主要用于容器鏡像存儲。當然塊存儲也常見用于容器的持久化存儲，如應用程序的日志讀寫。
而基礎平臺除了能夠提供NFS、對象存儲服務外，還需要具備和云協同服務的存儲能力，隨著容器的發放、運行、終止、回收進行生命周期的管理。為了保證數據的安全性和可用性，存儲平臺除了前面提到的和云配套的能力之外，還需要具備金融級的安全性和可靠性，從而能夠完全滿足監管機構對業務連續性要求。
圖2：容器應用場景
在業務連續性方面，微服務架構通常的做法是通過應用層面來提供容災能力，但當前主流的分布式數據庫采用的MySQL和類MySQL數據庫系統，它的本地、同城、異地容災能力往往是我們規劃的一個難題。比如，本地的一主多備模式保障本地的可用性，同城部署第三副本，以binlog復制方式保障RPO。若考慮強一致性的業務場景，這種方式下的RPO不能滿足業務需求。
另外，微服務改造后的容災架構往往也存在不合理的地方。業務拆分得非常復雜，某些業務和其他業務的關聯關系耦合度還很高，這就造成了一些高容災需求的業務系統依賴于低容災需求的業務系統，這種不合理的現象在分布式改造項目中是一個通病。這需要一個嚴格的統一的業務連續性規劃來規避這種潛在風險。
圖3：容器存儲使用場景
圖4：微服務架構應用容災
基于以上考慮，個人認為可以通過引入企業級集中式存儲來解決一些問題。利用集中式存儲的低時延、高可靠性解決容器應用的高性能場景，利用集中式存儲的雙活方案解決業務連續性的痛點。
三、實施效果
我行在云計算、微服務等技術方面進行了探索、試驗及落地，經過多年的技術探索，積累了一些經驗。諸如渠道類業務系統、辦公類系統、信貸類系統等利用容器技術實現了落地。為未來的其他重要業務系統的容器化部署打下了堅實的基礎，積累了豐富的實施經驗。
如智能柜面實現微服務改造，145個服務實現容器化部署。渠道業務層提供基于Docker的容器化服務，通過在容器中運行接口服務對接ESB以及其他業務系統和模塊。單中心使用資源約為1400C，3600G。經實際運行，目前單中心交易TPS約為1900左右，響應時間在50ms以下。整體運行穩定，滿足業務要求。
四、總結
微服務改造、容器云是當前熱點，我們緊跟時代技術發展脈搏，通過新技術的使用來解決當前的一些挑戰，也希望通過新技術來驅動金融服務的創新，從而完成數據來源于業務、數據驅動業務創新的閉環，實現真正意義上的企業數字化轉型，讓金融機構更加智慧化、智能化。
劉艷春 某金融公司架構師：
絕大多數容器生產業務，需要數據持久化，需要有狀態的容器服務，需要穩定、全方位支撐的數據存儲平臺才能保證業務安全穩定運行。
數據成為繼土地、勞動力、資本之后一種新的生產要素，成為提高生產效率，降低成本，增強企業發展韌性的關鍵，數據安全可靠、穩定運行在核心基礎設施之中才能產生價值， 因此數據存儲也正成為加速數字化轉型的堅實底座。
自2020年年初以來，一場突如其來的疫情，席卷了全球，改變著人類生活和工作模式。企業級存儲的IT基礎設施也隨之改變，如何滿足數據對存儲各種場景的需求，涌現出了很多存儲解決方案，如軟件定義分布式存儲、全閃存儲、云存儲、容器云存儲、大數據存儲、AI存儲、區塊鏈存儲、邊緣存儲、量子存儲等等。當前越來越多的企業正發揮以容器云為代表的數字技術的巨大潛力，優化運營能力，加速數字創新進程。容器平臺是以Kubernetes和Docker為技術基礎，為容器化應用提供從應用的創建、發布、運行、擴容、迭代、銷毀的全生命周期的管理能力，集成適應云場景下的網絡服務、存儲服務、鏡像服務等特性。絕大多數容器生產業務，需要數據持久化，需要有狀態的容器服務，需有穩定、全方位支撐的數據存儲平臺，才能保證業務安全穩定運行。本文將簡述容器云環境下如何設計存儲架構。
一、容器云平臺的存儲需求
1. 數量大-大量存儲卷
容器用戶需要建立更多的存儲卷來支持存儲的虛擬化和池化。由于容器技術可以實現在單個主機上運行數百個容器，但這些容器加起來需要的存儲卷可能超過操作系統的限制，需有靈活應對突發需求，敏捷響應業務變化、動態分配以及多容器應用的并行訪問的存儲卷的存儲。
2. 活性-動態存儲調度
由于容器會不斷的創建，銷毀，并且在Node之間遷移。因此需有動態靈活調度，軟硬件解耦，易于擴展并且可以緊密地集成到容器編排框架中的存儲。在容器層可實現卷的動態創建，裸卷映射、快照、克隆、卷擴展等。
3. 差異化-持久化卷支持適應不同場景
不同的容器有狀態應用需求不同的數據存儲方式，塊存儲（RBD，iSCSI）、文件存儲（NFS）、對象存儲（S3）。當節點異常時，Pod會被調度到其他節點，如果使用本地卷，新的Pod啟動后無法訪問原有數據，需要有支持持久化卷（Persistent Volume），Pod被調度后，依然可以訪問到之前的數據的存儲。同時也需要多應用同時訪問數據，多協議的支持，多容器類型的支持存儲平臺。
二、容器云平臺的存儲架構設計
1. 容器存儲卷主要有如下方式
1) 服務器本地存儲：固定在容器正在運行的主機上的存儲。
2) 傳統存儲設備：由其他供應商提供的容器存儲驅動程序配置的SAN、NAS或超融合系統平臺。
3) 分布式文件系統：由多個服務器提供的統一命名空間的共享文件系統。
4) 容器原生存儲：一種軟件定義的容器化存儲系統，專門為容器化應用程序提供數據管理。
5) 云塊存儲服務：IaaS平臺的塊存儲服務。
6) 云文件存儲服務：IaaS平臺的文件存儲服務。
2. 有狀態數據存儲要求
1) 存儲卷生命周期單獨管理。存儲卷的生命周期和容器分開，可以創建存儲卷，然后再綁定到容器，容器刪除不會自動刪除存儲卷。
2) 提供對接文件存儲，多個容器可以共享同一個存儲卷用于存儲數據。
3) 提供存儲快照和恢復能力。能夠對存儲卷做快照，或者通過快照恢復存儲卷數據。4) 提供對接本地存儲，可將本地文件路徑掛載到容器內部。
5) 支持插件擴展不同第三方存儲方案?？梢酝ㄟ^插件的方式對接不同的底層存儲方案。
3. 容器云存儲架構
軟件定義存儲能夠支持適用于容器的可動態創建的持久化存儲，可同時支持不同類型應用的存儲訪問需求。通過軟件將通用服務器整合為統一存儲資源池，以軟件定義的方式提供塊、文件、對象等不同數據存儲形態。在企業存儲管理上，大多數據中心存儲承載敏態穩態混合架構數據服務，需有一個統一存儲平臺管控。統一存儲平臺不但可以提供基于商用硬件的分布式存儲系統以及高性能高可靠性存儲，而且可以通過基于控制平面的軟件應用存儲控制器，同一套存儲系統為上層應用同時提供塊、文件和對象三種數據服務，滿足業務對結構化、半結構化、非結構化數據的存放需求。實現對虛擬化環境中不同異構存儲的統一管理交付，將底層異構存儲資源抽象化，數據中心管理員可依據前端業務團隊所要求的特性以需求創建存儲服務，并將其自動配置給所需的應用程序服務器。容器云平臺存儲按容器云架構分為五層架構，各層功能特性如下表：
表 1：容器云存儲功能架構
容器云存儲常用CSI (Container StorageInterface) 插件對外開放的存儲接口來實現存儲服務。解耦了Kubernetes系統的計算層和存儲層。
統一性：無論是塊存儲還是文件存儲，都可以通過CSI的方式去使用。
穩定性：CSI方案將存儲和計算兩種資源完全解耦，實現了資源的隔離，同時CSI插件以容器化部署， 因此穩定性更進一步得到保障。
兼容性：CSI插件以容器化部署，不會受操作系統版本和存儲集群的限制，消除環境差異所帶來的不確定性以及其他約束。
易運維：不需要復雜的集群配置修改和準備工作，只需填好CSI容器配置，拉取鏡像，一鍵可達。
無縫升級：如果之前使用的RBD，iSCSI，NFS對接，存儲也提供完善可靠的無縫升級到CSI接口。
豐富的特性：不僅僅滿足客戶存儲的基本需求，在實際使用中，存儲提供的存儲插件有很多非常重要和倍受青睞的高級特性，支持動態擴容，根據實際需求動態地擴容和縮容。除此之外，還會有Snapshots快照以及QoS管理等其他的特性，進一步完善容器生態。
高曉峰 無錫農商行 科技管理部系統管理團隊長：
對于中大型銀行是不可能憑借一種存儲技術解決大部分平臺容器需求，因此各種類型存儲資源池成為了設計主角，需要根據其業務特性選擇合適的存儲架構落地方案。
一、業務與容器云、與存儲的關系
引用《以業務為核心的云原生體系建設》對架構劃分，總的來說銀行IT架構包含以下幾個方面：業務架構、技術架構、數據架構、研發流程和組織架構。
就業務架構而言，目前大部分銀行核心系統多是外采的（合作開發），或者由于業務穩定性等諸多因素考慮，處于單體架構的階段。部分非核心業務，采用了服務化的架構，構建了中臺體系。而互聯網化業務因為要應對高并發流量，以及應對市場的快速變化，已經將服務拆分得更加細，實現了微服務架構。
就技術架構而言，最初銀行多會使用采購物理機的方式運行業務代碼，因為資源使用效率和靈活度的問題，很多銀行采用了虛擬化平臺。從虛擬化平臺到云平臺的變化不在于技術，而在于使用模式，主要是三點，統一接口，抽象概念，租戶自助，說白了就是讓業務方不需要特別專業的底層技術能力，就能實現應用的部署，同時將運維人員從應對越來越多的業務方的噩夢中解放出來。容器進一步讓應用從代碼到運行無縫的連接起來，并且可以實現跨云的遷移。ServiceMesh將微服務的治理放到統一的平臺上來做，進一步解放業務方。
就數據架構而言，在業務運行的過程中，會積累很多的數據。最初銀行的系統大多只做數據記錄的作用，并沒有發揮太多的價值，數據是散落在各個系統的數據庫之中的。如果想進行分析，查看當前業務的運行情況，需要分析師將數據導出來，做成表格和報告，給領導看，這樣時效性就會很差。后來很多銀行開始做數據的梳理，建設數據倉庫（數據倉庫或者數據湖），并且建設BI大屏，領導駕駛艙，支撐戰略決策。當然這種方式沒有辦法和業務直接結合，后期考慮數據運營驅動業務創新（或IT引領業務），也就是在電商和社交APP上的千人千面，智能推薦等功能。
容器云是一種技術手段，與虛擬化或物理機相比能更好的節能增效，并且與現階段微服務化應用更緊密結合。以Kubernetes為例，其對底層基礎架構進行抽象，池化了底層資源，將資源交付的時效性降低至分鐘級別。系統資源維護從原來的虛擬機（物理機）交付，變成了資源擴容（Quota分配），減輕運維的工作量；同時，開發應用通用鏡像技術打包發布，避免了環境變量不一致帶來的應用部署麻煩，將應用部署從天級縮減至小時級，甚至于分鐘級。
存儲既是技術架構的組成部分，也是支撐數據架構的重要基石，對于容器云來說，存儲提供了存儲資源池的功能，業務根據各自的需求按需申請存儲資源，存放數據信息。
二、業務需求與存儲需求
根據《中華人民共和國金融行業標準—金融數據安全數據安全分級指南》對金融行業的分類規則提供的參考表，其分為了四大類：客戶、業務、管理、監管。而這四大類數據又可以抽象為兩大類數據即結構化數據與非結構化數據。其中結構化數據主要表現形式為數據庫數據，數據記錄小以及隨機查詢的需要，讀寫硬盤的塊大?。˙lock size）一般都很小，這種小數據塊的讀寫，對于總帶寬要求不會很大，因此通常評定這類數據的性能指標為IOP；而非結構化的數據一般是比較大的文件為主，讀寫塊大小會設置得比較大（64KB以上，甚至512KB或者1MB），而且單個文件內部可以認為是連續讀寫的，因此對于這類數據的讀寫，更多以帶寬為其性能指標。因此對銀行應用數據來說，存儲既需要提供滿足于高IOPS的需求，也需要滿足高帶寬的需求。
目前主流的容器云平臺都是基于Kubernetes，Kubernetes存儲數據主要有三類：
鏡像文件
配置信息
應用數據
而數據庫一般不運行于容器云平臺中，因此對容器云來說，存儲需要提供高帶寬、高IOPS的服務。
三、容器云存儲架構設計
Kubernetes作為一個主流的開源容器平臺，有很多主流的存儲是默認支持的，例如本地盤，Ceph，以及主流公有云平臺的塊存儲等。支持這些存儲的代碼邏輯都是在Kubernetes代碼中運行的，我們稱為In-Tree方式。但是Kubernetes作為私有云平臺進行部署，會有一些商業化的NAS、SAN以及對象存儲需要進行對接，這就要用到CSI接口。CSI全稱Container Storage Interface，主要目標是將任意存儲系統都可以通過標準的接口暴露給容器化的應用。
對于多數銀行業的企業，都有豐富的SAN和NAS的存儲管理及運維經驗，結合應用的存儲需求、平臺鏡像方案的設計，以及銀行業的應用系統普遍有多中心部署的監管需求，我認為比較合適采用NFS類型的存儲用于支持容器數據持久化以及鏡像服務的相關存儲需求來應對容器平臺在小型銀行企業的落地。
當然對于中大型銀行是不可能憑借一種存儲技術解決大部分平臺容器需求的，因此各種類型存儲資源池成為了設計主角，需要根據其業務特性選擇合適的存儲架構落地方案。
結束語
綜上所述，對于容器云來說，存儲提供了存儲資源池的功能。金融企業不可能憑借一種存儲資源解決所有的容器需求，需要根據其業務特點選擇適合的存儲架構落地方案。
