“既然未來已來，不如直接進入那個未來！”  

核心系統轉型，相當於給正在跳動的心臟，做一場不停擺的換心手術。

不少核心系統採用的傳統集中式架構，已經不止是一種技術架構模式，而成為一種根深蒂固的思維習慣和設計理念。當它成為潛規則而影響了創新時，我們往往身在此山中而不為所知。

在阿里巴巴集團副總裁、阿里雲新金融&網際網路事業部總經理劉偉光看來，不少機構在做核心系統轉型時，極易陷入窘境：

• 選擇應用平遷、不做架構大變化，最簡單和快捷。有的銀行正因如此，開發力量80%以上的時間是在做程式碼的效能最佳化，難以承接新功能、新業務的開發。
• 先從簡單系統著手進行架構轉型，再推導到核心轉型。結果非核心領域的轉型實踐對於核心領域的參考借鑑意義有限。
• 核心系統按照功能模組切分，再眾包給不同的開發商來完成，避免被一家繫結。
• 選擇各個領域的最佳“供應商”，完成各自擅長的工作任務（諮詢建模、架構、設計、應用、基礎軟硬體），大家只熟悉自己這部分的“最佳實踐”。
• 追求技術架構完成解耦，碎片化供應商。實際上專案實施過程中IaaS/PaaS層適配雖然功能大體能夠適配，但在非功能性領域的磨合總出現莫名其妙的問題，產生大量溝通與適配成本。
• 業務應用是業務應用開發商的事情，技術平臺是技術平臺供應商的事情，兩者沒有關係。
• ……

這次，劉偉光將全面探討金融行業，尤其是銀行業，在進行核心系統轉型、升級過程中遇到的方方面面的問題與挑戰。本文從醞釀到成文歷經四年，期間他與團隊拜訪過近千家金融機構，沉澱出3.5萬字長文。

當中包括：目前核心領域分散式架構轉型、金融級雲原生分散式轉型的21個困惑與解答，新業態對舊核心的挑戰，雙核心並行與線上遷移的大致方案，以及第三代核心的標準與定義等。

作者 | 劉偉光

阿里巴巴集團副總裁

阿里雲新金融&網際網路事業部總經理

目錄

---

序言

---

劉偉光

阿里巴巴集團副總裁

阿里雲新金融&網際網路事業部總經理

中國金融四十人論壇（CF40）理事

2022.01.08 上海

引言

---

1.1金融核心從業者的困惑

1.2核心轉型成功的標誌

1.3面對誤區的破局思維

1.4新思路新出路

二  金融業務新方向呼喚技術的“供給側改革”

迪士尼有一句話反覆被提及：“藝術挑戰技術，技術啟發藝術 ”。

新時代是一個數字時代，數字時代的金融是以資料為關鍵生產要素、以場景和使用者價值為中心的服務模式，主要服務手段依靠對各類數字化技術的綜合運用，其重要載體便是透過網路送達的軟體服務，是以線上便捷服務為主、線下人工服務為輔，融合資料智慧和人類溫情，注重使用者體驗和風控原則的服務模式，金融服務將是開放、普惠、綠色的，嵌入式且靈活多變。而這樣的“泛在化”金融服務必然對賬戶、交易、結算等核心能力提出了“泛在化”、“全時線上”的要求。

2.1開放金融體系需要可標準化的構件式核心

規模是問題（業務）的解藥，規模也是問題（系統）的根源。

如今，開放銀行的理念已經成為銀行業的發展共識，最基本要求是銀行服務透過API、SDK的方式將銀行賬戶、支付、結算能力提供給合作方，以實現把銀行的服務融入到各行各業中。做為開放銀行戰略的升級，場景金融、產業鏈金融正在描繪更大的開放格局，形成一個“泛在化”“毛細血管”式的金融服務。這些業務需要規模來解決泛在化的場景和需求，但這樣的規模也是核心系統問題根源所在。

2.1.1不能變成新“豎井”的場景金融

場景金融是基於各類金融或者非金融場景順暢地融入金融服務。從銀行的角度看，最初的場景金融主要是與平臺類公司接入合作，在消費者眼中，場景金融則是便捷的支付、貸款等金融服務的獲得。

隨著場景金融的演進，其場景正在擴充套件到人們生活、學習、工作的各個方面，一些銀行已經共建、自建了大量的場景金融業務。但基於場景的使用者轉化需要一套完整的業務系統進行支援，包括大量標準化、模組化的能力，業務能力方面包括使用者中心、產品中心、合約中心、賬戶中心、權益中心等，資料能力方面包括使用者畫像、推薦模型、聯邦計算等資料。

此外，隨著數字人民幣試點領域的擴大，金融場景正在越來越豐富，僅數字人民幣的應用場景就已經超過350萬個。場景的價值日益受到重視，銀行都在努力構造更多的場景，這也導致了場景的碎片化以及對場景構建的敏捷性要求。我們建議銀行需要及早認識到如何讓場景不成為新一輪的“豎井式開發”，而業務的中臺化、標準化、構件化正是解決這一問題的出路，越來越多的銀行正在為其業務設計結構化的業務模型，並探索將其與應用設計緊密連線起來。

2.1.2必須實現生態化的產業金融

從理論上來講，供應鏈金融是金融業務從核心企業向周邊企業拓展的最好方式，也是推動產業金融發展的理想模式。但是，供應鏈金融的發展往往需要依靠核心企業的意願、平臺的服務水平、周邊企業的實際收益等諸多關鍵因素的綜合作用，因此，儘管很多研究機構將供應鏈金融視為十萬億級別以上的大市場，但其總體發展一直不是很順利。

如果只為供應鏈金融單獨去建設平臺，那之前存在的建設成本、相關方收益等問題，恐怕依然難以解決。只有透過超越供應鏈視角的大型商業平臺承載供應鏈服務，才有可能解決單一用途平臺面臨的問題。國家倡導建設的行業雲，可以承載這樣型別的商業平臺，現有商業平臺也可以進一步擴大互聯，使任何一家企業可以加入平臺即加入供應鏈，在平臺中也可以自由加入任何供應鏈，這樣的平臺模式，才可能突破傳統供應鏈平臺高封閉、重成本、低收益的困境，這一模式也符合國家要求大型企業開源、開放的政策基調。

多功能的大型商業互聯平臺不僅承載供應鏈，也是各型別企業建立自身應用的“標準化構件庫”，企業可以根據自身需要選擇雲原生的標準化構件組裝自己的業務，這是“產業數字化”的一大推手。當然，這需要高度的業務標準化，所幸，國家標準化發展政策正在推動這一趨勢的形成，未來銀行也會融入到這一宏大的數字化商業生態中，這將催生金融機構新一代面向數字生態的構件化核心系統。

2.2普惠金融體系需要可靈活組裝的核心繫統

普惠金融是致力於持續提高金融服務金融服務公平性、可獲得性的金融服務體系，是透過更有社會責任感的經營理念、更有效率的風控手段、更低的運營成本來使更大範圍的客戶群體可以獲得優質金融服務，在普惠金融的發展過程中，數字化技術將扮演越來越重要的角色。

普惠金融的發展需要做好以下三個方面的工作：

1.靈活的管理：在額度管理、計價定價、風險計量等體系中需要更靈活的能夠支撐不同策略調整，適應不同區域、不同時期、不同行業、不同客戶分層的普惠的要求；

2.經濟的管理：降低單賬戶/單交易成本，降低整體的綜合財務成本；

3.彈性的管理：業務系統可擴充套件支撐更大數量的中長尾市場。

普惠的客群物件和業務特點決定了其產品碎片化、上線週期短、業務變化頻繁，要求能夠像積木塊一樣解構業務和技術能力，靈活配置、實現業務需要，金融機構的核心繫統只有變得像一個可組裝的流水化工場才能應對環境的快速變化，而對長尾客戶群體的支援，更需要一套易擴充套件的核心繫統架構。

2.3綠色金融體系需要可泛化設計的核心繫統

發展綠色金融是不僅是金融行業的商業機會，更是金融行業的社會責任。綠色金融包括兩個部分，一是面向客戶的“雙碳”要求觸發的業務變革，一是金融機構自身要完成“雙碳”目標。

按照“雙碳”要求，金融機構要控制信貸資金流向，逐步減少高排放使用者的信貸支援，未來也可能會逐筆核算信貸資金的“碳排放量”，控制信用業務的“碳”風險。這需要社會資料的支援，而不僅僅是來自使用者的資料，需要更多的外部資料來源、權威資料支援金融機構計算“碳”風險。透過構建綠色金融賬戶，完善綠色金融產品，提升綠色金融智慧化評估，金融機構可以更好地支援綠色生態鏈上下游體系的開放性融合，打通綠色迴圈。綠色金融將推動對金融賬戶應用模式的泛化，從而影響核心系統的設計理念。

全生態鏈綠色金融模式設計

三  金融核心轉型的能力要求與建設體系

