河南移動是河南省規(guī)模最大、客戶最多、業(yè)務(wù)產(chǎn)品最先進、服務(wù)體系最完善的電信全業(yè)務(wù)運營企業(yè)之一。其原有核心營業(yè)系統(tǒng)用戶量超6000 萬、數(shù)據(jù)量超 80TB，面臨著數(shù)據(jù)容量大、業(yè)務(wù)連續(xù)性要求高等挑戰(zhàn)，亟需進行數(shù)據(jù)庫的分布式升級改造。經(jīng)過各項綜合評估，最終選定 OceanBase 作為其核心系統(tǒng)的分布式數(shù)據(jù)庫。在2024 外灘大會的OceanBase 見解論壇上，河南移動高級專家彭慶軍作為嘉賓受邀分享了河南移動營業(yè)系統(tǒng)核心數(shù)據(jù)庫分布式改造升級經(jīng)驗。他表示：基于自研軒轅數(shù)據(jù)總線替換方案，河南移動在兩個月內(nèi)完成了一套承載1500萬用戶的核心系統(tǒng)，從傳統(tǒng)數(shù)據(jù)庫到 OceanBase 的平滑升級，并取得運維效率顯著提升、7×24 小時穩(wěn)定運行的卓越成效。
01 建設(shè)背景：新一代IT架構(gòu)需要新一代數(shù)據(jù)庫
河南移動的現(xiàn)網(wǎng)即核心營業(yè)系統(tǒng)CRM呈數(shù)據(jù)容量大、業(yè)務(wù)并發(fā)高、連續(xù)性要求高、數(shù)據(jù)安全性高四大業(yè)務(wù)特征：
數(shù)據(jù)容量大。伴隨著業(yè)務(wù)發(fā)展，河南移動用戶數(shù)量現(xiàn)已突破6000萬，其營業(yè)核心系統(tǒng)數(shù)據(jù)量已超過80TB。相當(dāng)于每個庫擁有1500萬用戶，大約20TB數(shù)據(jù)。
業(yè)務(wù)并發(fā)高。單庫日SQL數(shù)量超40億次，日訂單量3千萬筆（含查詢工單），逢月末、月初業(yè)務(wù)量峰值更加持續(xù)增長。
業(yè)務(wù)連續(xù)性要求高。眾所周知，移動行業(yè)是涉及民生的基礎(chǔ)通信服務(wù)，需要為用戶提供7*24h電信級服務(wù)保障，業(yè)務(wù)中斷三個小時即為重大故障。
數(shù)據(jù)安全性高。核心營業(yè)系統(tǒng)數(shù)據(jù)庫存儲著超1500萬用戶的敏感信息和數(shù)據(jù)，數(shù)據(jù)不能錯、不能丟，且存儲和訪問安全要求高。
彭慶軍介紹，河南移動新一代IT架構(gòu)對數(shù)據(jù)庫有七大需求：高兼容、高可靠、高性能、高擴展、高容量、高安全、高運維。
對于當(dāng)時的河南移動來說，數(shù)據(jù)庫改造面臨成本高、訪問性能低、割接風(fēng)險大、替換周期長四大難題。傳統(tǒng)的數(shù)據(jù)庫替換方案主要圍繞功能、性能、運維，涉及數(shù)據(jù)庫和應(yīng)用系統(tǒng)兩方面，一般存在兩種替換方案：一，從Oracle遷移到國產(chǎn)數(shù)據(jù)庫，需要該國產(chǎn)數(shù)據(jù)庫完全適配應(yīng)用和兼容Oracle；二，應(yīng)用適配國產(chǎn)數(shù)據(jù)庫，這是目前數(shù)據(jù)庫替換采用的主流方案。
因為數(shù)據(jù)庫的替換歷來高風(fēng)險低收益，而通過應(yīng)用進行大量適配改造的換庫方式等于是單程車票，不僅并行期應(yīng)用存在兩個版本，且上線后難以回切，一旦替換后的新庫不滿足要求，再次替換的難度和風(fēng)險更高。有沒有第三種替換方案？
基于此，河南移動開始為核心系統(tǒng)探尋新的數(shù)據(jù)庫。根據(jù)河南移動的經(jīng)驗，數(shù)據(jù)庫選型可以分為兩個方面：一是如何評估一家數(shù)據(jù)庫企業(yè)”；二是如何評估一款數(shù)據(jù)庫產(chǎn)品。
在彭慶軍看來，第一要看企業(yè)的綜合實力，其次是企業(yè)的研發(fā)實力，最后需要關(guān)注這個企業(yè)做的產(chǎn)品是“長期主義”還是“短期的功利主義”。
02 兩個月完成割接上線，成效顯著
河南移動從選型到上線整體周期歷經(jīng)7個月。2023年5月，河南移動開啟國產(chǎn)數(shù)據(jù)庫選型，并重點關(guān)注幾大國產(chǎn)分布式數(shù)據(jù)庫；6月，河南移動選型集團公招標(biāo)中標(biāo)的OceanBase；9月，雙方團隊一起確認(rèn)升級改造方案；10月，召開國產(chǎn)升級啟動會；12月，核心系統(tǒng)成功割接上線。截止2024年9月底，河南移動核心營業(yè)系統(tǒng)數(shù)據(jù)庫已穩(wěn)定運行300余天。
彭慶軍介紹：在確認(rèn)升級改造方案時，團隊一直比較猶豫，因為核心系統(tǒng)升級至國產(chǎn)數(shù)據(jù)庫的動作很大，擔(dān)心分布式數(shù)據(jù)庫上線后運行不穩(wěn)，害怕沒有給業(yè)務(wù)帶來任何效益�；诖耍幽弦苿诱{(diào)研了已經(jīng)上線OceanBase的山東移動和江蘇移動。在聽取了兩地的實踐經(jīng)驗后，整個團隊心里底氣大增。10月份，正式啟動了核心營業(yè)系統(tǒng)數(shù)據(jù)庫的分布式產(chǎn)升級之路。最終僅用兩個月，當(dāng)年12月份即完成系統(tǒng)上線�！�
完成遷移升級之后，河南移動建設(shè)成效顯著，基本總結(jié)為“一少、二快、三穩(wěn)、四超”。
投入少。應(yīng)用不改，人力、資源、成本投入少，極大降低了國產(chǎn)數(shù)據(jù)庫替換成本。河南移動營業(yè)核心庫的分布式改造和以往數(shù)據(jù)庫的替換方式不同，不僅自有人員和應(yīng)用開發(fā)商投入特別少，而且核心營業(yè)庫的替換所需測試資源只有OceanBase數(shù)據(jù)庫的資源，先將OceanBase生產(chǎn)庫的資源做測試庫，做完適配驗證、性能壓測覺得可行后再轉(zhuǎn)為生產(chǎn)庫，就不需要搭建一套完整的測試環(huán)境；
替換快。生態(tài)不變，腳本不變，免學(xué)習(xí)，替換快，大庫兩個月、小庫一個月。河南移動有1500萬的營業(yè)核心大庫，兩個月就替換完畢；
割接穩(wěn)。風(fēng)險不升，應(yīng)用適配、性能測試360度全覆蓋，生產(chǎn)上線后性能和上線前壓測一致；
性能超。實現(xiàn)性能不降，緩存提效，連接增效，最佳配置模型，硬件加速，數(shù)據(jù)壓縮比高。
在營業(yè)系統(tǒng)核心數(shù)據(jù)庫上線OceanBase，河南移動運行效果顯著。下圖為割接前后對比，主要分為SQL執(zhí)行性能對比和數(shù)據(jù)庫性能對比。
SQL執(zhí)行性能對比顯示，通過跟蹤業(yè)務(wù)整體運行、高峰時段運行，對比 Oracle 與 OceanBase SQL 平均執(zhí)行時長，割接上線由平均 2.515 毫秒降低為 1.626 毫秒，性能整體提升 35.35%；通過跟蹤核心 CBOSS 業(yè)務(wù)運行情況，對比多天 Oracle 與 OceanBase SQL 執(zhí)行時長，割接上線后由原來平均 116 毫秒降低為 114 毫秒，平均節(jié)省 2 毫秒。
數(shù)據(jù)庫性能對比顯示，通過總線連接收斂能力，業(yè)務(wù)連接數(shù) 10760+ 不變的情況下，使用OceanBase進一步將數(shù)據(jù)庫活躍連接數(shù)由原來的 4765 壓降至 2140 ，數(shù)據(jù)庫連接收斂比提升 45.4%。替換完成后，經(jīng)歷多個賬期測試發(fā)現(xiàn)，整體業(yè)務(wù)運行穩(wěn)定，數(shù)據(jù)庫集群的平均資源利用率從7%-10% 提升至12%-20%，資源利用率大大提升。
從2023年12月份至今，河南移動核心營業(yè)系統(tǒng)穩(wěn)定運行，平穩(wěn)支撐多次月初、月末的流量高峰；與此同時，數(shù)據(jù)庫集群平均的資源利用率也非常穩(wěn)定，較原有集中式數(shù)據(jù)庫的CPU利用率提升8%-9%。
03自研軒轅數(shù)據(jù)總線中間件產(chǎn)品，助力數(shù)據(jù)庫升級
此前，河南移動CRM系統(tǒng)數(shù)據(jù)庫現(xiàn)網(wǎng)的部署架構(gòu)為集中式，各個應(yīng)用系統(tǒng)通過數(shù)據(jù)總線連到后端Oracle，該架構(gòu)共6個Proxy節(jié)點，中間通過SAN路由交換機連接后端的全閃存陣列，這種配置較此前Oracle小型機+集中的高端存儲性能提升明顯。
原集中式數(shù)據(jù)庫共6個RAC節(jié)點，共享存儲40TB，實際使用15TB左右，新分布式架構(gòu)將 9 個計算存儲合并為一個節(jié)點，總存儲量57TB。得益于OceanBase的數(shù)據(jù)壓縮功能，三副本架構(gòu)最終實際使用15TB左右，總占用容量和原庫基本持平。
新架構(gòu)前端應(yīng)用先連接軒轅數(shù)據(jù)總線，再連到后端OceanBase，共有12個節(jié)點，分為三個部分，每個部分有3個計算與存儲一體的節(jié)點，和3個OCP管理節(jié)點，從新架構(gòu)可以看出將路由器和比較昂貴的高端存儲進行優(yōu)化后，硬件成本得到一定下降，其數(shù)據(jù)庫容量也有了顯著提升。通過性價比高的本地存儲代替昂貴集中存儲，OceanBase全庫數(shù)據(jù)壓縮成效顯著，告別容量焦慮。在數(shù)據(jù)庫軟件許可成本層面，單臺x86主機的License費用僅為此前1/50，成本也實現(xiàn)了大幅下降。
新分布式架構(gòu)中的軒轅數(shù)據(jù)總線，作為河南移動自主研發(fā)的一款助力數(shù)據(jù)庫國產(chǎn)替代的數(shù)據(jù)庫中間件產(chǎn)品，以應(yīng)用不改、性能不降、風(fēng)險不升、生態(tài)不變?yōu)槟繕?biāo)，通過在業(yè)務(wù)應(yīng)用與數(shù)據(jù)庫之間增加一層“數(shù)據(jù)總線”抽象層，將國產(chǎn)數(shù)據(jù)庫替換中的四大難題上移至軒轅數(shù)據(jù)總線層解決，以此助力大規(guī)模高并發(fā)場景 OLTP 數(shù)據(jù)庫平滑國產(chǎn)升級，具有“投入少、替換快、割接穩(wěn)、性能超”四大優(yōu)勢。
應(yīng)用不改：不僅僅JAVA應(yīng)用不改，C、C++應(yīng)用，sqlplus、sqlldr、python腳本及配置全部不改，經(jīng)過1.5萬個以上的生產(chǎn)程序檢驗以及真實生產(chǎn)割接驗證，實現(xiàn)了國產(chǎn)數(shù)據(jù)庫無感知平滑上線的重大突破；
性能不降：將性能調(diào)優(yōu)的關(guān)注點從關(guān)注數(shù)據(jù)庫單次訪問性能上升到關(guān)注業(yè)務(wù)辦理每筆交易的整體性能，針對性地創(chuàng)造了高效緩存技術(shù)和連接收斂技術(shù)兩項創(chuàng)新點，使交易中訪問次數(shù)下降50%，連接數(shù)減少80%，從而實現(xiàn)了國產(chǎn)庫性能下降40%的前提下，交易性能整體不降的重大突破。
生態(tài)不變：針對國產(chǎn)庫替換后開發(fā)、運維人員整體轉(zhuǎn)型學(xué)習(xí)成本巨大的問題，打造了異構(gòu)數(shù)據(jù)庫混合組網(wǎng)能力和透明的數(shù)據(jù)庫運維工具兩項功能，新庫可異構(gòu)組網(wǎng)替換且完全繼承Oracle技術(shù)生態(tài)，從維護腳本、告警報錯、維護工具，全部訪問如初，無需改變，開發(fā)、運維人員無需改變技術(shù)棧，實現(xiàn)了數(shù)據(jù)庫升級過程中選擇權(quán)提升和替換后生態(tài)不變的可持續(xù)性突破。
總的來說，基于軒轅數(shù)據(jù)總線架構(gòu)，河南移動國產(chǎn)數(shù)據(jù)庫上線分4個步驟：第一步，應(yīng)用接入數(shù)據(jù)總線，實現(xiàn)應(yīng)用和數(shù)據(jù)庫解耦，從總線側(cè)獲取全量生產(chǎn)應(yīng)用SQL；第二步，部署國產(chǎn)數(shù)據(jù)庫，作為生產(chǎn)測試庫；第三步，流量回放及測試，將Oracle流量引入對應(yīng)國產(chǎn)數(shù)據(jù)庫，進行兼容性和性能的適配測試；第四步，一鍵切換，通過總線一鍵切換功能實現(xiàn)國產(chǎn)數(shù)據(jù)庫的生產(chǎn)上線。
軒轅數(shù)據(jù)總線為河南移動節(jié)省了數(shù)千萬應(yīng)用改造費用，同時為數(shù)據(jù)庫國產(chǎn)升級探索出了一條全新且可行的道路。
04實踐經(jīng)驗：應(yīng)用適配與性能提升
當(dāng)下，對于新建系統(tǒng)的國產(chǎn)數(shù)據(jù)庫升級改造往往會選擇基于新的數(shù)據(jù)庫進行開發(fā)，以避免適配遷移等問題，包括河南移動在內(nèi)的眾多企業(yè)數(shù)據(jù)庫系統(tǒng)國產(chǎn)升級往往是指存量系統(tǒng)的國產(chǎn)升級。
雖然很多國產(chǎn)數(shù)據(jù)庫的兼容性都可以達到90%以上，但不同應(yīng)用因這些不兼容的差異改造工作量不同，應(yīng)用改造費用評估標(biāo)準(zhǔn)很模糊，所以對于存量系統(tǒng)有升級改造需求的企業(yè)如何選型一款性價比高的數(shù)據(jù)庫是一個避不開的難題。以河南移動為例，彭慶軍介紹了其所在數(shù)據(jù)庫團隊的應(yīng)用適配和評估流程。
第一步，識別改造工作量。傳統(tǒng)方式是通過數(shù)據(jù)庫廠商提供的評估能力確認(rèn)數(shù)據(jù)庫中有哪些不兼容的語句，然后讓應(yīng)用花費大量人力通過排查代碼進行評估；河南移動評估方式是基于河南數(shù)據(jù)庫中間件的評估方案，記錄應(yīng)用到后端數(shù)據(jù)庫每個SQL的訪問情況，先將整個SQL進行回放以篩選不兼容的SQL，同時根據(jù)SQL的訪問記錄去反查每個不兼容SQL下有問題的應(yīng)用進程，統(tǒng)計出每個應(yīng)用進程有多少處不兼容點，初步確認(rèn)遷移改造的工作量；
第二步，對不兼容或不適配的SQL語句進行中間件改寫，使其符合目標(biāo)國產(chǎn)數(shù)據(jù)庫并且能夠在該數(shù)據(jù)庫順利運行。在這個過程中，河南移動自研了一套中間件產(chǎn)品軒轅數(shù)據(jù)總線，助力此次國產(chǎn)數(shù)據(jù)庫平穩(wěn)高效升級；
第三步，性能測試。傳統(tǒng)的性能壓測無法面面俱到，往往是通過主要業(yè)務(wù)根據(jù)日常配比去做測試。而河南移動采用的是真實全仿真的測試，將包括營業(yè)系統(tǒng)在內(nèi)的每一天的全量SQL語句，以200、300的高并發(fā)，分別在國產(chǎn)數(shù)據(jù)庫上進行壓力測試，并將測試出來的較慢的SQL與該數(shù)據(jù)庫一起進行優(yōu)化，通過評估后確認(rèn)具備上線條件。
在河南移動營業(yè)系統(tǒng)應(yīng)用適配和性能提升過程中，由于營業(yè)A庫數(shù)據(jù)量及每日歸檔量較大，原傳統(tǒng)集中式存儲空間緊張，歸檔過早清理導(dǎo)致OMS增量同步任務(wù)經(jīng)常中斷。在遷移演練階段，OMS產(chǎn)品通過多次及時發(fā)版提升了同步效率，最終在正式割接期間平穩(wěn)遷移完成，數(shù)據(jù)校驗100%一致。在特定統(tǒng)計場景營業(yè)日報業(yè)務(wù)內(nèi)，河南移動對遞歸查詢進行了優(yōu)化，進一步適配了OceanBase，性能獲得了明顯提升，目前的性能基本可以保證在40多秒內(nèi)進行查詢。
此外，河南移動還利用自研軒轅數(shù)據(jù)總線產(chǎn)品承擔(dān)了主要適配改造工作，解決了兼容性相對比較弱的一些問題代碼。比如面對高CPU利用率的函數(shù)切換到國產(chǎn)數(shù)據(jù)庫經(jīng)常會出現(xiàn)的一些難題，針對性地對 OceanBase 進行了一定程度的性能優(yōu)化。
可以說對比上面所提到的“單程車票”改造方法，基于軒轅數(shù)據(jù)總線架構(gòu)的國產(chǎn)數(shù)據(jù)庫升級方式是一張“往返車票”，支持無感切換回原數(shù)據(jù)庫。
寫在最后
未來，河南移動將持續(xù)推進B（業(yè)務(wù)支撐系統(tǒng)）/M（管理支撐系統(tǒng)）/O（網(wǎng)管支撐系統(tǒng)）全業(yè)務(wù)域升級改造，并結(jié)合特有軒轅數(shù)據(jù)總線產(chǎn)品，推進 OceanBase 生態(tài)構(gòu)建。
彭慶軍表示：OceanBase經(jīng)過了十年的內(nèi)部打磨，又經(jīng)過五年的外部推廣，作為一款頂天立地的產(chǎn)品，其未來發(fā)展大有可為。此次河南移動自研的軒轅數(shù)據(jù)總線可以幫助千行百業(yè)解決場景差異的SQL適配問題。相信在軒轅數(shù)據(jù)總線的加持下，會讓整個OceanBase分布式生態(tài)如虎添翼，為企業(yè)節(jié)省大量的改造費用，同時加快分布式數(shù)據(jù)庫改造推廣的進度，實現(xiàn)多贏！
