分布式微服務系統架構第90集：現代化金融核心系統

#1.1 深化數字化轉型，核心面臨新挑戰

1、架構側：無法敏捷協同數字金融經營模式轉型。

2、需求側：業務需求傳導低效始終困擾金融機構。

3、開發側：創新產品上市速度低于期望。

4、運維側：傳統面向資源型監控體系難以支撐現代化核心。

5、監管側：對業務連續性導向趨嚴趨細。

6、成本側：單客核心的運營成本逐漸走高。

#1.2 重塑現代化核心，科技引領新趨勢

1、新理念：重構行業差異化競爭力的服務體系。

2、新架構：構建面向開放型金融的現代化泛核心。

3、新科技：加強多維數據服務與核心交易融合創新。

4、新運維：推動業務鏈路一體化運維體系建設。

5、新韌性：探索多地多活的業務連續性保障。

隨著系統可用性、故障影響半徑等業務連續性水平要求不斷提升，核心系統從經典的“兩地三中心、一主多備”向“多地多中心、多活多副本”架構演進，但跨中心事務、數據一致性管理，全局交易查詢，批量拆分聚合等問題依然是技術難點，需要持續探索解決方案并充分驗證，真正實現“令行即切、切即可用、用可持久”的保障目標。

6、新工藝：選擇企業架構建模最優之路。

#2.1 現代化金融核心建設目標

現代化金融核心系統的目標架構是一個集基礎設施現代化、技術架構現代化、數據架構與應用架構現代化、安全與合規性以及創新與靈活性于一體的綜合體系。這一體系旨在幫助金融機構實現業務的韌性智能、極致體驗、敏捷創新、降本增效、業務連續性、安全合規等需求，提升金融機構的競爭力和整體能力，為客戶提供更加安全、高效、便捷的金融服務。

2.1.1 業務架構

金融機構業務架構主要包括：

1、業務目標：明確業務的核心目標、愿景和戰略方向。

2、業務流程：詳細分析業務流程，包括關鍵活動、輸入輸出、參與者等。

3、業務規則：識別并理解業務運作中必須遵守的規則和約束。

4、組織結構：了解企業的組織結構，包括部門、角色和職責分配。

5、客戶與利益相關者：識別并分析客戶需求、期望以及利益相關者的關注點。

現代化核心系統作為金融機構各類業務賬務系統，需要滿足數字渠道生態層、數字產品/服務層、業務中臺層、數據中臺層、科技支撐層等各層需求，實現以下能力：

1、產品管理：建設參數管理平臺，通過參數模板、流程引擎、向導式跨業務部門流轉處理能夠擴展為全行級參數管理平臺。

2、產品創新：統一產品工廠行業最領先并落地實施，跨產品進行產品部件復用，通過產品工廠引擎快速組裝產品。3、差異化定價：通過規則引擎實現利率、費率、匯率、稅率的差異化設置，能夠通過新增浮動因子設置快速擴展影響定價的浮動維度。

4、清算模式：零級清算、多級清算等。

5、賬戶管理：靈活的賬戶結構，滿足銀行線上線下母虛子實、母實子虛、母實子實的多層賬戶管理要求。

6、核算分離：實現交易與核算完全分離，建設全行會計核算引擎，多賬套支持，實現全行賬務一致性保障。

7、敏捷能力：業務建模、AI輔助開發、高低代碼開發。

8、韌性可靠：高安全、高性能、高擴展、高可用/容災、易運維、平臺化、服務化等能力。

2.1.2 技術架構

在數字化轉型下，金融機構目標業務架構主要包括數字渠道生態層、數字產品/服務層、業務中臺層、數據中臺層、科技支撐層共五層。其中，數字產品/服務層包括創新業務域、產業金融域、金融市場域、中間業務域、基礎業務域等。業務中臺域包括數字用戶域、數字產品域、數字運營域、數字風控域、數字員工域、數字治理域等。數據中臺層包括數字服務域。科技支撐層包括數據中心、云平臺、開發平臺、測試平臺、智能運維等科技支撐與IT治理。

