陸金所去 Oracle 實(shí)踐有四大特點(diǎn):

一是在線更換數(shù)據(jù)庫,不做服務(wù)降級(jí)。讓去 O 這類重大架構(gòu)改造實(shí)施落地的時(shí)候?qū)θ居脩粲绊懽钚?同時(shí)也最考驗(yàn)去 O 的架構(gòu)改造的技術(shù)實(shí)現(xiàn)能力。

二是對(duì)于高頻上線了上百次的去 O 變更,全程 0 故障、0 風(fēng)險(xiǎn),這一點(diǎn)非常考驗(yàn)陸金所去 O 的變更工具水平。

三是在短短 24 個(gè)月的時(shí)間完成全站 98% 的數(shù)據(jù)庫去 O 改造,并且涉及陸金所全部最核心的業(yè)務(wù),去 O 的整體落地效率非常快。

四是在去 O 各個(gè)環(huán)節(jié)實(shí)現(xiàn)了從開發(fā)、測(cè)試到運(yùn)維各種自研智能工具來把控去 O 各個(gè)核心環(huán)節(jié)的質(zhì)量,這也是把一個(gè)龐大、復(fù)雜、高風(fēng)險(xiǎn)的金融核心系統(tǒng),在非常短的時(shí)間內(nèi) 0 風(fēng)險(xiǎn)、0 故障,穩(wěn)妥落地去 O 的關(guān)鍵。

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

陸金所為什么需要啟動(dòng)去全站去 O,并且是 100% 全部去 O。

在去 O 項(xiàng)目立項(xiàng)之初,我們希望通過去 O 來實(shí)現(xiàn)三個(gè)方面的提升。

首先是降低昂貴的金融系統(tǒng)數(shù)據(jù)庫運(yùn)營成本。2013 年至 2018 年期間,陸金所的業(yè)務(wù)成長了上百倍。業(yè)務(wù)量增長帶來的數(shù)據(jù)庫運(yùn)營成本暴增。無論是傳統(tǒng)的 IOE 架構(gòu)還是去 IE 后的 X86+Oracle 分布式架構(gòu)都是如此。IOE 架構(gòu)下,高端服務(wù)器和高端存儲(chǔ)的價(jià)格隨著提供的計(jì)算和 IO 能力呈現(xiàn)指數(shù)型增長。X86+Oracle 架構(gòu)下,分布式改造和數(shù)據(jù)庫細(xì)粒度水平拆分后雖然沒有 I 和 E 的成本,但數(shù)據(jù)庫節(jié)點(diǎn)暴增后導(dǎo)致 Oracle 軟件授權(quán)費(fèi)用暴增。

其次是希望通過去 O 來打造一個(gè)不依賴特定數(shù)據(jù)庫特性的金融交易系統(tǒng),徹底擺脫被商業(yè)數(shù)據(jù)庫廠商技術(shù)綁架的風(fēng)險(xiǎn)。傳統(tǒng)金融交易系統(tǒng)使用數(shù)據(jù)庫特性承擔(dān)了大量的業(yè)務(wù)邏輯和架構(gòu)屬性,造成系統(tǒng)對(duì)某個(gè)數(shù)據(jù)庫特性的強(qiáng)依賴,也大大增加了被技術(shù)綁架的風(fēng)險(xiǎn)。陸金所通過全站去 O 實(shí)現(xiàn)了把金融交易系統(tǒng)里數(shù)據(jù)庫的角色轉(zhuǎn)化為只支持基本增、刪、改、查的存儲(chǔ)引擎,全站系統(tǒng)架構(gòu)弱依賴數(shù)據(jù)庫特性。

最后一點(diǎn)也是最重要的一點(diǎn),我們希望通過全站去 O 這樣一個(gè)涉及到開發(fā)、測(cè)試、架構(gòu)、DBA 等全部研發(fā)團(tuán)隊(duì)都參與的重大架構(gòu)改造項(xiàng)目,來鍛煉研發(fā)隊(duì)伍、提升研發(fā)能力,并把歷史上一些架構(gòu)設(shè)計(jì)不完善的地方,通過全站去 O 進(jìn)行重構(gòu)。因?yàn)槿?O 不僅僅是更換數(shù)據(jù)庫,更重要的是落地架構(gòu)拆分、微服務(wù)化、分布式事務(wù)等配套的大量架構(gòu)改造工作。這些工作需要開發(fā)、架構(gòu)、測(cè)試、運(yùn)維高度協(xié)同配合,并穩(wěn)妥落地。所以去 O 是非?？简?yàn)研發(fā)團(tuán)隊(duì)技術(shù)水平的架構(gòu)改造項(xiàng)目。通過,我們也希望通過去 O 打造“研發(fā)規(guī)范——研發(fā)工具——研發(fā)人員”的研發(fā)管理體系閉環(huán)。這一塊我們?cè)诤竺鏁?huì)詳細(xì)展開,并向大家進(jìn)行介紹。

