張式勤，郭岳（中國移動通信集團浙江有限公司，杭州 310012）

運營商去IOE策略研究*

張式勤，郭岳
（中國移動通信集團浙江有限公司，杭州 310012）

為增強運營商核心系統(tǒng)安全保障能力，切實保障企業(yè)乃至國家利益，需要逐步“去IOE”—— 去掉以IBM為代表的小型機硬件設(shè)備，不再使用集中式技術(shù)架構(gòu)，改為基于開放式x86硬件平臺的分布式技術(shù)架構(gòu)；去掉以O(shè)racle為代表的商用數(shù)據(jù)庫軟件，改為開源國產(chǎn)數(shù)據(jù)庫以及大數(shù)據(jù)等方案；去掉以EMC為代表的高端集中式存儲設(shè)備，改為使用開放通用的x86服務(wù)器本地存儲。

去IOE；云化架構(gòu)；SDS；數(shù)據(jù)庫一體機

1　去IOE研究背景

2013年5月17日，阿里巴巴集團最后一臺IBM小型機在支付寶下線，同年7月10日，淘寶廣告系統(tǒng)使用的Oracle數(shù)據(jù)庫下線，也是整個淘寶最后一個Oracle數(shù)據(jù)庫。自2009年阿里巴巴透露去IOE戰(zhàn)略以來，去IOE已然成為社會討論的熱點。

在傳統(tǒng)業(yè)務(wù)領(lǐng)域，如金融、電信，IOE架構(gòu)憑借著高可用、高可靠、高安全性贏得了大部分市場，然后隨著數(shù)據(jù)量爆發(fā)式增長以及系統(tǒng)功能的日益復(fù)雜，IOE架構(gòu)受到了巨大的挑戰(zhàn)。

Scale-up（縱向擴展）模式的系統(tǒng)通常是一個應(yīng)用只有一個節(jié)點，通過向該節(jié)點增加處理器等運算資源進行升級以滿足應(yīng)用對性能的要求，但當(dāng)節(jié)點容量逐漸增大，系統(tǒng)性能、擴容成本都會成為嚴(yán)重的瓶頸。

IOE架構(gòu)向來以封閉性為主，也因而帶來該架構(gòu)的高可用和高可靠性，然而，封閉性帶來的還有服務(wù)和技術(shù)必須受制于原廠，此外封閉性導(dǎo)致的信息安全也不容忽視。

由此可見，去IOE不是簡單的將IBM、Oralce、EMC的產(chǎn)品替換掉，其本質(zhì)是采用“分布式+開源”架構(gòu)替代“集中式+封閉”架構(gòu)。

2　去“IOE”研究方向

本項目以IT支撐系統(tǒng)為研究范圍，以構(gòu)建靈活、開放、彈性的“分布式+開源”架構(gòu)為目標(biāo)，進行去IOE的策略及技術(shù)演進路線的研究。主要研究內(nèi)容如下。

（1）通過與互聯(lián)網(wǎng)企業(yè)比較，進行運營商去IOE驅(qū)動力研究：重點分析運營商去IOE與互聯(lián)網(wǎng)企業(yè)的不同之處以及運營商去IOE的關(guān)鍵點。

（2）對引入互聯(lián)網(wǎng)分布式架構(gòu)采用的x86刀片化、分布式文件系統(tǒng)、分布式數(shù)據(jù)庫、MPP、SDS、數(shù)據(jù)庫一體機等進行技術(shù)及可行性研究，針對去IOE技術(shù)難點制定解決對策。

（3）進行運營商IT支撐系統(tǒng)去IOE技術(shù)演進路線研究：分別針對去IOE制定對應(yīng)的技術(shù)演進路線，并制定最終演進目標(biāo)。

（4）制定運營商IT支撐系統(tǒng)未來3年去IOE后續(xù)建設(shè)目標(biāo)及計劃。

3　去IOE技術(shù)選型分析

