陸金所金融核心場景數據庫的去 O 之路

做者介紹:萬霽春，陸金所數據架構 DBA 團隊經理。

金融行業該如何在線替換金融核心場景數據庫？在 TUG 陸金所企業行活動中，來自陸金所的數據架構 DBA 團隊經理萬霽春老師分享了陸金所的去 O 之路，如下內容整理自當天活動分享實錄。

陸金所全站去 O  成果

陸金所全站去 O 項目從 2018 年中開始，整個項目遷移過程當中沒有作任何的服務降級，在不影響線上業務的狀況下，把全站 100% 的數據庫從 Oracle 無縫遷移到開源和國產數據庫上，其中包括：MySQL、 TiDB 及其餘開源數據庫。

整個遷移過程零故障、零風險，對用戶來講徹底沒有感知。陸金所去 O 數據庫覆蓋基金、網貸、信託、資管等全金融場景，同時也包括金融系統最核心的帳務、資金、支付、交易和資產系統，目前都已經運行在國產開源數據庫上面。

金融核心系統全站去 O 的挑戰

在金融核心系統持續對外提供服務的狀況下，實現更換全套數據庫是極具挑戰性的架構改造工做。

去 O 項目咱們把它稱之爲 CTO 項目，這個項目聽上去是由純運維或 DBA 團隊來主導實施的項目，但實際上替換一個異構數據庫在本質上是徹底不一樣的，它涉及到業務系統、應用系統裏全部的 SQL 代碼，換一個數據庫就要根據新的數據庫語法進行邏輯重構，因此這個項目的進展中不但有 DBA，有應用開發，還有整個架構團隊。引入一個新的數據庫系統會涉及到架構規範、開發規範、中間件引入等問題，須要架構團隊進行支持，一些 SQL 語句跟原來的使用方法徹底不同，其上層的業務邏輯須要進行修改，包括測試、開發、產品經理、業務方，在某些狀況下也須要介入。

在這樣一個多團隊參與的項目中，去 O 過程須要有嚴格的標準，而且要有嚴格的流程去監控這些規則是否有效落實到每一行代碼的改造和變動上，不然任何一個環節出現失誤均可能致使數據遷移過程當中不一致，或者業務邏輯在遷移過程當中發生變化。

金融系統去 O 的主要工做

金融系統去 O 分爲如下四個步驟：

• 第一，應用層的服務化改造；
• 第二，從 Oracle 數據庫到開源數據庫的數據字典的轉換，包括數據的遷移，以及遷移後雲端和目標端數據一致性的校驗；
• 第三，從 Oracle 到開源數據庫的 SQL 代碼語法適配改造和存儲過程改造；
• 第四，怎樣在不停機的狀況下把原來在 Oracle 上面的讀寫流量以很是快、很是穩妥的方式切換到新的數據庫上面，而且在切換以後，出現問題能夠隨時回滾。

其中提到的第一點就是服務化改造。在傳統的架構上 Oracle 數據庫會用得特別大、特別重，數據量動輒十幾個 T、幾十個 T，這些數據可能囊括陸金所全部業務線數據，所以一個數據庫會被上層幾十個、上百個應用同時鏈接、訪問，進行讀寫操做。

在這種架構中，去 O 工做很難有效推動，由於若是要遷移一張表，可能上層有不少關聯的應用要同時進行改造，應用間的相互依賴、相互耦合會制約項目的進展。因此咱們第一步是把這些數據庫對象的上層應用進行服務化，規定某一個庫，某一個 Schema 的某些表只能由某一個特定應用來訪問，這樣其餘要訪問這些數據的關聯應用就調用他的屬主應用進行數據的讀寫操做的訪問。這樣的話，咱們在去 O 的改造過程當中只要對這一個屬主應用進行改造，其餘相關聯調動應用就不須要關心底層用的是什麼數據庫。

服務化改造以後，咱們爲了去 O 項目的快速迭代，能夠在多個拆分後的業務域的屬主應用下面進行去 O 改造，由於相互的耦合性已經解開了，因此整個代碼改造能夠並行開始。

金融數據庫流水線式的開源改造

基於這套方法論，咱們總結出一套流水線式的開源數據庫的改造方案。

• 第一，高效數據庫異構遷移，能夠一鍵全自動化地把原來 Oracle 上的數據庫表對象直接作完數據字典的轉換，把數據遷移到新的數據庫上面；
• 第二，爲了便於應用代碼的 SQL 改造而作了一個 SQL 智能轉換的工具；
• 第三，存儲過程轉換工具，能夠輸入你的存儲過程， 幫你輸出，能夠直接在 Java 上運行一段代碼；
• 第四，在線換庫框架，即在作完應用和數據遷移改造以後，把流量從舊的數據庫切到新的數據庫。