技術(shù)選型:為什么是 MySQL,又不僅是 MySQL

決定去 Oracle 之后,選擇什么數(shù)據(jù)庫或存儲(chǔ)引擎來承載 Oracle 的流量?我們從功能、資源、案例和壓測(cè)四個(gè)方面來進(jìn)行選型和評(píng)估。

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

最后,同時(shí)也是最重要的一個(gè)評(píng)估標(biāo)準(zhǔn)就是陸金所自身上線前嚴(yán)格的壓測(cè)環(huán)節(jié)。陸金所在切換任何一張表流量的時(shí)候,都會(huì)使用生產(chǎn)環(huán)境完全真實(shí)的數(shù)據(jù)搭建 O 和 M 并行壓測(cè)環(huán)境,來獲取訪問這張表的所有讀寫接口的在 Oracle11.2 和 MySQL5.7 下的性能比對(duì)報(bào)告。經(jīng)過每一輪非常嚴(yán)格的壓測(cè)后,發(fā)現(xiàn) MySQL5.7 的性能比我們預(yù)估中的更好。通過從邊緣系統(tǒng)往核心系統(tǒng)的逐步去 O 演進(jìn)中,MySQL5.7 就成為陸金所去 O 最主要的替代存儲(chǔ)引擎。

我們都知道 Oracle 是個(gè)非常優(yōu)秀、且覆蓋場景非常全面,無論是 OLTP 還是 OLAP 場景表現(xiàn)都很優(yōu)秀,所以這種功能承接應(yīng)該遠(yuǎn)遠(yuǎn)不止一種數(shù)據(jù)庫或存儲(chǔ)引擎,涉及到多種存儲(chǔ)引擎發(fā)揮他們的優(yōu)勢(shì)在各種特定場景下來替換 Oracle。

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

陸金所去 Oracle 方案

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

去 O 雙寫和切換方案

首先介紹一下應(yīng)用層部分的落地。應(yīng)用層在去 O 的時(shí)候會(huì)做一個(gè)整體規(guī)劃,把一個(gè)大的系統(tǒng)或庫拆分成多個(gè)可獨(dú)立落地的批次,然后會(huì)把應(yīng)用的業(yè)務(wù)邏輯層從數(shù)據(jù)庫的訪問接口盡可能剝離出來,讓 DAL 層專注只做好數(shù)據(jù)庫交互的操作。同時(shí),在 Oracle DAL 層的基礎(chǔ)上,對(duì) MySQL DAL 層的進(jìn)行重構(gòu),并且配置流量開關(guān)讓上層的業(yè)務(wù)邏輯層可以自由選擇和數(shù)據(jù)庫的交互是走 Oracle DAL 層還是 MySQL DAL 層。每個(gè)批次都會(huì)有自己單獨(dú)的流量開關(guān)進(jìn)行控制。批次拆分的時(shí)候遵循一個(gè)原則就是把具備業(yè)務(wù)相關(guān)性和事務(wù)相關(guān)性的表放在一個(gè)批次里。

再說數(shù)據(jù)庫層的落地,在 Oracle 還在不斷對(duì)外提供服務(wù)的時(shí)候,我們會(huì)在后臺(tái)建立起一個(gè)和 Oracle 保持實(shí)時(shí)數(shù)據(jù)同步的 MySQL 數(shù)據(jù)庫,即當(dāng) Oracle 的事務(wù)提交后,秒級(jí)同步到后端的 MySQL 里面。同時(shí)這個(gè)同步是雙向的,當(dāng)未來流量切換到 MySQL 后,也會(huì)在 MySQL 事務(wù)提交完成后,把數(shù)據(jù)秒級(jí)同步回 Oracle,這就類似 MySQL 的雙 master 架構(gòu),只不過數(shù)據(jù)是在 Oracle 和 MySQL 這個(gè)異構(gòu)數(shù)據(jù)庫之間建立雙 master 架構(gòu)。

