有一個傳說，以前叫做去IOE。
“2015年11月11日20:00，浙江移動手機營業(yè)廳充值1折秒殺活動順利結(jié)束，DCOS平臺充分展現(xiàn)了其在應對業(yè)務高峰時的能力優(yōu)勢，順利通過雙11考驗。”
很顯然，去IOE的傳說已經(jīng)在浙江移動變成了現(xiàn)實，那么運營商如何實現(xiàn)了自己去IOE的理想呢？
能夠改變世界的，都將是偉人；
能夠去IOE的，都不是一般人。
再次糾正去IOE認知
對于在O領域摸爬滾打了10多年的王曉征，現(xiàn)在是中國移動浙江公司信息技術部副總經(jīng)理、中國移動的知名IT專家。11月19日在首屆“天璣數(shù)據(jù)2015精英論壇”的演講中再次提到去IOE認知與哲學，在他看來去IOE不是一種風氣，而是一種真正的實踐與學問。
從各種信息表明，移動、聯(lián)通、電信還是都有不同程度的去IOE實踐。但這種實踐的過程首先需要有明確的認知，IOE架構(gòu)的特點霸道的地方在于，基于向上擴展(Scale-up)技術的高端設備以及圍繞著它們開發(fā)的專有硬件、大型數(shù)據(jù)庫和商業(yè)中間件。當前用戶紛紛開始云計算實踐，IT系統(tǒng)云化的本質(zhì)是以云計算技術為驅(qū)動，基于分布式架構(gòu)，將系統(tǒng)進行基礎軟硬件標準化、應用軟件服務化改造，從而打破信息孤島，實現(xiàn)資源共享、動態(tài)調(diào)整，提高資源利用率、降低建設成本。
王曉征再次糾正業(yè)界存在的去IOE認知，現(xiàn)場侃侃而談。
不論去IOE對不對，先談一談對定義的理解。去IOE廣義的理解，是要去掉小型機、商業(yè)閉源數(shù)據(jù)庫、高端集中式存儲陣列。以IBM、Oracle、EMC為代表的傳統(tǒng)IT巨頭提供的是整體解決方案，去IOE的本質(zhì)是“分布式+開源+ Scale-out”架構(gòu)替代“集中式+封閉+ Scale-up”架構(gòu)，從而轉(zhuǎn)變成徹底的云計算服務模式。
思路明確了，方向走對了，去IOE目標才能逐漸靠近。
不過，即便去IOE的目標一致，但隔行如隔山，每個行業(yè)的去IOE還是有許多不同之處的，如果拿同一個標準和方法去套用每個行業(yè)，最終的結(jié)果和拿著框框買鴨蛋一樣。
阿里去IOE不具備普世性
去IOE是來自互聯(lián)網(wǎng)行業(yè)的概念，由阿里巴巴公司于2010年最先發(fā)起。必須看到阿里巴巴的去IOE方案絕對是一種創(chuàng)舉，但也得認識到它不具備普世性，具體情況具體分析才是王道。以去O為例，盲目去O是莽撞，就像七傷拳，打得越多傷得越重。
這里需要指出的是：阿里業(yè)務爆發(fā)性增長，對系統(tǒng)的擴展性具有極大的需求，并且商業(yè)產(chǎn)品的采購以及服務成本高，同時，阿里云是公有云，需要采用開源產(chǎn)品降低成本，才能展示實力，加上阿里也有自己的IT技術資源與積累。可見，阿里去IOE的驅(qū)動力很強，這是剛需，也有自己的技術能力去搞定開源與IT系統(tǒng)的事情。
三大因素驅(qū)動運營商去IOE
相對來說，作為傳統(tǒng)的運營商，需要的是穩(wěn)定可靠高效的IT，又是什么驅(qū)動力讓其也要去IOE呢？
王曉征分析認為運營商去IOE來自幾個方面的原因：
首先，我們都處于一個移動互聯(lián)網(wǎng)時代，像運營商這樣傳統(tǒng)行業(yè)的IT系統(tǒng)也不可能獨善其身。定會遇到各種互聯(lián)網(wǎng)流量沖擊，其中因業(yè)務驅(qū)動帶來的諸多挑戰(zhàn)也是其中的原因。這就需要建立分布式的開放架構(gòu)，實現(xiàn)系統(tǒng)能力線性擴展，有效支撐未來業(yè)務發(fā)展，確保系統(tǒng)架構(gòu)的先進性和能力領先。
其次，是運營商自身的技術能力驅(qū)動。即使運營商沒有阿里那樣的技術研發(fā)能力，但像浙江移動也一直考慮在合理情況下是不是可以降低對供應商的依賴度，使用一些更開放的架構(gòu)去解決移動供應鏈的問題。最終實現(xiàn)技術內(nèi)化，加強對核心能力的掌控。
再次，也是成本問題，運營商照樣需要開源節(jié)流，降低成本也是大家考慮的重點之一。但成本這個詞有著很多的內(nèi)容，并非價格就可以代表。這就需要考慮引入標準化通用基礎設施和配套的新一代技術架構(gòu)，優(yōu)化投資和運維成本結(jié)構(gòu)，提升技術掌控力，提升整體效益。
再者，運營商都屬于國企，信息安全和社會輿論都很重視。有些事情阿里可以做，但運營商不能做，這就是政策原因。但兩者去IOE發(fā)展的方向是一致的。
上面一張圖，是否讓你秒懂運營商和阿里去IOE的驅(qū)動力？呵呵
對于阿里，對于運營商，大家對于去IOE有著不同的驅(qū)動、不同的能力，必然帶來不同的選擇。如果選擇相同，就需要想想是不是哪里出了問題？
既然去IOE已經(jīng)成為一種選擇，那么到底該如何一個一個地去I、去O、去E呢？其中的技術難點在哪里？有何良策可依呢？
去I：技術架構(gòu)是關鍵
小型機作為IT系統(tǒng)的主要計算設備承載了大部分的業(yè)務，但從擴展性、性價比、核心能力掌控等角度而言已經(jīng)不適宜當前發(fā)展。X86單個CPU處理能力一直在提升，目前已達到或超越小型機單CPU處理能力。應用了分布架構(gòu)和云計算技術，是否可以用一個數(shù)據(jù)中心去替代某一臺大機？這在理論上是可行的，不過，應用采用分布式架構(gòu)，提升處理能力，必須對應用代碼進行改造。
比如在近年來運營商做的很多核心系統(tǒng)云化的嘗試本質(zhì)上也可以看成是一種相對私有化的、有限度的云計算架構(gòu)創(chuàng)新。一般的做法是采用傳統(tǒng)的IT架構(gòu)思路對應用進行云化改造，底層往往是基于虛機化方式去實現(xiàn)IAAS層的標準化，然后將應用進行私有化的分布式和集群化改造。這種路線的進一步演進的必然結(jié)果就是DCOS的橫空出世。
三條路線，簡單明了，親們覺得這三條去I路如何？
那么，去I技術路線就非常明確了，應用層確實可以替換成廉價X68服務器，不過需要指出的是任何指望應用層完全透明的云化改造都是“耍流氓”，云化必然帶來對應用的侵入，無非是用什么技術方案如何侵入的問題，理論上應用侵入越小，云化就越不徹底。（比如常見的將應用簡單遷移到虛機，應用伸縮完全依賴于虛機的伸縮，這就是一種非常原始的云化方案）。數(shù)據(jù)層也可以采用X86服務器或者是數(shù)據(jù)庫一體機來實現(xiàn)云化改造，分析型業(yè)務則主要遷移到大數(shù)據(jù)平臺，基本上就是這些基本路線，無非是大家根據(jù)什么情況去做什么樣的選擇。
總之，去I主要難點在于技術架構(gòu)，應用層會涉及部分代碼重構(gòu)，而數(shù)據(jù)庫層則需通過數(shù)據(jù)庫云平臺等新技術手段實現(xiàn)去I。
延展幾句話，IOE架構(gòu)的基石是穩(wěn)定的基礎設施，去IOE架構(gòu)的基礎是不穩(wěn)定的基礎設施，那么就需要在一個不穩(wěn)定的基礎設施上建立一個穩(wěn)定的系統(tǒng)，同時沒有強大的軟件支持就很難實現(xiàn)。比如浙江移動與天璣科技聯(lián)合研發(fā)的DCOS（數(shù)據(jù)中心操作系統(tǒng)），以分布式集群資源調(diào)度（Apache Mesos和Apache Hadoop YARN）為基礎，結(jié)合容器（Docker）技術構(gòu)建的一個標準化的高效平臺，支持多種計算框架，具備敏捷開發(fā)、快速部署和彈性伸縮的特性。
浙江移動DCOS技術架結(jié)合行業(yè)主流技術方案，通過關鍵技術選型，即以容器為基礎封裝各類無狀態(tài)應用和運行環(huán)境，以Mesos為核心實現(xiàn)容器資源的分布式調(diào)度與協(xié)調(diào)。DCOS已經(jīng)成為了浙江移動的第三代PaaS中的核心組件。
為此，今年雙十一期間，DCOS的首次實踐在浙江移動手機營業(yè)廳充值秒殺活動中，成功應對業(yè)務高峰，順利通過雙11的實戰(zhàn)考驗。
去E：SDS代表了未來
傳統(tǒng)高端集中式存儲是目前運營商IT系統(tǒng)中數(shù)據(jù)存儲的主要介質(zhì),但從擴展性、性價比、核心能力掌控等角度而言已經(jīng)不再是用戶的不二選擇。
去E主要難點僅限于技術架構(gòu)，對應用基本無影響，但是進度依賴于技術手段的成熟度。
看完上圖后，去E你們覺得還有什么路可以走嗎？
去E需要在存儲性能、可靠性和容災方面考慮對策。傳統(tǒng)架構(gòu)中，在IOE架構(gòu)中的存儲提出了相當多的可靠性要求，既要高性能，又要穩(wěn)定和可靠，還要能夠支撐各種各樣數(shù)據(jù)安全的復制。從表面上看去E似乎也都有出路，比如說數(shù)據(jù)庫在OLTP的場景下往往可以采用數(shù)據(jù)庫一體機，當然也可以用SDS或者分布式文件系統(tǒng)去搞定。
其實，分布式文件系統(tǒng)與SDS在某種意義上有著類似的架構(gòu)思路，說到底E針對的就是數(shù)據(jù)，無非要在平衡CAP原理的情況下，用各種各樣不同的技術路線來解決數(shù)據(jù)的安全問題，這是基本思路。
王曉征認為，去E最終可能是一件比較靠譜的事情，但過程具有挑戰(zhàn)性。
為什么呢？
實際上，如果一個產(chǎn)品采用了封閉架構(gòu)，那么從理論上說，這種架構(gòu)對供應商有利，而對用戶不利。因為供應商往往會搞定整個產(chǎn)品的解決方案，而不會為一個架構(gòu)創(chuàng)新。
傳統(tǒng)存儲采用了一個集中化的架構(gòu)，很難想像HP和IBM的存儲是否可以互換硬件？那么如何才能對用戶比較有利呢？目前的一個大方向就是采用標準化硬件搭建，借助軟件定義存儲去實現(xiàn)。可是，事情又說回來了，市場上有那么多SDS，用戶怎么知道哪一個廠商SDS經(jīng)過了商業(yè)化定制，真正能夠穩(wěn)定和安全。因此，這對實際要采用SDS的用戶來說算是一個很大的挑戰(zhàn)，可見，SDS代表了未來，然而前途是光明的道路是曲折的，對用戶和存儲廠商都是一種挑戰(zhàn)。
去O：四大誤區(qū)與四條道路
去O是去IOE中爭議最大的一個問題，現(xiàn)在大家對去O存在4大誤區(qū)：一是認為去O能省成本；二是認為去O能降低對供應商依賴；三是認為去O是解決數(shù)據(jù)庫可擴展性問題的主要途徑；四是認為去O主要問題在于數(shù)據(jù)運維。
從運營商角度來看，如何糾正去IOE這四大誤區(qū)呢？
一方面，去O費成本，去O肯定會導致成本增加，但操作得當可以提升核心能力掌控；
二方面，去O很可能會加大對供應商依賴，簡單去O會降低對數(shù)據(jù)庫原廠的依賴，但會增加對新數(shù)據(jù)庫以及應用系統(tǒng)開發(fā)商的依賴；很少有哪個數(shù)據(jù)庫的生態(tài)環(huán)境達到O記的水平，而良好的生態(tài)環(huán)境正是降低對原廠依賴的關鍵。如果連O的掌控都做不到，去O換成任何一個數(shù)據(jù)庫，很可能更掌控不了。走都走不好何談去跑？
三方面，去O主要困難是數(shù)據(jù)架構(gòu)管控能力，因為去O的主要困難不是新數(shù)據(jù)庫的運維，而是數(shù)據(jù)一致性和性能方面的挑戰(zhàn)，本質(zhì)上是數(shù)據(jù)架構(gòu)管控的爭奪；
四方面，解決數(shù)據(jù)庫擴展問題不一定要去O，對于數(shù)據(jù)庫擴展問題，可以通過Scale-out+Scale-up 等多種技術手段解決，不可一概而論。
Oracle是一個最強大的關系型數(shù)據(jù)庫，它的單點處理能力、數(shù)據(jù)安全性和開發(fā)支持能力等都是比較強的。想要把單點處理能力解決掉的話，當然數(shù)據(jù)庫一體機的Scale-up方案是一種選擇，不過，從Scale-out角度上說，就必須要走分布分表的方案。
其實，阿里分布式關系型數(shù)據(jù)庫服務(Distribute Relational Database Service,簡稱DRDS)本質(zhì)上在走這種技術架構(gòu)，但是這種技術架構(gòu)對用戶應用有著很大侵入，這一點必須任何到。
去O的數(shù)據(jù)庫產(chǎn)品選型上，想要徹底去除國外商業(yè)數(shù)據(jù)庫，使用O以外的商業(yè)數(shù)據(jù)庫來實現(xiàn)去O，這是投機取巧的選擇，不具備太大的意義；采用純國產(chǎn)數(shù)據(jù)庫，需要審慎對待，國產(chǎn)數(shù)據(jù)庫在企業(yè)級應用環(huán)境下的穩(wěn)定性以及性能還未得到長時間運行驗證，風險高，同時選擇國產(chǎn)數(shù)據(jù)庫，會進入到產(chǎn)品的細小分支，后續(xù)支持力度可能會存在問題；國內(nèi)廠商收購的國外數(shù)據(jù)庫，其本質(zhì)暫時仍然是國外數(shù)據(jù)庫，國人完全掌控需要一段時間；采用開源數(shù)據(jù)庫，叫好不叫座。開源數(shù)據(jù)庫是互聯(lián)網(wǎng)去O的主流選擇，但需要較高的技術掌控門檻，然而，對于開源定制版數(shù)據(jù)庫，相對靠譜。本地自主掌控運維優(yōu)化能力，把代碼級能力交給合作伙伴或體系內(nèi)自主研發(fā)團隊，實現(xiàn)合作共贏的方式。
目前，MySQL和PostGreSQL是業(yè)界去O的兩個典型選擇，但是在維護以及開發(fā)維護均有較大差異。PostGreSQL提供的維護支持功能豐富，適合大型數(shù)據(jù)庫系統(tǒng)，而MySQL則較為簡易、靈活。
PostGreSQL在表結(jié)構(gòu)、SQL語法支持、程序代碼支持上更貼近Oracle，開發(fā)人員更易接受。因為PostGreSQL世界上最大的開源數(shù)據(jù)庫，具備很多類似Oracle的優(yōu)點，比如優(yōu)化器強大、穩(wěn)定，支持復雜查詢，支持多種表連接方式，維護調(diào)優(yōu)工具豐富。
基于這些分析和對比，去O可以有四條路可以走：
一是直接采用開源定制產(chǎn)品進行替換，比如浙江移動使用的大云RDB產(chǎn)品，以開源PG-XC為藍本，在軟硬件層面進行優(yōu)化定制；
二是打造統(tǒng)一數(shù)據(jù)路由Scale-out平臺，分庫分表，提升橫向擴展能力；
三是立足于Scale-up數(shù)據(jù)庫云平臺，持續(xù)研究創(chuàng)新，提升單點硬件的支撐能力，為去O打造硬件基礎；
四是打造數(shù)據(jù)架構(gòu)管控能力，組建產(chǎn)品DBA小組，全面參與項目規(guī)劃與開發(fā)，實現(xiàn)充分利用緩存以及數(shù)據(jù)庫讀寫分離技術，有效減輕對數(shù)據(jù)庫性能的直接依賴。
浙江移動去O四步走
實踐出真知。從?浙江移動去O的推進實踐過程來看，從易到難，分三階段，遵循“研究、驗證、上線”的科學發(fā)展觀，步步為營，穩(wěn)步推進去O。
第一步，研究驗證開源MySQL和PostGerSQL在OLTP與OLAP場景下的適用性，外圍系統(tǒng)先行試用PostGreSQL/MySQL，積累開發(fā)、運維經(jīng)驗，在合適的外圍系統(tǒng)中試用，積累開發(fā)、運維使用經(jīng)驗，逐步推進到核心系統(tǒng)。
第二步，在一階段積累的去O基礎上，逐步推進到部分核心系統(tǒng)，研究分布式內(nèi)存數(shù)據(jù)庫+關系型數(shù)據(jù)庫結(jié)合的去O方案，在關鍵系統(tǒng)中驗證可行性。實現(xiàn)去O里程碑的事情，浙江移動基于BC-RDB的統(tǒng)一用戶管理系統(tǒng)正式上線，采用基于開源PG定制版的BC-RDB數(shù)據(jù)庫，標志著浙江移動對開源定制版產(chǎn)品的掌控開始。其中，數(shù)據(jù)分布采用Sharding方式，對數(shù)據(jù)切分進行了嘗試。在與Oracle高度兼容的存儲過程、復雜SQL移植方面，積累了去O割接經(jīng)驗。
第三步，視情況逐步推進到核心系統(tǒng)。對浙江移動來說，去O已經(jīng)不再是一個技術難題，但需要根據(jù)自身需要去綜合考慮必要性和推進程度。
大家都知道，支撐域中絕大部分的數(shù)據(jù)庫系統(tǒng)都采用集中式IOE架構(gòu)，而基于X86設備的通用數(shù)據(jù)庫云平臺是一個很好的解決方案，這種解決方案國內(nèi)已經(jīng)有天磯、華為等多家公司推出了自己的成熟產(chǎn)品。例如浙江移動聯(lián)合天璣數(shù)據(jù)共同研發(fā)成功的PBData，在經(jīng)分報表、統(tǒng)一酬金、稽核等系統(tǒng)通過驗證測試，總體性能提升達到3-8倍。
從實際應用效果來看，數(shù)據(jù)庫云平臺意義非常重要，在很多場景下可以既滿足性能提升要求，也實現(xiàn)應用完全透明情況下的數(shù)據(jù)庫去IE，或者應用輕度改造下的數(shù)據(jù)庫去IOE，從而實現(xiàn)大幅降低風險，提升系統(tǒng)處理能力，增強擴展能力，大幅降低采購成本。
去IOE的理性世界觀
通過詳細的分析和長期的實踐，王曉征在充分總結(jié)浙江移動去IOE的體會上，形成了一個比較清晰的去IOE世界觀。
去I應激進，很省TCO。倒逼開發(fā)團隊，提升應用架構(gòu)，DCOS很好玩，提升性能、擴展性、可用性，可維護性不是夢。
去E應淡定，較省TCO。數(shù)據(jù)庫云技術+大數(shù)據(jù)技術解決大部分問題。SDS，前途光明過程曲折。
去O應謹慎，讓去O回歸理性，回歸技術。阿里去O方案是創(chuàng)舉卻不具備普世性。沒有最好的技術只有最合適的技術。需要結(jié)合自身實際情況選擇“最適合”的技術，量力而行。
總之一句話：對于大部分用戶來說，去IOE綜合成本不會降低，只是結(jié)構(gòu)變化，但自主可控能力可望得到明顯提升。（阿明）
