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

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

這一階段主要是為了后面真正遷移的時候做準備工作，將該核心應用系統的所有數據訪問入口統一到一起，全部以服務化的接口方式呈現給其他有需要的系統，一來方便后續變更的控制，二來也推進了服務化的進程。

• 應用接口統一

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

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

這個數據訪問中間層，對前端應用服務器來說，就是一個完整的數據庫，所有數據請求都從這里實現，以協議的方式和前端應用服務器的jdbc驅動進行交互，以便讓數據庫對應用服務器徹底透明。

• Oracle數據庫中拆分（1拆16）

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

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

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

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

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

• Oracle遷移至 MySQL（16拆128）

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

• 附屬Detail信息遷移至 MySQL

　　這個遷移項目算是徹底完成了，但是我們的遷移之路并不會就此止步，還有很多的系統仍然存在擴展性問題，還有很多的數據庫應用等著我們去拆分。

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