最近“去IOE”炒得火熱，作為一個在中國移動從事IT技術(shù)的人，基于中國移動的現(xiàn)狀，筆者也發(fā)表幾句不成熟的想法，請諸位專家批評指正。

“去O”的應(yīng)用驅(qū)動分析

從技術(shù)角度，沒有什么是絕對不能做的，只是看代價多少，以及是否合適。

比如，當年阿里還沒“去IOE”時候，浙江移動某些系統(tǒng)就在用MySQL了。MySQL不是天使，Oracle（甲骨文）也不是妖魔，關(guān)鍵還是要看用戶的技術(shù)場景和技術(shù)管理機制。適合你的，就是好的。

此外，浙江移動2011年的CRM項目，包括我們自己做的一些技術(shù)創(chuàng)新，都基本證明了在運營商生態(tài)環(huán)境下，“去I”和“去E”這兩件事情，都沒有大的技術(shù)難點，難點在于“去O”。

從技術(shù)能力儲備和管理體系分析方面我們就可以看出一些端倪。像阿里巴巴這樣的互聯(lián)網(wǎng)公司，它們自己掌握開發(fā)人員，自己掌握架構(gòu)，其中又包含了應(yīng)用架構(gòu)、技術(shù)架構(gòu)和數(shù)據(jù)架構(gòu)。阿里巴巴的技術(shù)團隊的薪酬管理體系，很能體現(xiàn)技術(shù)人員的價值，適合技術(shù)人員生存發(fā)展。在這種環(huán)境下，開源數(shù)據(jù)庫的缺點完全可以靠自己培養(yǎng)的、國內(nèi)少見的代碼級專家來解決，開源數(shù)據(jù)庫與應(yīng)用可以做到高度融合。

運營商的情況卻完全不同。由于開發(fā)長期完全外包，自己幾乎沒有研發(fā)技術(shù)人員，體制內(nèi)也缺乏技術(shù)人員的發(fā)展環(huán)境，這導(dǎo)致十多年前培養(yǎng)起來的真正具備動手能力的少量第一代技術(shù)骨干，正隨著時間流逝風雨飄搖。與此同時，新生力量又頂不上來?，F(xiàn)狀是，運營商對核心能力的掌控非常有限。相對來說，技術(shù)架構(gòu)的掌控還算得力，但應(yīng)用架構(gòu)和數(shù)據(jù)架構(gòu)已經(jīng)成為現(xiàn)實的重災(zāi)區(qū)。最終，在運營商生態(tài)環(huán)境中，可以對MySQL進行代碼級掌控的元素已基本缺失。

實際上，阿里巴巴做去IOE有其業(yè)務(wù)發(fā)展上的原因。

對于互聯(lián)網(wǎng)和傳統(tǒng)企業(yè)來講，最終都得為用戶服務(wù)。因此其希望盡量減少收費和依賴，變成一個盡可能廉價且擁有性價比的公共服務(wù)平臺，在這個平臺上則可以產(chǎn)生出更好的服務(wù)。而運營商的應(yīng)用場景目前來看，比較明確的還是私有云，并且希望通過“去O”加強自身核心能力的建設(shè)，減少對合作伙伴的依賴，劍指亞聯(lián)這樣的開發(fā)商和Oracle這樣的平臺提供商。

很多人認為，阿里巴巴“去O”的技術(shù)原因，是Oracle不能滿足互聯(lián)網(wǎng)業(yè)務(wù)的可擴展性需求。我覺得這個理論可能是站不住腳的。充分利用閃存混合架構(gòu)，MySQL的單庫容量都能提高，更何況Oracle數(shù)據(jù)庫？而且還有Exadata這樣的產(chǎn)品來為Oracle“撐腰”。在海量數(shù)據(jù)的處理方面，直接用Hadoop、NoSQL就可以，本來就和“去O”這種使用場合的議題扯不到一起。

“去O”的技術(shù)難點

“去O”需要考慮以下幾個方面的問題。首先是數(shù)據(jù)一致性。具體操作上，這需要看不同的業(yè)務(wù)需求，但是運營商的核心系統(tǒng)一般是有強一致性要求的。此外，還要關(guān)注復(fù)雜查詢支持、單機擴展性以及優(yōu)化的成熟度三個方面。 、

這幾個問題，會顯著增加業(yè)務(wù)開發(fā)的復(fù)雜度， 因為必須將這部分功能的需求，在應(yīng)用層實現(xiàn)。對于技術(shù)儲備一般的公司來講， 這就是非常高的門檻了。而運營商，在這幾方面也正好“中槍”。

因為“去O”必須將部分原本已經(jīng)在數(shù)據(jù)庫層實現(xiàn)很好的功能去掉，交給應(yīng)用來做，因此這往往會造成開發(fā)浪費。對于阿里巴巴這樣擁有開發(fā)實力的互聯(lián)網(wǎng)公司來說，從業(yè)務(wù)角度看是值得投入的，但對運營商來說，完全可能是自找麻煩。

運營商最好的辦法，是向互聯(lián)網(wǎng)公司學習改革，創(chuàng)造機制培養(yǎng)自己技術(shù)人員。如果做不到，那在數(shù)據(jù)庫這種核心平臺相關(guān)的架構(gòu)上，或許還真不如用那些國際大公司的產(chǎn)品。