理解業務架構，技術架構應滿足業務系統運行的功能需求、非功能需求、數據需求以及AI需求，技術架構總體目標是韌性、可信、敏捷、智能，以平臺化、服務化、組件化等原則設計目標技術架構，共性能力沉淀到技術平臺，實現技術架構高安全、高性能、高擴展、高可用/容災、易運維等要求。隨著技術的進步，云計算、分布式、云原生、大數據、 AI等新技術已經在技術架構中普遍采用。

1、系統分層：將系統劃分為不同的邏輯層次，如業務應用層、技術平臺層、數據訪問層等。

2、組件劃分：根據功能需求，將系統進一步細分為可獨立開發、測試和維護的組件。

3、技術選型：根據業務需求和非功能需求，選擇微服務框架、數據庫、中間件、開發測試平臺等技術棧。

4、應用集成：定義組件之間、系統之間以及系統與外部系統之間的訪問模式。

5、數據架構：設計數據模型、數據流向、數據應用和存儲策略。

6、安全架構：考慮系統的安全需求，設計相應的安全機制等。

7、性能與可擴展性：設計系統以支持高并發、低延遲、高可用性和可擴展性。

8、數據中心容災：同城雙活、兩地三中心、多地多活等。

#2.2 現代化核心深化轉型十大挑戰

近年來，國內金融機構對于核心系統從集中式架構向分布式架構轉型已形成行業共識。基于開放硬件、云計算平臺、分布式數據庫和分布式技術中臺等產品構建分布式核心的技術架構逐漸成為主流選擇。

挑戰一：分布式架構下如何開展核心架構規劃

由于核心項目規模大、周期長、涉及業務面廣，金融機構在啟動新核心建設前通常會選擇開展核心架構咨詢項目，以梳理和明確新核心建設所需要的方方面面。相比上一代集中式核心，分布式核心的架構規劃范圍已明顯擴大，從業務架構、應用架構、數據架構、技術架構和項目實施方案擴展到分布式技術中臺架構、基礎設施架構和多活高可用架構。這些新增范圍通常不是傳統咨詢關注的重點，如何完成這些新內容的規劃設計以及由誰來做，是擺在新核心建設面前的第一個挑戰。

挑戰二：如何解答業務建模難題

是否開展業務建模是金融機構在開展新核心建設之前常常會探討的問題。業務建模具有成本高和周期長的特點，表面上看僅大型金融機構能夠承擔這樣的投入。但業務建模是新核心進行領域化微服務拆分的源頭，同時業務建模所包含的流程建模本身也是對業務流程的梳理和優化，即使是對于采購核心廠商產品的金融機構，業務建模也能夠提供較大的價值。因此如何能夠既享受到業務建模的好處，又合理的控制周期成本成為金融機構仍有待解答的難題。

挑戰三：如何解決核心廠商和云廠商的技術集成難題

分布式核心有別于過往集中式核心的瀑布開發流程，各家核心供應商也在同步構建自己的應用開發平臺，各自劃定了不同的范圍邊界，比如Z核心供應商的應用開發平臺除了應用開發功能之外還包含了中間件，甚至容器平臺，這就和云廠商提供的PaaS平臺形成了重疊。雖然看似提供了更多的選擇，但實則對于開展核心建設的金融機構來說反倒造成了很多困擾：如何合理劃分核心供應商應用開發平臺和云廠商PaaS平臺的邊界；如何在充分利用各自優勢的基礎上減少技術集成成本等。同時從行業上來看，能否形成有一條行業共識的邊界線，減少無謂的消耗勢在必行。

挑戰四：如何構建核心領域的分布式技術規范和最佳實踐