“重大問題的解決方案，永遠不可能在產生這個問題的維度上出現。”–愛因斯坦

數字韌性被越來越多的金融機構所提及，什麼是數字化韌性？當應對外界環境變化，或者客戶需求變更時，軟體產品需要有彈性和韌性，要有反應足夠快的數字化體系。當集中式架構在面臨“數字韌性”而“力不從心”的時候，我們認為很難用“舊時代的方法”去解決新時代的問題。雲原生似乎成為一個數字化企業的“標準答案”了。

3.1何為“金融級雲原生”

何為雲原生呢？為什麼現在雲原生這麼火了？

雲原生架構是基於雲原生技術的一組架構原則和設計模式的集合，旨在將應用中的非業務程式碼部分進行最大化的剝離，從而讓雲設施接管應用中原有的大量非功能特性（如彈性、韌性、安全、可觀測性、灰度等），使業務不再有非功能性業務中斷困擾的同時，具備輕量、敏捷、高度自動化的特點。

雲原生技術主要以容器、DevOps、微服務、分散式中介軟體、分散式資料庫、Serverless、服務網格、不可變基礎設施、宣告式API、開放應用模型（OAM）等技術為核心，能夠幫助我們實現業務應用與基礎設施的解耦，因此被認為新一代雲計算的“作業系統”。如下是一些雲原生的核心架構思想（而無關於產品）：

• 分散式微服務：微服務的核心就是將大的單體應用拆分為更小的元件服務（微服務）。能夠做到從底層IT基礎設施、到資料庫、到中介軟體、到應用部署包等全部環境都能夠獨立部署。這樣實現從需求設計、開發、打包、部署全部都能夠獨立完成。實現各個微服務之間徹底的松耦合。同時微服務之間又能夠透過輕量的介面進行互動。
• DevOps：核心就是敏捷研發、持續整合和持續交付。需要將軟體生命週期過程中的需求、設計、開發、編譯、構建、打包、部署，從測試環境、到生產環境整個過程能夠實現全部自動化。將敏捷研發、自動化測試進行整合和協同。
• 服務網格：去中心化的服務整合和治理框架。原來架構一般採用集中式ESB匯流排/API閘道器來做介面、API的服務治理和管控，將API介面註冊到API閘道器。由於ESB/API閘道器是一箇中心化的架構，所有的請求和流量透過API閘道器，所以中心化的API閘道器可以對流量進行安全、日誌、限流熔斷、監控等各方面的管控和治理能力。當在去中心化的架構下，沒有中心化的EBS/API閘道器情況下，所有流量下沉到了各個微服務中去了，需要在為服務端增加一個邊車代理，透過邊車代理來做流量的攔截，同時實現對流量的管控和服務治理。
• 不可變基礎設施：當傳統環境部署中，當有各類變更（應用程式、資料庫、中介軟體、基礎設施等）發生時，往往可以直接修改配置來實現。但云原生強調任何應用當你部署到生產環境中形成一個例項（容器/虛機）後，這個例項不能發生任何變更。當發生了變更修改時，應該基於映象生成一個新的例項，同時銷燬舊的例項。
• 宣告式API：與命令式API操作相對應的概念。傳統環境的後端操作（比如建立一個容器例項）會去執行命令列，來完成操作動作（這種方式對小規模應用而言比較有效，但大規模和自動化而言，就非常低效）。而對於宣告式API而言，需要透過定義宣告配置檔案（比如：YAML檔案），來宣告清楚所要做的動作、以及做完後需要達到的狀態。只需要完成這個宣告式的配置檔案，底層平臺再去解釋這個宣告式API配置檔案的內容，再去做後端的操作，同時把各個底層的技術元件協調到需要的狀態。宣告式API下面，任何對生產環境、對軟體的修改都不是直接去操作一個命令來完成，都是先要寫宣告、寫配置，這個配置檔案可以納入配置管理中集中去做管控和管理的。這樣既可以大規模、自動化去執行變更和管理任務，也可以當生產環境出問題時，可以快速去追溯對生產環境做過什麼樣的操作，方便做相關的回退和回滾操作。

金融機構採用雲原生技術，並不是將應用上公有云，而是將金融對安全合規、交易強一致性、單元化擴充套件、容災多活、全鏈路業務風險管理、運維管理等各方面行業要求與雲原生技術進行深度融合，發展為一套既符合金融行業標準和要求、又具備雲原生技術優勢的“金融級雲原生架構”。

金融級雲原生能將過去在應用架構層做的大量工作，尤其是彈性與韌性、可靠性、自動化等，下沉到技術架構去實現，讓應用只需要關注業務邏輯本身。所以，我們有理由相信，銀行的主流技術架構將從以IOE為核心的集中式架構向金融級雲原生架構演進。未來金融機構基於雲原生的應用，將天然具備彈性與韌性。

3.2銀行核心系統轉型能力需求

“總有人問我未來十年，會有什麼樣的變化，但很少人問我，未來十年，什麼事不變的。我認為第二個問題比第一個問題更重要。因為你要把戰略建立在不變的事物上。”— 傑夫-貝索斯

透過前文的分析，不論未來金融的服務形態如何演變，我們看到，對“靈活性、易擴充套件、高併發、標準化元件、低成本、可靠的線上服務”的追求是金融核心的“不變”所在。所以需要將核心戰略聚焦在這個“不變”上面。我們從業務、工程和技術的角度，總結了雲原生分散式核心應該具備“不變”的能力需求；針對每一項能力需求，進行詳細拆解為十二項支撐能力；對十二項支撐能力進行歸納分層，形成建議的雲原生分散式核心建設過程中的五層十二大能力體系，如下圖所示：

針對核心系統建設過中的困惑、業務轉型對核心系統的要求，本節從業務、工程和技術能力三個方面分別進行回答。

3.2.1業務能力

業務敏捷

Q：如何提供滿足金融業務新方向的核心繫統？

A:可標準化的構件式核心系統、可靈活組裝的核心繫統和可泛化設計的核心繫統，需要核心系統擁有完備的業務元件，可以透過快速配置滿足不同型別客戶、不同場景的業務需求。

Q: 核心下移雲原生分散式轉型工程龐大環節眾多，沒有一家公司能夠全方面覆蓋，還採取傳統專案的多家供應商整合工作模式，如何保證真正實現雲原生分散式核心而不是新瓶裝舊酒，換湯不換藥？

A：雲原生分散式核心建設不僅僅是透過雲原生技術對核心系統進行重寫，滿足自研可控和容量效能的需求；更重要的是從業務價值的角度對核心系統進行重新規劃，形成全行企業級可複用的業務中臺能力和快速創新能力，支援業務敏捷。

3.2.2工程能力

質量、工期、風險可控

Q: 如何確保核心安全可靠的完成雲原生分散式轉型？

A:從專案組織管理的角度來看：建議核心系統建設工程是一把手工程，不僅是技術創新突破，還可以透過業務架構和應用架構變革帶來組織架構的變化；所以，整個核心系統建設需要業務部門充分參與而非科技部門自嗨。從工程過程的角度來看：研發過程中，各廠商應基於行內統一的技術體系和應用元件、標準的實施工藝，開發核心系統涉及的眾多應用；在系統遷移切換時，可採用不停機線上遷移模式，實現新老核心的平穩、有序過渡。

Q: 傳統廠商懂業務應用但是不懂雲原生和分散式，懂雲原生分散式的不懂銀行業務，如何推進？

A：建議在雲原生分散式核心系統建設初期，透過一個輕量級諮詢專案，藉助一批有云原生分散式核心落地經驗的專家，結合金融機構自身業務特點，繪製核心系統藍圖；並基於選定的技術架構和應用架構，選擇典型交易場景進行原型驗證，確保架構層面滿足核心系統需求。

持續治理

Q: 核心雲原生分散式轉型一定是一個過程，在這個過程中如何快速整合不同技術體系構建的應用系統？

A:核心系統雲原生分散式轉型過程中，會涉及到多種型別系統的整合：雲原生分散式核心與老核心、已有其他系統（渠道等）的整合；同時，從我們在多家行的實踐來看，與雲原生分散式核心整合的系統通常存在多種技術棧（Spring Cloud、Dubbo等）。建議使用服務網格(ServiceMesh)進行系統間整合，在充分發揮其多技術棧整合能力的同時，還能享受服務治理的紅利。

3.2.3技術能力

Q：核心雲原生分散式轉型的技術難點或者挑戰主要有那些?

A：核心雲原生分散式轉型過程中，技術難點通常集中在非功能需求方面，例如分散式架構下大量微服務呼叫帶來的效能問題、分散式事務帶來的一致性問題、硬體採用PC機帶來的穩定性問題等，以及大規模分散式叢集下如何進行系統運維的問題。因此，需要有一套經過磨合驗證、滿足核心系統研發和執行時需求的IaaS和PaaS平臺，結合雲原生分散式核心設計、研發過程中的最佳實踐，才能從容應對轉型過程中的各種挑戰。