從技術(shù)生態(tài)環(huán)境的角度看，不可否認的是，Oracle的數(shù)據(jù)庫產(chǎn)品確實出色，特別是在較為傳統(tǒng)的OLTP和OLAP場景下更加如此。事實上，開放和封閉的差別，不僅僅存在于代碼環(huán)節(jié)，還存在于技術(shù)支持環(huán)節(jié)。而在移動環(huán)境下，后者比前者更加重要。Oracle數(shù)據(jù)庫有非常開放的技術(shù)文檔，帶來了極度繁榮的、獨一無二的第三方技術(shù)支持市場。

“去O”不是直接上MySQL，產(chǎn)品的選擇不是兒戲，不能簡單抄襲。還是那句話，環(huán)境不同，別人適合的東西不一定適合自己，反之亦然。此外，選擇產(chǎn)品本身也可能涉及到技術(shù)路線的選擇。MySQL和Oracle相比功能要簡單得多，很多復(fù)雜查詢不支持，數(shù)據(jù)結(jié)構(gòu)很多需要轉(zhuǎn)換，語法也差別較大。也就是說，如果把程序從Oracle割接到MySQL，數(shù)據(jù)倒換代價不說，代碼基本上兼容性較低，需要重寫的部分占比應(yīng)該會很高。而現(xiàn)實情況是，運營商對業(yè)務(wù)連續(xù)性的要求極高，但技術(shù)掌控力又不如互聯(lián)網(wǎng)企業(yè)。這種情況下，想象一下運營商的系統(tǒng)“去O”會面臨什么樣的挑戰(zhàn)？

運營商該如何對待“去O”？

沒有金剛鉆，別攬瓷器活?！叭”有風險，操作需謹慎。在這個問題上，不能被一些人云山霧罩地一吹就暈，一味照搬互聯(lián)網(wǎng)公司的做法，簡單粗暴地快速全面“去O”，那樣很容易搬起石頭砸自己的腳。場景不同，還是要實事求是，因地制宜，不能脫離實際。

運營商應(yīng)該把精力，花在局方和第三方Oracle技術(shù)支持力量的培養(yǎng)上。市場上有那么多專業(yè)的第三方合作伙伴，全國一盤棋，是否能在技術(shù)支援體制上做文章，改變現(xiàn)有的各省“煙囪式”技術(shù)團隊的現(xiàn)狀？運營商內(nèi)部好的甲乙方技術(shù)力量，是否可以復(fù)用創(chuàng)造更大的效益？

如果確實要這么干，那么應(yīng)該從對數(shù)據(jù)的強一致性、數(shù)據(jù)庫的可擴展性、安全性等要求相對不高的系統(tǒng)入手，逐漸積累經(jīng)驗，鍛煉隊伍，逐步深入?；蛟S有那么一天，我們能將“去O”落實到我們的核心系統(tǒng)中，但這一天應(yīng)該不會馬上到來。要知道，技術(shù)掌控力強于多數(shù)運營商的阿里巴巴，目前真正涉及到錢款交易的支付寶核心系統(tǒng)，仍然在使用Oracle?？梢钥吹剑ヂ?lián)網(wǎng)公司的“去O”進程，也是由淺入深，由外向內(nèi)的，這一點值得借鑒。

此外，運營商也可以考慮一下國產(chǎn)數(shù)據(jù)庫，走國產(chǎn)庫的路是符合社會特點的。

很多人一談到國產(chǎn)數(shù)據(jù)庫就嗤之以鼻，筆者認為這種態(tài)度不可取?，F(xiàn)在國貨或許還不行，但我們還是要努力培養(yǎng)，讓其盡可能茁壯成長。至少，目前國產(chǎn)數(shù)據(jù)庫與Oracle代碼在紙面上的兼容性要強于MySQL，而且不同程度地支持與Oracle的異構(gòu)容災(zāi)。國產(chǎn)數(shù)據(jù)庫發(fā)展壯大，我想也不是完全沒有可能，沒準我們的國產(chǎn)數(shù)據(jù)庫廠家也能成為下一個華為呢？

總之，“去O”數(shù)據(jù)庫產(chǎn)品的選擇，本質(zhì)是在運營商環(huán)境下不同技術(shù)路線的選擇。西藥立竿見影，中藥固本陪源，歸根結(jié)底還是要培養(yǎng)自身技術(shù)力量，多學習互聯(lián)網(wǎng)公司以及銀行業(yè)的先進經(jīng)驗。只要正確理解、有機汲取互聯(lián)網(wǎng)行業(yè)的先進技術(shù)思路，結(jié)合運營商的現(xiàn)實環(huán)境情況，開拓思維，勇于創(chuàng)新，我們一定能走出一條我們自己的有運營商特色的“去O”之路來。

總之，“去O”數(shù)據(jù)庫產(chǎn)品的選擇，本質(zhì)是在運營商環(huán)境下不同技術(shù)路線的選擇。西藥立竿見影，中藥固本陪源，歸根結(jié)底還是要培養(yǎng)自身的技術(shù)力量，多學習互聯(lián)網(wǎng)公司以及銀行業(yè)的先進經(jīng)驗。