在這個(gè)架構(gòu)中為了確保數(shù)據(jù)庫的一致性和完整性,一定是嚴(yán)格要求某個(gè)批次的寫流量只能在某個(gè)時(shí)間點(diǎn)只能在 O 和 M 一個(gè)地方寫入。陸金所研發(fā)了一整套自動(dòng)化構(gòu)建數(shù)據(jù)庫雙寫的工具平臺(tái),只要在平臺(tái)上選擇需要建立批次的 Oracle 表,就能在后臺(tái)全自動(dòng)完成 Oracle to MySQL 從表結(jié)構(gòu)轉(zhuǎn)化、數(shù)據(jù)全量同步、數(shù)據(jù)增量同步、數(shù)據(jù)實(shí)時(shí)同步、數(shù)據(jù)校驗(yàn)和數(shù)據(jù)雙向同步建立整個(gè)全流程繁瑣。依據(jù)這套自動(dòng)化平臺(tái),陸金所只投入 2 個(gè) DBA 就完成了全站上萬張表的去 O 數(shù)據(jù)庫遷移和運(yùn)維層的全部準(zhǔn)備工作。

最后是流量切換,我們?cè)O(shè)計(jì)并研發(fā)了一套總控開關(guān)機(jī)制來協(xié)調(diào)從應(yīng)用、到數(shù)據(jù)庫、到傳輸、最后到流向的全盤流量切換。實(shí)現(xiàn)當(dāng)流量在 O 時(shí),實(shí)時(shí)同步到 M。當(dāng)流量在 M 時(shí),實(shí)時(shí)同步到 O。保證切換一瞬間,最后一筆事務(wù)在源庫提交成功,在目標(biāo)庫傳輸成功,并完成最后一筆事務(wù)的數(shù)據(jù)在源庫和目標(biāo)庫的數(shù)據(jù)校驗(yàn)后,同一個(gè)批次下所有表的寫流量在同一個(gè)時(shí)間點(diǎn)同時(shí)完成切換。

應(yīng)用流量在 O 和 M 之間快速切換

雖然去 O 流量切換會(huì)在 10 秒內(nèi)瞬間完成,但整個(gè)過程按照細(xì)粒度劃分會(huì)有十多個(gè)步驟。為了方便介紹,我們把這十幾個(gè)步驟精簡成了三個(gè)狀態(tài)。

首先是初始狀態(tài),這個(gè)狀態(tài)下生產(chǎn)的只讀流量可以在 Oracle 或 MySQL,寫流量可以在 Oracle,由 Oracle 對(duì)外提供服務(wù)。這個(gè)狀態(tài)狀態(tài)可以理解為 Oracle 為主庫,MySQL 為 Oracle 的異構(gòu)實(shí)時(shí)備庫。

其次是中間狀態(tài),這個(gè)狀態(tài)下 Oracle 和 MySQL 會(huì)進(jìn)入一個(gè)非常短暫的寫保護(hù)靜止?fàn)顟B(tài)。在完成最后一筆 Oracle 事務(wù)提供成功,并同步至 MySQL,且完成最后一筆數(shù)據(jù)一致性校驗(yàn)后,會(huì)把應(yīng)用開關(guān)的流量切換到 MySQL,這個(gè)時(shí)候這個(gè)批次的寫流量在某個(gè)時(shí)間點(diǎn)全部一致性都切換到 MySQL。

一旦在 MySQL 里寫流量進(jìn)來,就進(jìn)入了第三個(gè)狀態(tài)即完成狀態(tài),一旦寫流量的事務(wù)在 MySQL 中提交成功,雙向?qū)崟r(shí)同步鏈路會(huì)把 MySQL 的數(shù)據(jù)秒級(jí)同步回 Oracle,這個(gè)時(shí)候可以理解為 MySQL 是主庫,Oracle 是 MySQL 的實(shí)時(shí)備庫。

需要注意的是,這個(gè)架構(gòu)下需要解決大量的細(xì)節(jié)問題,比如避免同一筆記錄雙向循環(huán)寫的問題。

