超大型金融機構(gòu)國產(chǎn)數(shù)據(jù)庫全面遷移成功實踐
時間：2023-03-13 08:32:01 | 來源：電子商務(wù)
時間：2023-03-13 08:32:01 來源：電子商務(wù)
在國家層面提出加快建設(shè)科技強國，實現(xiàn)高水平科技自立自強的大背景之下，數(shù)字技術(shù)的自主研發(fā)與創(chuàng)新應(yīng)用愈發(fā)重要。然而，由于金融機構(gòu)對業(yè)務(wù)連續(xù)性和數(shù)據(jù)準確性的嚴苛要求，傳統(tǒng)頭部金融機構(gòu)始終沒能有一家完成國產(chǎn)數(shù)據(jù)庫全面遷移。
近日，阿里巴巴集團副總裁、阿里云智能新金融 &互聯(lián)網(wǎng)事業(yè)部總經(jīng)理劉偉光與 InfoQ 分享，他們深度合作的一家某超大型保險（集團）公司，深入推進數(shù)字化轉(zhuǎn)型，緊隨先鋒技術(shù)發(fā)展趨勢，前瞻性布局啟動 IT 架構(gòu)分布式改造轉(zhuǎn)型，并于 21 年 9 月圓滿實現(xiàn)了最后一個規(guī)模高達 20TB+核心數(shù)據(jù)庫的全面遷移改造工作，也為后續(xù)向云原生多活架構(gòu)演進打下了堅實的基礎(chǔ) 。
在劉偉光看來，該數(shù)據(jù)庫國產(chǎn)遷移項目成功上線，樹立了金融行業(yè)踐行科技強國的標桿實踐，也是對國家科技自立自強戰(zhàn)略以及國產(chǎn)技術(shù)的履責(zé)擔當；更推動了整個國內(nèi)數(shù)據(jù)庫管理與應(yīng)用體系科技生態(tài)建設(shè)和科技產(chǎn)業(yè)鏈的快速成熟。
那么，這家超大型保險（集團）公司，究竟是怎樣一步步完成國產(chǎn)數(shù)據(jù)庫全面遷移工作的？本篇干貨長文整理自劉偉光的分享，以饗讀者。
劉偉光，阿里巴巴集團副總裁阿里云新金融 &互聯(lián)網(wǎng)行業(yè)事業(yè)部總經(jīng)理
在金融保險行業(yè)，短時業(yè)務(wù)并發(fā)壓力雖沒有互聯(lián)網(wǎng)企業(yè)那么大，但是在業(yè)務(wù)復(fù)雜性和對數(shù)據(jù)庫專有特性的依賴程度上，都要遠大于互聯(lián)網(wǎng)企業(yè)。保險業(yè)務(wù)的處理更為復(fù)雜，單一業(yè)務(wù)要多個系統(tǒng)完成，調(diào)用鏈比銀行和互聯(lián)網(wǎng)業(yè)務(wù)更長、更復(fù)雜，確保復(fù)雜集合大交易量的穩(wěn)定是保險業(yè)務(wù)數(shù)據(jù)庫國產(chǎn)的挑戰(zhàn)。
這家保險公司成功實施國產(chǎn)數(shù)據(jù)庫全面遷移，并取得了五個突破：
突破一：更短的遷移時間。在傳統(tǒng)金融機構(gòu)從未實現(xiàn)過如此大規(guī)模的核心系統(tǒng)全量遷移的情況下，該公司從 2020 年 9 月到 2021 年 9 月，僅用時一年就完成遷移。
突破二：更大的遷移規(guī)模。該公司在一年內(nèi)完成了包括傳統(tǒng)核心、互聯(lián)網(wǎng)核心、個險銷售、團險銷售、經(jīng)營管理、客服管理、大數(shù)據(jù)在內(nèi)的近百個業(yè)務(wù)系統(tǒng)在線 Oracle 數(shù)據(jù)庫的全量搬遷工作，遷移數(shù)據(jù)規(guī)模超 400TB、數(shù)據(jù)量超千億，單庫數(shù)據(jù)規(guī)模超 20TB。
突破三：遷移全程同時保障了業(yè)務(wù)連續(xù)性和數(shù)據(jù)準確性。該公司在整個遷移過程無一例回切，上線至今一年內(nèi)，系統(tǒng)穩(wěn)定運行,且歷經(jīng) 2021 年完整周期的金融保險行業(yè)“業(yè)務(wù)大考”——承受住了開門紅高峰 TPS 5 萬+、QPS 21 萬+，以及包括精算在內(nèi)的所有業(yè)務(wù)環(huán)節(jié)的嚴苛考驗，不僅完全滿足公司生產(chǎn)需要，還實現(xiàn)國產(chǎn)數(shù)據(jù)庫從“可用”到“好用”的跨越。
突破四：遷移后實現(xiàn)技術(shù) 100%自主創(chuàng)新。該公司基于完全自研創(chuàng)新的國產(chǎn)數(shù)據(jù)庫，遷移過程中版本升級持續(xù)發(fā)版共計 50 余次，最長需求解決時間 2 個月（Pro*C+Tuxedo）。并通過系統(tǒng)培訓(xùn)與交流實現(xiàn)累計超過 500 位員工的數(shù)據(jù)庫專業(yè)考試認證，實現(xiàn)了數(shù)據(jù)庫的全面自主掌控能力。
突破五：遷移后新一代技術(shù)成為關(guān)鍵生產(chǎn)力。遷移后，該公司的存儲成本顯著下降，設(shè)備節(jié)省投入近 2 億元； 性能也大幅度提升，TPS：5.8 萬筆/秒，QPS：21 萬筆/秒，1:3 的存儲壓縮比。數(shù)據(jù)庫由主備模式發(fā)展為支持兩地三中心 多活部署，生產(chǎn)事件處理時長從小時級縮短到分鐘級。
當我們回顧這一段歷程，過程雖然艱辛，但積累了寶貴的大型金融機構(gòu)國產(chǎn)數(shù)據(jù)庫遷移實踐經(jīng)驗。下文將詳細介紹遷移的全過程，希望對“在路上”的企業(yè)有所參考。
1、 國產(chǎn)金融級數(shù)據(jù)庫遷移實踐
1.1 前期準備工作
1.1.1 數(shù)據(jù)庫選型
數(shù)據(jù)庫是企業(yè) IT 基礎(chǔ)設(shè)施中皇冠上的明珠，存儲企業(yè)運行核心數(shù)據(jù)資產(chǎn)，向上支撐應(yīng)用，向下屏蔽底層基礎(chǔ)設(shè)施，在金融行業(yè)
“穩(wěn)定壓倒一切”的大前提下，數(shù)據(jù)庫的選型更為慎重，根據(jù)信通院《數(shù)據(jù)庫發(fā)展研究報告（2021年）》 的描述，截至 2021 年 6 月底，國產(chǎn)關(guān)系型數(shù)據(jù)庫廠商就高達 81 家。面對如此紛繁復(fù)雜的產(chǎn)品，如何選擇合適的數(shù)據(jù)庫是擺在該保險公司面前的首要問題。雖然數(shù)據(jù)庫產(chǎn)品眾多，經(jīng)過審慎的評估后，該公司最終選擇了 OceanBase、PolarDB 等三款產(chǎn)品作為先期試點驗證，主要選型考量點如下：
1. 是否能滿足業(yè)務(wù)的平滑遷移和未來架構(gòu)的演進要求；
2. 是否具備分層解耦能力，重點關(guān)注能否解除數(shù)據(jù)庫與底層硬件、操作系統(tǒng)、中間件之間的耦合；
3. 是否有足夠的人才儲備、資金投入，能否商業(yè)兜底產(chǎn)品的長期演進；
4. 是否有廣泛的行業(yè)實踐案例；
5. 是否能做到完全自主研發(fā)；
6. 是否能兼容原有開發(fā)運維體系，自有技術(shù)人員能否快速掌握。
1.1.2 基礎(chǔ)設(shè)施準備
確定數(shù)據(jù)庫選型標準后，前期準備工作的進度表走到了下一環(huán)節(jié)——基礎(chǔ)設(shè)施準備。
該公司核心業(yè)務(wù)系統(tǒng)原先共計使用超過 60 多臺 IBM 和 HP 高端小型機，超過 70 多臺高端存儲，傳統(tǒng)集中式架構(gòu)耦合性強，難以實現(xiàn)規(guī)模和性能的線性擴展。本次國產(chǎn)數(shù)據(jù)庫采用機架式服務(wù)器和本地存儲全面替代進口小型機及傳統(tǒng) SAN 存儲架構(gòu)，以滿足核心系統(tǒng)全量遷移的云原生分布式架構(gòu)改造。同時，為了避免基礎(chǔ)設(shè)施變動過大導(dǎo)致業(yè)務(wù)系統(tǒng)不穩(wěn)定，采用 Intel+海光+鯤鵬服務(wù)器混合部署的架構(gòu)。前期仍以 Intel X86 為主，逐步過度到海光、鯤鵬芯片國產(chǎn)服務(wù)器，實現(xiàn)在線調(diào)整不同型號機器，解除了基礎(chǔ)設(shè)施供應(yīng)依賴。
2020 年 9 月，該公司正式啟動國產(chǎn)數(shù)據(jù)庫遷移項目之后，從硬件環(huán)境的型號選擇，到選出目標系統(tǒng)，進行容量規(guī)劃。不到兩個月的時間內(nèi)，該公司從 0 開始完成了國產(chǎn)數(shù)據(jù)庫的硬件和操作系統(tǒng)適配、以及整個服務(wù)器集群的搭建工作。
1.1.3 遷移策略制定
基礎(chǔ)設(shè)施準備工作落地后，該公司開始指定遷移策略。
從需求出發(fā)，基于該保險公司的業(yè)務(wù)經(jīng)過多年的發(fā)展，業(yè)務(wù)范圍覆蓋全國，特色鮮明、種類繁多，業(yè)務(wù)關(guān)聯(lián)關(guān)系錯綜繁雜，想要進行核心數(shù)據(jù)庫的遷移，首先需要進行廣泛的調(diào)研和充分的科學(xué)論證——既要求數(shù)據(jù)庫產(chǎn)品比照原有生產(chǎn)數(shù)據(jù)庫的高性能和安全可靠，也需要快速實現(xiàn)多套系統(tǒng)的平滑遷移，同時解決資源彈性和數(shù)據(jù)庫橫向擴展的能力。
面對這樣的需求，該公司先后建立了數(shù)據(jù)庫遷移實施的統(tǒng)一規(guī)范和標準--總體遵循“評估-實現(xiàn)-控制-分析改進”的科學(xué)方法論，開展有序遷移，并定下三大遷移策略：
1.先平遷再做業(yè)務(wù)和架構(gòu)改造升級，避免多個變量同時發(fā)生，影響業(yè)務(wù)的連續(xù)性。由于原有數(shù)據(jù)模型不做改造，所以主體改造工作由新數(shù)據(jù)庫來承擔。
2.遷移批次遵循“以業(yè)務(wù)系統(tǒng)為粒度，從低負載到高負載，從外圍到核心”的原則。
3.所有數(shù)據(jù)庫遷移不影響正常業(yè)務(wù)開展。用 1 年時間完成所有業(yè)務(wù)系統(tǒng)的數(shù)據(jù)庫全量遷移改造，所有系統(tǒng)數(shù)據(jù)庫遷移動作時間窗口只給周六、周日凌晨 0 點到早上 6 點，周末小流量驗證，周一重點保障，不影響正常業(yè)務(wù)開展。
1.2 互聯(lián)網(wǎng)核心遷移
1.2.1 明確業(yè)務(wù)系統(tǒng)背景
在完成了所有前期準備工作之后，該公司著手選定數(shù)據(jù)庫系統(tǒng)進行遷移工作。
該保險公司核心系統(tǒng)涉及眾多，大體可以分為：互聯(lián)網(wǎng)核心業(yè)務(wù)系統(tǒng)和傳統(tǒng)核心業(yè)務(wù)系統(tǒng)，中間通過類似 ESB 的總線機制實現(xiàn)異步解耦。
核心系統(tǒng)分類
早在 2016 年，這家保險公司的互聯(lián)網(wǎng)核心和傳統(tǒng)新核心應(yīng)用就開始從傳統(tǒng)單體架構(gòu)向分布式微服務(wù)架構(gòu)改造。至 2020 年，也就是開始遷移的時間點，互聯(lián)網(wǎng)核心業(yè)務(wù)系統(tǒng)已經(jīng)拆分成了 40 多個微服務(wù)模塊并完成 Mesh 化接入。
該公司互聯(lián)網(wǎng)核心業(yè)務(wù)系統(tǒng)的特點是：
1.數(shù)據(jù)庫系統(tǒng)已實現(xiàn)全國物理集中、邏輯集中，數(shù)據(jù)庫對接的關(guān)聯(lián)系統(tǒng)較多；
2.雖然做了微服務(wù)拆分，但是數(shù)據(jù)庫仍有一定量的存儲過程，另外觸發(fā)器、自定義類型、函數(shù)、外鍵、分區(qū)表等高級功能均有使用；
3.該公司因為業(yè)務(wù)特點，需要服務(wù)好 100 多萬代理人，對數(shù)據(jù)庫資源彈性和性能要求更高。
因此，進行互聯(lián)網(wǎng)核心業(yè)務(wù)系統(tǒng)的數(shù)據(jù)庫遷移面臨的主要技術(shù)挑戰(zhàn)是：
1.全國集中式部署下單點故障會影響到全國；
2.主數(shù)據(jù)系統(tǒng)作為核心業(yè)務(wù)鏈路中的整個保險開戶入口，內(nèi)部對接 43 個關(guān)聯(lián)系統(tǒng)，數(shù)據(jù)規(guī)模超 20TB，最大單表超 50 億條數(shù)據(jù)，每天接口調(diào)用量超 2000 萬次，是該公司單體數(shù)據(jù)庫日均請求量最大的系統(tǒng)，因為關(guān)聯(lián)系統(tǒng)多，且處在業(yè)務(wù)鏈路的核心位置，因此對數(shù)據(jù)庫 SQL 的效率要求非常高，要求遷移過程不能影響原有生產(chǎn)系統(tǒng)；
3.遷移到新的數(shù)據(jù)庫平臺要具備實時同步到 Kafka 的能力，并兼容原有格式，供下游大數(shù)據(jù)系統(tǒng)消費。
原有大數(shù)據(jù)消費鏈路
1.2.2 選定技術(shù)方案
針對以上技術(shù)挑戰(zhàn)，該公司選擇了和原有 Oracle RAC 架構(gòu)更接近的PolarDB作為互聯(lián)網(wǎng)核心數(shù)據(jù)庫的替換。PolarDB 作為新一代云原生數(shù)據(jù)庫主要特點如下：
1.計算與存儲分離，使用共享分布式存儲，滿足業(yè)務(wù)彈性擴展的需求。極大降低用戶的存儲成本；
2.讀寫分離，一寫多讀，PolarDB 引擎采用多節(jié)點集群的架構(gòu)，集群中有一個主節(jié)點（可讀可寫）和至少一個只讀節(jié)點（最大支持 15 個只讀節(jié)點）。寫操作發(fā)送到主節(jié)點，讀操作均衡地分發(fā)到多個只讀節(jié)點，實現(xiàn)自動的讀寫分離；
3.基于 K8S 形態(tài)部署，提供分鐘級的配置升降級，秒級的故障恢復(fù)，全局數(shù)據(jù)一致性和完整的數(shù)據(jù)備份容災(zāi)服務(wù)；
4.集中式架構(gòu)，不需要進行分布式架構(gòu)相關(guān)考慮設(shè)計，和原有使用習(xí)慣保持一致，性能不低于原有 Oracle 數(shù)據(jù)庫；
5.高度兼容 Oracle，應(yīng)用基本上不需要做 SQL 語法調(diào)整。
為了避免對原有生產(chǎn)業(yè)務(wù)造成影響且保證遷移數(shù)據(jù)的嚴格一致性，該公司采用了 DTS 全量+增量的方式，對于數(shù)據(jù)規(guī)模超大的 Oracle 集群，如客戶主數(shù)據(jù)系統(tǒng)，提前 2 周啟動數(shù)據(jù)遷移鏈路，在全量數(shù)據(jù)遷移之前 DTS 會啟動增量數(shù)據(jù)拉取模塊，增量數(shù)據(jù)拉取模塊會拉取源實例的增量更新數(shù)據(jù)，并解析、封裝、存儲在本地存儲中。
當全量數(shù)據(jù)遷移完成后，DTS 會啟動增量日志回放模塊，增量日志回放模塊會從增量日志讀取模塊中獲取增量數(shù)據(jù)，經(jīng)過反解析、過濾、封裝后遷移到目標實例，通過目標端主鍵保證數(shù)據(jù)的唯一性。
應(yīng)用切換成功后，從應(yīng)用接口的響應(yīng)速度上看，性能比 Oracle 提升約 30%。到 2020 年底，該公司和阿里云數(shù)據(jù)庫團隊攜手完成了互聯(lián)網(wǎng)核心業(yè)務(wù)系統(tǒng)所有模塊的遷移，包括服務(wù)超百萬代理人的出單系統(tǒng) APP，和注冊用戶超 1 億的壽險 APP、客戶主數(shù)據(jù)等在內(nèi)的共計 40 多個業(yè)務(wù)系統(tǒng)。
互聯(lián)網(wǎng)核心整體遷移技術(shù)方案
為了減少遷移過程中對下游大數(shù)據(jù)消費造成影響，該公司到大數(shù)據(jù)的同步鏈路改造采用了 2 步走的策略，
大數(shù)據(jù)同步鏈路改造方案
1.增加 PolarDB 到 Oracle 的反向?qū)崟r同步，原有 Oracle 到 Kafka 同步鏈路不變，避免數(shù)據(jù)庫切換帶來太大的變動；
2.參考 SharePlex 的格式對 DTS 進行定制化開發(fā)改造，待驗證充分后，直接替換掉 SharePlex 原有同步鏈路。
遷移完成后，PolarDB 作為互聯(lián)網(wǎng)核心業(yè)務(wù)系統(tǒng)的數(shù)據(jù)庫，需要穩(wěn)定支撐起該公司在 2021 年一季度的業(yè)務(wù)沖刺。最前端的出單系統(tǒng)，是整個業(yè)務(wù)沖刺過程中性能壓力的集中點。并且，由于做了微服務(wù)化改造拆成了 30 多個模塊，分散在了多個數(shù)據(jù)庫中，任何一個數(shù)據(jù)庫都可能存在被打爆的風(fēng)險。在遷移到 PolarDB 之前，該公司的做法是拆在多個 Oracle RAC 集群中，依靠內(nèi)部開發(fā)的數(shù)據(jù)庫監(jiān)控完成多個 Oracle 集群的監(jiān)控，遷到 PolarDB 之后，預(yù)計整體架構(gòu)將更適應(yīng)業(yè)務(wù)彈性的以下挑戰(zhàn)：
1.統(tǒng)一管控：通過 PolarStack 將多臺機器組成的集群進行統(tǒng)一管控，提供 DBaaS 服務(wù)；
2.資源彈性：實例由原來的物理機部署，變?yōu)?K8S Pod 部署，更為靈活和彈性；
3.讀寫分離：通過智能代理服務(wù)實現(xiàn)自動的讀寫分離，實現(xiàn)分鐘級擴容，故障場景下自動切換，應(yīng)用不需要做任何調(diào)整。
PolarDB 技術(shù)架構(gòu)
業(yè)務(wù)沖刺當天，互聯(lián)網(wǎng)核心業(yè)務(wù)系統(tǒng)經(jīng)過了三個性能壓力高高峰時間點：12：00、17：00、21：00。這三個時間點的每小時出單量和全天出單量進入了歷史的前三位，高峰期出單筆數(shù)達到 9000 筆/s。
2020 年 9 月，該公司互聯(lián)網(wǎng)核心業(yè)務(wù)系統(tǒng)的首批應(yīng)用模塊遷移到 PolarDB，整個適配過程不到一個月。此后，互聯(lián)網(wǎng)核心各個模塊就開始了大規(guī)模的遷移。
2020 年 11 月，PolarDB 完成了最大的單庫客戶主數(shù)據(jù)遷移。
2021 年 1 月底，PolarDB 作為互聯(lián)網(wǎng)核心出單系統(tǒng)的數(shù)據(jù)庫，穩(wěn)定支撐起該保險公司 2021 年一季度業(yè)務(wù)沖刺。
1.3 傳統(tǒng)核心遷移
1.3.1 明確業(yè)務(wù)系統(tǒng)背景
該大型保險公司的傳統(tǒng)核心系統(tǒng)歷史悠久，既有 1998 年之前建成的，也有 2004 到 2008 年間建成的，時間跨度長，數(shù)據(jù)量異常龐大，單個數(shù)據(jù)庫的數(shù)據(jù)規(guī)模甚至超過 20TB。更具挑戰(zhàn)的是，很多老核心按省市做了拆分，要分省市分別進行遷移，單一老核心系統(tǒng)需要遷移的數(shù)據(jù)庫可能就要多達 36 個。
通過詳細地梳理，該公司將傳統(tǒng)核心業(yè)務(wù)系統(tǒng)歸納為三類系統(tǒng)：
第一類：2016、2017 年基于 Java 技術(shù)棧開發(fā)的新核心系統(tǒng)，大概有 13 個。
第二類：分別在 1998 年之前，2004 到 2008 年間建成的老核心系統(tǒng)，大概有 6 個。
第三類：一些可能要下線的，不在此次數(shù)據(jù)庫遷移范圍內(nèi)的系統(tǒng)。
彼時，這些傳統(tǒng)核心業(yè)務(wù)系統(tǒng)的數(shù)據(jù)庫當時面臨的主要技術(shù)挑戰(zhàn)是：
1.系統(tǒng)關(guān)聯(lián)關(guān)系龐雜，既有保單平臺管理系統(tǒng)也有資金類系統(tǒng)，系統(tǒng)間關(guān)系難以梳理；
2.既有物理和邏輯集中的新核心，也有物理集中，邏輯分離的老核心，其中老核心分省部署，每個省都會有一套數(shù)據(jù)庫，遷移工作量巨大；
3.對 Oracle 專有特性依賴較多，大量使用存儲過程、觸發(fā)器、自定義類型、函數(shù)、外鍵等。更為挑戰(zhàn)的是，老核心大量使用 Pro*C（SQL 嵌入式 C 程序）和 Tuxedo（Oracle 中間件做分布式事務(wù)處理）做保單過程處理，僅該公司某年金系統(tǒng)涉及到的 Pro*C 程序就有 1500 多個，約 140 萬行代碼，業(yè)務(wù)短時間難以改造；
4.單庫體量非常大，超過 10TB 的就有 6 個，最大單庫規(guī)模超 20TB，停機窗口短暫；
5.交易量大，每天數(shù)據(jù)庫調(diào)用幾十億次，還有大量復(fù)雜集合類精算和結(jié)算類交易。
1.3.2 確定技術(shù)方案
針對以上技術(shù)挑戰(zhàn)，該公司選擇了分布式數(shù)據(jù)庫OceanBase作為傳統(tǒng)核心的替換。OceanBase 數(shù)據(jù)庫主要特點如下：
1.采用基于無共享（Shared-Nothing）的多副本架構(gòu)，整個系統(tǒng)沒有任何單點故障，保證系統(tǒng)的持續(xù)可用；
2.基于 LSM 存儲引擎技術(shù)，結(jié)合新硬件的能力，采用可擴展的分布式架構(gòu)，提供高性能和擴展性；
3.數(shù)據(jù)庫針對 Oracle、MySQL 等應(yīng)用最為廣泛的數(shù)據(jù)庫生態(tài)都給予了非常高的應(yīng)用兼容性支持；
4.雖然為分布式架構(gòu)，一般也不需要應(yīng)用層做相應(yīng)的重新設(shè)計如指定分布鍵等，與原有 Oracle 使用習(xí)慣基本一致；
5.OceanBase 數(shù)據(jù)庫完全自主研發(fā)，不依賴外部開源代碼，真正做到自主研發(fā)。
該公司針對傳統(tǒng)核心復(fù)雜的數(shù)據(jù)庫情況進行全面驗證，最終形成了 140 頁的遷移操作手冊和詳細的割接行事歷，為后續(xù)系統(tǒng)的遷移和大面積推廣積累了寶貴的經(jīng)驗，并形成了標準的遷移割接方案。整體遷移方法過程如下，從“基礎(chǔ)環(huán)境準備--遷移過程演練--正式割接--監(jiān)控運維”等四大環(huán)節(jié)進行逐項拆解，落實到人，精確到分。
數(shù)據(jù)庫整體遷移割接流程
對于規(guī)模較大 Oracle 數(shù)據(jù)庫的遷移，我們總結(jié)了如下四點幫助提升遷移效率：
1. 冷熱數(shù)據(jù)分離
一般的業(yè)務(wù)庫數(shù)據(jù)中，數(shù)據(jù)具有自己的生命周期，數(shù)據(jù)的高頻訪問具有冷熱特點。比如，流水表歷史數(shù)據(jù)，日志表歷史數(shù)據(jù)除了在審計回查場景之外，訪問很少甚至不訪問，但是通常這部分數(shù)據(jù)都會比較大，數(shù)據(jù)遷移的開銷會比較高，造成數(shù)據(jù)遷移時間的延長。針對該部分數(shù)據(jù)，我們可以預(yù)先對這部分數(shù)據(jù)進行歸檔備份，然后采用靜態(tài)遷移或者利用 OMS 工具全量遷移單獨遷移。
2. LOB 類型數(shù)據(jù)
Oracle 數(shù)據(jù)表行 LOB 類型空間占用較大，每一批次的數(shù)據(jù)拉取大小會在原始行的基礎(chǔ)上有顯著增加。相比無 LOB 數(shù)據(jù)類型，對 OMS 端內(nèi)存需求有數(shù)倍的需求，因此，優(yōu)化的策略是單獨對 LOB 類型的表建立新的鏈路，采用較小的并發(fā)，防范 JVM OOM 的風(fēng)險，同時，為了提高整體遷移的速度，進行多鏈路并行遷移。
3. 無 LOB 類型數(shù)據(jù)
相對于 LOB 類型數(shù)據(jù)，無 LOB 數(shù)據(jù)類型的表的遷移，單位遷移批次的大小較小且穩(wěn)定，內(nèi)存需求可控，并發(fā)度可適度加大，提高遷移速度。所以，對該部分數(shù)據(jù)可使用較高的并發(fā)度單鏈路或多鏈路遷移。
4.多個大庫遷移鏈路通過不同 OMS 并發(fā)遷移
單臺 OMS 可以支持多個遷移任務(wù)，但是共享數(shù)據(jù)網(wǎng)絡(luò)出口。鑒于大庫數(shù)據(jù)的持續(xù)拉取，可以將大庫的遷移分散至不同 OMS 節(jié)點，減少大數(shù)據(jù)網(wǎng)絡(luò)流量的爭用。
在整個遷移過程面臨的挑戰(zhàn)中，我們認為最難的是針對 Pro*C 的適配。Pro*C 是 Oracle 提供的應(yīng)用程序?qū)Ｓ瞄_發(fā)工具，應(yīng)用 C 語言編寫程序，在程序源代碼中可以直接嵌入 SQL 語句，執(zhí)行數(shù)據(jù)庫操作。
Pro*C 既兼容了傳統(tǒng) C 語言的開發(fā)模式，又提供了強大的數(shù)據(jù)庫操控能力，所以在保險行業(yè)和其他行業(yè)也有不小的用戶基礎(chǔ)。而 Tuxedo(Transactions for Unix, Extended for Distributed Operations)作為是最早的分布式事務(wù)產(chǎn)品，是 AT&T 在 20 世紀 80 年代推出的。傳統(tǒng)老核心業(yè)務(wù)中，大量使用 Tuxedo 調(diào)用相關(guān)的 Pro*C 程序來做保單業(yè)務(wù)流程處理來保證跨庫事務(wù)的一致性。
為了根本上解決該問題，實現(xiàn)應(yīng)用的平滑遷移，阿里成立項目攻堅團隊，計劃用 1 個月時間，從頭開發(fā) Pro*C 兼容預(yù)編譯程序和運行時庫。2020 年國慶節(jié)前，攻堅團隊的預(yù)編譯程序成功編譯了某年金業(yè)務(wù)的全部 1000 多個 Pro*C 程序，并正確跑通了兩個典型批處理作業(yè)，通過了該公司的驗收，進展大大超出該公司預(yù)期，也因此在“數(shù)據(jù)庫賽馬”中成功勝出并贏得了該公司對 OceanBase 產(chǎn)品研發(fā)能力的信心。
OceanBase 能在短時間內(nèi)完成對老核心的適配，得益于：
1.自主研發(fā)讓 OceanBase 團隊對每一行代碼熟稔于心。OceanBase 始終堅持自主研發(fā)，讓研發(fā)人員有優(yōu)秀的個人能力，清楚產(chǎn)品每一行代碼的來龍去脈，能夠快速和高質(zhì)量地新增和修改代碼，真正做到了自主研發(fā)。
2.全鏈路打通的研發(fā)模式。Pro*C 只是外在交互模式，底層還要依賴數(shù)據(jù)庫的內(nèi)核能力，從 SQL 模式、優(yōu)化器、服務(wù)端等做到了全鏈路打通，比如研發(fā)在批處理作業(yè)現(xiàn)場聯(lián)調(diào)時發(fā)現(xiàn) SQL 對 to_date 函數(shù)的'J'參數(shù)尚未支持時，快速反映給 SQL 模塊，后端僅用一天完成了開發(fā)測試和發(fā)布。
3.敏捷開發(fā)模式，攻堅小組的研發(fā)和測試大家坐到一起，每日隨著項目進展和變化快速確定和調(diào)整當日的目標。打破研發(fā)和測試邊界，研發(fā)一邊在開發(fā)，測試同學(xué)已經(jīng)把單測和集成測試案例寫好，開發(fā)側(cè)有一點小的進展就立即驗證測試，使得開發(fā)和測試能接近同步完成。
2020 年 10 月，首個傳統(tǒng)新核心理賠系統(tǒng)順利上線。
2021 年 3 月，完成傳統(tǒng)老核心最小省份的遷移上線。
2021 年 4 月，完成 13 個傳統(tǒng)新核心的遷移上線。
2021 年 8 月，完成傳統(tǒng)老核心最后一個大省遷移上線。
2021 年 9 月，完成傳統(tǒng)老核心最后一個單體庫遷移上線。
1.4 全面體系化遷移
該保險公司發(fā)現(xiàn)：如何體系化全面遷移是是核心遷移過程中頻發(fā)引發(fā)團隊思考的問題，雖然在 2021 年 3 月完成最小省份的遷移，但后面還有多個老核心分布在 36 個按省市獨立部署的 Oracle 數(shù)據(jù)庫中，每個省份又包括了 20 多個 schema，如果按照老的遷移方式，每個省份都需要創(chuàng)建 20 多條遷移鏈路，對于資源和人力都是極大的消耗，短時間也難以完成。
通過分析，工程化批量遷移最大的問題是沒有做到全流程自動化，手工操作的步驟還比較多，為了解決該問題，產(chǎn)研和現(xiàn)場交付同學(xué)做了三件事情：
1.OMS 數(shù)據(jù)遷移工具在底層鏈路上從技術(shù)層面支持多 schema 合并操作，從而可以將同一個省份的二十多條鏈路合并到一條遷移鏈路中。
2.在產(chǎn)品層面將數(shù)據(jù)遷移工具的底層能力進行拆解，將原來無法自動化的步驟做了自動化，并通過 API 的方式暴露出來，使得前線交付同學(xué)可以根據(jù)用戶的實際情況像搭積木一樣進行組裝使用。
3.交付同學(xué)基于暴露的 API 和 140 多頁的遷移操作手冊，用一個月時間開發(fā)出簡化遷移鏈路配置的快捷遷移工具。
一鍵自動遷移過程圖
在對快捷遷移工具迭代了四個版本后，投入使用。需要人工干預(yù)的工作量減少了 80%。同時一起建立了數(shù)據(jù)庫遷移實施的統(tǒng)一規(guī)范和標準，開展有序遷移。上線實施標準流程包括 8 大環(huán)節(jié)，98 個步驟，5 倍峰值壓測，體系化遷移 8 大環(huán)節(jié)如下：
1. 兼容性評估：明確改動范圍，進行適配改造工作量評估并合理安排工作任務(wù)。
2. 負載評估：從原數(shù)據(jù)庫獲取 SQL 負載信息并在新數(shù)據(jù)庫測試環(huán)境回放，驗證新數(shù)據(jù)庫應(yīng)用后的性能。
3. 測試遷移、適配改造：進行適配改造、全量回歸測試、性能測試。有條件的系統(tǒng)（微服務(wù)化較好、重構(gòu)等），可以分批改造和實施遷移。其中，性能測試可根據(jù)遷移前的關(guān)鍵業(yè)務(wù)容量基線，確定測試準出標準。
4. 生產(chǎn)庫存量、增量式遷移：對于業(yè)務(wù)連續(xù)性要求不高的系統(tǒng)，一般操作一次性存量方式完成數(shù)據(jù)遷移；對于業(yè)務(wù)連續(xù)性要求高的系統(tǒng)，采取全量+增量遷移方式，待增量數(shù)據(jù)追平后實施切換，僅需在切換時點暫停業(yè)務(wù)（分鐘級）。
5. 反向回流：對于關(guān)鍵應(yīng)用，可實施數(shù)據(jù)同步回原數(shù)據(jù)庫應(yīng)對未知風(fēng)險。
6. 數(shù)據(jù)驗證：遷移完成后進行數(shù)據(jù)準確性驗證及應(yīng)用驗證。
7. 持續(xù)監(jiān)控：對可能遇到的問題進行監(jiān)控、詳細評估分析。
8. 在線壓測：遷移完成后，定期開展在線壓測，基于實際生產(chǎn)場景進行業(yè)務(wù)全鏈路壓力測試，持續(xù)保障應(yīng)用容量和性能。
2021 年 5 月，西部某省的遷移在 2 小時內(nèi)順利完成，驗證了 Oracle 端多 schema 合并遷移這一重要技術(shù)難點，相比之前有數(shù)倍的提升，為剩余省份的并行遷移掃清了障礙，經(jīng)過優(yōu)化后：
1.測試環(huán)境：自主進行數(shù)據(jù)遷移和壓測回放，并通過 SQL 自動優(yōu)化建議工具，大大提高了遷移驗證效率，可以自助解決 90%以上的問題。
測試環(huán)境多次遷移演練步驟
2.生產(chǎn)環(huán)境：將過程中需要人工檢查費時、費力的步驟，做到了自動化
正式遷移割接步驟
緊接著完成了東北三省+內(nèi)蒙古總共四個省份的數(shù)據(jù)，過程中解決了 Oracle 源端出現(xiàn)不可見控制字符臟數(shù)據(jù)的問題，確保了數(shù)據(jù)準確無誤。
2021 年 8 月，歷經(jīng)前面 11 次的遷移后，終于完成了最后一個、最重要省份，也是數(shù)據(jù)規(guī)模最大的的數(shù)據(jù)庫遷移。
2021 年 9 月，在解決了所有技術(shù)難題，完成了所有核心數(shù)據(jù)庫的遷移，經(jīng)歷了開門紅大促的考驗后，該公司要完成一個保險公司一個完整的業(yè)務(wù)周期，只剩下最后一關(guān)，就是保險精算。
保險精算是保險公司業(yè)務(wù)經(jīng)營的特色，需要運用數(shù)學(xué)、統(tǒng)計學(xué)、金融學(xué)、保險學(xué)及人口學(xué)等學(xué)科的知識與原理，去解決商業(yè)保險與各種社會保障業(yè)務(wù)中需要精確計算的項目。一般會在季度末和年末進行，以衡量企業(yè)的經(jīng)營狀況，并制定更有市場競爭力的保險產(chǎn)品，是保險業(yè)務(wù)開展不可或缺的關(guān)鍵一環(huán)。
保險精算分析的特點在于數(shù)據(jù)量大，分析的模型復(fù)雜，過程中還有大量的數(shù)據(jù)寫入，往往要持續(xù)一周甚至更長時間，并且要確保精算過程中，快照點的數(shù)據(jù)不能發(fā)生變化。
基于傳統(tǒng) IOE 架構(gòu)往往通過存儲層的快照來實現(xiàn)。遷移到分布式數(shù)據(jù)庫后，怎么保證在不停應(yīng)用的情況下完成保險精算，是整個遷移過程的最后一個障礙。經(jīng)過反復(fù)評估，阿里云為此制定了最佳方案，受益于 OceanBase 底層數(shù)據(jù)塊的快速物理備份和表級的恢復(fù)能力。經(jīng)過近 1 個月的壓測驗證，集群恢復(fù)速度達到 800MB/S，完全滿足精算的備份恢復(fù)的時間要求。最終在 2021 年 9 月 30 日在規(guī)定的時間窗口完成了數(shù)據(jù)的備份并導(dǎo)入到了精算庫，有效支撐了全面遷移后的保險精算業(yè)務(wù)，解決掉了最后遺留的小尾巴。
保險精算數(shù)據(jù)準備過程
1.5 主要問題總結(jié)
當然，整個遷移過程并不是一帆風(fēng)順，雖然未產(chǎn)生重大生產(chǎn)事故，但過程中也出了幾次故障。而這些故障背后既反映了國產(chǎn)數(shù)據(jù)庫在面對復(fù)雜場景上能力的提升，也反映了分布式架構(gòu)帶來的根本性變化。以下詳細介紹三大故障情況以及解決辦法。
1.5.1 數(shù)據(jù)庫連接打滿多次觸發(fā)高可用切換
互聯(lián)網(wǎng)核心遷移到 PolarDB 過程中遇到的最大一次問題是在 2021 年 1 月，當天凌晨面向 C 端用戶的兩個重要系統(tǒng)完成數(shù)據(jù)遷移和應(yīng)用的割接。伴隨著日間業(yè)務(wù)流量逐漸增加，兩系統(tǒng)因為大量的慢查詢堆積較多應(yīng)用連接，將數(shù)據(jù)庫服務(wù)堵塞，全天多次觸發(fā) PolarDB 實例自動高可用切換，執(zhí)行節(jié)點重建恢復(fù)流程。
以云原生容器形式部署的數(shù)據(jù)庫服務(wù)節(jié)點，除了受本身數(shù)據(jù)庫相關(guān)的內(nèi)存參數(shù)限制外，還受 cgroup 指定的 CPU 和內(nèi)存限制。當時連接池打滿后，由于內(nèi)存超出限制，引起實例的多次高可用切換重建。云原生數(shù)據(jù)庫基于容器部署需要在穩(wěn)定性和自保能力方面做諸多增強，為了解決相關(guān)問題，后續(xù)的版本中增加了 global plan cache、resource manager、并行日志回放、global index 等功能，數(shù)據(jù)庫的內(nèi)核參數(shù)也針對金融場景逐一做了定制化優(yōu)化。
針對金融場景對穩(wěn)定性要求極高的需求，通過本次互聯(lián)網(wǎng)核心遷移也增加了諸多管控運維能力：
1. 增加 AWR 功能，定期收集 AWR 報告對性能和可用性進行分析。
2. 增加 GAWR 功能，對主機、Dockers、RW/RO 進行全量數(shù)據(jù)采集。
3. 新增 online promote 功能，優(yōu)化在線切換，進一步縮短切換時間。
4. 增加 Idle 狀態(tài) Session 超時自動斷開連接功能，減少后臺進程數(shù)，及時釋放回收 Idle Session 的內(nèi)存資源。
5. 優(yōu)化元信息緩存功能，Session 級別元信息緩存優(yōu)化為全局元信息緩存，降低后臺進程的內(nèi)存使用。增加內(nèi)存總量資源管理控制，設(shè)置一定的閾值，到達閾值后開始 Cancel Query、Kill Idle Session、Kill Active Session、拒絕新用戶 Session 連接，增強數(shù)據(jù)庫的自保能力。
1.5.2 SAN 交換機故障導(dǎo)致數(shù)據(jù)庫進入無主狀態(tài)
由于原有 Oracle 數(shù)據(jù)庫都是基于 SAN 存儲部署，在 2020 年 9 月份啟動數(shù)據(jù)庫遷移工作之時，針對 OceanBase 部署建議的本地 SSD 盤硬件還沒有采購到位。為了快速啟動相關(guān)的遷移工作，最開始 OceanBase 傳統(tǒng)新核心集群還是部署在 SAN 存儲上，這也為第一個生產(chǎn)問題埋下了隱患。
第一個傳統(tǒng)新核心應(yīng)用理賠上線后，系統(tǒng)運行比較平穩(wěn)。意外出現(xiàn)在某天下午 14 點 7 分，系統(tǒng)同時收到了應(yīng)用監(jiān)和數(shù)據(jù)庫監(jiān)控的告警。監(jiān)控顯示，應(yīng)用出現(xiàn)了 90 秒的阻塞迭停。然而，當雙方團隊還在排查問題時，數(shù)據(jù)庫已經(jīng)自動完成了恢復(fù)。
OceanBase QPS 監(jiān)控截圖
問題現(xiàn)象時間軸分析
經(jīng)過深入分析，發(fā)現(xiàn)是 SAN 存儲交換機到核心交換機連接的一個端口出現(xiàn)了故障。雖然配置了多路徑轉(zhuǎn)發(fā)，但由于操作系統(tǒng)內(nèi)核的超時時間與 OceanBase 切主時間不匹配，觸發(fā)了 OceanBase 的自動選主操作。
而選主過程中，另外一臺物理機也走的同樣端口也出現(xiàn)了 IO 阻塞的問題，最終導(dǎo)致 OceanBase 進入無主狀態(tài)，當多路徑軟件成功切換后，OceanBase 未經(jīng)過任何干預(yù)就完成了自動恢復(fù)。本質(zhì)上是因為軟件超時參數(shù)與硬件超時參數(shù)不匹配所導(dǎo)致，也是軟硬件系統(tǒng)磨合不夠充分的表現(xiàn)，通過相關(guān)參數(shù)的調(diào)整能減少 RTO 的時間。
在此次故障之前，大家對 OceanBase 的了解都停留在 PPT 層面：RPO=0、RTO<30 秒。直到這次故障才真切的感受到，
故障時的快速切換和自動恢復(fù)能力是多么的重要。但是故障發(fā)生，項目組內(nèi)部也有質(zhì)疑聲音出來：“OceanBase 基于 SAN 存儲的部署本來就是錯的，我們就不該使用 OceanBase。”
但經(jīng)過深入的分析才發(fā)現(xiàn)并不是 OceanBase 的問題，也不是 SAN 存儲的問題，而是有沒有充分的磨合，軟硬件相關(guān)的參數(shù)是不是最合適的。IOE 架構(gòu)之所以成為集中式架構(gòu)下的最佳組合，正是經(jīng)過廣泛的實踐和各種場景的錘煉，讓軟硬件都能在一個最佳的狀態(tài)下提供服務(wù)。最終經(jīng)過這次事件之后，大家統(tǒng)一認識，調(diào)整參數(shù)并不能根本性解決問題。原來部署在 SAN 存儲上的 OceanBase 遷移到了本地盤硬件設(shè)備上，隨后也逐漸演進到兩地三中心多活架構(gòu)部署。
1.5.3 執(zhí)行計劃跳變導(dǎo)致業(yè)務(wù)卡頓
如果一個數(shù)據(jù)庫廠商說 100%兼容 Oracle，保證遷移過程不出任何問題，那一定是自吹。即便做到了事前壓測充分，且盡量覆蓋完所有業(yè)務(wù)場景。但對于割接上線后的系統(tǒng)穩(wěn)定性、兼容性還是要畫問號。保證遷移過程中不出問題的關(guān)鍵在于，是否有及時有效的監(jiān)控，以及出現(xiàn)問題后的快速應(yīng)急手段。已經(jīng)投產(chǎn)的應(yīng)用，應(yīng)急應(yīng)該放在第一優(yōu)先級。
在 11 月份某個周末，理賠系統(tǒng)出現(xiàn)慢 SQL，導(dǎo)致理賠應(yīng)用系統(tǒng)票據(jù)匯總操作卡頓超時。為什么系統(tǒng)已經(jīng)穩(wěn)定運行了半個多月，沒有任何的業(yè)務(wù)變更，反而在周末業(yè)務(wù)低峰期出現(xiàn)問題？現(xiàn)場交付專家經(jīng)過分析很快定位到原因：OceanBase 的執(zhí)行計劃發(fā)生了跳變，導(dǎo)致執(zhí)行計劃走錯。
交付專家經(jīng)過進一步深入分析發(fā)現(xiàn)：OceanBase 和其他數(shù)據(jù)庫一樣，通過使用執(zhí)行計劃緩存(Plan Cache)，對于相同的 SQL（參數(shù)不同），跳過解析階段，避免重新生成執(zhí)行計劃，以提升 SQL 的性能。但是早實際場景中，傳入的參數(shù)往往是不同的，就像淘寶雙 11 有熱點庫存，在保險行業(yè)也有大小機構(gòu)號。雖然 SQL 看起來一樣，但因為傳入的參數(shù)不同，優(yōu)化的手段和執(zhí)行的路徑也不一樣。傳統(tǒng)數(shù)據(jù)庫（比如 Oracle）為了選擇最優(yōu)的執(zhí)行計劃，會定期進行數(shù)據(jù)對象統(tǒng)計信息的收集（如每天夜間的維護窗口（maintenance window）），淘汰舊的執(zhí)行計劃，使新的執(zhí)行計劃能夠按照實際的數(shù)據(jù)統(tǒng)計信息生成更準確更優(yōu)的執(zhí)行計劃。OceanBase 采用類似的方法，但由于 OceanBase 每天進行數(shù)據(jù)凍結(jié)合并，增量數(shù)據(jù)落盤，數(shù)據(jù)庫對象的實際數(shù)據(jù)信息（行，列，平均值等）會發(fā)生較大的變化。因此合并以后，計劃緩存會進行清理，并根據(jù)第一次傳入的參數(shù)生成執(zhí)行計劃進行緩存，默認情況下，只會保留一個執(zhí)行計劃。由于周末當時第一次傳入的參數(shù)不具備普遍代表性，導(dǎo)致后續(xù)執(zhí)行計劃走錯，產(chǎn)生了性能問題。
執(zhí)行計劃跳變是一個比較常見的數(shù)據(jù)庫性能現(xiàn)象。Oracle 先后推出了 Cursor Sharing，Outline，Bind peeking，ACS，SPM 等手段來優(yōu)化改進，然而生產(chǎn)上也無法徹底規(guī)避執(zhí)行計劃走錯的問題，新的數(shù)據(jù)庫產(chǎn)品從 Oracle 99%到 100%的兼容優(yōu)化也是最難的，也不是短時間能一蹴而就。對于這種小概率事件，應(yīng)急就成為了最后的兜底手段，在不動應(yīng)用的大前提下，通過數(shù)據(jù)庫靈活的綁定執(zhí)行計劃，是出現(xiàn)突發(fā)問題時比較有效和容易落地的手段。實際整個遷移過程中，對于偶發(fā)的執(zhí)行計劃跳變，項目組也已經(jīng)駕輕就熟，沒有給遷移帶來意外影響。
1.6 整體效果
從 2020 年 9 月到 2021 年 9 月，一年的時間里，該公司近 100 個業(yè)務(wù)系統(tǒng)全面實現(xiàn)國產(chǎn)數(shù)據(jù)庫遷移，成為首家完成 100%核心業(yè)務(wù)系統(tǒng)國產(chǎn)數(shù)據(jù)庫遷移的大型金融企業(yè)，采用的數(shù)據(jù)庫中 OceanBase 和 PolarDB 用量占比超過 97%。
該公司通過數(shù)據(jù)庫的全面替換，實現(xiàn)了對數(shù)據(jù)資產(chǎn)的的全面安全保障能力，做到了：
1.100%數(shù)據(jù)庫技術(shù)棧的安全可控，擺脫對 Oracle 數(shù)據(jù)庫的依賴；
2.擺脫對小型機和高端存儲的依賴；
3.促進云原生和分布式數(shù)據(jù)庫應(yīng)用成熟，從可用到好用并取得性能提升；
4.數(shù)據(jù)庫服務(wù)集中管控，顯著降低硬件及整體運維成本；
5.真正的實時擴縮容和高可用能力，輕松應(yīng)對大促活動。
從完全封閉的體系架構(gòu)到逐步開放再到全面開放，該公司真正實現(xiàn)了對數(shù)據(jù)庫核心技術(shù)的自主掌控。得益于云原生架構(gòu)和分布式架構(gòu)的彈性和資源池化能力，也自此能實現(xiàn)“一庫多芯”，只需一條命令就可以把租戶切換到海光服務(wù)器節(jié)點，實現(xiàn)了國產(chǎn)硬件的平滑替換。
整體來看，該公司遷移后由于分布式數(shù)據(jù)庫提供的高效壓縮能力，存儲容量的大小只有原來的 1/3，加上高端小型機遷移到國產(chǎn)機架式服務(wù)器，設(shè)備投入節(jié)省近 2 億元。
硬件方面，該公司的數(shù)據(jù)庫服務(wù)器及存儲機柜數(shù)量利用率提高了 300%，設(shè)備功率下降至原有 1/3。經(jīng)測算，該公司全年可節(jié)約電力約近千萬度，為該公司數(shù)字化轉(zhuǎn)型提供了源源不斷的綠色動能，有力踐行了國家雙碳戰(zhàn)略，部分沖銷了公司由于自建數(shù)據(jù)中心帶來的碳排放增量。
2、 總結(jié)
行業(yè)角度看，今天國內(nèi)大部分金融機構(gòu)的核心業(yè)務(wù)仍然運行在國外的數(shù)據(jù)庫上，這是一個我們無法回避的現(xiàn)實。數(shù)據(jù)庫的替換不僅是一個產(chǎn)品的替換，替換的目的不單純?yōu)榱恕皣a(chǎn)”兩個字，更重要的是：技術(shù)必須進步；替換后的新系統(tǒng)必須具備老系統(tǒng)和國外產(chǎn)品不具備的能力，不僅是性能和穩(wěn)定，更多是對業(yè)務(wù)的敏捷支撐能力，和面對海量業(yè)務(wù)和不確定性的業(yè)務(wù)高峰時刻的處理能力，以及更上一層樓的金融級高可用能力。
這些年我們看過很多內(nèi)容對于數(shù)據(jù)庫替換進行了分析和暢想，但是在面對實際的大規(guī)模復(fù)雜的核心應(yīng)用系統(tǒng)的技術(shù)平臺替換過程中，尤其對于現(xiàn)有運行的環(huán)境的各種適配和兼容，對應(yīng)用的友好性等需要實踐出真知的問題。某超大型保險（集團）公司和阿里巴巴阿里云團隊一同堅定實現(xiàn)的國產(chǎn)數(shù)據(jù)庫全面遷移，為行業(yè)積累了彌足珍貴的經(jīng)驗，也將為今后的國產(chǎn)數(shù)據(jù)庫遷移進程給出了很好的范例。
作者簡介劉偉光，阿里巴巴集團副總裁、阿里云新金融 &互聯(lián)網(wǎng)行業(yè)事業(yè)部總經(jīng)理，CF40 理事，畢業(yè)于清華大學(xué)電子工程系。加入阿里云之前，在螞蟻金服負責(zé)金融科技的商業(yè)推廣和生態(tài)建設(shè)工作以及螞蟻區(qū)塊鏈的商業(yè)拓展工作；他在企業(yè)軟件市場深耕多年，曾經(jīng)創(chuàng)建 Pivotal 軟件大中華區(qū)分公司，開創(chuàng)了企業(yè)級大數(shù)據(jù)以及企業(yè)級云計算 PaaS 平臺的市場先河。在創(chuàng)建 Pivotal 中國軟件公司之前，劉偉光曾經(jīng)擔任 EMC 公司大中國區(qū)數(shù)據(jù)計算事業(yè)部總經(jīng)理，并在 Oracle 公司工作多年，曾經(jīng)創(chuàng)建了 Exadata 大中國區(qū)的產(chǎn)品事業(yè)部并擔任事業(yè)部總監(jiān)。
關(guān)鍵詞：遷移,成功,實踐,數(shù)據(jù),大型,金融,機構(gòu),國產(chǎn)
在線咨詢