本文會分享陸金所在線換庫的全過程，詳細剖析陸金所設計的在線換數據庫方案，整套方案又是如何在一個複雜龐大的金融系統裡，通過多團隊緊密配合穩妥落地。希望閱讀本文之後，能夠讓大家深入了解金融核心系統去 Oracle 的難點和風險，并給想去 Oracle 但是不敢落地實施的同學提供真正的實戰案例解決思路。

陸金所從 2018 年啟動全站去 O 項目以來，在不做任何服務降級的情況下，曆時 2 年通過上百次變更，把全站 98% 的 Oracle 數據庫無縫切換到 MySQL 上。其中，這 98% 的數據庫覆蓋了陸金所的賬務、資金、資産中心、支付、交易、用戶、基金、主賬戶、網貸、資管、銀行理财等全金融場景。整個去 O 的全程 0 故障、0 風險、對用戶幾乎不感知。

陸金所去 Oracle 實踐有四大特點：

一是在線更換數據庫，不做服務降級。讓去 O 這類重大架構改造實施落地的時候對全站用戶影響最小，同時也最考驗去 O 的架構改造的技術實現能力。

二是對于高頻上線了上百次的去 O 變更，全程 0 故障、0 風險，這一點非常考驗陸金所去 O 的變更工具水平。

三是在短短 24 個月的時間完成全站 98% 的數據庫去 O 改造，并且涉及陸金所全部最核心的業務，去 O 的整體落地效率非常快。

四是在去 O 各個環節實現了從開發、測試到運維各種自研智能工具來把控去 O 各個核心環節的質量，這也是把一個龐大、複雜、高風險的金融核心系統，在非常短的時間内 0 風險、0 故障，穩妥落地去 O 的關鍵。

陸金所為什麼需要啟動去全站去 O，并且是 100% 全部去 O。

在去 O 項目立項之初，我們希望通過去 O 來實現三個方面的提升。

首先是降低昂貴的金融系統數據庫運營成本。2013 年至 2018 年期間，陸金所的業務成長了上百倍。業務量增長帶來的數據庫運營成本暴增。無論是傳統的 IOE 架構還是去 IE 後的 X86 Oracle 分布式架構都是如此。IOE 架構下，高端服務器和高端存儲的價格随着提供的計算和 IO 能力呈現指數型增長。X86 Oracle 架構下，分布式改造和數據庫細粒度水平拆分後雖然沒有 I 和 E 的成本，但數據庫節點暴增後導緻 Oracle 軟件授權費用暴增。

其次是希望通過去 O 來打造一個不依賴特定數據庫特性的金融交易系統，徹底擺脫被商業數據庫廠商技術綁架的風險。傳統金融交易系統使用數據庫特性承擔了大量的業務邏輯和架構屬性，造成系統對某個數據庫特性的強依賴，也大大增加了被技術綁架的風險。陸金所通過全站去 O 實現了把金融交易系統裡數據庫的角色轉化為隻支持基本增、删、改、查的存儲引擎，全站系統架構弱依賴數據庫特性。

最後一點也是最重要的一點，我們希望通過全站去 O 這樣一個涉及到開發、測試、架構、DBA 等全部研發團隊都參與的重大架構改造項目，來鍛煉研發隊伍、提升研發能力，并把曆史上一些架構設計不完善的地方，通過全站去 O 進行重構。因為去 O 不僅僅是更換數據庫，更重要的是落地架構拆分、微服務化、分布式事務等配套的大量架構改造工作。這些工作需要開發、架構、測試、運維高度協同配合，并穩妥落地。所以去 O 是非常考驗研發團隊技術水平的架構改造項目。通過，我們也希望通過去 O 打造“研發規範——研發工具——研發人員”的研發管理體系閉環。這一塊我們在後面會詳細展開，并向大家進行介紹。

決定去 Oracle 之後，選擇什麼數據庫或存儲引擎來承載 Oracle 的流量？我們從功能、資源、案例和壓測四個方面來進行選型和評估。