從傳統集中式核心轉型到分布式核心，中間件也從功能相對集中的CICS、 TUXEDO、MQ改變為功能更為專一的分布式中間件，比如注冊中心、RPC框架、分布式事務、分布式數據訪問等。金融機構建設新核心要根據自身情況，確定分布式環境下中間件在不同核心業務場景下如何應用和組合，比如服務注冊采用一層注冊還是兩層注冊、分布式事務在什么場景使用SAGA模式或者 TCC模式等。因此，分布式核心建設需要構建基于分布式技術的工程工藝，才能高質量完成核心項目交付。

挑戰五：如何選擇最適合的高可用架構

是否采用單元化架構是金融機構在新建分布式核心系統時普遍面臨的問題。從國內金融機構實踐來看，國有銀行和股份制銀行基本都選擇單元化架構作為支撐高可用的基礎架構，并且在進一步探索異地多活單元化架構的落地方案。單元化架構會增加資源投入成本和應用改造成本，而同城雙活架構具有成本較低、運維成熟度較高等優勢。對于地理分布較廣、資產規模差異較大的區域性金融機構，高可用架構的選擇需要進行系統性的分析和設計，開展包括但不限于高可用架構優劣對比、基礎設施環境評估、高可用架構選擇和適配等方案設計。

挑戰六：如何構建從應用到基礎設施的端到端運維

相對于集中式核心系統，分布式微服務架構會導致部署節點成量級增加、版本更新頻率速度顯著加快、網狀調用鏈路提升問題定位復雜度等難題，亟需升級其對應的運維體系，以保障分布式核心系統的穩定運行。面向應用、多場景、支持應用到基礎軟硬設施逐層下鉆的一體化運維體系是當前國內金融機構針對分布式核心系統運維的重點建設方向。同時，金融機構應充分認識到分布式架構下一體化運維的復雜性，尤其是第一次使用云平臺、分布式數據庫、容器等分布式技術，所以需要制定一體化運維體系分階段建設的方案，比如首先構建并打通云、數據庫、容器、PaaS等平臺的自身運維能力，然后優先從可觀測性開始逐步建設核心應用的不同場景的運維能力。

挑戰七：如何應對微服務拆分后的性能優化難題

核心系統基于分布式技術棧構建，在任何一層的性能問題都會導致應用全局性能受到影響。同時由于微服務拆分導致交易調用鏈路延長，鏈路上微小的網絡時延增加也會導致最終交易時延翻倍的增長。因此分布式核心系統的性能調優需要覆蓋從應用、中間件、數據庫、云虛機、物理服務器、存儲以及網絡的全部技術棧，整體調優難度較高，單一廠商難以完成全部工作。如何組織協調多家廠商開展性能調優，采用哪些性能調優方法，是金融機構需要解答的難題。

挑戰八：如何選擇最優的數據庫部署架構

核心系統落地分布式架構，數據庫毫無疑問是最關鍵的基礎軟件之一。隨著 25GE網絡、RDMA、無損網絡、無阻塞轉發網絡大量被應用，以及高性能計算、存儲能力的不斷發展，分布式數據庫的計算存儲架構再次從存算一體走向存算分離的架構，這也給數據的高可用能力帶來更多的選擇。金融機構選擇何種數據庫部署架構，需要結合自身的高可用目標、投入成本預算以及數據庫供應商的產品能力進行綜合評估后，制定相應的方案。

挑戰九：容器/虛擬化/裸金屬多種部署模式如何選擇

金融機構對于核心系統是否使用容器存在疑慮，主要原因是核心應用供應商的容器化實施案例不夠，以及自身對容器的掌握能力不夠。隨著行業案例逐漸增多，核心系統使用容器已基本成為行業共識，但由于容器本身具備分層解耦能力，容器下的部署選擇有多個分支選項，包括容器+物理機、容器+虛擬化服務器、容器+云上虛機以及容器+云上裸金屬。選擇哪種容器部署架構，需要綜合考慮系統性能目標、高可用目標、容

#2.3 構筑現代化核心六大新質體系