運營商IT支撐系統(tǒng)承擔(dān)著舉足輕重的作用，尤其如BOSS、CRM等核心支撐系統(tǒng)與用戶日常手機業(yè)務(wù)的使用息息相關(guān)，基于高可用、高可靠、高安全性等要求，運營商IT支撐系統(tǒng)多數(shù)采用IOE架構(gòu)，隨著用戶數(shù)增長，業(yè)務(wù)量提升，IT支撐系統(tǒng)將可能處于高負(fù)荷運行狀態(tài)，原有的IOE架構(gòu)將不再適應(yīng)業(yè)務(wù)的發(fā)展需求，需要考慮實施去IOE策略。

（1）容量驅(qū)動：通過去IOE，建立分布式的開放架構(gòu)，實現(xiàn)系統(tǒng)能力線性擴展，有效支撐未來業(yè)務(wù)發(fā)展，確保系統(tǒng)架構(gòu)的先進性和能力領(lǐng)先。

（2）管理驅(qū)動：通過去IOE，減少在軟硬件維保、技術(shù)支持、以及開發(fā)方面對供應(yīng)商的依賴度，技術(shù)內(nèi)化，加強對核心能力的掌控。

（3）成本驅(qū)動：過去IOE，引入標(biāo)準(zhǔn)化通用設(shè)備和開源數(shù)據(jù)庫，大幅節(jié)省投資和運維成本，提升效益。

（4）政策及社會責(zé)任驅(qū)動。

3.1去I驅(qū)動力分析

（1）小型機集中式架構(gòu)擴展性能受限。

（2）x86服務(wù)器成本低于小型機。

（3）加強核心能力掌控，減少對供應(yīng)商的依賴。

（4）引入國產(chǎn)或定制產(chǎn)品，保障信息安全。

小型機技術(shù)封閉且非標(biāo)準(zhǔn)化，運營商無法掌控信息安全，可能影響企業(yè)、國家利益，有必要引入國產(chǎn)或定制產(chǎn)品，增強信息安全管控力度。

3.2去I技術(shù)難點與對策

小型機作為IT系統(tǒng)的主要計算設(shè)備承載了大部分的業(yè)務(wù)，但從擴展性、性價比、核心能力掌控等角度而言已經(jīng)不適宜當(dāng)前發(fā)展。

3.2.1計算性能

難點分析：單臺x86服務(wù)器性能不足。

解決對策：x86單個CPU處理能力一直在提升，目前已達到或超越小型機單CPU處理能力，應(yīng)用采用分布式架構(gòu)，提升處理能力。

3.2.2可靠性

難點分析：x86服務(wù)器可靠性一般不超過99.99%，低于Unix服務(wù)器。

解決對策：通過集群技術(shù)以及云化技術(shù)，確保整體可靠性。

3.2.3應(yīng)用遷移

難點分析：x86服務(wù)器采用Linux操作系統(tǒng)，小型機采用Unix操作系統(tǒng)，基于C++架構(gòu)的應(yīng)用移植性較差。

解決對策：C++架構(gòu)向Java架構(gòu)遷移，軟件模塊化，降低耦合度。

從上面分析可以看出，去I主要難點在于技術(shù)架構(gòu)，應(yīng)用層會涉及部分代碼重構(gòu)，而數(shù)據(jù)庫層則需通過數(shù)據(jù)庫云平臺等新技術(shù)手段實現(xiàn)去I。

3.3去I技術(shù)路線

去I技術(shù)路線以直接替換為x86服務(wù)器為主，部分系統(tǒng)遷移至數(shù)據(jù)庫云平臺，OLAP主要遷移至大數(shù)據(jù)平臺，如圖1所示。

圖1　去I技術(shù)路線

3.4去O驅(qū)動力分析

（1）傳統(tǒng)商業(yè)數(shù)據(jù)庫擴展性受限。

（2）傳統(tǒng)國外商業(yè)數(shù)據(jù)庫采購及服務(wù)成本高。

（3）加強核心能力掌控，減少對供應(yīng)商的依賴。

（4）引入國產(chǎn)或開源產(chǎn)品，保障信息安全。

傳統(tǒng)數(shù)據(jù)庫技術(shù)為封閉式非標(biāo)準(zhǔn)化，運營商無法掌控信息安全，影響企業(yè)、國家利益，有必要引入國產(chǎn)或開源產(chǎn)品，增強信息安全管控力度。

3.5去O技術(shù)路線