首先，選擇的數據庫要從功能和性能上能夠承接 Oracle 在各種場景下計算和 IO 能力。其次，它還要具備最廣泛的社區資源、技術資料和問題處理案例，通俗的說就是大量坑被踩過，以及最廣泛的用戶基礎，外面招開發和運維工程師都比較好招。然後，還要在業界有可參考的金融場景案例。這一點相信大家都很熟悉，阿裡和騰訊在金融場景上已經有不少成功的案例。

最後，同時也是最重要的一個評估标準就是陸金所自身上線前嚴格的壓測環節。陸金所在切換任何一張表流量的時候，都會使用生産環境完全真實的數據搭建 O 和 M 并行壓測環境，來獲取訪問這張表的所有讀寫接口的在 Oracle11.2 和 MySQL5.7 下的性能比對報告。經過每一輪非常嚴格的壓測後，發現 MySQL5.7 的性能比我們預估中的更好。通過從邊緣系統往核心系統的逐步去 O 演進中，MySQL5.7 就成為陸金所去 O 最主要的替代存儲引擎。

我們都知道 Oracle 是個非常優秀、且覆蓋場景非常全面，無論是 OLTP 還是 OLAP 場景表現都很優秀，所以這種功能承接應該遠遠不止一種數據庫或存儲引擎，涉及到多種存儲引擎發揮他們的優勢在各種特定場景下來替換 Oracle。

所以最終的結論是綜合選型下來确定 使用 MySQL 為主，TiDB、Redis、ES、HBase 等多種存儲引擎為輔的方式，100% 全部替換掉 Oracle。

接下來，我們就詳細介紹陸金所的去 Oracle 方案。

陸金所去 Oracle 改造主要是分為應用和數據庫兩個部分來落地的。

首先介紹一下應用層部分的落地。應用層在去 O 的時候會做一個整體規劃，把一個大的系統或庫拆分成多個可獨立落地的批次，然後會把應用的業務邏輯層從數據庫的訪問接口盡可能剝離出來，讓 DAL 層專注隻做好數據庫交互的操作。同時，在 Oracle DAL 層的基礎上，對 MySQL DAL 層的進行重構，并且配置流量開關讓上層的業務邏輯層可以自由選擇和數據庫的交互是走 Oracle DAL 層還是 MySQL DAL 層。每個批次都會有自己單獨的流量開關進行控制。批次拆分的時候遵循一個原則就是把具備業務相關性和事務相關性的表放在一個批次裡。

再說數據庫層的落地，在 Oracle 還在不斷對外提供服務的時候，我們會在後台建立起一個和 Oracle 保持實時數據同步的 MySQL 數據庫，即當 Oracle 的事務提交後，秒級同步到後端的 MySQL 裡面。同時這個同步是雙向的，當未來流量切換到 MySQL 後，也會在 MySQL 事務提交完成後，把數據秒級同步回 Oracle，這就類似 MySQL 的雙 master 架構，隻不過數據是在 Oracle 和 MySQL 這個異構數據庫之間建立雙 master 架構。

在這個架構中為了确保數據庫的一緻性和完整性，一定是嚴格要求某個批次的寫流量隻能在某個時間點隻能在 O 和 M 一個地方寫入。陸金所研發了一整套自動化構建數據庫雙寫的工具平台，隻要在平台上選擇需要建立批次的 Oracle 表，就能在後台全自動完成 Oracle to MySQL 從表結構轉化、數據全量同步、數據增量同步、數據實時同步、數據校驗和數據雙向同步建立整個全流程繁瑣。依據這套自動化平台，陸金所隻投入 2 個 DBA 就完成了全站上萬張表的去 O 數據庫遷移和運維層的全部準備工作。

最後是流量切換，我們設計并研發了一套總控開關機制來協調從應用、到數據庫、到傳輸、最後到流向的全盤流量切換。實現當流量在 O 時，實時同步到 M。當流量在 M 時，實時同步到 O。保證切換一瞬間，最後一筆事務在源庫提交成功，在目标庫傳輸成功，并完成最後一筆事務的數據在源庫和目标庫的數據校驗後，同一個批次下所有表的寫流量在同一個時間點同時完成切換。

雖然去 O 流量切換會在 10 秒内瞬間完成，但整個過程按照細粒度劃分會有十多個步驟。為了方便介紹，我們把這十幾個步驟精簡成了三個狀态。