高效能、無限容量

Q: 核心雲原生分散式轉型對於分散式資料庫的考慮有那些，尤其是對分散式事務處理？

A: 分散式資料庫應具備以下幾方面的能力，降低核心系統研發和運維的複雜度：內建分散式事務引擎、透明可擴充套件、極致的高可用、同城容災RPO為零。

安全穩定執行

Q: 核心雲原生分散式轉型，傳統主機或虛機與雲之間的關係，二種模式的混合運維給生產中心帶來哪些挑戰？

A: 建議透過統一管理及自動化運維能力，使用單一平臺對多種雲資源（包括傳統主機、虛擬機器）進行靈活的管理、編排與部署。同時，針對雲原生分散式核心系統的運維，面臨著應用叢集規模龐大、交易鏈路節點變多、PC伺服器穩定性等多方面的挑戰，可參考網際網路企業在高可用運維和容災等方面的經驗，建設面向風險管理的SRE運維體系。

自研可控

Q：將雲原生分散式核心納入自研可控體系，如何做到風險可控？

A:建議採用自研可控單元化架構，在單元化架構下設定一個獨立的自研可控單元（採用符合自研可控要求的軟硬體）；基於單元化流量調撥能力，先小流量驗證自研可控單元能力後，再逐步增加流量到自研可控單元，穩步實現自研可控轉型，做到風險可控。

3.3支撐核心轉型的五層十二大能力體系

上一節回答了雲原生分散式核心建設過程中需具備的能力，本節將針對提出的五層十二大能力體系進行詳細的闡述。

3.3.1業務領域建模

為了使IT系統完整的承接業務需求，雲原生領域建模是運用領域建模思想，充分考慮雲原生應用的特點，使用領域建模及管理平臺，把建模變得簡單、敏捷、易落地，並透過平臺實現建模資產的保鮮。具體來說，雲原生領域建模透過抓住建模本質，簡化建模過程；採用建模平臺，管理模型資產；運用低程式碼技術，落地模型資產。

業務領域建模應關注以下幾個方面：

• 基於銀行同業已有建模實踐成果敏捷建模，而非投入大量資源且週期長的建模過程；
• 透過建模平臺實現成果保鮮，持續為業務迭代和創新服務，而非核心繫統建設完成之後束之高閣，逐步與系統演進結果脫節；
• 建模成果能夠藉助建模平臺、結合雲原生技術快速落地。

3.3.1.1業務建模與技術建模

業務領域建模包括業務建模和技術建模，整體建模流程圖如下：

1.業務建模包括業務流程建模和業務物件建模：

• 業務流程建模：透過對業務流程現狀分析，結合目標核心系統建設能力要求，參考行業建模成果，形成結構化的業務流程模型；
• 業務物件建模：基於資訊模型資產，結合對業務流程提取的業務實體，進一步分析實體間關係，獲得業務物件模型和業務行為模型。

2.技術建模是為了對業務模型進行落地實現，把上述業務模型轉換為技術模型。透過技術建模，實現三個模型的轉換：

• 業務流程模型到服務流程組合的轉換；
• 業務物件模型到邏輯/物理資料模型的轉化；
• 物件行為模型到API介面/原子服務的轉換。

3.3.1.2建模平臺

建模工具是支援業務領域建模的平臺，包括對領域模型、資料模型、中臺能力模型等的管理，提升建模設計效率並有效沉澱最佳實踐。

在建模平臺中，業務模型包含領域架構、業務模型、業務流程、交易模型、資訊模型五層，五層概念逐層縮小：

• 領域架構作為系統的整體架構，包含系統中所有的業務模型，把系統中的業務模型按架構圖的方式編排起來；
• 業務模型是由業務流程組成，是多條業務流程的集合；
• 業務流程串聯交易模型，形成業務流程圖；
• 交易模型中定義交易行為、交易的屬性及交易行為的輸入輸出；
• 資訊模型主用於定義九大資訊要素：參與者、產品、合約、賬戶、事件、條件、地理位置、資源項、渠道，理論上任何交易模型都是由九大資訊要素構成，在不能滿足時也支援新增新的資訊要素。

在建模平臺中，技術模型包含：微服務模型、流程模型、實體模型、資料模型。

• 微服務模型是利用雲原生特性，把業務流程中的步驟進行聚類分析，獲得相應的微服務模型；
• 流程模型承接業務建模中的業務流程，透過對業務流程中的功能進行細化分析，獲得實現業務功能的一個或多個具體介面，明確每個介面的輸入輸出欄位，分析出實現業務功能所需的實體及實體間關係，獲得實體模型；
• 需要持久化的實體模型，按資料庫設計的相關要求轉換為資料模型，通常情況下實體模型與資料模型是一對一或一對多關係。

透過上述步驟，最終得到技術模型中的微服務模型、流程模型、實體模型和資料模型。

3.3.2應用架構整合

應用架構整合層承接業務領域建模成果，將核心系統按照業務領域建模體系進行整體規劃，形成可供全行IT系統複用的業務中臺能力，提供生產各業務系統必須的業務元件；透過服務治理與組合的低程式碼能力，快速支撐業務創新；服務網格為傳統應用、遷移到雲原生分散式架構下的應用互通提供技術保障。

應用架構層面，雲原生分散式核心與傳統瘦核心或分散式核心重大區別是：

• 不是：簡單的將核心系統按照業務條線劃分為客戶、存款、貸款等應用，採用分散式技術重新實現一遍，很多公共的能力（例如產品管理、合約管理等）都需要各個應用重複建設，資料層面不互通；
• 而是：將核心系統按照業務領域建模體系進行整體規劃設計，形成可供全行IT系統複用的業務中臺能力，提供業務構件；透過服務運營與編排，使用業務構件快速進行業務創新。

3.3.2.1應用架構中臺化

1.雲原生分散式核心中臺化應用架構

透過多年自身金融業務實踐和實際參與銀行客戶核心系統轉型專案，基於標準化業務建模和技術建模成果，建議將使用者、產品、合約、額度、交易、賬戶、計價等金融服務的核心商業要素數字化、中臺化，構建出全行級中臺能力地圖，從而支援前臺業務的快速迭代。

雲原生分散式核心中臺化應用架構，可參考下圖：

2.強大、穩定的中臺元件

每一箇中臺元件的設計，都承接自業務領域建模成果，具備豐富的業務功能。為確保中臺元件集能支撐業務敏捷創新，中臺元件應具備如下能力：

• 功能豐富：經過核心系統實際使用驗證、具備能夠支撐產品系統的必備業務功能；
• 迭代穩定：作為企業級能力共享元件，被大量產品系統複用，需要能夠保持穩定、清晰的迭代升級路徑；
• 非功能特性卓越：具備優秀的效能和可用性，為整個產品系統的效能和業務連續性提供保障。

3.3.2.2服務治理與組合

金融行業通常採用了分層、分域的IT架構，每一個層、每個域都提供了大量的服務。

架構轉型的過程中，透過服務統一治理和運營，在技術層面支撐研發過程、確保安全生產執行；在業務層面透過金融業務中臺提供服務複用能力，高效進行流程組裝，支援業務敏捷、快速響應市場需求。

1.服務治理保障生產穩定執行

透過架構分層、能力域、系統、應用、服務等多級領域模型，全面梳理軟體資產，建立服務目錄，提升服務複用率；提供服務的全生命週期管理，覆蓋事前、事中、事後環節，支援服務保鮮，建立服務反饋和最佳化閉環。

2.服務運營編排，支撐業務敏捷、快速創新

服務組合方面，透過業務中臺提供的可複用原子金融服務使用視覺化服務編排能力，實現低程式碼快速開發業務場景，縮減研發週期，提高產研效率，降低投產風險。

服務編排平臺內建流程模型驅動業務開發，透過編排、執行兩大核心能力取代研發過程中部分枯燥而重複的工作；同時，我們認為平臺應該深度整合中介軟體，提供一個完整的金融級服務編排解決方案。服務編排能力大圖如下：

3.3.2.3異構應用整合

1.傳統微服務、ServiceMesh和傳統單體應用整合需求

在向雲原生架構轉型的過程中，傳統單體應用也面臨著遷移雲原生分散式轉型的挑戰；同時，兩種微服務架構（傳統SDK微服務和Sidecar模式）並存已經是一個不可迴避的現實問題。如何打通諸多異構應用系統，實現全面雲原生分散式轉型，需要有一套強大的技術支撐體系。

2. 基於服務網格(ServiceMesh)實現異構系統整合

在雲原生架構下，服務網格可以輕鬆應對異構系統整合的問題。透過服務網格平臺，提供與平臺無關、語言無關、輕量無侵入的雲原生架構整合與治理能力：相容 Kubernetes和 Istio生態、支援傳統SDK模式微服務框架的服務治理；支援物理機、虛擬機器場景，相容過渡階段的容器化和虛擬化混合部署的場景，滿足傳統單體應用向Service Mesh轉型的需求。