國內核心系統集中式架構的時代雖然逐漸落幕，但集中式架構在過去近30年中積累了大量的產品能力、技術規范和解決方案，仍需要在分布式架構領域持續進行改造和補充，僅僅靠數個分布式平臺產品的堆疊難以建成高質量的現代化核心系統。

在歷經多個不同類型金融機構的分布式核心建設之后，我們得以完整視角審視核心系統建設的全生命周期，在實踐中構筑出支撐現代化核心高質量建設的六大新質體系，分別是：韌性架構體系、全棧可信體系、開放集成體系、工程工藝體系、平滑遷移體系和敏捷智能體系。

六大新質體系全面覆蓋了分布式核心在架構設計、開發測試、遷移切換、運營運維等階段的主要解決方案，同時也為分布式核心建設的10大挑戰提供解決思路參考：

1、核心架構規劃挑戰

升級分布式核心規劃設計，擴充基礎設施規劃和高可用架構規劃，補完架構規劃缺失的環節。

2、業務建模挑戰

探索基于大模型技術的敏捷智能建模方案，降低人力成本，縮減時間周期，實現提質提效。

3、技術集成挑戰

建立生態集成方案和生態集成實驗室，提前完成應用廠商和云廠商的技術集成，使技術分層解耦和集成達到最佳平衡點。

4、分布式技術規范挑戰

在項目實踐中不斷積累補充高質量的工程工藝方案，落地核心領域的分布式技術規范和最佳實踐。

5、高可用架構選擇挑戰

開發從兩地三中心到多地多中心的多種高可用方案，為不同類型金融機構提供最合適的高可用架構選擇。

6、核心應用運維挑戰

構建面向應用的一體化運維方案，實現從應用到基礎設施的端到端運維。

7、核心性能優化挑戰

以軟硬協同的7層性能優化方法和服務，實現廠商間聯合完成核心性能調優。

8、數據庫部署架構選擇挑戰

提供數據庫存算分離+分布式的多種組合方案，應對不同金融機構的數據部署架構要求。

9、部署架構遷移挑戰

分別定制存量核心的應用服務器遷移、數據庫遷移、容器化遷移的方案，滿足金融機構不同類型遷移需求。

10、安全合規挑戰

通過一體化的等保、密評方案和服務體系，幫助金融機構滿足安全合規要求。

2.3.1 韌性架構體系

韌性架構體系是指在分布式核心建設中橫跨多個技術棧層次，需要通盤進行方案的韌性架構能力設計，包括：單元化高可用架構、軟硬協同性能優化和一體化應用運維。

2.3.1.1 單元化高可用架構

提升高可用容災能力，構建高度韌性的核心系統是大多數金融機構分布式核心的建設目標之一。

由于不同類型、不同體量金融機構的高可用容災目標存在差異，所以需選擇符合自身的高可用容災架構，比如同城雙活架構或單元化多活架構等。總體來說，無論選擇哪種高可用架構都需要充分考量自身容災的關鍵目標并制定對應解決方案。

金融機構在構建高可用架構時，目前主要的關注點在選擇何種架構以及選擇原因評估，卻容易忽視更為基礎的東西，即高可用能力框架的梳理。高可用能力框架是針對容災、演練、調撥以及伸縮等能力的體系化框架，該框架并不綁定某一特定的容災架構，有助于防漏補缺，提升核心整體的高可用能力。

金融機構在構建高可用架構時，除了關注選擇何種架構以及優劣評估，還需梳理高可用能力框架。

總結出高可用能力3+1框架如下：

2.3.1.2 軟硬協同性能優化

核心系統軟硬協同性能優化是指針對整個技術棧（從應用程序到基礎設施）進行全面的性能優化，以提高系統的響應速度、吞吐量和資源利用率。全棧性能調優需要綜合考慮多個層面的因素，包括但不限于網絡、服務器、數據庫、中間件和應用程序等。基于核心關鍵接口業務流程，分解關鍵子系統，識別關鍵瓶頸點，從應用層精簡優化、平臺層提速增效兩個方面對7層技術棧進行專項調優，達成性能目標。

