為了對核心技術(shù)擁有更多的自主控制能力，為了解決數(shù)據(jù)庫的線性擴(kuò)展問題，為了盡量減少對商業(yè)軟件的依賴，為了擺脫對高端硬件的依賴，為了…基于以上多種原因，2年前，我們計劃將公司某核心應(yīng)用平臺進(jìn)行大手術(shù)：數(shù)據(jù)庫平臺從軟件到硬件全部重構(gòu)。當(dāng)然，這其中應(yīng)用架構(gòu)的改造也不可避免的進(jìn)行了大換血。

　　這個項目無論是從技術(shù)角度還是是業(yè)務(wù)角度來說，都對我們有著非常大的價值，也必定會帶來非常深遠(yuǎn)的影響。項目歷時2年多，分4個階段才完成：

• 應(yīng)用接口統(tǒng)一

這一階段主要是為了后面真正遷移的時候做準(zhǔn)備工作，將該核心應(yīng)用系統(tǒng)的所有數(shù)據(jù)訪問入口統(tǒng)一到一起，全部以服務(wù)化的接口方式呈現(xiàn)給其他有需要的系統(tǒng)，一來方便后續(xù)變更的控制，二來也推進(jìn)了服務(wù)化的進(jìn)程。

• Oracle數(shù)據(jù)庫中拆分（1拆16）

這個階段本不是必要的，但是由于項目啟動稍微晚了點，數(shù)據(jù)出現(xiàn)了爆發(fā)性增長，導(dǎo)致該系統(tǒng)的數(shù)據(jù)表太大（單表不帶索引過500GB），原 Oracle 數(shù)據(jù)庫已經(jīng)快撐不住了。為了安全起見，先在 Oracle 中從一個主表以會員ID進(jìn)行 hash 運算后再進(jìn)行水平拆分，從1個表分拆成了16個。附表由于訪問量稍小，而且全部是根據(jù)主鍵訪問，暫時保留原樣。

當(dāng)然，這樣的水平拆分，必然會帶來數(shù)據(jù)訪問路由以及數(shù)據(jù)合并的問題。我們專門為此開發(fā)了具有分布式數(shù)據(jù)庫路由/數(shù)據(jù)合并，數(shù)據(jù)庫讀寫分離，數(shù)據(jù)庫鏈接管理等功能的數(shù)據(jù)訪問中間層，專門解決拆分后給應(yīng)用服務(wù)器帶來的影響，使得應(yīng)用服務(wù)器完全感受不到后端數(shù)據(jù)庫的變化。

這個數(shù)據(jù)訪問中間層，對前端應(yīng)用服務(wù)器來說，就是一個完整的數(shù)據(jù)庫，所有數(shù)據(jù)請求都從這里實現(xiàn)，以協(xié)議的方式和前端應(yīng)用服務(wù)器的jdbc驅(qū)動進(jìn)行交互，以便讓數(shù)據(jù)庫對應(yīng)用服務(wù)器徹底透明。

• Oracle遷移至 MySQL（16拆128）

這個階段是整個階段中歷時最長，復(fù)雜度最高，風(fēng)險系數(shù)最高的，未知因素也最多的一個階段。雖然 MySQL 數(shù)據(jù)庫已經(jīng)在互聯(lián)網(wǎng)行業(yè)占據(jù)了大片江山，但是對于阿里巴巴來說，卻仍然是一個新鮮玩意兒，因為之前我們一直都用 Oracle 來提供所有的業(yè)務(wù)系統(tǒng)的數(shù)據(jù)庫服務(wù)。

在此之前，我們從來沒有在如此核心業(yè)務(wù)系統(tǒng)的數(shù)據(jù)庫上使用過 PC Server 和本地硬盤來承載數(shù)據(jù)庫，一直是使用 IBM 小型機和中高端存儲設(shè)備來解決高性能和高可靠的問題。在更換成 PC Server 和本地硬盤來承載數(shù)據(jù)庫之后，我們就必須面對 PC Server 本身硬件可能存在的不可靠性所帶來的 Crash，所以我們必須有一套完善的 HA 切換機制，要比小型機廠商所提供的商業(yè) HA 管理軟件更加高效更加自動化更加可控，才能我們降低了設(shè)備本身可靠性之后達(dá)到原有的可用性要求。

對于一個需要滿足 365 * 24 * 7 的核心業(yè)務(wù)系統(tǒng)來說，肯定是不可能給我們太多時間來進(jìn)行數(shù)據(jù)遷移的，所以我們不得不設(shè)計出一個對現(xiàn)有系統(tǒng)影響盡可能小的遷移方案，這勢必會造成方案的高度復(fù)雜化，帶來更多的風(fēng)險。最后的遷移方案要經(jīng)歷如下4個階段：

1. Oracle 讀/寫;；MySQL 初始化并增量寫
2. Oracle 讀/寫； MySQL 寫
3. Oracle 寫； MySQL 讀/寫
4. Oracle 停訪問； MySQL 讀/寫

當(dāng)然，也正式由于有如此復(fù)雜的方案，才確保了在整個遷移過程中的的停機時間被控制在了10分鐘之類。

• 附屬Detail信息遷移至 MySQL

從項目開始，至完成主表拆分結(jié)束，已經(jīng)接近2年了。這2年時間內(nèi)，數(shù)據(jù)量一直都在飛漲，這讓即使僅僅只是按照主鍵訪問的附表也快無法承受持續(xù)增長的業(yè)務(wù)壓力，附表的拆分也就成了必行之勢。由于在原來主表拆分的過程中，整個項目組已經(jīng)積累了大量的經(jīng)驗，附表拆分過程非常順利，基本沒有出現(xiàn)任何問題。雖然附表的拆分過程與主表相比除了 1拆16這個階段外沒有減少其他任何環(huán)節(jié)，但是整個拆分過程也才2個月就全部搞定了。

　　這個遷移項目算是徹底完成了，但是我們的遷移之路并不會就此止步，還有很多的系統(tǒng)仍然存在擴(kuò)展性問題，還有很多的數(shù)據(jù)庫應(yīng)用等著我們?nèi)ゲ鸱帧?/p>

　　注：同事們還為此送了我們一個雖不太雅但也意思相近的名稱“拆遷隊”。

it知識庫：核心業(yè)務(wù)系統(tǒng)數(shù)據(jù)庫平臺遷移： Oracle -> MySQL，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。