3.3.3應用系統建設

應用系統建設層提供標準化生產線，遮蔽複雜的雲原生技術細節，規範雲原生應用開發標準。

應用系統建設層面，應重點考慮以下幾方面：

• 統一ISV（獨立軟體開發供應商）開發技術棧，避免技術管理失控，降低系統執行風險；
• 統一、易用的開發平臺與框架，簡化和規範化應用開發；
• 全流程覆蓋的DevOps體系，涵蓋需求結構化管理、程式碼版本與分支管理、質量管控與度量，自動化編譯打包與部署等方方面面。

3.3.3.1統一開發體系

1.複雜的雲原生技術細節和難以管理的ISV（獨立軟體開發供應商）多技術棧應用

在雲原生體系下，應用開發所採用的技術架構，涉及到數量龐大、使用複雜的技術元件，如何讓技術服務於應用開發而不是成為障礙和故障點，是一個必須回答的問題；同時，採購了大量獨立軟體供應商（ISV）的應用，不同ISV使用了不同微服務框架、註冊中心、訊息中介軟體、事務中介軟體等中介軟體，實際造成行裡的開發技術棧不統一，提高了開發人員的學習成本，同時也增大了系統的運維難度。

2.簡化、標準化和規範化應用開發

透過雲原生應用開發框架，提供從金融級應用、元件到工具類包等多層次的開發支援，從而提升研發效能、保障研發質量。這裡面應該主要包括：

• 透過腳手架，快速建立規範化、標準化、金融級的應用開發工程；
• 透過元件模板，生成符合不同金融場景的元件使用模板程式碼，確保使用的正確性和規範性；
• 在工具類包層面，提供全面的金融級工具類，避免安全隱患。

在應用層面，透過腳手架可以快速建立規範化、標準化、金融級的應用開發工程。工程基於應用模板（靈活可定製）建立，目錄結構和應用分層標準化，整合金融級中介軟體和架構規範（日誌、錯誤碼等規範）；

在元件層面，可生成符合不同金融場景的元件使用模板程式碼，確保使用的正確性和規範性。以金融IT開發中備受關注的分散式事務元件為例，可以基於不同業務場景選擇合適的事務模型，生成標準化程式碼模板，開發人員只需要關注業務邏輯實現即可；

在工具類包層面，提供全面的金融級工具類（例如金融日期操作類、金額操作類等），避免安全隱患。

3.3.3.2開發運維一體化

1.雲原生分散式核心對研發、運維釋出的挑戰

從傳統核心到雲原生分散式核心，不僅僅是系統本身的架構進行了重塑與變化，更是在團隊、度量、流程、規範、質量、工具、時效等層面都提出了更高的要求。有以下幾方面的挑戰需要去應對：

• 需求結構化與變更管理：業務需求條目化之後儲存，需求變更影響分析、程式碼修改與測試用例變更整個過程形成閉環管理；
• 程式碼版本、分支的管理策略：面對不同上線週期的需求，如何設定程式碼分支、如何進行合併管理，需要有成熟的指引與配套工具；
• 程式碼質量管控與度量：面對不同合作伙伴、不同能力層級的開發人員產出的程式碼，需要做到程式碼質量可度量並得到有效的管控；
• 自動化編譯、打包與部署：眾多微服務應用、多環境和大規模部署叢集，手工構建與釋出已經完全不具備可行性，必須有配套的工具支撐。

2.開發運維一體化支撐高效研發與運維釋出

開發運維一體化平臺，覆蓋從專案協同、程式碼管理到持續整合、持續釋出等階段全流程管理，避免多入口和流程割裂，實現規範、標準的快速落地，提供從研發到釋出的全鏈路數字化管理，確保核心系統的研發效能和高效可靠釋出。

開發運維一體化平臺我們認為應該具備以下幾方面的能力：

• 專案協同：提供對需求、迭代、缺陷等各個維度的協同管理以及相關的統計報告，讓研發團隊高效協作；
• 程式碼管理：提供程式碼託管、評審和掃描、質量檢測等功能，保護企業程式碼資產，實現安全、穩定高效的研發生產；
• 測試管理：標準化管理測試用例，快速搭建一體化（開發、測試、反饋）流程，有效提升交付效率和治理；
• 持續整合、釋出流水線：提供靈活可用的持續整合、持續驗證、持續釋出功能，幫助企業高質量、高效率的交付業務；
• 製品倉庫：提供多種軟體包管理工具的企業級私有倉庫服務，支撐企業級依賴託管。
• 知識庫：透過可協作的結構化文件，將知識沉澱下來，並在團隊中有效流動，提升企業創造力。

3.3.4基礎軟體設施

基礎軟體設施層面，提供在苛刻的金融場景中久經考驗的基礎軟體設施和架構體系，涵蓋從執行時和運維時所需要的各項能力，包括異地多活單元化架構能力、分散式服務能力、分散式資料庫、高可用運維能力。

基礎軟體設施層面，應關注以下幾點：

• 採用充分磨合與驗證、功能完備（如單元化支援）的中介軟體體系，而非在應用系統開發階段還需要不斷修修補補、甚至進行架構妥協的中介軟體體系；
• 滿足自研可控與容災需求的分散式資料庫，容災情況能夠真正做到可切換、敢切換；
• 異地多活單元化能力，不只是架構設計，還需要中介軟體、資料庫和運維體系都具備必需的單元化支撐能力。

3.3.4.1分散式服務能力

作為支撐雲原生分散式核心應用分散式、微服務化的基礎能力，分散式服務能力應該涵蓋：同步呼叫的雙模微服務、非同步解耦的訊息佇列服務、支撐批次作業的任務排程和API閘道器。

1.高效能的雙模微服務體系，滿足聯機交易場景需求

雙模微服務體系，支援傳統SDK服務框架和ServiceMesh兩種模式的微服務體系。核心系統對雙模微服務體系，有以下具體的能力需求：

• 高效能：核心的一個交易可能涉及到多次服務呼叫，服務框架必須高效能以避擴音高服務響應時間；
• 可擴充套件：擴充套件性包括多個方面，例如：每家銀行內部通訊協議各有不同，強大的擴充套件性是服務框架適配行內需求的重要考量；
• 企業級的服務註冊中心：具備支撐海量服務註冊發現的能力，從而實現銀行內部真正服務打通；
• 服務治理能力：在具備限流、熔斷、服務訪問控制等動態服務質量治理能力的同時，具備與靜態服務治理打通的能力，從而形成服務動靜結合、全生命週期的管理；
• 高效能的服務鏈路跟蹤：支援抽樣的高效能跟蹤能力，為分散式環境下的問題排查提供必需的基礎能力。

2.高可靠的訊息佇列服務，滿足非同步解耦需求，提升交易響應時間

雲原生分散式核心系統中，透過訊息佇列可以將很多業務功能從聯機交易中解耦，在提升聯機交易效能的同時，也為業務的擴充套件性提供了可能。

例如：存款賬戶餘額變動通知，可以透過非同步訊息傳送給不同的系統進行消費，從而實現多種型別的業務功能（簡訊/微信通知、頭寸即時計算等）；交易核算分離也可以透過非同步訊息做到準即時的核算。

雲原生分散式核心系統中，訊息佇列應做到訊息不丟、確保能夠被消費成功。

同時，事務訊息機制是訊息佇列應該提供的能力；無需核心應用再建立一套訊息傳送表，來實現訊息的可靠傳送。

3.高效能、高可用的排程框架，支撐核心系統大量的批處理作業

核心系統有大量的批處理作業，包括基於檔案的批處理（如代發工資）和週期性執行的批處理（如存款結息、計提等）。

在分散式架構下，批處理排程框架具備兩個層面的能力，提升處理效能：

• 應用分散式架構的排程、協同：統一排程、協調分散式下的批處理應用叢集，充分利用分散式算力、提升批處理執行效率、降低處理時間，為日終作業鏈加速，留出更充分的時間給大資料處理等系統；
• 資料分散式架構的作業拆分與事務控制：資料分散式儲存之後，一個作業中的資料按照合理的規則進行資料分包，以資料包為單位併發處理以提升執行效率，同時，要考慮分包策略對資料庫事務的影響。

同時，排程框架的高可用性也非常重要，完善的重試、斷點續作等自動化異常處理機制，可以大大降低運維人員的人工介入，在提升效率的同時避免人工干預帶來新的風險。

4.多種模式、高效能和保障一致性的分散式事務元件

核心應用服務的分散式化和資料分散式儲存，必然會引入分散式事務。分散式事務元件具有以下能力：

• 多種事務模式：支援TCC、SAGA等多種分散式事務實現模式；支援跨服務、跨資料庫的分散式事務需求；
• 異常處理能力：支援空回滾、防懸掛等能力，完善的異常處理機制，包括掛起事務、異常事務的重試、監控與告警等處理。