2.3.2 全棧可信體系

2.3.3 開放集成體系

分布式技術棧還存在IaaS （基礎設施即服務）、CaaS（容器平臺即服務）、iPaaS（集成平臺即服務）、 aPaaS（應用平臺即服務）以及分布式數據庫的縱向分層集成，由于每層技術產品的供應商眾多且相互存在重疊，如何開展分層技術棧的解耦和整合是開展分布式新核心建設需要解答的難題之一。

異構服務集成

與核心系統有服務調用關系的外圍系統數量眾多，細化到具體接口更是數以千計，核心系統同外圍系統的集成也是核心系統建設中的難點。新核心基于分布式和微服務技術重構，過往基于ESB 的SOA服務集成架構已經不再適用。但大量外圍系統不會短時間進行替換，因此，金融機構的IT環境會存在兩種不同的服務集成區域，既傳統SOA集成區和微服務集成區，同時兩個區域間存在大量的服務集成。由于金融機構將微服務化的分布式核心部署在云平臺，兩個區域的服務集成也被稱為云上云下服務集成。

目前業界對云上云下服務集成主要有兩種集成模式：API網關集成模式和服務圖：一站式合規可信方案網格集成模式

2.3.4 工程工藝體系

2.3.5 平滑遷移體系

國內金融機構由于地域分布廣泛、IT 建設能力差別大，核心系統作為金融領域最復雜的IT系統，呈現出多樣化的演進方式。除了采用重構方式建設分布式核心，在滿足技術可控能力的要求下，如何低成本穩步開展存量核心的技術平臺遷移也是重要的核心演進路徑。目前，金融機構存量核心系統的技術平臺構成主要包括服務器平臺和數據庫平臺，所以其平滑遷移主要針對應用和數據庫。

2.3.5.1 基礎設施遷移

目前核心系統的服務器遷移主要是從物理機或虛擬化平臺遷移到云上的虛擬化服務器，由于國內核心系統除了主流的JAVA語言開發外，還存在少量C語言和COBOL語言開發的核心系統，對于核心系統的上云遷移，需要從多個方面進行資源和應用的全面調研評估和規劃。結合多個平臺遷移項目的經驗，總結了核心系統遷移在資源調研規劃的5圖兩表和在應用調研規劃的7圖4表，全面覆蓋核心平臺的遷移。

2.3.6 敏捷智能體系

2.3.5.2 應用遷移

在核心系統的應用遷移需要需要定制化的對核心系統進行調研分析，開展全面信息收集，包括部署架構信息、計算資源信息、網絡資源信息、存儲資源信息、數據庫信息、中間件信息、容器資源信息、微服務信息、容災信息、 DevOps信息等，并在此基礎上，規劃各項資源的遷移方案。

此外因為核心系統涉及到和外圍系統的大量交易調用，還需要全面的分析核心業務覆蓋的各種交易鏈路情況。同時為實現遷移后對外圍系統無影響，需制定對應的網絡訪問、存儲訪問和服務集成方案。

數據庫遷移

數據庫遷移主要是從集中式商用數據庫到分布式數據庫的遷移，并實現遷移過程自動化、可校驗化、可并行化，同時保持遷移前后數據庫表結構不變以及應用無感的數據庫分片處理。完整的數據庫遷移應包括語法遷移、數據遷移、數據校驗、流量回放等過程，并支持持續采集SQL，實施同步數據對比等能力。

規劃設計升級

核心系統的架構規劃設計普遍受到金融機構重視，核心分布式架構轉型需要擴充兩方面的架構規劃設計。一是對基礎架構的規劃設計，傳統集中式架構在基礎軟件和硬件設備的架構相對固定且解耦性較高，而對基礎架構的關注較少。采用分布式架構后，分布式和微服務帶來更多的應用部署、更多樣的分布式形式和更高的容災能力，核心系統對基礎架構的適配要求越來越高，因此基礎架構的規劃設計越來越重要。二是對多活高可用的規劃設計，傳統技術棧各層負責自身的容災高可用，而單元化新容災架構橫跨了多層技術棧，并需要每層針對性的開展適配，建議提前開展多活高可用架構的規劃，避免容災方式后面決定而導致返工。