陸金所實(shí)現(xiàn)的這個(gè)雙寫框架流量切換速度極快,在數(shù)秒內(nèi)就能實(shí)現(xiàn)有狀態(tài)的寫流量從 O 到 M 的快速切換,整個(gè)過程在低峰期落地對(duì)業(yè)務(wù)影響非常小,甚至是不感知。如果在去 O 之前在 Oracle 內(nèi)部已經(jīng)完成了對(duì)用戶的水平拆分,以批次和用戶雙重細(xì)粒度進(jìn)行去 O 流量切換,那么整個(gè)更換數(shù)據(jù)庫過程幾乎是無感的。

在流量從 O 切換到 M 后,以陸金所落地的經(jīng)驗(yàn)來看,大概有一定概率(比如程序的 bug)需要回切到回 Oracle。這套切換框架可以確保在幾秒內(nèi)流量快速回到 Oracle,且在 MySQL 寫入的少量數(shù)據(jù)也會(huì)同步會(huì) Oracle,且在保證 Oracle 和 MySQL 兩邊的數(shù)據(jù)嚴(yán)格一致性和完整性的過程中,進(jìn)行流量的快速前滾和回滾。

適用于金融核心系統(tǒng)的穩(wěn)妥去 O 推進(jìn)方案

了解了去 O 流量切換的架構(gòu)和方案,接下來我們介紹如何在一個(gè)關(guān)聯(lián)系統(tǒng)龐大、業(yè)務(wù)邏輯復(fù)雜、改造風(fēng)險(xiǎn)極高的金融核心系統(tǒng)里落地整個(gè)去 O 方案。

首先我們會(huì)以表為粒度來把一個(gè)復(fù)雜、龐大的金融核心系統(tǒng)和數(shù)據(jù)庫拆分成多個(gè)批次,拆分的原則上面也提到了一點(diǎn),即把有業(yè)務(wù)相關(guān)性和事務(wù)相關(guān)性的表放在同一個(gè)批次里,在確保這個(gè)基本原則的情況下,把單個(gè)大庫盡可能的拆分成多個(gè)批次,確保每個(gè)批次里的表盡可能的少。

為什么要基于這個(gè)原則來落地實(shí)施呢,因?yàn)榕问侨?O 變更的單位,O 和 M 之間的流量切換開關(guān)是控制到批次的。把批次拆分的足夠細(xì),最終目標(biāo)是為了實(shí)現(xiàn)“改造難度可控、上線進(jìn)度可控、切換風(fēng)險(xiǎn)可控”的 3 原則。

首先對(duì)于金融核心系統(tǒng)中一個(gè)復(fù)雜的模塊來說,去 O 改造的周期會(huì)橫跨半年甚至一年以上,在這個(gè)過程中,金融核心系統(tǒng)在 7*24 小時(shí)不間斷對(duì)外提供服務(wù),應(yīng)用層的代碼和功能每個(gè)月甚至是每周也處在高速迭代中,不斷的新功能被加入到系統(tǒng)并被發(fā)布到生產(chǎn)。

而在這個(gè)過程中,要落地去 O 這類龐大的架構(gòu)改造,必須框定一個(gè)可快速迭代和實(shí)施的改造范圍,批次就是一個(gè)合理設(shè)定的單次去 O 改造和變更的范圍。批次拆分的粒度細(xì),可以確保在單個(gè)批次的去 O 改造工作量可控、改造難度也可控。

同時(shí)因?yàn)榕蔚牧６燃?xì),在做去 O 變更切換流量時(shí),對(duì)整個(gè)金融核心系統(tǒng)的影響也可控?；谶@種思路,就可以實(shí)現(xiàn)“小步快跑”的高速迭代方式來改造應(yīng)用、上線版本以及切換流量。即每次只改動(dòng)核心系統(tǒng)的一小部分,改動(dòng)完成后快速測(cè)試、快速發(fā)版上線、并且風(fēng)險(xiǎn)可控的把這部分流量切換到 MySQL 運(yùn)行,如果有問題依靠強(qiáng)大的流量切換框架,快速把流量回切回 Oracle。

從圖中大家可以看到一個(gè)龐大的金融核心系統(tǒng)去 O 改造中,應(yīng)用改造、上線版本和流量切換這 3 件事情實(shí)在并行落地的。

最開始是應(yīng)用改造,改造完了上線發(fā)版,發(fā)版后就有了這個(gè)批次 O 和 M 的流量開關(guān),并具備了切換條件,之后在某個(gè)變更日把流量從 O 切換到 M,如果遇到任何問題可以快速切回來。應(yīng)用版本在不斷上線迭代,流量在分批次不斷切換,一個(gè)龐大的金融核心系統(tǒng)就在多次高速迭代中一點(diǎn)點(diǎn)的從 O 切換到了 M。