5..高效能、多協議且具備靈活路由規則的API閘道器

在部分銀行的實踐中，雲原生分散式核心在銀行整體IT架構中對外還是一個完整的系統。在這種架構下，核心系統可以透過API閘道器作為對外服務門戶，實現服務治理、協議轉換等統一的處理；同時，在單元化架構下，基於API閘道器進行服務路由分發，是單元化必備的能力。

對於API閘道器，需要具備如下幾方面的特點：

• 高效能：作為每個對外服務都經過的鏈路節點，高效能是API閘道器最基礎的要求；
• 支援多協議和協議轉換：支援常見RPC協議（Dubbo、HTTP等）和行內特色通訊協議的自動轉換能力；
• 靈活的路由規則配置：支援自定義擴充套件路由策略，從而可以快捷的實現單元化路由功能；
• 服務治理能力：在閘道器層提供熔斷、限流、降級、訪問控制等治理能力。

3.3.4.2分散式資料能力

分散式資料能力有三種不同的架構模式：分散式資料庫、傳統關係型資料庫+分散式資料中介軟體體系、分散式資料庫+分散式資料訪問中介軟體。

這三種模式中，推薦採用“分散式資料庫+分散式資料訪問中介軟體”模式配合單元化架構，在充分發揮分散式資料相關優勢（容災、自研可控、彈性）的同時，又能享受單元化架構帶來的紅利。

1.分散式資料庫

應用於金融核心系統的分散式資料庫，必須在核心金融場景中穩定執行、經過嚴格的驗證。分散式資料庫應具備以下幾方面的能力，降低核心系統研發和運維難度：

• 分散式事務引擎：內建成熟的分散式事務引擎，嚴格支援事務的ACID屬性；
• 透明可擴充套件：支援對應用透明的線上平滑擴縮容，提供不受限的資料容量和處理能力；
• 極致的高可用：作為核心系統資料庫，需要有完備的高可用架構和高可用等級；
• 同城容災RPO為零：確保同城容災可切換、敢切換；
• 滿足自研可控需求：國內自主智慧財產權的資料庫，安全可控。

2.傳統關係型資料庫+分散式資料中介軟體體系

基於傳統關係型資料庫和分散式資料中介軟體，也可以實現資料分散式儲存與訪問能力。該模式下，分散式資料中介軟體體系需要包含以下元件：

• 分散式資料訪問元件：支援對應用程式碼透明的分庫分表、讀寫分離和全表掃描，能夠生成全域性唯一序列號，可以實現平滑擴容；
• 資料同步元件：實現資料變更的準即時處理。通常用於資料多副本同步、分庫分表資料匯聚、分散式快取更新等場景。

3.分散式資料庫+分散式資料訪問中介軟體

在單元化架構下，通常採用這種模式。分散式資料庫基於業務資料某個維度切分為多個叢集部署，每個叢集相互獨立；資料訪問中介軟體提供對應用透明的叢集選擇能力。

3.3.4.3高可用運維能力

1.核心系統轉型中帶來的運維挑戰

核心系統在雲原生分散式轉型過程中，運維同樣也面臨了一系列新的挑戰，其中最為主要的幾個挑戰有：

• 隨著核心系統進行微服務應用拆分，原有運維管理的應用從個位數增長為數十甚至上百個；
• 核心應用微服務拆分後，交易鏈路需要跨多個微服務應用完成，對業務監控和定位提出了挑戰；
• 以往核心系統主要採用被動運維方式，即出現故障然後定位故障和處置故障，而隨著業務的不斷發展，核心系統也面臨網際網路流量、業務快速上線等衝擊，為應對多方衝擊需要從被動運維轉向主動運維；
• 技術的進步也驅動了核心系統容災的升級，同城容災切換RPO=0也成為新核心建設的目標，既滿足合規要求，也極大的減少了業務損失；
• 此外還有諸如混沌工程，AIOps等智慧化運維工具的優勢也在逐步應用到核心系統運維中。

2.四位一體的高可用運維保障體系

核心在雲原生分散式轉型的同時，構建與之對應的高可用運維保障體系顯得尤為必要。總體來說，高可用運維保障體系需包括系統安全、資金安全、高可用能力以及成本容量管理四大部分，如下圖所示：

• 資金安全：發現資金損失的風險。透過執行核對規則，以小時為頻率、準即時等多種時效策略，發現資金類資料問題，向用戶告警；使用者可以第一時間收到告警，根據異常資料排查問題，分析原因，進而解決問題；
• 系統安全：透過IaaS層安全系統和安全攻防演練，確保基礎設施層面的安全；基於應用安全體系、資料隔離和安全掃碼，確保應用層面的安全；
• 高可用能力：高可用能力包括風險預防能力和應急處置能力。一是透過高可用巡檢能力和應急演練能力建設加強高可用風險預防能力；二是透過監控能力，故障定位能力，應急預案能力建設和打通加強應急處置能力；
• 成本容量管理：透過全鏈路壓測來提升系統和業務真實水位測試能力，以此為基礎去打通資源管理平臺和容量管理平臺。在保障業務容量穩定的前提下實現容量管理自動化，快速進行容量調撥。

3.3.4.4異地多活單元化

異地多活是分散式系統的一種高可用部署架構，可以滿足金融機構城市級容災的需求。實現異地多活架構的關鍵問題是如何處理跨地域的網路延遲影響，而單元化架構為異地多活架構的實現提供了可行路徑。

所謂單元，是指一個能完成所有業務操作的自包含集合，在這個集合中包含了所有業務所需的所有服務，以及分配給這個單元的資料。

單元化架構就是把單元作為部署的基本單位，在所有機房中部署數個單元，每個機房裡的單元數目不定，每一個單元都部署了系統所需的所有應用，資料則是全量資料按照某種維度劃分後的一部分。

透過採用單元化架構，在容災、彈性、資源利用率和灰度釋出方面都將有顯著收益：

• 容災與業務連續性：支援同城和異地容災模式，RPO=0，RTO很短；單元化多活，縮小故障影響範圍；藉助自動化容災平臺，可支援容災預案和便捷的容災演練；
• 彈性：異地多活提升擴充套件性，理論上無限擴充套件；按照單元靈活部署，提升擴容效率；
• 資源利用率：相對傳統兩地三中心部署架構，單元化架構能夠充分利用各個資料中心資源，顯著提升資源利用率；
• 灰度：靈活的流量調撥能力，支援單元級灰度釋出；新老單元呼叫隔離，避免交叉訪問相容性，提升釋出效率。

單元化架構的核心原則是單元內流量封閉，這樣將同一筆業務處理的上下游鏈路均在同一個單元內完成，避免了中間跨地域呼叫的網路延遲。為了實現單元化架構，需要圍繞兩個方面來設計系統能力，一方面是資料分割槽，另一方面是交易路由：

• 資料分割槽：對於資料的儲存至少需要具備兩項能力。其一是資料分割槽拆分，即是把資料按照某一個維度水平劃分開來；其二就是系統業務資料分割槽所用的拆分維度和拆分規則都保持一樣，確保同一條交易在整個鏈路中各個業務系統的資料分割槽是一致的，避免出現因拆分規則不一致導致的跨單元訪問；
• 交易路由：一筆交易鏈路中能夠按照預先設計的單元流量規則進行流量的路由和轉發。

1.經典單元化

採用中介軟體來實現單元化的方案，在頭部網際網路公司和一些大中型金融機構獲得了廣泛實踐，並且獲得了廣泛的技術收益，我們稱之為“經典單元化”架構。

經典單元化架構對中介軟體、資料分割槽和運維體系都提出了相應的能力要求：

• 中介軟體能力要求：各中介軟體（API閘道器、服務框架、訊息佇列等）整合單元化路由能力，並且能夠透過全域性的動態配置中心即時修改並準確推送路由規則到各中介軟體，實現單元化的切流。例如：API閘道器能夠根據路由規則選擇合適的單元進行呼叫分發；服務框架能夠根據路由規則進行服務提供者路由、訊息佇列能夠根據路由規則進行訊息跨單元投遞
• 資料分割槽能力要求：資料按同一維度水平拆分；資料分片按地域部署，各資料分片在同城和異地均有副本，資料庫分片主備副本可隨時切換；非容錯場景各機房應用只訪問本單元資料分片，容災場景可直接訪問同城的資料分片；
• 運維體系能力要求：支援單元化架構下的監控、容災切換、應急預案等能力。

2.動態單元化

經典單元化架構中，對應用資料分割槽和中介軟體能力建設提出了很高的要求，系統建設成本較高、實施週期較長。

伴隨技術的演進，分散式資料庫、服務網格技術逐步成熟，並已在頭部網際網路企業獲得了廣泛應用，這些新技術應用也為單元化架構的實現帶來了新的思路。

仍然從單元化架構落地需要具備的兩項能力出發，資料分割槽和交易路由：

