陸金所目前已經完成全站 90% 以上的去 Oracle 工作，並且將在 6 月底前下線最後一臺 Oracle。他們是怎麼做到的？
在蒐集企業去 Oracle 實踐的過程中，我們發現很多企業都會依賴於雲廠商或者其它已經去 Oracle 成功企業的幫助，真正憑藉自己力量去 Oracle 的企業並不多。而今天我們介紹的去 Oracle 案例，恰恰就是憑藉自己力量去 Oracle 的一家企業，這家企業是陸金所。
陸金所去 Oracle 實踐開始於 2018 年年中，歷時 18 個月，將全站 90% 的數據庫、數千張表從 Oracle 無縫切換至 MySQL。InfoQ 記者為此獨家採訪陸金所去 Oracle 實踐的負責人王英傑，試圖為大家還原全過程。
陸金所的業務場景與去 Oracle 節奏
陸金所的去 Oracle 從 2018 年年中開始啟動，涉及大幾百個子系統，總數據量超過 PB 級，去除的 Oracle 數據庫覆蓋基金、網貸、信託、資管、銀行理財、證 券、保險、主賬戶等全金融場景，全程使用自動化平臺管控和推薦去 Oracle 實踐。
據王英傑介紹，“陸金所全部的研發和技術運營部門都參與了全站去 Oracle，至少有 500 人以上的開發、測試和運維工程師參與其中。”
如果從整個實踐過程來看，陸金所去 Oracle 實踐有三個比較關鍵的階段：
- 一是通過邊緣系統進行方案驗證階段；
- 二是去”O“自動化工具平臺構建和優化階段；
- 三是全自動化標準化去”O“落地階段。
去 Oracle 方案的選擇
與大多數企業去 Oracle 的原因相同，陸金所選擇去 Oracle 也是因為原有的 Oracle 數據庫架構擴展性很差，並且 Oracle 軟件授權費用太高，無法支撐陸金所從 2013 年到現在交易量井噴式暴增下的業務需求。
另外，隨著陸金所業務逐步擴展為基金、網貸、信託、私募、AI 理財、保險、銀行等全金融業務線，原來的 Oracle 數據庫不僅在容量上無法支持全金融業務場景，而且在監管上也不一定合規。
在去 Oracle 之前，陸金所對全站所有應用場景的各個接口和 SQL 進行了逐一審核，評定替代方案。結果選定了以 MySQL 作為主替代數據庫，同時因為 MySQL 無法支撐 Oracle 的所有場景，還引入了 Elasticsearch、Redis、TiDB、HBase 等多種存儲引擎，充分發揮這些存儲引擎在各自場景下的優勢，從而重構出一個合理的數據庫架構來無縫替換 Oracle。
陸金所現在的數據庫架構
陸金所對於去 Oracle 的核心訴求是在外部用戶不感知的情況下，更換掉核心數據庫。因此，陸金所研發了一套數據同步工具，以表為粒度，把 MySQL 作為 Oracle 的備庫，實時同步 Oracle 的 DDL 和 DML 變更。同時在應用層實現 Oracle 和 MySQL 兩套訪問數據庫的 DAO 層，以及開關模式的動態數據源，便於流量在 Oracle 和 MySQL 之間快速切換，在確保流量切換到 MySQL 之後，
數據還能夠反向向 Oracle 同步，保證數據一致性。
去 Oracle 的準備工作：按域拆分
為了順利完成去 Oracle 工作，陸金所在 2016 年到 2018 年期間進行了數據庫的按域拆分。據王英傑介紹，按域拆分的主要目的有三個，分別是：
- 細粒度拆分數據庫、分片化，實現數據庫容量的水平擴展；
- 應用解耦、服務化，讓應用訪問數據庫的調用更加清晰和規範；
- 嚴禁應用跨域訪問數據庫，嚴禁數據庫之間產生數據交互，從業務角度呈現出一個更加完善的數據庫架構。
整個按域拆分過程中比較大的難點是大事務拆分和多表關聯複雜查詢。王英傑表示：“單庫上原有的大事務拆分後是通過應用層的分佈式事務機制在多庫上實現，而單庫上原有的多表關聯複雜查詢在拆分之後，是在應用層實現或在特殊場景中通過分佈式存儲引擎來支持。”
據瞭解，陸金所的數據庫按域拆分主要有四個關鍵階段：
- 應用改造實現邏輯拆分：按表為粒度對大庫的數據庫對象進行梳理，把每張表歸屬於不同的應用域。在應用層根據梳理的結果對操作表的代碼進行改造，包括：拆分複雜的大查詢拆分龐大的事務操作表的代碼全部封裝在屬主應用的代碼中，非屬主應用無法直接操作表，通過調用服務接口的方式實現非常規範的應用訪問數據庫的調用鏈。
- 邏輯拆分完成後，以數據庫的角度對應用改造的結果進行驗證：在同一個物理庫，使用邏輯 schema 的方式對數據庫對象的授權進行調整，驗證應用改造符合預期。
- 數據庫遷移和實時同步：邏輯層拆分驗證完成後，通過實時同步把待拆分的數據庫對象實時同步到另外一個物理庫。上述所有改造步驟對應用層無感知。
- 物理拆分和切換流量：源端和目標端保持實時同步後，在某個時間點推送配置並切換流量。整個過程最好有一套完善的自動化運維確保各個細節工作的無縫落地。流量切換操作，必須確保可以隨時前滾和回滾。
去 Oracle 的具體實踐
講完去 Oracle 的方案和準備工作之後，接下來我們具體講講詳細的替代過程。
去 Oracle 前後的數據庫架構差異
在去 Oracle 之前，陸金所全站的金融 OLTP 業務場景都是由 Oracle 支撐的，而完成之後，全部的金融場景是由 MySQL 支撐，部分 Oracle 上的大事務也被優化成為了 MySQL 上的小事務。
值得注意的是，去 Oracle 完成之後，陸金所中 85% 的數據庫查詢請求都是簡單的單表查詢，15% 的關聯查詢都是比較簡單的關聯查詢，而原先 Oracle 數據庫中包含的複雜業務邏輯的多表關聯也做了以下的優化：
- 被拆解成簡單查詢，在代碼層實現部分複雜的關聯邏輯；
- 通過陸金所的數據總線平臺，把數據實時同步到 Elasticsearch 裡，在 Elasticsearch 裡實現複雜且高效的關聯搜索；
- 部分在 Oracle 讀庫上支撐的複雜業務邏輯查詢（支持業務監控和實時對賬等），通過數據總線平臺同步到 TiDB 裡，在 TiDB 裡實現複雜的關聯查詢。
具體遷移過程
在真正去 Oracle 之前，陸金所先把 MySQL 作為對外提供服務的 Oracle 備庫掛在了 Oracle 後面。與傳統備庫不同，從 Oracle 到 MySQL 的異構數據庫備庫，不需要實例級的數據同步，可以按表為粒度進行數據的實時同步。
陸金所整個去 Oracle 實踐主要是依賴於其內部的去 Oracle 平臺來落地的，在去 Oracle 平臺上勾選需要同步的 Oracle 表，數據遷移工作就會自動完成。據介紹，陸金所智能化去 O 平臺橫跨代碼改造到上線切換以及後期運維的全流程自動化保障和落地，其中主要包含的工具有：
- Oracle SQL 代碼自動轉 MySQL SQL 代碼工具
- O to M 數據字典轉化和管理工具
- O to M 數據自動遷移和雙寫工具
- 去 O 流量一鍵切換
- 跨機房一鍵切換去 O 自愈工具
據王英傑介紹，在陸金所去 Oracle 平臺中完成數據遷移的主要過程如下：
- 首先去 Oracle 平臺會解析 Oracle 表結構，並轉化成 MySQL 表結構部署到 MySQL 上。之後，Oracle 有任何數據字典變更，去 Oracle 平臺都會對 MySQL 進行同步；
- 將 Oracle 的數據全量同步至 MySQL，因為 Oracle 庫還在對外提供服務，所以會記錄同步開始時間點，發生過變更的 Oracle 數據；
- 在全量同步完成後，解析 Oracle 的 redo log，把同步期間發生過變更的數據進行增量追平；
- 增量追平後，比對 Oracle 和 MySQL 每一筆記錄和每一個字段的數據一致性，因為 Oracle 還處在不斷更新中，去 Oracle 平臺會使用增量補償重試的方式不斷對記錄進行一致性校驗；
- 當 Oracle 和 MySQL 數據完全追平且校驗一致後，去 Oracle 平臺會開始嘗試解析 MySQL binlog，建立從 MySQL 到 Oracle 的數據同步通道；
- 因為 Oracle to MySQL 和 MySQL to Oracle 的雙向數據同步鏈路都會被自動建立起來，為了防止數據迴流，必須區分好是應用層寫入的數據還是同步框架寫入的數據，確保一份數據無論在 Oracle 還是 MySQL 提交，都會同步到對端，且僅寫入一次。
據悉，陸金所核心業務去 Oracle 的時間大約是 6 個月，在這 6 個月中會出現應用中部分表讀寫流量在 Oracle、部分表讀寫在 MySQL 的中間狀態，而這時陸金所的業務系統還會有大量的功能版本不斷上線，如何平衡業務系統的版本上線和去 Oracle 的數據遷移呢？
王英傑表示：“為了降低業務功能改造和去 Oracle 架構改造之間高頻交叉上線的風險，陸金所自研的 Bettle 系統實現了業務版本和去 Oracle 版本並行推進，且互相透明的重要功能。”
遷移完成之後，陸金所每 3 個月會通過數據庫一鍵切換平臺把全站數據庫寫庫更換一次，一鍵切換平臺在 180 秒完成全站數百套數據庫的跨機房切換後，數千張表的 O 和 M 雙寫同步會自動重建，並確保數據一致性和完整性。
經驗總結
作為去 Oracle 的實踐者，王英傑也分享了他在整個實踐過程中獲得的感悟和經驗，希望能對之後想要去 Oracle 的企業有所幫助。
- 對於嚴苛的金融系統來說，去 Oracle 是個非常複雜的系統工程，涉及到開發、測試、架構和 DBA 等幾乎全部技術部門的通力合作；
- 整個去 Oracle 改造過程需要在各個階段都總結出一套完善的方法論，確保各個細節改造工作能穩妥落地；
- 需要有一套完善的去 Oracle 工具平臺來落地整套方法論，讓開發、測試和 DBA 在上面開展去 Oracle 工作，通過工具無縫銜接好這些團隊在去 Oracle 改造中的協同工作，通過工具來確保從代碼改造、到壓測、到數據遷移、到流量切換等橫跨多個團隊、長週期的工作風險可控，效果如期。
嘉賓介紹：
王英傑，陸金所數據架構團隊負責人，負責陸金所全站存儲引擎運營和智能化工具研發。
關注我並轉發此篇文章，私信我“領取資料”，即可免費獲得InfoQ價值4999元迷你書！
閱讀更多 InfoQ 的文章
關鍵字: ElasticSearch 所去