整個(gè)過程對(duì)核心業(yè)務(wù)不影響、不感知,且對(duì)參與去 O 的開發(fā)、測(cè)試和運(yùn)維開展去 O 工作非常友好,讓他們可控的去落地各項(xiàng)工作。

在這個(gè)過程中,從第 1 張表從 Oracle 切換到 MySQL,到最后一張表關(guān)閉 Oracle 流量,在非常長的一段時(shí)間內(nèi),整個(gè)應(yīng)用是由 Oracle 和 MySQL 在同時(shí)提供服務(wù)。其中某些表已經(jīng)完成去 O,讀寫的流量在 MySQL 上,由 MySQL 同步到 Oracle,部分表還未完成去 O,讀寫流量在 Oracle 上,由 Oracle 同步至 MySQL。這就非?？简?yàn)運(yùn)維的能力,要確保在這個(gè)架構(gòu)下每天高頻的各種發(fā)版和數(shù)據(jù)庫變更都非常準(zhǔn)確。

基于此,陸金所是有研發(fā)一整套配套去 O 變更工具,來確保整個(gè)去 O 過程中大量變更準(zhǔn)確實(shí)施和落地。以陸金所交易、主賬戶、資產(chǎn)中心、基金、賬務(wù)等核心庫為例,從第一張表流量切換到 MySQL 到最后一張表切換到 MySQL,歷時(shí) 12 個(gè)月以上。按照上述方案一點(diǎn)一點(diǎn)的替換掉 Oracle 數(shù)據(jù)庫,整個(gè)過程完全不做服務(wù)降級(jí),對(duì)陸金所的 4500 多萬用戶無感知。

陸金所去 Oracle 方案的落地

在 PPT 中畫出去 Oracle 的架構(gòu)圖是很簡單的事情,但是架構(gòu)改造的難點(diǎn)和重點(diǎn)在于落地。要在生產(chǎn)環(huán)境落地是非常龐大且復(fù)雜的系統(tǒng)工程,尤其是對(duì)一個(gè) 7*24 小時(shí)的金融核心系統(tǒng)來說,進(jìn)行重大架構(gòu)改造本身就是一件高風(fēng)險(xiǎn)的工作,既要做到規(guī)避風(fēng)險(xiǎn),確保各種工程實(shí)現(xiàn)細(xì)節(jié)有效落地,同時(shí)又要保證系統(tǒng)的業(yè)務(wù)連續(xù)性,甚至是對(duì)外部用戶不感知。

去 Oracle 架構(gòu)改造的本質(zhì)是什么?我覺得有兩方面,一是細(xì)節(jié)規(guī)則,二是上生產(chǎn)前發(fā)現(xiàn)和上生產(chǎn)后兜底。

去 O 的重點(diǎn)不僅僅是方案本身,更重要的是組成方案的數(shù)百條細(xì)節(jié)規(guī)則,能在一個(gè)參與去 O 的、龐大的研發(fā)團(tuán)隊(duì)里每個(gè)開發(fā)所寫的每一行代碼都有效遵守規(guī)則,同時(shí)在每個(gè)運(yùn)維設(shè)計(jì)的生產(chǎn)變更方案里每一條命令都有效遵守規(guī)則。方案通過從邊緣系統(tǒng)往核心系統(tǒng)逐步推進(jìn)過程中,會(huì)逐步趨于完善,方案中的規(guī)則也會(huì)被逐步積累和完善起來,那么把這些規(guī)則落地到研發(fā)團(tuán)隊(duì)的每個(gè)人上,是關(guān)鍵和重點(diǎn)。

上生產(chǎn)前發(fā)現(xiàn)是指如果規(guī)則在某個(gè)微小的細(xì)節(jié)實(shí)施時(shí)沒有被遵守,如何盡可能的在上生產(chǎn)環(huán)境之間發(fā)現(xiàn)隱患。上生產(chǎn)后兜底如果問題突破了所有檢測(cè)環(huán)節(jié)上了生產(chǎn),如何設(shè)計(jì)一個(gè)兜底方案可以有效控制風(fēng)險(xiǎn),把影響盡可能降低。

去 Oracle 落地工作都應(yīng)該圍繞有效解決這兩個(gè)本質(zhì)問題展開,并提升這兩個(gè)問題的解決效率,降低人力成本。