首先是初始狀态，這個狀态下生産的隻讀流量可以在 Oracle 或 MySQL，寫流量可以在 Oracle，由 Oracle 對外提供服務。這個狀态狀态可以理解為 Oracle 為主庫，MySQL 為 Oracle 的異構實時備庫。

其次是中間狀态，這個狀态下 Oracle 和 MySQL 會進入一個非常短暫的寫保護靜止狀态。在完成最後一筆 Oracle 事務提供成功，并同步至 MySQL，且完成最後一筆數據一緻性校驗後，會把應用開關的流量切換到 MySQL，這個時候這個批次的寫流量在某個時間點全部一緻性都切換到 MySQL。

一旦在 MySQL 裡寫流量進來，就進入了第三個狀态即完成狀态，一旦寫流量的事務在 MySQL 中提交成功，雙向實時同步鍊路會把 MySQL 的數據秒級同步回 Oracle，這個時候可以理解為 MySQL 是主庫，Oracle 是 MySQL 的實時備庫。

需要注意的是，這個架構下需要解決大量的細節問題，比如避免同一筆記錄雙向循環寫的問題。

陸金所實現的這個雙寫框架流量切換速度極快，在數秒内就能實現有狀态的寫流量從 O 到 M 的快速切換，整個過程在低峰期落地對業務影響非常小，甚至是不感知。如果在去 O 之前在 Oracle 内部已經完成了對用戶的水平拆分，以批次和用戶雙重細粒度進行去 O 流量切換，那麼整個更換數據庫過程幾乎是無感的。

在流量從 O 切換到 M 後，以陸金所落地的經驗來看，大概有一定概率（比如程序的 bug）需要回切到回 Oracle。這套切換框架可以确保在幾秒内流量快速回到 Oracle，且在 MySQL 寫入的少量數據也會同步會 Oracle，且在保證 Oracle 和 MySQL 兩邊的數據嚴格一緻性和完整性的過程中，進行流量的快速前滾和回滾。

了解了去 O 流量切換的架構和方案，接下來我們介紹如何在一個關聯系統龐大、業務邏輯複雜、改造風險極高的金融核心系統裡落地整個去 O 方案。

首先我們會以表為粒度來把一個複雜、龐大的金融核心系統和數據庫拆分成多個批次，拆分的原則上面也提到了一點，即把有業務相關性和事務相關性的表放在同一個批次裡，在确保這個基本原則的情況下，把單個大庫盡可能的拆分成多個批次，确保每個批次裡的表盡可能的少。

為什麼要基于這個原則來落地實施呢，因為批次是去 O 變更的單位，O 和 M 之間的流量切換開關是控制到批次的。把批次拆分的足夠細，最終目标是為了實現“改造難度可控、上線進度可控、切換風險可控”的 3 原則。

首先對于金融核心系統中一個複雜的模塊來說，去 O 改造的周期會橫跨半年甚至一年以上，在這個過程中，金融核心系統在 7*24 小時不間斷對外提供服務，應用層的代碼和功能每個月甚至是每周也處在高速疊代中，不斷的新功能被加入到系統并被發布到生産。

而在這個過程中，要落地去 O 這類龐大的架構改造，必須框定一個可快速疊代和實施的改造範圍，批次就是一個合理設定的單次去 O 改造和變更的範圍。批次拆分的粒度細，可以确保在單個批次的去 O 改造工作量可控、改造難度也可控。

同時因為批次的粒度細，在做去 O 變更切換流量時，對整個金融核心系統的影響也可控。基于這種思路，就可以實現“小步快跑”的高速疊代方式來改造應用、上線版本以及切換流量。即每次隻改動核心系統的一小部分，改動完成後快速測試、快速發版上線、并且風險可控的把這部分流量切換到 MySQL 運行，如果有問題依靠強大的流量切換框架，快速把流量回切回 Oracle。

從圖中大家可以看到一個龐大的金融核心系統去 O 改造中，應用改造、上線版本和流量切換這 3 件事情實在并行落地的。