• 分散式資料線上分割槽調整與擴容能力：傳統實現資料分割槽的方式是資料結構上增強拆分鍵用於分庫分表後的資料訪問路由。這種方式一旦投產後資料拆分規則就不能隨意進行調整，如迫不得已必須調整，則要進行資料拆分的重新分佈遷移，對業務連續性會有較大的影響。分散式資料庫依靠自身的分割槽技術可以實現對應用相對透明的資料擴充套件能力；支援線上分割槽調整的能力則對單元化架構下實現資料分割槽的線上調整提供了可行性；
• 服務網格統一管理路由規則能力：服務網格技術是將中介軟體等能力下沉，實現原有各中介軟體的功能。同樣，對於單元化的路由，也可以下沉到服務網格統一處理，減少單元化架構落地實施時對各中介軟體的能力需求。
• 透過服務網格加分散式資料庫的單元化方案，因為可以根據業務需求而動態的調整分割槽和路由規則，所以我們稱之為“動態單元化”方案。

3.3.5基礎資源設施

基礎設施層具有高度開放性和彈性擴充套件能力，可以靈活適配、穩定管理不同型別的基礎設施，為核心系統的自主掌控和降本增效提供無限可能。

雲原生架構下的基礎資源設施層面，應重點考慮以下幾方面：

• IaaS層能夠真正做到按需快速交付，避免複雜又漫長的申請、審批和採購流程；
• 安全、穩妥的推進自研可控能力建設，確保核心系統的業務連續性。

3.3.5.1彈性擴充套件能力

採用雲原生架構的IaaS層，實現雲原生分散式核心系統按需獲得IT資源、保持業務持續性的需求。

透過基礎設施雲化，實現資源打通，透過彈性擴容，使得成本、效能及穩定性達到最優。

IaaS層應具備以下幾方面的特徵：

• 軟體定義平臺，遮蔽底層硬體差異，資源可根據需求進行橫向或縱向的擴充套件，對上層應用無感知；
• 生產級的可靠性及安全合規，保證金融機構資料的連續性和安全性；
• 統一管理入口，對不同人員的角色進行許可權隔離，便於使用者運維管裡。

3.3.5.2自研可控能力

核心系統作為銀行最關鍵的業務系統，逐步落地自研可控的資訊科技體系成為必然的發展方向。然而，在落地層面存在以下幾方面的難點：

1.核心系統的自研可控涉及技術面較廣，包括應用、中介軟體、資料庫、雲軟體/虛擬化軟體、各類硬體設施；

2.核心系統在落地自研可控的同時仍需保障高標準的可用性，不能因單個或部分替代導致技術水平降級；

3.不僅是中大型銀行，小型銀行也需要在科技人員規模較小的情況下對核心系統的開發和維護實現自研可控。

而透過多雲管理與一雲多芯能力、自研可控單元化架構體系，可以滿足銀行核心系統在自主掌控方面的需求。

1.多雲管理與一雲多芯

多雲管理和一雲多芯是解決基礎資源可管理、可替代的重要基礎。多雲管理使用單一控制器對多種雲資源（也可包括虛擬化環境）進行靈活的管理、編排、部署。一雲多芯則透過適配多種型別伺服器和伺服器晶片，遮蔽底層硬體的差異，實現統一的雲資源納管。

2. 自研可控單元化架構

單元化架構本身具備單元內應用封閉、業務自閉環、流量可調撥、可快速容災切換等良好的架構特性。特別適合使用到核心系統這種跨多層技術棧的自研可控場景，可透過分別構建傳統軟硬設施的單元和可替換軟硬設施的單元，併合理分配業務流量，當某個單元出現故障時也可快速把流量切換到另外一個單元，既可逐步落地自研可控，又滿足了業務連續性和技術水平不降級的要求。

3.4基於能力體系打造的金融級雲原生工場

基於上節對五層十二大能力的分析，我們認為需要一整套端到端的能力體系，能夠覆蓋從業務建模、架構設計到系統建設，再到系統執行和運維的全流程；同時，這套能力體系應具備明確的實施工藝和高度的自動化能力，從而形成可標準化、規模化與高效的工場化生產模式。

基於這套能力體系打造的核心繫統雲原生分散式轉型與建設模式，我們稱之為“金融級雲原生工場”模式。其中“雲原生分散式核心輕諮詢”與 “雙核心並行與不停機遷移”作為系統實施路徑的兩個階段，在下一章中進行闡述。

從生產過程與執行的視角來看，金融級雲原生工場整體上包含了以下幾方面的內容：

• 設計車間：業務領域建模是將業務需求轉化為IT能力的關鍵設計環節，充分考慮雲原生應用的特點，使用領域建模及管理平臺，把建模過程變得簡單、敏捷，建模成果易落地並持續保鮮；
• 原材料（功能完備的元件與聯結器）：核心引擎透過中臺化能力中心，承接業務領域建模成果，為生產業務系統提供功能完備的業務元件；服務治理與整合作為聯結器，整合各業務元件進行服務組合，支撐業務快速創新；服務網格作為聯結器整合多種技術棧的新老系統，為應用互聯互通提供保障能力；
• 標準化生產線：透過企業級應用開發和架構治理平臺、企業級一站式DevOps平臺，遮蔽複雜的雲原生技術細節，提供低程式碼編排生產能力，助力金融機構和合作夥伴（ISV）高效開發業務應用；
• 執行底座：堅實的技術底座，涵蓋充分磨合的PaaS、IaaS、單元化架構和高可用運維體系，為雲原生分散式核心的穩定執行奠定堅實的基礎；基於單元化架構和一雲多芯的自研可控能力，滿足金融機構自研可控需求。

四  實施路徑與建設模式

經過對國內一些金融機構的核心下移與改造的實施路徑和建設模式分析，可以基本上分為兩種建設模式：

1）核心自主重構模式

路線特點：

1.自主研發新核心系統，非採購ISV（獨立軟體開發供應商）核心系統產品，強調自研可控

2.大多數原有核心採用AS400或大機的銀行希望採用重構的方式完成核心下移

3.建設目標包括業務建模、領域架構重構

4.絕大多數銀行構建了全新的核心應用技術平臺

5.部分銀行選擇基於雲平臺進行核心系統重構

6.部分銀行在核心重構過程中包含自研可控規劃

7.核心開發實施過程會採購ISV（獨立軟體開發供應商）的人力資源

採用該路線的銀行範圍：國有大行、股份制、大農信、部分中大城商/農商

2）採購核心產品套件模式

路線特點：

1.採購ISV的核心繫統產品，並主要基於ISV的人力資源完成核心實施交付

2.主要訴求為替代原有第一代的老舊核心

3.基於ISV核心產品的業務模型和架構建設

4.基於ISV核心產品自帶的應用技術平臺

5.部分銀行要求ISV產品簡單部署在雲平臺上

自研可控方面，部分銀行僅能夠要求ISV產品整合國產資料庫

採用該路線的銀行範圍：部分中小城商/農商、民營銀行、外資銀行

4.1四階段五層模式

透過結合國內金融行業核心相關領域的實踐以及核心領域對於技術的雲原生分散式轉型的業務能力，工程能力，技術能力要求，橫縱結合形成4階段5層的建設模式和路徑：

透過這張圖我們可以清晰的認識到核心下移雲原生分散式轉型的路徑的全貌以及自身所處的不同階段。上圖中任務顏色的深淺代表在不同階段中任務的關鍵程度和優先順序，顏色更深的優先順序更高。且每一個階段的產出是下一個階段的輸入。從而形成一個系統化的完整的核心下移的頂層工作任務與路徑階段安排。

例如部分銀行採用重構模式，即業務架構和技術架構並行改造，以金融業的領域模型重構核心業務的同時配以主流的分散式架構支撐系統；也有部分銀行採用平遷模式，保持原有系統業務邏輯和流程不變，僅透過選用分散式資料庫來滿足底層海量資料要求。

4.2多種實施路徑

4.2.1重構模式

銀行核心系統的重構之旅，不僅僅只是網際網路技術改造，更是自身服務模式和服務思維的再造。從流程銀行轉向數字銀行，從產品為中心到客戶為中心，從做功能轉向做場景，從做渠道轉向做平臺。整體的實施路徑會從業務重構及核心應用技術平臺搭建兩大方向入手,進而實現核心銀行業務數字化轉型。

4.2.1.1業務重構

回顧“面對誤區的破局思維”的斷言6

斷言6：核心轉型相比選擇“供應商”而言，更為重要的是選擇具備“端到端落地實踐”的。從理念、方法論、設計規劃、平臺架構、標準規範都能夠戰略性長期投入和總體把控的“合作伙伴”才能真正落地實現業務敏捷和推動數字化轉型，而不是為一堆冠名“數字化轉型”的文件買單。

