運營商“去O”之我見

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

“去O”的應用驅動分析

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

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

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

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

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

實際上，阿里巴巴做去IOE有其業務發展上的原因。

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

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

“去O”的技術難點

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

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

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

運營商最好的辦法，是向互聯網公司學習改革，創造機制培養自己技術人員。如果做不到，那在數據庫這種核心平臺相關的架構上，或許還真不如用那些國際大公司的產品。

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

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

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

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

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

如果確實要這么干，那么應該從對數據的強一致性、數據庫的可擴展性、安全性等要求相對不高的系統入手，逐漸積累經驗，鍛煉隊伍，逐步深入。或許有那么一天，我們能將“去O”落實到我們的核心系統中，但這一天應該不會馬上到來。要知道，技術掌控力強于多數運營商的阿里巴巴，目前真正涉及到錢款交易的支付寶核心系統，仍然在使用Oracle。可以看到，互聯網公司的“去O”進程，也是由淺入深，由外向內的，這一點值得借鑒。

此外，運營商也可以考慮一下國產數據庫，走國產庫的路是符合社會特點的。

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

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

總之，“去O”數據庫產品的選擇，本質是在運營商環境下不同技術路線的選擇。西藥立竿見影，中藥固本陪源，歸根結底還是要培養自身的技術力量，多學習互聯網公司以及銀行業的先進經驗。