“去O”一直是最近10年描述系統架構改造中最常出現的詞之一。雖然“去O”被很多工程師和技術從業者津津樂道，但業界真正能實現把系統全部去O，特別是金融場景的核心繫統全部去O的案例並不多。那麼去O到底難在哪裏呢。
爲了解答這個問題，首先我們要理解去O架構改造的本質是什麼？去O架構改造的本質其一是讓系統架構具備在線更換數據庫的能力，無論去O的目標庫是MySQL，或是其他的關係型數據庫，最終都是要解決這樣一個問題。
在線更換數據庫到底難在哪裏，會遇到哪些問題呢？
問題一：如何無感知的實時動態數據的遷移？
首先數據庫作爲交易型系統最核心的組件沒有之一，這一點對於數據庫的重要性評價一點都不誇張。當前大部分知名的網站和系統都是7x24小時對外提供服務，數據庫也是7*24小時無時不刻處理着大量的讀寫服務，要實現去O就意味着你要在一個Oracle庫還在對外提供服務的時候，在某個時間點讓一個MySQL庫快速替換掉Oracle庫，並平穩的接管Oracle的所有服務。
不同於無狀態的系統組件切換把流量切走即完成切換工作，而數據庫作爲有狀態的系統組件，如何設計一套從應用改造、到數據同步、再到數據庫流量切換的穩妥去O方案，可以非常謹慎的把一個正在對外提供服務，數據處在實時變化狀態的Oracle庫上的數據無縫的方式遷移至MySQL中。
爲了有效解決這個問題，陸金所研發的去O工具包含一整套完善的在線數據遷移功能。在工具中勾選需要去O的Oracle表，工具會自動完成O to M的全量同步、增量同步，並通過解析Oracle redolog來追增量日誌，最終形成一個Oracle爲主庫，MySQL爲備庫的異構實時備庫。
問題二：如何管理和協調好高頻迭代的去O改造和功能改造？
其次去O架構改造的主體工作是對應用層代碼的重構，特別對DAO（數據訪問層）的重構，對於某些複雜的系統來說，重構的時間會持續數月甚至更久。在這段漫長的去O改造時間窗口裏，不但Oracle庫的數據在動態發生變化，對於一個處在高速迭代中的網站和系統來說，應用的功能代碼也在不斷髮生變化。如果A團隊在爲應用做去O架構改造，而這個期間B團隊在不斷的給應用開發新的功能，如何進行去O的工作拆分可以有效的管理和協調好兩個開發團隊的編碼和上線節奏呢。
爲了有效應對這個場景，陸金所研發的去O工具會在去O架構改造和應用業務改造之前進行有效協調，並向業務開發儘可能屏蔽去O架構改造的影響。比如業務改造需要在處於O和M並行雙寫的庫上修改表結構併發布新的數據庫訪問接口，大量的工作會由去O工具來自動化完成。
問題三：如何穩妥落地數據庫流量的在線切換？
當某個庫的應用去O改造完成並上線後，會實施生產環境Oracle的流量切換到MySQL上。在這個切換過程中，如何確保Oracle上的最後一筆事務提交成功，並同步到MySQL後完成數據一致性校驗，且針對這個Oracle庫的所有寫操作能在快速、全部切換到MySQL上，不會出現部分寫流量Oracle，部分寫流量MySQL，兩庫雙寫的異常狀態。
當流量切換到MySQL後a，如果出現應用報錯或bug、MySQL性能問題等在前期壓測或準備工作中未覆蓋到的突發情況，如何實現流量快速回切到Oracle上，且確保在MySQL中寫入的數據也能完全一致的回到Oracle中。
解決好這個問題，是控制好去O落地風險的核心所在。陸金所設計了一整套在線切換數據庫的架構框架來確保在瞬間把流量從Oracle切走到MySQL中，同時也可以瞬間把流量切回到Oracle，並確保兩邊的數據完全一致。
問題四：如何有效拆分去O的任務，從而實現對全站業務單次影響小、迭代頻度快的去O上線？
要實現全站去O，必然面臨着對一些複雜、龐大的核心繫統進行去O改造。以陸金所爲例，在全站中像用戶中心、資產中心、資金賬戶等這種給全站所有金融產品線都提供基礎服務的子系統就是這類複雜和龐大的核心繫統，同時包括基金、主賬戶等專屬金融產品線的業務邏輯複雜，所以子系統也非常龐大。
所以對於這類子系統，如果需要在一個大版本里全部去O改造完成，並在一個晚上業務低峯期一次性全部從O切換到M，無論是當晚的切換風險，還是切換完成後，在第二天業務高峯期出現問題和bug的風險，包括開發團隊短時間內去O改造的工作量和出現重大bug的機率都是非常大且不可控的。
如何把一個龐大且重要的複雜子系統拆分成多個去O的版本按批次上線和切換流量，且做到單個批次影響可控，也是全站去O中需要謹慎設計的方案。
而這也是整個去O過程中架構設計最有趣的部分。
上面提到了去O中在架構層實現在線換庫需要解決的四大問題。除了在線換庫外，去O架構改造的本質其二是引入更多的存儲引擎在合適的場景來承接Oracle數據庫的計算和存儲能力。這就引出了第五個問題。
問題五：如何在各種場景下使用合適的開源存儲引擎來去O，並且在架構上進行融合。
首先Oracle是個非常強大的關係型數據庫，無論在OLTP和OLAP場景表現都很出色，且具備一整套完善、好用的運維和監控工具。但於此同時Oracle雖然對各種場景支持較爲全面，但在各個特定場景下，一些開源的數據庫或存儲引擎在性能或成本投入的綜合考量上勝過Oracle，都會是比Oracle更合適的選擇方案。
所以全站去O不僅僅是去O到MySQL中，MySQL能承接的只是Oracle的部分計算和存儲能力，在整個陸金所的全站去O落地過程中，除了MySQL外，我們還在不同的場景下使用ES、HBase、TiDB、Impala+kudu等存儲引擎，甚至是應用層的代碼來承接和替換Oracle，並且整體收益比使用Oracle更好。
在完成去O後，陸金所的生產環境出現了大量開源的存儲引擎來支撐各種合適的業務場景。同時我們也研發了數據總線平臺來實現數據在一個地方寫入和提交，秒級同步到其他存儲引擎的架構。
上述是陸金所在全站去O過程中遇到的5個實戰問題大類，整個全站去O過程中需要解決細節問題還有很多，這裏無法一一列舉，因爲去O作爲一個複雜的系統架構改造本身就要求技術團隊事無鉅細的處理好各種細節問題。
基於此，陸金所優化和開發了一整套方案和工具來，有效推進去O改造穩妥落地且保障風險可控。後續會推出一個系列的去O專題和大家分享，希望給有去O改造計劃的技術團隊和公司帶來一些參考和借鑑價值，敬請期待。
作者介紹：
王英傑，陸金所數據架構團隊負責人，負責陸金所全站存儲引擎運營和智能化工具研發。