業務重構主要是根據業界領先的理論和最佳實踐建立企業級業務模型，進而基於模型逐層細化業務規劃並向產品引數化設計轉變。整個改造過程會以現狀業務流程、資料和產品實踐為基礎，以待實現的業務需求為輸入，以領域驅動設計思想為指導，形成具備模型驅動的核心業務架構體系。

傳統的建模方式注重在企業級架構規範的範疇，能夠以結構化的方式將戰略，業務連線起來，但是從實際的落地來說，並不是傳統建模方式關注的。以產品為例，結合領域分層的理念，下圖能夠比較清晰的表明企業級建模與系統架構設計兩者之前的差異。

同時傳統的領域建模需要耗費大量的人力和資源，通常週期比較長，並不是所有的金融企業都能夠參考建行的模式。往往全行級建模花費了數年的時間之後，整個格局，環境，戰略又發生了變化，導致與時代的錯配。在這個背景之下，敏捷，中臺化，領域化建模的理念開始逐步進入大家的視野。

核心系統領域化架構設計的原則

1.把核心系統開啟，對原有核心的業務能力重新進行領域劃分

2.把核心系統中的領域實體構建成微服務應用，實現核心服務能力的對外暴露，以及業務的松耦合

核心系統領域架構設計的進一步描述

1.將核心系統的通用領域提升到中臺能力層次：客戶中心、產品中心、合約中心

2.將核心系統的基礎功能放入基礎服務層，並構建成為對應的微服務應用：賬戶域、定價計價域，核算清算域、公共域、財務域等。

3.將核心系統中的各個業務產品放入產品服務層，各個業務產品的微服務包含了對中臺能力服務和基礎服務的流程編排組裝。

經過中臺化的重構之後，原有的業務流程建模和邏輯也會發生相應的改變，以定期支取為例，在經過中臺化的建模改造之後的流程變成如下的模式

4.2.1.2技術重構

回顧“面對誤區的破局思維”的斷言2、3、5

斷言2：“基礎不牢、地動山搖”，底層架構的高效穩定是第一目標。底層架構在起步階段從“統一架構”更加容易走穩，再逐步進行區域性最佳化和解耦。

斷言3：核心架構中“非功能性需求”考慮要大於“功能性需求”。“非功功能性需求”應由技術架構來承載。業務模組可以解耦設計和分包，技術架構要統一規劃和統一標準，實現核心領域的“統、分結合”。

斷言5：核心轉型最佳路徑是追求“P/PC平衡”– 產出和產能平衡。不僅僅是完成 “產出”任務（應用遷移），更為重要的是升級“產能”（技術架構能力）。“產能”（技術架構）升級後會推動更大的“產出”（業務價值），成為全行數字化轉型的助推引擎。

從這三個重要的判斷可以看到，核心雲原生分散式轉型需要一整套具備可伸縮、高可用的分散式金融技術平臺作為支撐，核心應用技術平臺的搭建整體包括DevOps平臺、分散式中介軟體平臺以及運維保障平臺三部分。其中DevOps平臺能提高核心應用開發上線的效率，主要包括有專案協作、程式碼託管、持續整合持續交付等；分散式中介軟體平臺提供核心應用分散式能力層，提供了兼備應用分散式和資料分散式能力；運維保障平臺主要承載核心業務系統高可用應急管理功能，提供支援容量管理、壓測管理及容災管理。

同時，技術重構由於涉及的方面太多，我們進一步的進行層次化的拆解與明確，定義了五層十二大能力體系，幫助金融機構進行相應的落地設計。

企業自身可能不太具備這樣的技術能力和相應匹配的團隊，需要藉助大量的外部資源與夥伴來完成整個理想中的藍圖。整體的價值，優勢的可獲得性相對比較低。我們建議在建設過程中配套匹配的工場，流水線，實施工藝等模式，降低整體的設計，開發，部署，運營，運維的難度。讓這些先進的技術真正可以落地，可以自主的掌控。建議增加中間框架體系與流水線體系，進一步降低落地難度，增加技術的可獲得性，讓終端的開發、運維等技術人員更容易上手，更容易使用。

4.2.2平行遷移模式

平遷模式實施的原則和前提是對業務不產生影響。業務流程不變、業務功能不變、應用處理邏輯不變、與外圍系統介面不變以及資料邏輯模型不變。

在這種模式下，主要解決的是國家一些指引的要求，同時解決集中式架構的非功能層面帶來的一些挑戰，例如效能、擴充套件性這些阻礙業務發展和損害客戶體驗的障礙。但從助力業務發展的視角來看，平遷模式是一個過渡性的中間狀態，從長遠來說，最終還是要解決業務敏捷帶來的挑戰。

從目前行業目前的實踐來看，目前具體有這麼幾種平行遷移形式

1）資料不動，應用下移

資料架構不動，應用按照一個一個模組進行下移和分散式改造，在過程中建立起全域性的註冊中心，基礎微服務框架體系，同時引入分散式中介軟體相關技術來支援交易路由、交易熔斷降級、安全中心、統一配置中心等功能。此外，為更好應對核心下移，運維體系需要相關改造完成相應日誌監控、鏈路追蹤和監控報警等功能。

這種模式的利：

資料體系和架構一般與業務和應用關聯度比較高，尤其經過長期的執行之後，資料體系非常複雜，牽一髮可能會動全身，迴歸測試等成本也會非常高。所以不動資料的模式相對比較簡單，業務人員的參與程度非常低。基本上技術可控，在過程中鍛鍊了技術人員的分散式，雲原生能力，鍛鍊了團隊。

這種模式的弊端：

沒有新的業務價值的過多體現，並且整體架構沒有太多變更，轉型不徹底，尤其是資料架構容易造成各種瓶頸，無論是對業務敏捷而言，還是效能角度而言。並且程式碼的自動化翻譯工具等體系無法很好的應對領域建模等中臺化要求，翻譯程式碼需要大量的效能最佳化與調整，採取這種模式的開發人員通常需要花費70%的經歷在程式碼的效能結構最佳化上，無暇應對新業務應用的開發。

2）應用不動，資料下移

為了靈活應對海量交易和超量資料的衝擊，需要使用分散式資料技術來解決資料一致性問題。這種核心下移和分散式改造模式多輔以少量人工完成主機核心應用程式改造，或者自身已經在x86虛擬機器等集中式架構下。透過介面改造與適配等來對接分散式資料庫體系。這種模式對於底層的分散式，雲原生資料庫的技術要求非常高。

這種模式的利：

底層的交易瓶頸比較容易解除，並且實現了分散式情況下的最大挑戰之一的資料一致性挑戰。

這種模式的弊端：

對於分散式資料庫的技術要求，成熟度要求太高，可供選擇的供應商不太多。同時從業務角度而言，沒有新的價值體現，也無法做到業務敏捷。

4.2.3 SaaS化批次模式

相比傳統集中式架構，雲原生分散式核心建設對技術積累、人員能力的要求也更高，相比有自研能力的大中型銀行，中小銀行新建核心除了依賴廠商的支援，也存在另一條新的路線，即金融核心SaaS。

基於雲原生架構研發的金融核心，經過實地落地驗證後逐步完善、標準化，最終走上SaaS化。對於銀行、尤其中小銀行研發資源有限的情況下，避免投入大量時間、資源做核心的下移或重構，利用SaaS產品提供的標準化元件、OpenAPI，採用低程式碼、服務編排快速實現業務敏捷，透過服務網格、Serverless等技術將非功能的需求下移，保障系統的高可用、可擴充套件、可灰度、可觀測。

選擇SaaS化的金融核心開拓了核心下移之旅的“批次模式”，也是面向雲原生未來的架構。

4.3 線上遷移與雙核心並行

4.3.1 面臨的並行挑戰

雲原生分散式核心建設一個關鍵必經之路就是如何在保障安全可控的基礎上完成新老核心的切換，金融機構出於人員、成本、風險等因素考慮，針對賬務核心部分往往會採用按模組、按機構分批遷移的策略，雲原生分散式核心建設進入到投產期將會存在雙核心並行。傳統方案中遷移動作需要在停業期間進行，對銀行提供服務的連續性造成影響。

金融機構對自身分散式技術平臺、運維體系以及核心應用的成熟度存在擔憂，傳統做法是在投產之前進行大量的功能測試、遷移演練、旁路驗證等，但這些均不能完全呈現生產環境實際執行情況。

另外，對核心實施人員來說專案週期長、壓力大，核心下移是持久戰、要打硬仗，但也需要有階段性成果進行激勵、給團隊信心。

4.3.2 雲原生分散式核心推薦遷移策略

在按模組、按機構分批次遷移的基礎上，將遷移顆粒度進一步縮小到按單客戶、單賬戶進行遷移，把遷移的風險控制在可接受的程度。同時，整個遷移過程全部即時線上完成，包括從舊核心的資料遷出、新核心的資料遷入、並保障資料一致性。整個核心遷移期間銀行不間斷對外提供服務、客戶無感知。