#3.1 規劃設計，清晰整體目標，承接戰略藍圖

3.1.1 業務規劃

業務規劃主要包括市場定位與差異化戰略、業務拓展與產品創新、風險管理與合規經營、數字化轉型與科技創新、服務實體經濟與助力地方發展等內容。其中，數字化轉型與科技創新是提升金融機構創新能力、產品能力、服務能力、風控能力、管理能力以及提升客戶滿意度和自身競爭力的必然驅動力。數字化轉型與科技創新通常包括五個方面：

一是結合自身特點和市場環境制定差異化的數字化戰略，明確數字化轉型的目標、路徑和優先級，確保轉型工作的有序開展。

二是加強基礎設施建設，完善云計算、大數據等基礎設施平臺，提升數據處理與分析能力，為數字化轉型提供有力支撐。

三是推動業務創新，利用數字技術推動金融產品和服務的創新，滿足客戶的多元化需求，探索開放銀行模式，與第三方平臺合作拓展服務渠道。

四是優化組織架構和流程，建立適應數字化轉型的組織模式和決策機制，優化業務流程，實現業務流程的標準化、智能化。

五是加強人才隊伍建設，引進和培養數字化人才，建立健全激勵機制，提升員工的數字化素養和技能水平，激發員工的創新活力和工作積極性。

3.1.2 科技規劃

科技賦能主要包括渠道一體化、企業級業務中臺、企業級數據中臺、敏捷的全生命周期管理的產品體系、數據治理、數字化服務體系、場景化數據應用、數據驅動的客戶經營模式、智能化的業務支撐能力、數字化智能化風險控制體系、業財一體的經營決策、機控代替人控的流程優化能力等。

技術體系建設主要內容包括兩地三中心、基礎設施與云平臺、技術平臺（微服務框架、中間件、分布式數據庫、數據湖倉、AI平臺、開發平臺、研發效能平臺）的收斂與統一、以及安全架構、自動化測試體系、智能化運維體系等。

科技規劃的實施需要明確每個階段的具體目標和計劃，并配套高效的組織架構、資源投入、業務驅動創新、科技治理等綜合保障。

3.1.3 技術驗證

現代化金融核心系統往往應用多項新技術，需要對虛擬化、云計算、分布式、中間件、數據庫、數據湖倉、模型推理與訓練等關鍵技術進行驗證，具體包括資源、高性能、可拓展、高可用、容災、一致性、安全性、難易度、可維護性等多個方面。金融機構應選擇適合自身的關鍵技術，特別要考慮從原應用系統到新技術的遷移路徑是否可行，并通過同業實施案例評估和自行搭建環境進行驗證。

3.1.4 架構規劃

3.1.5 實施方案

#3.2 平臺搭建，構筑韌性平臺，沉淀共性能力

平臺搭建包含多活基礎設施、技術平臺、業務中臺、數據中臺、分布式數據庫等建設項目，是實現業務服務化、組件化、快速敏捷，以及系統高可靠、高性能、高可用、高安全、高可維等目標的基礎。平臺化有利于架構管控，實現應用系統共享平臺的能力，并實現最終的架構管控目標。平臺化還有利于開發人員僅需關注業務邏輯的實現，降低開發人員工作量。

3.2.1 多活基礎設施

多活的關鍵點就是指不同地理位置上的系統都能夠提供業務服務，“活”是指實時提供服務的意思。與“活”對應的是“備”，備是備份，正常情況下對外不提供服務，如果需要備系統提供服務，需要大量的人工干預和操作，花費大量時間才能讓“備”變成“活“。隨著業務規模和容災級別的提升，多活方案會給業務系統設計帶來更大復雜度，也會增加耗時和成本。但對于重要的業務系統有必要做雙活或多活。