阿里集團業(yè)務(wù)增長迅速，傳統(tǒng)IOE架構(gòu)無法滿足業(yè)務(wù)發(fā)展，隨著業(yè)務(wù)的爆炸性增長，不得不采用了全分布式架構(gòu)，其采用的應(yīng)對方式如下。

（1）大量的業(yè)務(wù)改造：充分發(fā)揮阿里自主研發(fā)團隊擁有研發(fā)能力的優(yōu)勢，進行大量業(yè)務(wù)改造，實現(xiàn)數(shù)據(jù)遷移、數(shù)據(jù)路由、數(shù)據(jù)同步、分布式事務(wù)處理以及規(guī)模化運維系統(tǒng)，從系統(tǒng)層徹底實現(xiàn)全分布架構(gòu)。

（2）適度結(jié)合技術(shù)架構(gòu)改造：使用緩存、閃存等技術(shù)提升系統(tǒng)垂直擴展能力。

（3）明確的業(yè)務(wù)補償機制：采用業(yè)務(wù)補償，解決用戶投訴。

相比阿里集團的去IOE改造，運營商有以下不同。

（1）業(yè)務(wù)處于相對平穩(wěn)發(fā)展期，業(yè)務(wù)發(fā)展及能力開放造成的壓力將主要沖擊BOSS。

（2）借鑒阿里等互聯(lián)網(wǎng)企業(yè)的經(jīng)驗，系統(tǒng)中已經(jīng)全面使用了緩存技術(shù)，大幅降低數(shù)據(jù)庫壓力。

（3）對應(yīng)用架構(gòu)進行改造的代價將遠(yuǎn)遠(yuǎn)高于對技術(shù)架構(gòu)進行改造；已驗證可通過使用數(shù)據(jù)庫云平臺，提升系統(tǒng)單點處理能力。

（4）因公司承擔(dān)更多社會責(zé)任，不建議推廣使用業(yè)務(wù)補償機制。

（5）阿里公司有自主研發(fā)團隊，而運營商的技術(shù)研發(fā)能力相對較弱。

綜合對比分析阿里集團和運營商的業(yè)務(wù)情況，要吸取阿里集團去IOE的精髓，同時，結(jié)合自身系統(tǒng)特點，走出一條國內(nèi)運營商的去O之路，在一致性、可用性、分區(qū)容忍性、水平擴展、垂直擴展等因素之間獲得更合適的平衡點，盡量規(guī)避業(yè)務(wù)補償，規(guī)避不必要的應(yīng)用改造代價。

不推薦完全照搬阿里的全分布式架構(gòu)，不同業(yè)務(wù)場景采用不同程度的分布式解決方案。利用數(shù)據(jù)庫云平臺，緩存等新技術(shù)，有力提升系統(tǒng)的垂直擴展能力。

3.6去E驅(qū)動力分析

（1）傳統(tǒng)集中式存儲設(shè)備擴展性受限。

（2）x86服務(wù)器本地存儲成本低于傳統(tǒng)盤陣。

（3）加強核心能力掌控，減少對供應(yīng)商的依賴。

（4）引入國產(chǎn)或定制產(chǎn)品，保障信息安全。

傳統(tǒng)存儲設(shè)備技術(shù)為封閉式非標(biāo)準(zhǔn)化，運營商無法掌控信息安全，影響企業(yè)、國家利益，有必要引入國產(chǎn)或開源產(chǎn)品，增強信息安全管控力度。

3.7去E技術(shù)難點與對策

傳統(tǒng)高端集中式存儲是目前運營商IT系統(tǒng)中數(shù)據(jù)存儲的主要介質(zhì)，但從擴展性、性價比、核心能力掌控等角度而言已經(jīng)不適宜當(dāng)前發(fā)展。

3.7.1存儲性能

難點分析：單個普通本地存儲IOPS達不到中高檔存儲設(shè)備IOPS能力，本地存儲整體存儲性能不及中高檔存儲設(shè)備。

解決對策：采用SSD、Fusion IO等技術(shù)提升單個存儲能力，比如引入數(shù)據(jù)庫云平臺，利用分布式存儲技術(shù)提升整體存儲性能（SDS技術(shù)尚未成熟，待繼續(xù)研究）。

3.7.2可靠性

難點分析：x86服務(wù)器本地硬盤故障率相對較高，可靠性下降。