陸金所的做法是建立“人員——規(guī)則——工具”的閉環(huán)。

陸金所通過“人員制定規(guī)則——規(guī)則通過工具落地——工具確保所有人員的代碼和變更符合規(guī)則”的方式來確保各種細(xì)節(jié)工作落實(shí)到位,整套工具最終沉淀為陸金所數(shù)據(jù)庫升級(jí)平臺(tái)。

以陸金所的去 O 落地經(jīng)驗(yàn)來看,一個(gè)不起眼的細(xì)節(jié)問題如果未進(jìn)行有效管控,都有可能引發(fā)嚴(yán)重的生產(chǎn)故障。所以我們可以把陸金所數(shù)據(jù)庫升級(jí)平臺(tái)理解成為一套強(qiáng)大的去 O 風(fēng)控系統(tǒng)。這套風(fēng)控系統(tǒng)覆蓋 SQL 重構(gòu)、表結(jié)構(gòu)轉(zhuǎn)化、數(shù)據(jù)遷移、數(shù)據(jù)校驗(yàn)、分布式事務(wù)構(gòu)建、流量切換等橫跨從開發(fā)到運(yùn)維在去 O 架構(gòu)改造方方面面會(huì)遇到的問題。通過這套工具平臺(tái),有效確保參與去 O 的研發(fā)團(tuán)隊(duì)在每個(gè)細(xì)節(jié)上都處理的非常規(guī)范,從而實(shí)現(xiàn)歷時(shí) 24 個(gè)月的全站去 O,無風(fēng)險(xiǎn)平穩(wěn)落地。

除了確保各種規(guī)則精準(zhǔn)落地外,金融核心系統(tǒng)去 O 改造需要多個(gè)研發(fā)團(tuán)隊(duì)協(xié)同作戰(zhàn)、有效配合、共同推進(jìn)。其中涉及到大量工程實(shí)現(xiàn)細(xì)節(jié)工作需要多團(tuán)隊(duì)有條不紊、事無巨細(xì)的協(xié)同配合好。任何疏漏都有可能會(huì)引發(fā)嚴(yán)重的生產(chǎn)故障。

經(jīng)驗(yàn)總結(jié):談?wù)勂髽I(yè)去 Oracle 的目標(biāo)

去 Oracle 的口號(hào)喊了很久了,但是為什么要去 Oracle,去 Oracle 想要達(dá)到什么樣的目標(biāo)…有些企業(yè)可能沒有想得很清楚,所以我也想從自己的角度和經(jīng)歷來談?wù)勅?Oracle 的目標(biāo)。

目標(biāo)一:省錢

去 O 完成后,使用“免費(fèi)的開源數(shù)據(jù)庫 + X86 架構(gòu)的 PC Server”來搭建金融核心系統(tǒng),真的很省錢。因?yàn)榇罱ń鹑诤诵南到y(tǒng)從昂貴的高端服務(wù)器、高端存儲(chǔ)和 Oracle 一體機(jī),以及昂貴的 Oracle 軟件授權(quán)變成只需要 6 萬一臺(tái)的 X86 服務(wù)器,花在數(shù)據(jù)庫上的運(yùn)營成本降為之前的 10% 不到。

在整個(gè)去 Oracle 的過程中,陸金所架構(gòu)從一個(gè)傳統(tǒng)金融的超大型數(shù)據(jù)庫支持各種核心業(yè)務(wù)的架構(gòu)變成了以微服務(wù)化驅(qū)動(dòng)的分布式架構(gòu),這種架構(gòu)具備以下特點(diǎn):

• 每個(gè)服務(wù)有自己獨(dú)立的應(yīng)用和數(shù)據(jù)庫。
• 每個(gè)庫只提供給服務(wù)內(nèi)的應(yīng)用直接訪問,即服務(wù)內(nèi)的應(yīng)用可以通過 SQL 訪問。
• 服務(wù)之外的應(yīng)用訪問數(shù)據(jù)庫需要走應(yīng)用層的服務(wù)接口,避免跨服務(wù)訪問數(shù)據(jù)庫。
• 服務(wù)分為同步調(diào)用和異步消息。
• 在服務(wù)內(nèi)實(shí)現(xiàn)數(shù)據(jù)庫的水平擴(kuò)展。
• 對(duì)于類似用戶、交易、資金等公共類基礎(chǔ)服務(wù),逐步迭代為中臺(tái)服務(wù)。