首先是一鍵全自動化的數據庫底層遷移工具，它實現了從數據庫的字典轉換到全量同步、增量同步。增量同步這一步作完就能夠理解爲咱們已經作了一個異構的實時同步的數據庫，每當 Oracle 裏面有數據變化，MySQL 立刻就會獲得實時更新好的數據，保持實時同步的狀態。以後咱們會進行全量的 Oracle 和 MySQL 的數據校驗。數據校驗咱們會校驗到總體數據庫表的行數，包括每一行、每一個記錄、每一個字段裏面的值，包括它的精度、小數點，每一位數字都要保證嚴格一致的狀況下才知足咱們切換的條件。

整個遷移的過程當中咱們也支持數據庫的遷移改造。原來是一個庫的，咱們能夠在去 O 過程當中從原來的 Oracle 遷到多個 MySQL 或者多個 TiDB 庫上面，也能夠在一個大表的狀況下拆分紅支持多庫的分庫分表的形式，一樣也是能夠和上面的雙向同步的架構混合使用的。

第二個工具是咱們從 Oracle 到開源數據庫，目前是 TiDB 和 MySQL 的 SQL 語法兼容的智能化適配轉化器，如今能夠基於 Java 代碼的 Mybatis 的 SQLMap 文件，咱們會分析它的文件的結構，根據裏面 XML 的標籤提取出 SQL 語句，經過 SQL 語句把它拆解成詞素流  ，把每一個詞素進行分析，根據 Oracle 到  MySQL 特定的轉換的規則去把它轉換成 MySQL 的語句，而後再填充回 Mybatis 的文件。

這個工做主要爲了方便開發快速對應用代碼進行基於數據庫替換的改造工做。

存儲過程轉換工具整體和 SQL 轉換類似，也是把存儲過程自己的開發語言語法解析成 AST 的語法樹，而後根據這個樹上的每一個節點，它的元素類型和含義，轉換成 Java 代碼裏面所操做的對象。

最後是一個流量的切換的工具。這裏會有一個總開關，經過一個應用層的開關去控制當前要使用哪一個版本的 SQL map，並且總開關除了控制 SQL map，還能夠控制底層數據的同步流向。

在生產流量切換的時間點，咱們會對底層數據庫先同步切換，切換以後咱們會進行最後一次數據的增量比對，數據比對沒問題的狀況下，會把應用的開關流量直接切到新的 MySQL 數據庫上面，這時候 MySQL 進來的數據會立刻同步回 Oracle，若是發生一些意外情況，好比 MySQL 的執行效率忽然發生大的波動或遷移過程當中代碼改造有 bug，咱們能夠立刻經過開關切回 Oracle 模式。

流水線式去 O 改造效率提高效果

咱們能夠看到去 O 過程當中大部分工做集中在數據庫的遷移，還有開發人員的 SQL 應用改造和存儲過程的重構，咱們在這方面進行了相應研發，如今有兩個工具能夠支持咱們快速轉化，這也是整個去 O 過程當中效率提高最大的一部分。

有了這套方案，只須要作好計劃，制定好每個去 O 的業務批次。

由於咱們去 O 是根據表維度進行遷移，因此通常會針對某一個庫，根據業務模塊的分工確立好批次，而後有計劃地進行改造，按批次推動到線上，再進行每一批次的開關切換，這樣能夠減小整個數據庫流量切換的風險，保證每次切換控制都是某個業務線或者某一個功能模塊的變動操做。

去 O 先後數據庫運營成本比較

去 O 以前會用比較好的設備，用 Oracle 數據庫總體來支撐網站上層大部分的業務。去 O 以後，咱們主要用 X86 服務器，很是便宜，數據庫是用開源的或者是國產的。

去 O 以後咱們數據庫整個的服務器數量和實例數也大規模增加，底層用了本身研發的 DataBus 數據同步工具，它會把業務線寫入的數據實時同步到咱們後端分析型數據庫存儲引擎上面，像 ES、TiDB、Hbase、Clickhouse 都會有。由於原來在 Oracle 的一個大庫下面作些關聯查詢、統計計算比較方便，但去 O 以後這麼多數據分散在那麼多實例裏面，要作這方面的關聯查詢就須要藉助智能架構。

金融核心系統 100% 去 O 的收益

關於去 O 的收益總結以下：

• 下降運營成本；
• 核心技術自主研發，擺脫技術綁架；
• 提升整個陸金所研發部門的研發能力，在傳統架構上更多依賴數據庫自己的特性和它特有的一些功能去支持業務的正常拓展，但如今咱們能夠藉助更多、更好的中間件，包括用開源的技術去支撐業務更好的運行；

以上就是陸金所數據庫的去 O 之路，但願能對你們有所幫助。