解決對策：采用分布式文件系統(tǒng)或分布式存儲，將數(shù)據(jù)分布在多份副本上，提升數(shù)據(jù)可靠性。

3.7.3容災(zāi)技術(shù)

難點分析：傳統(tǒng)盤陣下基于底層復(fù)制，去E后需要研究適用x86平臺的容災(zāi)備份技術(shù)。

解決對策：采用基于開源的存儲復(fù)制技術(shù)或數(shù)據(jù)庫復(fù)制技術(shù)（如ADG等）。

3.8去E技術(shù)路線

數(shù)據(jù)存儲類型主要分為數(shù)據(jù)庫與文件系統(tǒng)兩大類，不同的存儲類型，不同的性能和容量要求需要采用不同的去E技術(shù)，任何一種單一技術(shù)都難以適應(yīng)運營商全部數(shù)據(jù)采集、存儲、處理的需求，多種技術(shù)并存才是發(fā)展趨勢。具體技術(shù)路線如圖2所示。

圖2　去E技術(shù)路線

4　去IOE演進策略

4.1從服務(wù)著手，制定運營商特色的去O之路

Oracle數(shù)據(jù)庫在運營商核心系統(tǒng)中仍占據(jù)重要地位，近期內(nèi)完全去O不符合實際需求，在吸取互聯(lián)網(wǎng)公司去IOE精髓的基礎(chǔ)上，結(jié)合自身系統(tǒng)特點提出：近期內(nèi)，從服務(wù)方面去O著手，提升自身技術(shù)水平，降低維護成本，同時在部分外圍系統(tǒng)采用非Oracle數(shù)據(jù)庫實現(xiàn)完全去O，保留核心系統(tǒng)中的Oracle數(shù)據(jù)。

（1）第1步：去O的服務(wù)，以及核心數(shù)據(jù)庫去IE。核心系統(tǒng)暫時保留O，但通過培養(yǎng)自主的力量來實現(xiàn)O的服務(wù)自主化，積累在數(shù)據(jù)庫方面的經(jīng)驗和技能。通過與合作伙伴合作組建創(chuàng)新研發(fā)團隊，研發(fā)數(shù)據(jù)庫云平臺技術(shù)（數(shù)據(jù)庫云平臺是基于x86平臺搭建的高效、 廉價的一體機平臺，在同等性能下，相比傳統(tǒng)IE架構(gòu)，能大幅降低采購成本，同時可應(yīng)用于其它數(shù)據(jù)庫，提供完整去O的硬件平臺支撐），在去IE的同時完成性能的提升。

（2）第2步：部分業(yè)務(wù)系統(tǒng)嘗試去O。在周邊系統(tǒng)、以及部分經(jīng)營分析類應(yīng)用中，可以通過Hadoop、 Mysql、國產(chǎn)數(shù)據(jù)庫嘗試替代傳統(tǒng)的O，并培養(yǎng)積累自主的技術(shù)能力，為長遠(yuǎn)去O打下基礎(chǔ)。

（3）第3步：核心系統(tǒng)逐步去O。在已有積累的基礎(chǔ)上，確定完整去O的計劃。

4.2引入數(shù)據(jù)庫云平臺技術(shù)，為全面去O打下堅實基礎(chǔ)

數(shù)據(jù)庫云平臺解決方案是以x86架構(gòu)的服務(wù)器、存儲為核心，結(jié)合高性能交換設(shè)備和數(shù)據(jù)庫，搭建而成的數(shù)據(jù)庫一體機，用于擺脫傳統(tǒng)的以小型機和高端存儲為核心搭建的高性能數(shù)據(jù)庫模式。

傳統(tǒng)數(shù)據(jù)庫的云化有如下難點。

（1）簡單的x86化無法滿足傳統(tǒng)數(shù)據(jù)庫高并發(fā)，低延遲的要求。

（2）數(shù)據(jù)庫云化不是簡單的技術(shù)架構(gòu)問題， 可能會對現(xiàn)有系統(tǒng)的應(yīng)用架構(gòu)和數(shù)據(jù)架構(gòu)造成極大沖擊。

數(shù)據(jù)庫云平臺具有如下優(yōu)勢。