3.2.2 數字化底座（IaaS）

3.2.3 技術平臺（PaaS）

PaaS平臺通過將應用系統共性的能力抽象下沉，提供具備完全自主創新的微服務平臺（包括微服務框架、注冊中心、配置中心、服務治理中心等）、API 網關組件、容器平臺、服務網格、分布式緩存組件（如Redis）、RocketMQ 消息隊列組件、Kafka消息隊列組件、分布式事務組件、分布式調度組件、 DevOps軟件研發工具鏈、日志平臺、應用運維與全鏈路可觀測平臺等能力。

技術平臺應提供應用多地多活高可靠管理方案，提供從流量、應用層、平臺層到數據層的端到端方案，支持自定義跨中心流量調撥、流量路由，提供完整的故障注入及容災演練能力。

微服務框架支撐金融機構應用架構微服務化改造升級，通過靈活的應用架構來適配業務的敏捷，支持業務快速增長。

通過建設統一服務注冊發現、配置中心、網關、服務治理平臺等微服務組件，并進行統一運維，實現系統的高可用管理。

從微服務的可觀測、可追蹤和可運維三個維度入手，構建微服務治理體系，并且通過分布式部署保證系統高性能、高可靠、高拓展能力，實現系統安全穩定運行。

技術平臺建設伴隨核心應用全生命周期，其規范化和標準化也是核心應用現代化實現過程。構筑應用全生命周期管理能力，對應用開發、運行和發布進行抽象建模以滿足跨環境可擴展的應用管理需要。

云廠商從應用的開發態、運行態、運維態都提供了豐富的云組件實現，確保應用現代化建設落地。在開發態上，提供自主創新、研發工具鏈，支撐應用研發流程敏捷升級，全方位提升研發效能；在運行態上，以云服務形式提供容器管理、微服務管理、中間件管理等關鍵技術組件，保證云上應用穩定可靠運行；在運維態上，統一日志歸集分析、全鏈路監測、性能指標實時采集等在線化運維能力，支撐應用本地高可用、同城雙活的高可用與容災管理能力。

3.2.4 分布式數據庫

從數據庫發展來看，云原生應用推動金融機構引入云數據庫，選擇企業級云數據庫將成為核心系統等關鍵應用數據持久化的最優選擇。

分布式數據庫靈活的架構適合提高核心系統構建高并發、高性能、高可靠、高可用、易擴展的能力，且應用無需關注數據的分片以及數據一致性，適合中小金融機構核心系統從小型機集中架構向分布式架構遷移。

分布式數據庫的數據分片是將全局數據按照一定的規則劃分成多個片段，并將片段分布到不同的節點（服務器）上進行存儲和處理的過程。

以下是分布式數據庫數據分片的詳細步驟和常見方法。

1、數據分片步驟

1）確定分片策略：根據業務需求、數據訪問模式、系統架構等因素，選擇合適的分片策略，包括Hash分片、范圍分片（Range分片）、列表分片（List 分片）等。

2）選擇分片鍵：確定用于分片的字段（即分片鍵），分片鍵的選擇對數據分布和查詢性能有重要影響，通常選擇數據分布均勻、查詢頻繁的字段作為分片鍵。

3）劃分數據片段：根據選定的分片策略和分片鍵，將全局數據劃分成多個片段，每個片段包含全局數據的一部分，并且每個片段的數據在邏輯上是獨立的。

4）分配數據片段：將劃分好的數據片段分配到不同的節點上進行存儲，分配時需要考慮負載均衡、數據冗余等因素，以確保系統的可用性和可靠性。

5）管理元數據：維護分片數據的元數據，包括分片鍵、分片規則、節點映射等信息，元數據的管理對于數據查詢、數據遷移等操作至關重要。

2、分片原則