每日最新頭條.有趣資訊

去Oracle實錄:如何在線更換金融核心場景中的數據庫?

作者 | 王英傑

策劃 | 田曉旭

本文會分享陸金所在線換庫的全過程,詳細剖析陸金所設計的在線換數據庫方案,整套方案又是如何在一個複雜龐大的金融系統裡,通過多團隊緊密配合穩妥落地。希望閱讀本文之後,能夠讓大家深入了解金融核心系統去 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 的關鍵。

1

陸金所為什麽要全站去 Oracle?

陸金所為什麽需要啟動去全站去 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 打造“研發規範——研發工具——研發人員”的研發管理體系閉環。這一塊我們在後面會詳細展開,並向大家進行介紹。

2

技術選型:為什麽是 MySQL,又不僅是 MySQL

決定去 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。

3

陸金所去 Oracle 方案

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

去 O 雙寫和切換方案

陸金所去 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 和 M 之間快速切換

雖然去 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 變更的部門,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 多萬用戶無感知。

4

陸金所去 Oracle 方案的落地

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

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

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

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

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

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

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

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

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

5

經驗總結:談談企業去 Oracle 的目標

去 Oracle 的口號喊了很久了,但是為什麽要去 Oracle,去 Oracle 想要達到什麽樣的目標...... 有些企業可能沒有想得很清楚,所以我也想從自己的角度和經歷來談談去 Oracle 的目標。

目標一:省錢

去 O 完成後,使用“免費的開源數據庫 + X86 架構的 PCCookr”來搭建金融核心系統,真的很省錢。因為搭建金融核心系統從昂貴的高端伺服器、高端存儲和 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 公開課的視頻回放

https://www.infoq.cn/video/NAje834UlKY75bXVjMCN

點個在看少個 bug

獲得更多的PTT最新消息
按讚加入粉絲團