（1）計算節(jié)點與存儲節(jié)點間通過Infiniband交換機互聯(lián)，并通過SSD加速，對訪問數(shù)據(jù)進行智能緩存，大幅提高數(shù)據(jù)庫IO性能。

（2）開放平臺可以部署多種數(shù)據(jù)庫如Oracle、Mysql、DB2等，實現(xiàn)現(xiàn)有業(yè)務(wù)系統(tǒng)的平滑遷移。

（3）通過分布式存儲的設(shè)計，將數(shù)據(jù)均勻分散在存儲節(jié)點的所有磁盤上，并可在帶外和其它存儲進行數(shù)據(jù)同步復(fù)制，實現(xiàn)存儲級容災(zāi)。

（4）計算節(jié)點、存儲節(jié)點、SSD、Infiniband交換機全部選用標(biāo)準(zhǔn)成熟部件，無任何工業(yè)定制。

數(shù)據(jù)庫云平臺架構(gòu)如圖3所示。

4.3制定3條技術(shù)路線，確定系統(tǒng)架構(gòu)演進方向

根據(jù)當(dāng)前云計算技術(shù)的發(fā)展，結(jié)合運營商自身系統(tǒng)現(xiàn)狀，針對去IOE分別提出技術(shù)演進路線，為未來IT系統(tǒng)架構(gòu)的演進指明了方向。

（1）去I技術(shù)路線：應(yīng)用層部分，以當(dāng)前小型機直接替換為x86服務(wù)器為主；數(shù)據(jù)層部分，IO性能要求不高的系統(tǒng)直接替換為x86服務(wù)器，核心OLTP以及高IO要求的系統(tǒng)遷移至數(shù)據(jù)庫云平臺，OLAP主要遷移至大數(shù)據(jù)平臺。

圖3　數(shù)據(jù)庫云平臺架構(gòu)圖

（2）去O技術(shù)路線：從服務(wù)方面去O著手，降低維護成本，同時在部分外圍系統(tǒng)采用非Oracle數(shù)據(jù)庫實現(xiàn)完全去O，培養(yǎng)積累自主的技術(shù)能力，在已有積累的基礎(chǔ)上，逐步實現(xiàn)核心系統(tǒng)完全去O。

（3）去E技術(shù)路線：不同的存儲類型，不同的性能和容量要求需要采用不同的去E技術(shù)。

數(shù)據(jù)庫方面，以數(shù)據(jù)庫云平臺為主要承載技術(shù)，中等存儲容量需求的OLAP以MPP為主要承載技術(shù)，中等存儲容量需求的OLAP以分布式文件系統(tǒng)（如HDFS）為主要承載技術(shù)。

文件系統(tǒng)方面，以分布式文件系統(tǒng)（如HDFS）為主要承載技術(shù)。

低等容量存儲容量需求的OLTP以及文件系統(tǒng)近期以中低端存儲設(shè)備為主要承載載體，遠(yuǎn)期隨著SDS（軟件定義存儲）技術(shù)的成熟，可將其作為主要承載技術(shù)。

［1］ 饒高鋼，郝金隆. 電信運營商IT系統(tǒng)去IOE思路及實施方法［J］.電信工程技術(shù)與標(biāo)準(zhǔn)化，2014（09）.

［2］ 葉純敏. 中國去“IOE”之路［J］. 金融科技時代，2014（08）.

Research on operators’ strategy of de-IOE

ZHANG Shi-qin， GUO Yue
（China Mobile Group Zhejiang Co.， Ltd.， Hangzhou 310012， China）

To strengthen the security capability of operators’ core systems and safeguard enterprises and national interests， we need to de IOE gradually: remove the minicomputer hardware device represented by IBM and replace the centralized architecture by the distributed architecture based on the open style X86 hardware platform， replace the commercial database software represented by Oracle by open source homemade database and big data， replace the advanced centralized storage device represented by EMC by X86 server used for local storage that is open and interoperable.

de-IOE； cloud-based architecture； software defi ned storage； database machine

TN915

A

1008-5599（2016）08-0026-05

2016-07-16

* 中國移動集團級一類科技創(chuàng)新成果，編號zj2015_LY005_006，原成果名稱為《運營商去“IOE”策略研究 》。