具體實施中遷移批次可以按照先內後外（銀行內部客戶到外部客戶）、先簡單後複雜（基於大資料分析客戶交易習慣）等策略進行安排。

4.3.3遷移平臺能力建設

要達到雙核心並行以及線上平滑遷移的效果，雲原生平臺需要具備如下關鍵能力：

1.全域性路由模組實現新老核心資料識別和路由轉發，新核心採用單元化架構的要同步考慮單元路由；

2.遷移管控平臺對資料遷出、轉換、遷入等遷移步驟進行統一排程，並且保障資料遷移一致性；

3.新老核心並行期對外提供服務保持一致，減少系統間整合的影響。

只有具備以上的能力要求才能到達客戶無感、不停機線上遷移和雙核心並行方案，支援核心系統從集中式架構平穩、有序過渡到雲原生架構。

基於該方案，金融架構將獲得兩方面的收益：

1.降低遷移實施風險：按客戶分批次遷移、試點，逐步驗證、排查與解決風險，最終完成新老核心切換。

2.提高業務連續性：線上遷移對客戶正常進行業務操作沒有影響；同時，技術上可以實現遷移不涉及到停業。

五  核心雲原生分散式轉型的價值與經驗教訓總結

愛它的人，總會讓它一次次重生，並賦予它更大的意義。

經過上述的探討，我們歸結出來核心轉型的一些價值，一些共識和通用的標準，結論如下，可以作為行業機構設計和實施的參考。

5.1 第三代雲原生分散式核心的價值體現

核心的雲原生分散式轉型，成為第三代雲原生分散式核心，有如下的一些價值方向:

1.自研可控，100%滿足相關的國家要求

2.運維成本降低400%

雲原生架構基於相對廉價的PC伺服器構建，在同等處理能力下，分散式架構的單位執行成本大幅度降低，分散式架構的年均執行維護成本是大型機的17%

3.業務敏捷，縮短40%以上的落地時間

雲原生，中臺化的模式降低業務模組間的強耦合性，業務交付更加敏捷，平均需求交付週期可以縮短40%左右，在進一步提升效率之後，可以達到數量級的效率提升

4.彈性擴充套件，完全線性

雲原生架構具備良好的橫向彈性擴充套件能力，較好的滿足中國特有的“春節高峰”時段的特殊要求以及每年超過20%以上的業務增長量的需求，同時在底層資源充足的情況下，能夠做到即時的線性擴容。

5.下一代的異地多活架構，RPO=0，RTO<1分鐘

基於雲原生的單元化異地多活架構，以及分散式中介軟體，分散式資料庫，雲原生分散式框架，可以構建超過三地五中心全活多活架構，具備城市級別災備能力，城市級別RPO=0，RTO分鐘級別RTO<1分鐘。

5.2 第三代雲原生分散式核心的關鍵標準

透過全篇的介紹，我們最後嘗試提出雲原生第三代核心的一些關鍵標準，這也是行業從業者的一些共識。而為了達成這些標準，我們必須轉換思路，打造能實現這些標準的自動化流水線工廠。

1.雲原生

雲原生是應用架構演進，整體降本增效的必然趨勢和要求

2.異地多活單元化

單元化是架構灰度，進行架構線上升級的關鍵企業級架構設計

3.中臺化

中臺化是實現業務敏捷，業務彈性，應對未知挑戰的關鍵要素

4.數字化

數字化是實現面向未來金融基礎設施的關鍵設計

5.自研可控

自研可控是實現金融安全的必要保障

而云原生工場模式，是將這些標準與規範融入至整個的標準化製造與加工流水線以及實施工藝的端到端體系化模式，助力金融機構的核心雲原生分散式轉型。

5.3 核心相關係統建設的經驗教訓總結

1.分離採購與建設模式的折扣

核心的下移不簡單是從主機等集中式環境換一個雲原生和分散式的平臺，傳統的應用是應用開發商去建設，技術平臺是技術平臺供應商去建設的分離模式從最終預期要達到的效果和價值來說，並不會很好。因為應用開發商對於雲原生底層技術平臺並沒有很深的瞭解，很多特性和優勢用不上，只能當虛擬機器或者普通的資料庫來使用，基本上無法發揮出雲原生的真正的價值。最終實現的業務價值會大打折扣。所以建議在整體建設之前，需要透過一個輕諮詢或者諮詢專案設計出整體的模式，架構，規劃，週期，預算等，為後期的建設做好統籌的設計，而不要盲目的開展建設專案。

2.承上啟下的困難與挑戰

核心等關鍵業務系統的雲原生分散式轉型，需要對於核心業務以及對於底層雲原生平臺都非常瞭解，才能夠真正實現高價值的核心雲原生分散式轉型。應用架構和資料架構，資料模型等關鍵要素需要匹配分散式的環境做適應性的改造和最佳化設計才能保證最終的效果。例如在雲化分散式環境下的賬戶與賬務資料模型的設計，例如在兩地三中心多活架構下的業務應用分域，以及客戶中心，產品合約的部署設計，例如在單元化模式下的單元區分規則，數不勝數。而這一點，往往很多傳統核心從業人員不太理解，認為應用業務與技術平臺無關，業務是業務，應用是應用，技術平臺是技術平臺。這三者的之間的隔閡，導致的業務無法敏捷，應用無法擴充套件。而我們急需的，便是運用工場流水線模式將這兩個鴻溝進行聯通，運用業務建模數字化平臺和工序將業務與應用有機貫穿以及同步，達成業務敏捷，運用架構治理與腳手架數字化平臺和工序，將應用和最終的開發運營運維體系有機貫穿與同步，達成應用敏捷以及安全可靠。實現最終的業務端到端敏捷。

3.效能等非功能性的忽視

從集中式架構的CA取向向雲原生平臺的擴充套件性取向進行下移和建設的時候，由於增加了很多的網路，RPC，分散式儲存等傳統集中式架構沒有的底層開銷，效能層面通常在早期的設計中沒有很好的考量和設計，而到最後的整體端到端效能壓力測試等時候才會爆發出來，無法滿足基本的併發與時延標準，達不到上線標準，然後重新進行各種調整，這個時候大的體系基本上已經建設完畢，無法做整體性最佳化，無法達到最優的效果。所以，建議在架構設計以及開發的早期，就要引入全鏈路測試與容量規劃的工具，早期識別關鍵鏈路以及關鍵設計的缺陷，為後期大規模應用建設排雷以及打好框架基礎。

4.技術風險與運營的挑戰

傳統集中式架構的運維保障通常由廠商和傳統的服務生態來保障，而到了雲原生分散式體系下，整體需要運維的技術棧和平臺的數量，整體架構的複雜程度遠超以前，此時需要更多的將運維保障的任務交給自動化的，體系化的技術風險防控體系來處理，這部分的設計和建設的經驗傳統廠商基本上比較難以具備，也沒有實際落地的經驗。這對於整體系統的可用性，穩定性等帶來很大的隱患和風險，這部分的提前的考量，設計與建設也需要在早期同步開展，因為SRE體系對於架構，應用開發等有一定的規範和要求，遵從這些最佳實踐，才能給最後的運維提供必要的支援，便利和保障，確保整體性的運維管控能夠做到實效，給生產系統穩定高效執行提供真正的高效保障。

5.系統建設實施的巴別塔

系統架構即組織架構，這裡的組織架構從傳統意義上大家理解是系統建設成之後，整體的內部開發，運維，管控的組織結構，權責邊界以及溝通交流等體系。但是從實際情況來看，新一代核心的建設週期往往都比較長，通常比較大型的金融機構建設週期都會在20個月以上，參與方眾多，大家往往會忽視這個長週期專案建設團隊自身的組織形式與管理模式。在雲原生分散式，中臺化，業務敏捷驅動的這種新的核心架構方式之上，整個核心專案組的組織形式，具體工作任務劃分的方式和邊界，溝通交流方式這些也會有變化。這部分目前如果還按照以前集中式架構的專案組織和開展形式來運作的話，可能會有比較大的資訊不對稱以及摩擦，影響整體的工程效率和最後落地的實際效果。因此我們也建議整個專案工程管理和溝通模式需要採用新的組織理念，採用數字化的工具體系來進行組織協調，更高效更高質量的完成實際落地交付上線。

最後，如果需要用幾句話來進行總結的話，那就是

“集中式架構，已經不止是一種技術架構模式，而成為一種根深蒂固的思維習慣和設計理念。當它成為潛規則而影響了創新時，我們往往身在此山中而不為所知。朝著雲原生分散式轉型的過程中，打破這種集中式架構的思維慣性和習慣（設計、開發、運維），這些才是最難改變的”

“從金融行業的角度而言，要實現核心的雲原生分散式轉型的關鍵在於打造一套新的雲原生數字化流水生產線、配套設計工藝以及穩固的雲原生分散式基礎設施，嘗試用綜合的視角去改變那些最難改變的部分”。

完整內容點選閱讀原文檢視！