一文讀懂金融行業如何做雲原生

過去兩年，金融行業IT人員對“雲原生”充滿了疑惑甚至誤解。我們一直在不同場合聽到關于雲原生的各種不同定義

有人說，雲原生就是Kubernetes和容器；也有人說，雲原生就是“彈性可擴充”；還有人說，雲原生就是Serverless。

其實雲原生本身就是“哈姆雷特”，因為每個人的了解都不一樣。

CNCF和kubernetes技術生态定義的雲原生概念中指出雲原生的本質是一系列最佳實踐的結合。換句話說雲原生為實踐者指定了一條低心智負擔，能夠以可擴充、可複制的方式最大化地發揮雲的價值的最佳路徑。

是以，雲原生應當是一種“以應用為中心”的思想。

何為雲原生應用

目前，雲原生技術已被大家認可。那麼何為雲原生技術？

首先，所有技術都是為業務服務，雲原生技術誕生的背後也是業務驅動。随着軟體的發展，業務越來越複雜、龐大，但軟體使用者卻希望可以得到更快的需求響應、更穩定的運作狀态，是以網際網路企業開始大量使用雲原生技術。

雲原生主要圍繞着3個目标：加速創新、降低成本、提高效率。 基于雲原生技術開發的應用就是雲原生應用，那麼雲原生應用就意味着統一：

• 統一架構标準： 通常以微服務架構進行服務開發，服務之間使用标準的API契約進行通信。松耦合的架構方式會減輕因需求變更導緻的系統疊代成本，并加快傳遞速度；
• 統一傳遞标準： 标準容器化的打包方式實作了真正的應用可移植性，不依賴于特定的基礎架構（虛拟機，混合雲等）。而容器基于程序粒度的資源使用方式，也會降低系統的資源開銷；
• 統一流程标準： DevOps強調軟體全研發周期的管理，從軟體需求到最終生産的全流程的改進和優化，然後結合統一工具鍊，實作文化、流程、工具的一緻性，本質解決的是加快軟體傳遞速度的同時，提升軟體産品品質。

  

金融行業的應用是否需要雲原生的改造？

傳統的金融軟體架構存在很多難以解決問題。在巨石型的應用中，每個系統資料都是一座孤島，沒有接口可以對外服務，如果客戶有創新需求想實作多個系統配合，幾乎不可能。各業務系統采用的傳遞方式部署安裝的硬體标準不一，導緻金融機構運維超級複雜，成千上百台機器以及上百個應用需要一個龐大運維團隊支撐。金融軟體的傳遞周期目前是按月傳遞的，研發流程更多還是傳統的瀑布或者靈活方式，導緻了很多客戶需求被延誤。

為滿足使用者快速多變的投資理财訴求，金融行業的軟體架構更新已經迫在眉睫，雲原生架構則成為最佳選擇。

雲原生應用演進路徑

作為金融行業全領域的軟體提供商，恒生所有業務系統在過去兩年全面往雲原生架構更新，積累了不少經驗。

總體而言，雲原生應用演進面臨着三大難題：微服務拆分、容器化傳遞、DevOps改造。

微服務拆分之路

從單體應用到SOA再到微服務，軟體架構一直在追求不同的拆分次元。微服務架構更強調的是按照業務能力垂直架構劃分，即每個微服務完成一種特定功能，可以獨立運作、獨立部署。

微服務拆分的依據一般為兩個原則：一是業務獨立性，維持微服務業務内部的權責單一原則；二是團隊自主性，維持微服務團隊内部的地溝通成本原則。

業務層面的邏輯梳理，可以根據團隊成員大小以及團隊間的溝通成本來檢驗業務拆分是否合理。一般建議一個微服務開發團隊10人左右比較合适，這樣可以快速疊代使用者的需求。

想把微服務拆分做得十分合理往往比較困難。拆分是一個持續工作，随着業務上線，通過更新部署等運維方式就可以校驗微服務劃分是否合理。

以恒生的理财銷售系統為例，系統的第一輪拆分包括了交易、支付結算、賬戶、清算等7個微服務，當業務系統在用戶端上線時發現部分拆分還是過大，影響到了很多業務更新，于是進行了第二輪拆分疊代。第二輪拆分把支付結算拆成獨立支付微服務，把清算拆為交易清算以及資金清算等。按照實踐經驗來看，微服務的拆分一開始可以粗粒度一些，随着生産校驗的推進可以逐漸細化和合理化。

最近兩年，另外一個與微服務拆分的相關的理念開始火起來了，這就是起源于2004的DDD（領域驅動設計）。目前業内傾向于認為DDD是微服務劃分的終極解決辦法，也是托了微服務的福，DDD才有流行的土壤。

