一、引言
在“技術+數據”雙輪驅動改革轉型的大背景下，民生銀行於2018年啓動了數據中臺的論證建設，2019年全線完工投入使用。數據中臺的技術訴求與雲原生有着“天然”的契合，我行自主探索、自主研發，在建設中進行了諸多探索創新，走出了一條自己的道路。近期作者將分成工具篇和管理篇兩個篇章分享這些數據中臺在雲原生領域的落地實踐。
二、民生銀行數據中臺建設概況
數據中臺是當下一個比較火的理念，由阿里在2017年左右率先對外提出，本質是通過數據技術統一標準和口徑，對“全域”數據進行採集、加工、存儲，形成一個口徑統一的數據服務中間層，進而高效爲業務層和決策層提供數據支撐。數據中臺理念對大企業更具吸引力，可以對症很多企業成長到一定規模後的“數據病”，金融行業首當其衝，各家金融機構也都在探索中。
民生銀行數據中臺建設概況
民生銀行在數據中臺的論證實施上走在了金融機構的前列，是首家在金融領域探索並落地金融數據中臺的機構，獲得金融電子化頒發的《2018年度金融行業科技創新突出貢獻獎》，整體架構基於“微服務+容器化”思路設計，Store數據存儲體系、Service數據服務體系、Open數據路由體系、Plus管理體系4大功能體系核心模塊自主研發，基礎組件按照安全可控（國產化）標準落地。現階段正在爲民生銀行個金、小微、私銀、網金、公司、供應鏈、資管、監管等10餘個業務領域的數據訴求提供支撐，涵蓋100餘項專業化金融場景、數百項數據服務，日均調用次數超1000萬。
三、初探雲原生
雲原生（Cloud Native）的概念在2013年左右提出，2015年Linux基金會推出獨立的雲原生應用基金會（CNCF），雲原生技術與應用的發展開始走上快車道，孵化了包括Kubernetes、Prometheus等衆多耳熟能詳的優秀項目。
“原生”即爲土生土長的意思，指應用在設計階段即明確將進行“雲化”的部署運行（而非基於虛擬機技術的遷移改造），充分利用彈性、松耦合等雲化的優勢進行架構設計。CNCF公佈的雲原生代表技術包括容器（Container）、服務網格（Service Mesh）、微服務（Microservice）、不可變基礎設施（immutable infrastructure）和聲明式API（declarative APIs）。
這裏作者結合民生銀行基礎技術棧，將雲原生的建設思路抽象爲按照微服務、容器化的架構設計應用、兼顧DevOps標準，滿足持續交付基本訴求，即：雲原生 = 微服務 + DevOps + 持續交付 + 容器化
雲原生建設思路
四、從數據中臺建設“痛點”談雲原生技術架構“訴求”
開篇提到數據中臺的架構訴求與雲原生（微服務與容器化）有着“天然”的技術契合，契合點在於：數據中臺在打造金融領域數據服務場景的過程中所面臨的“痛點”與雲原生技術的特長不謀而合。
近年來銀行經營壓力持續增大，各業務條線在一線經營上，爲了尋求新的增長點，提出了諸多個性化數據分析和服務的述求，在沒有數據中臺時，要滿足諸如小微、私銀、網金、公司、供應鏈、監管等諸多銀行業務條線的數據需求，數據分析師和工程師需要在後臺數據倉庫上完成T+1的數據加工，然後將數據文件推送給各個業務前端系統，每個業務前端系統都維持一個小規模的數據團隊，專門負責將數據文件轉化爲自己領域內的數據服務，實現業務述求。這種模式下痛點以及對數據中臺架構選型的要求主要體現在以下幾點：
痛點1：存儲浪費大。數據以文件方式分發到各個下游系統，均需要佔用業務庫寶貴的存儲資源，尤其是通用場景數據（例如用戶畫像標籤等），重複的資源浪費尤爲突出，亟需集中化的存儲和服務支撐，體現在架構選型上，即需要“雲化的異構存儲能力”支撐；
痛點2：傳遞效率低。文件式數據傳遞鏈路以T+1批量爲主，數據需要“一股腦”全部加載進本地應用庫後方可使用，數據獲取的效率遠低於通過服務“按需”調用獲取指定內容（例如指定客戶信息、指定機構指標），數據中臺爲了支持前端各具業務特色的數據應用場景，需要藉助“微服務”解耦和組裝；
痛點3：人力投入大。雖然每個業務前端系統只維持一個小規模的數據團隊，但銀行前端業務系統衆多，整體投入不容忽視。這部分工作收歸沉澱在數據中臺後，爲了繼續保持對各業務場景迭代訴求的快速響應、同時確保數據中臺不會被突增的繁複工作壓垮，就需要考慮通過技術手段降本增效，提升持續交付能力。體現在技術訴求上，就是需要“雲化的部署運營能力”支撐；
痛點4：管控力度弱。文件式的數據應用方式，文件傳送出去後，缺少有效的管控手段，無法準確回答數據使用場景、使用頻次等問題，數據的價值難以量化評估，這就要求數據中臺建設時除了技術架構考量外，需要同等注重“雲化的協作管理能力”建設。
數據中臺建設“痛點”與技術“訴求”
“微服務”、“雲化的異構存儲能力”、“雲化的部署運營能力”、“雲化的協作管理能力”就是數據中臺解決目前金融業數據應用痛點的思路，與雲原生技術的特長不謀而合。
五、民生銀行數據中臺在雲原生領域的探索與創新
“求木之長者，必固其根本；欲流之遠者，必浚其源泉。”在我行數據中臺近兩年的摸索、彎路中，上述經驗被反覆印證，雲原生應用不止要在技術層面“達標”，更要在配套管理層面“創新”，配套管理就是雲原生應用的本和源。我行數據中臺在踐行雲原生架構思想上結合金融領域數據服務特點進行了三個方面的探索與創新：
探索1：工具層面，打造一站式的數據服務雲化DevOps工作臺。
核心模塊“數據服務雲平臺”與“場景化數據存儲組件”聯合打造具備服務場景化管理、技術框架靈活插拔、運維工具豐富全面的“雲化開發”、“雲化存儲”、“雲化發佈”、“雲化運維”的一站式工作臺。
探索2：管理層面，提出一套場景金融服務管理方案。
結合民生銀行自身業務經營狀況對雲化微服務集、異構服務組件，從業務場景、是否對客、組件多租戶使用等角度進行管控，“場景分區+技術分級”，保證數據中臺服務在業務場景高交付下做到可管理、可控制，能夠長期有序的運行。
探索3：組件層面，提出一套異構組件分級應用方案。
數據中臺結合金融數據應用特點、數據存儲組件能力、運維服務級別等因素，構建了一套異構大數據存儲組件的分級應用體系，在大數據存儲組件服務能力和業務場景訴求間取得平衡，取長補短，根據場景選擇合適的存儲組件，靈活組合、插拔式使用。
下面作者將分成工具篇（探索1）和管理篇（探索2和探索3）兩個篇章分享這些數據中臺雲原生領域的落地實踐。
實踐：工具篇
我行數據中臺在雲原生工具層面，探索打造了一套一站式的數據服務雲化DevOps工作臺，下文將以點代面，從一項項實用、易用的工具層面，挑選有代表性的功能點，串聯中臺服務開發、投產、運行的全過程，從而分享數據中臺是如何踐行雲原生架構的。
數據服務雲化DevOps工作臺小工具示例
1）插拔式的開發框架與代碼生成器
在數據中臺上開發應用需要滿足微服務設計、支持雲化部署、支持異構存儲組件等技術特點，這些均對代碼標準、開發人員綜合能力提出很高的要求，例如：
-
微服務設計具有低耦合+高內聚的特點，這就要求任何一個微小的服務都要集成諸如日誌、緩存、註冊與追蹤等大量基礎功能，且支持在雲化環境中運行；
-
中臺的異構存儲組件涵蓋關係型、內存KV型、分佈式KV型等，或獨立、或組合以適配不同的應用場景（適配方案在管理篇中介紹），每項組件的連接池管理、最優操作實踐、基本規範等均有所不同。
基於以上幾點考量，數據中臺提供了一套便捷的開發框架生成器和代碼生成器，開發人員通過界面勾選方式選擇該業務場景微服務所需要使用的基礎功能（目前支持服務註冊、日誌模塊、服務攔截、數據攔截、多線程模塊、緩存模塊等）和存儲組件（目前支持MySQL、Redis、Gauss、SDB、HBase），代碼生成器會直接生成包含所選功能、包含最優操作實踐、可直接雲化部署運行的工程代碼，開發人員可以快速上手的同時，可以將更多的精力投入到核心業務邏輯的開發中。
插拔式的開發框架生成器
便捷的代碼生成器
2）一鍵式的雲化編譯、部署、封版工具
微服務的雲化部署運行是一項十分繁複的工作，包含諸多操作細節（例如源碼編譯、應用打包、鏡像構建、容器部署等）和配置細節（涵蓋應用配置、數據庫配置、集羣配置、緩存配置、容器配置等），但同時也是一項直接影響雲化運行是否穩定穩定的重要工作，包含多項重要的管理抓手（諸如源碼版本、配置版本、運行的環境、鏡像的管理、部署的集羣、資源的調配等），對服務開發人員技術門檻要求極高。
數據中臺整合集成、將繁瑣的操作和配置透明化，提供了一套面向docker雲化運行環境的一鍵式編譯、部署工具微服務應用在雲化環境中從構建到部署一鍵觸發、各中間環節執行進展一目瞭然、歷史版本一鍵追溯回滾。
一鍵式雲化編譯、部署工具
同時結合民生銀行生產變更與版本管理標準，提供一鍵式的封版、校驗工具，將源碼校驗、配置校驗等工作固化到標準流程中。
一鍵式雲化封版、校驗工具
兩項工具配合使用，在落實雲化運行各項管理抓手穩定可控的同時，降低了開發人員雲化應用開發的技術門檻。
3）自動化的源碼校驗、配置校驗工具
數據中臺針對敏捷交付中版本快速迭代可能出現的風險點，推出了人性化自動校驗工具，包含：
①源碼級別的Change List校驗，提供任意兩次版本（或兩次投產）間源碼級別的更新信息、更新內容等；
源碼級別的Change List校驗工具
②配置級別的Change List校驗，提供任意兩次版本間配置文件比對提示（新增、差異、缺失等）、文件內容差異化展示（鍵同值不同、鍵缺失、鍵新增等），人性化的設置了紅黃警示，配置文件缺失、配置項缺失時用紅色進行嚴重問題警告，配置值不相同用黃色進行一般性的提示。出現一項紅色警示則爲校驗失敗，中斷後續流程。
配置級別的Change List校驗
4）雲化的全鏈路服務跟蹤
隨着雲化運行的微服務達到一定的量級，微服務的運行狀態追蹤、依賴調用分析、熱點分析成爲雲原生領域的技術難題。民生銀行數據中臺在起步階段就行了系統性設計，通過服務註冊、API Key識別、流水號串接、服務攔截、數據攔截、日誌留痕、準實時分析等一系列規範和技術手段，聯合打造了一整套完整的雲化服務全鏈路跟蹤體系。
同時針對數據中臺微服務的業務特性（主要爲數據類服務），在鏈路跟蹤體系中增加對數據存儲層訪問與數據返回量級的追蹤，方便運營人員更全面瞭解每項微服務的健康狀態。
微服務依賴分析
微服務鏈路追蹤與耗時分析
微服務鏈路日誌
5）異構組件聯動的生命週期管理工具
數據中臺在大數據存儲組件層面打造了一套支持異構組件聯合使用的分級應用體系，在存儲組件服務能力、業務場景訴求、運維級別間取得平衡，取長補短，組合使用（將在管理篇中介紹）。
異構存儲組件種類多樣，涵蓋傳統關係型、分佈式關係型、內存KV型、分佈式KV型等，這就要求中臺數據生命週期管理工具在支持基本的單組件數據退役功能的同時，還要支持多組件的數據升降級管理，例如在MySQL退役的歷史數據需要聯動加載到SequoiaDB，實現數據降級服務。
6）可視化的緩存熱管理工具
中臺另一項與雲化運行結合緊密的小工具是可視化的緩存熱管理工具，針對配置有緩存組件的微服務，支持在應用運行階段，動態調整緩存時效和緩存開關，同時配備緩存KV檢索看板和緩存使用分析等輔助功能。
緩存熱管理工具
六、結語
“工具篇”是數據中臺雲原生應用實踐的開篇，一個好的原生應用不止要在技術層面“達標”，更要在配套管理層面“創新”，下一篇章“管理篇”，將從雲原生的配套管理方案視角，分享民生銀行在諸如“微服務解耦粒度如何把控”、“異構存儲組件中的數據如何保持一致性”等雲原生難題上是如何落地實踐的。
作者丨羅京 來源丨民生大數據（ID：gh_87c716ca6553） dbaplus社羣歡迎廣大技術人員投稿，投稿郵箱： [email protected]