最開始是應用改造，改造完了上線發版，發版後就有了這個批次 O 和 M 的流量開關，并具備了切換條件，之後在某個變更日把流量從 O 切換到 M，如果遇到任何問題可以快速切回來。應用版本在不斷上線疊代，流量在分批次不斷切換，一個龐大的金融核心系統就在多次高速疊代中一點點的從 O 切換到了 M。

整個過程對核心業務不影響、不感知，且對參與去 O 的開發、測試和運維開展去 O 工作非常友好，讓他們可控的去落地各項工作。

在這個過程中，從第 1 張表從 Oracle 切換到 MySQL，到最後一張表關閉 Oracle 流量，在非常長的一段時間内，整個應用是由 Oracle 和 MySQL 在同時提供服務。其中某些表已經完成去 O，讀寫的流量在 MySQL 上，由 MySQL 同步到 Oracle，部分表還未完成去 O，讀寫流量在 Oracle 上，由 Oracle 同步至 MySQL。這就非常考驗運維的能力，要确保在這個架構下每天高頻的各種發版和數據庫變更都非常準确。

基于此，陸金所是有研發一整套配套去 O 變更工具，來确保整個去 O 過程中大量變更準确實施和落地。以陸金所交易、主賬戶、資産中心、基金、賬務等核心庫為例，從第一張表流量切換到 MySQL 到最後一張表切換到 MySQL，曆時 12 個月以上。按照上述方案一點一點的替換掉 Oracle 數據庫，整個過程完全不做服務降級，對陸金所的 4500 多萬用戶無感知。

在 PPT 中畫出去 Oracle 的架構圖是很簡單的事情，但是架構改造的難點和重點在于落地。要在生産環境落地是非常龐大且複雜的系統工程，尤其是對一個 7*24 小時的金融核心系統來說，進行重大架構改造本身就是一件高風險的工作，既要做到規避風險，确保各種工程實現細節有效落地，同時又要保證系統的業務連續性，甚至是對外部用戶不感知。

去 Oracle 架構改造的本質是什麼？我覺得有兩方面，一是細節規則，二是上生産前發現和上生産後兜底。

去 O 的重點不僅僅是方案本身，更重要的是組成方案的數百條細節規則，能在一個參與去 O 的、龐大的研發團隊裡每個開發所寫的每一行代碼都有效遵守規則，同時在每個運維設計的生産變更方案裡每一條命令都有效遵守規則。方案通過從邊緣系統往核心系統逐步推進過程中，會逐步趨于完善，方案中的規則也會被逐步積累和完善起來，那麼把這些規則落地到研發團隊的每個人上，是關鍵和重點。

上生産前發現是指如果規則在某個微小的細節實施時沒有被遵守，如何盡可能的在上生産環境之間發現隐患。上生産後兜底如果問題突破了所有檢測環節上了生産，如何設計一個兜底方案可以有效控制風險，把影響盡可能降低。

去 Oracle 落地工作都應該圍繞有效解決這兩個本質問題展開，并提升這兩個問題的解決效率，降低人力成本。

陸金所的做法是建立“人員——規則——工具”的閉環。

陸金所通過“人員制定規則——規則通過工具落地——工具确保所有人員的代碼和變更符合規則”的方式來确保各種細節工作落實到位，整套工具最終沉澱為陸金所數據庫升級平台。

以陸金所的去 O 落地經驗來看，一個不起眼的細節問題如果未進行有效管控，都有可能引發嚴重的生産故障。所以我們可以把陸金所數據庫升級平台理解成為一套強大的去 O 風控系統。這套風控系統覆蓋 SQL 重構、表結構轉化、數據遷移、數據校驗、分布式事務構建、流量切換等橫跨從開發到運維在去 O 架構改造方方面面會遇到的問題。通過這套工具平台，有效确保參與去 O 的研發團隊在每個細節上都處理的非常規範，從而實現曆時 24 個月的全站去 O，無風險平穩落地。

除了确保各種規則精準落地外，金融核心系統去 O 改造需要多個研發團隊協同作戰、有效配合、共同推進。其中涉及到大量工程實現細節工作需要多團隊有條不紊、事無巨細的協同配合好。任何疏漏都有可能會引發嚴重的生産故障。

去 Oracle 的口号喊了很久了，但是為什麼要去 Oracle，去 Oracle 想要達到什麼樣的目标…有些企業可能沒有想得很清楚，所以我也想從自己的角度和經曆來談談去 Oracle 的目标。