微服務其實是一種架構風格，而DDD是一種思想，微服務定義的九大核心特質跟 DDD的原則是完全一緻的，這在某種程度上也是業界願意在微服務上下文中采用 DDD 方法和實踐的原因 。

目前已經有很多DDD如何結合微服務的技術文章和演講開始流行，相信有朝一日DDD能成為真正微服務拆分的解決之道。

容器化傳遞之路

IT基礎設施往雲上遷移是大勢所趨。在雲平台競争激烈的市場環境裡，在金融機構對成本、廠商鎖定的擔憂下，包含公用雲、私有雲和本地部署組合的混合雲誕生了。

混合雲時代，容器依靠自身标準化、一次建構随處運作的能力開始大行其道。

金融機構的傳遞方式往往存在嚴重不統一的問題，在不下于幾十家開發商産品提供的情況下，每種軟體的安裝部署都是不一樣的标準和操作方式，容器就可以很好的解決這個問題。

容器類似于集裝箱，金融機構隻需要部署好混合雲底座就具備了存放集裝箱的基礎，然後所有開發商按照統一安裝集裝箱的方式提供傳遞。此時金融機構的運維人員進行簡單羅列排布即可，更新的時候進行簡單替換即可。這将大大減少金融機構機房内運維人員數量，就好比一個碼頭，全是自動化集裝箱解除安裝、排放、運輸、排程，實作真正的智能運維。

如果通過容器把金融機構的機房變成一個全智能的“碼頭”，對容器雲平台需要做好以下幾點：

• 統一的傳遞規範。針對容器傳遞要有一定的規範要求，譬如作業系統版本，安全漏洞、中間件版本等。這些基本要求是所有傳遞物要進入這個“碼頭”需要首先做到的；
• 統一的編排規範。針對所有容器編排，形成一個應用要有統一的限制和要求，譬如：配置中心各自分區限制，日志中心統一采集要求，編排檔案格式要求等，這是所有容器可以自動運作運維的基礎；
• 統一的排程管理界面。所有容器需要按照應用次元去管理，所有應用中用到的技術中間件需要通過統一的PaaS平台管理和擷取。業務運維人員需要從應用視角展示管理界面，包括：名額監控告警、應急切換操作、日志檢視操作等。

DevOps改造之路

DevOps（Development和Operations的組合詞，開發即運維）涉及整個軟體生命周期中的持續開發、持續測試、持續內建、持續部署和持續運維與回報，目的是實作短周期内的高品質軟體開發與傳遞，確定軟體的持久穩定，為企業帶來營運能力和效能的持續提升。

實際上，DevOps是一種實踐，更是一種文化理念，它強調的是合作、自動化、精益、度量、共享。 正是依托微服務架構以及容器化的傳遞，DevOps才變得更加流行起來。

重塑原來的軟體研發傳遞流程和軟體研發過程主要展現在研發傳遞流程、參與角色的重塑。DevOps強調按照需求進行持續的內建、測試、傳遞、部署、監控全自動化化流水線，通過每個環節設定品質卡點，確定傳遞效率與品質。此外，所有角色的統一操作視圖、一站式體驗、資料全部彙總打通，提供全研發鍊路的直覺展示以及每個過程資料彙總分析，提供後續改進的可能性也是DevOps強調的内容。

除了流程的調整梳理之外，DevOps會進一步要求通過工具鍊的統一來完成流程的固化和落地。工具統一的過程可借助開源也可以購買商業産品，但核心是需要通過統一視圖以及流水線的引擎來完成互動以及資料統一。

恒生雲原生應用平台

恒生公司業務系統的雲原生改造開始于2015年，經曆這樣幾個階段：

2017年，技術平台選型統一的階段，完成了JRES3.0技術中台的确定；2019年，業務系統完成微服務拆分，核心重點産品全部改造完成上線；2019年，完成對所有金融業務中共用的業務子產品提取，進一步發展形成業務中台、資料中台。

**至此，恒生整體的大中台架構就真正形成。**從微服務拆分到中台形成，恒生公司也完成了對應的組織結構調整。

作者介紹：許欣芃

恒生公司平台業委會負責人、研發中心總經理。十多年的金融行業技術平台的設計開發經驗，參與交易、風險、清算等金融業務系統設計和研發，目前負責恒生公司統一技術中台的研發管理工作。對雲原生技術有比較深入的研究，對微服務、容器、Devops相關技術有一定實戰經驗。

更多金融科技文章請見恒生LIGHT雲社群