通過微服務(wù)化拆分,幾套集中式的 IOE 大庫就變成了微服務(wù)小庫,同時(shí)對(duì)于訪問量和數(shù)據(jù)量較大的中臺(tái)服務(wù),又會(huì)進(jìn)一步細(xì)粒度水平拆分。

目標(biāo)二:架構(gòu)升級(jí)和改造

除了降低成本,我認(rèn)為更重要的是通過去 O 實(shí)現(xiàn)傳統(tǒng)金融系統(tǒng)全方位的架構(gòu)升級(jí)和改造。

對(duì)于一個(gè)傳統(tǒng)金融系統(tǒng)來說,借助去 O 來實(shí)施和落地全系統(tǒng)的架構(gòu)改造和升級(jí),應(yīng)該是一個(gè)再好不過的機(jī)會(huì)。以陸金所為例,通過去 O 實(shí)現(xiàn)了以下的升級(jí)和改造:

• 數(shù)據(jù)庫底層計(jì)算和 IO 能力的水平擴(kuò)展,并且這種水平擴(kuò)展完全基于 6 萬一臺(tái)的 X86 服務(wù)器,擴(kuò)容成本極低。
• 同時(shí)實(shí)現(xiàn)了應(yīng)用訪問數(shù)據(jù)庫的規(guī)范化,應(yīng)用和應(yīng)用之間的服務(wù)化。全站的調(diào)用鏈會(huì)非常清晰,應(yīng)用和數(shù)據(jù)庫之間不合理的依賴將大幅降低。
• 另外實(shí)現(xiàn)數(shù)據(jù)庫層去中心化,單個(gè)數(shù)據(jù)庫的可用率對(duì)全局可用率影響有限,消除中心化的單點(diǎn)隱患
• 最后借助去 O 實(shí)現(xiàn)的分布式架構(gòu),可以把各個(gè)分片的數(shù)據(jù)庫部署在不同的機(jī)房,從而實(shí)現(xiàn)真正意義上的機(jī)房多活。

目標(biāo)三:引入更合適的存儲(chǔ)引擎

提到去 Oracle,可能很多人在第一時(shí)間就想到了 MySQL。其實(shí),MySQL 是承接 Oracle 主要流量的數(shù)據(jù)庫,但 MySQL 無法承接 Oracle 的全部流量,例如以下幾類經(jīng)典場景:

• Oracle 在 oltp 場景當(dāng)中少量 hash join 查詢場景。
• Oracle 中多表關(guān)聯(lián)和多層復(fù)雜嵌套查詢場景。
• MySQL 細(xì)粒度拆分后,跨庫、跨分片的查詢場景。
• 在 MySQL 集群和 Hadoop 集群之間構(gòu)建一個(gè)秒級(jí)數(shù)據(jù)同步的 ODS 層。

在這些場景中,可以引入 TiDB、Elasticsearch、Impala+kudu、Redis 等多種存儲(chǔ)引擎。這些存儲(chǔ)引擎在合適的場景下替換 Oracle,產(chǎn)生的效果是不但比 IOE 架構(gòu)成本低得多,性能也會(huì)比 Oracle 快得多。

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

陸金所有個(gè)實(shí)時(shí)對(duì)賬的場景,需要跨用戶庫、交易庫、資金庫和資產(chǎn)庫進(jìn)行復(fù)雜的關(guān)聯(lián)查詢。在完成去 O 后,數(shù)據(jù)庫在 MySQL 上做了細(xì)粒度拆分,無法跨多個(gè)獨(dú)立的服務(wù)庫進(jìn)行復(fù)雜且高頻的跨庫查詢。

為了支持這個(gè)場景,我們研發(fā)了數(shù)據(jù)總線來實(shí)施解析 MySQL binlog 并生成消息同步至 TiDB,事務(wù)在 MySQL 提交后實(shí)現(xiàn)秒級(jí)同步至 TiDB。之后通過 TiDB4.0 的 TiFlash 功能(類似 clickhouse 的列式存儲(chǔ)),在 MySQL 和 Hadoop 之間搭建一個(gè)實(shí)時(shí) ODS,實(shí)現(xiàn)了秒級(jí)處理跨庫、多表、復(fù)雜關(guān)聯(lián)的查詢場景。性能遠(yuǎn)超去 O 之前在 IOE 架構(gòu)下的處理結(jié)果。

來源：網(wǎng)絡(luò)

xiesc