去 O 完成後，使用“免費的開源數據庫 X86 架構的 PC Server”來搭建金融核心系統，真的很省錢。因為搭建金融核心系統從昂貴的高端服務器、高端存儲和 Oracle 一體機，以及昂貴的 Oracle 軟件授權變成隻需要 6 萬一台的 X86 服務器，花在數據庫上的運營成本降為之前的 10% 不到。

在整個去 Oracle 的過程中，陸金所架構從一個傳統金融的超大型數據庫支持各種核心業務的架構變成了以微服務化驅動的分布式架構，這種架構具備以下特點：

• 每個服務有自己獨立的應用和數據庫。
• 每個庫隻提供給服務内的應用直接訪問，即服務内的應用可以通過 SQL 訪問。
• 服務之外的應用訪問數據庫需要走應用層的服務接口，避免跨服務訪問數據庫。
• 服務分為同步調用和異步消息。
• 在服務内實現數據庫的水平擴展。
• 對于類似用戶、交易、資金等公共類基礎服務，逐步疊代為中台服務。

通過微服務化拆分，幾套集中式的 IOE 大庫就變成了微服務小庫，同時對于訪問量和數據量較大的中台服務，又會進一步細粒度水平拆分。

除了降低成本，我認為更重要的是通過去 O 實現傳統金融系統全方位的架構升級和改造。

對于一個傳統金融系統來說，借助去 O 來實施和落地全系統的架構改造和升級，應該是一個再好不過的機會。以陸金所為例，通過去 O 實現了以下的升級和改造：

• 數據庫底層計算和 IO 能力的水平擴展，并且這種水平擴展完全基于 6 萬一台的 X86 服務器，擴容成本極低。
• 同時實現了應用訪問數據庫的規範化，應用和應用之間的服務化。全站的調用鍊會非常清晰，應用和數據庫之間不合理的依賴将大幅降低。
• 另外實現數據庫層去中心化，單個數據庫的可用率對全局可用率影響有限，消除中心化的單點隐患
• 最後借助去 O 實現的分布式架構，可以把各個分片的數據庫部署在不同的機房，從而實現真正意義上的機房多活。

提到去 Oracle，可能很多人在第一時間就想到了 MySQL。其實，MySQL 是承接 Oracle 主要流量的數據庫，但 MySQL 無法承接 Oracle 的全部流量，例如以下幾類經典場景：

• Oracle 在 oltp 場景當中少量 hash join 查詢場景。
• Oracle 中多表關聯和多層複雜嵌套查詢場景。
• MySQL 細粒度拆分後，跨庫、跨分片的查詢場景。
• 在 MySQL 集群和 Hadoop 集群之間構建一個秒級數據同步的 ODS 層。

在這些場景中，可以引入 TiDB、Elasticsearch、Impala kudu、Redis 等多種存儲引擎。這些存儲引擎在合适的場景下替換 Oracle，産生的效果是不但比 IOE 架構成本低得多，性能也會比 Oracle 快得多。

我們以 TiDB 為例來講講使用 MySQL 之外的存儲引擎是如何支撐 Oracle 流量的。

陸金所有個實時對賬的場景，需要跨用戶庫、交易庫、資金庫和資産庫進行複雜的關聯查詢。在完成去 O 後，數據庫在 MySQL 上做了細粒度拆分，無法跨多個獨立的服務庫進行複雜且高頻的跨庫查詢。

為了支持這個場景，我們研發了數據總線來實施解析 MySQL binlog 并生成消息同步至 TiDB，事務在 MySQL 提交後實現秒級同步至 TiDB。之後通過 TiDB4.0 的 TiFlash 功能（類似 clickhouse 的列式存儲），在 MySQL 和 Hadoop 之間搭建一個實時 ODS，實現了秒級處理跨庫、多表、複雜關聯的查詢場景。性能遠超去 O 之前在 IOE 架構下的處理結果。

更多實踐細節，可以點擊了解更多查看

關注我并轉發此篇文章，私信我“領取資料”，即可免費獲得InfoQ價值4999元迷你書！

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!