周龍，陳喜珠，彭江強

（湖南省郵電規(guī)劃設(shè)計院有限公司，長沙 410001）

“IOE”是指以IBM小型機、Oracle數(shù)據(jù)庫、EMC存儲設(shè)備為代表所組成的IT架構(gòu)，三者構(gòu)成了一個從軟件到硬件的企業(yè)數(shù)據(jù)庫系統(tǒng)。這類數(shù)據(jù)庫系統(tǒng)幾乎占領(lǐng)了全球大部分商用數(shù)據(jù)庫系統(tǒng)市場份額。除阿里巴巴這樣需要大量數(shù)據(jù)運算的電商企業(yè)外，其他如電信行業(yè)也廣泛地使用這套系統(tǒng)。

“去IOE”最初由阿里巴巴提出，阿里去“IOE”背后的原因主要有4個。

（1）集中式強大單點遠(yuǎn)遠(yuǎn)不能滿足爆炸式業(yè)務(wù)增長應(yīng)用模式的出現(xiàn)，導(dǎo)致系統(tǒng)不能滿足業(yè)務(wù)需求。

（2）“IOE”的技術(shù)限制了其它技術(shù)潛力的發(fā)揮。有很多底層細(xì)節(jié)企業(yè)根本無法掌控。

（3）“IOE”設(shè)備對機架、電力、網(wǎng)絡(luò)有特殊要求，要單獨為它設(shè)計，成本偏高。

（4）數(shù)據(jù)庫安全問題。包括數(shù)據(jù)的路由、數(shù)據(jù)安全、規(guī)?；\維、異步數(shù)據(jù)同構(gòu)等問題。

“IOE”所代表的IT架構(gòu)一方面約束了互聯(lián)網(wǎng)巨頭在業(yè)務(wù)靈活配置等方面的企業(yè)長遠(yuǎn)發(fā)展，另一方面也帶來極高的擴展壓力以及天價的包括部署、維護(hù)在內(nèi)的總成本，所以需要采用新的互聯(lián)網(wǎng)技術(shù)和架構(gòu)取代傳統(tǒng)“IOE”架構(gòu)。

1 運營商“去IOE”驅(qū)動力

基于“IOE”設(shè)備的體系架構(gòu)被廣泛地運用到運營商包括營業(yè)、計費、客服等各類IT系統(tǒng)之中。以小型機為基礎(chǔ)搭建起一套集中式的IT支撐系統(tǒng)，在UNIX的開放性系統(tǒng)上開發(fā)應(yīng)用軟件，滿足相應(yīng)的數(shù)據(jù)處理能力。據(jù)業(yè)內(nèi)人士估算，“IOE”設(shè)備的比例一度占到70%～80%。這可以說是同類產(chǎn)品中的最佳組合，是電信級運營系統(tǒng)穩(wěn)定、可靠的典型代表。

近年來，移動互聯(lián)網(wǎng)環(huán)境同樣給運營商支撐系統(tǒng)帶來了數(shù)據(jù)量爆發(fā)性增長。海量數(shù)據(jù)與高并發(fā)對運營商現(xiàn)有支撐系統(tǒng)架構(gòu)已經(jīng)形成沖擊。客戶感知、成本投入、運營效率成為運營商支撐系統(tǒng)建設(shè)需要考慮的突出問題。

運營商流量經(jīng)營過程中，業(yè)務(wù)量快速增長、業(yè)務(wù)峰值問題突出（如表1所示），首先是查詢請求成倍增加。特別是移動互聯(lián)網(wǎng)的發(fā)展帶來的話單查詢的方便性，導(dǎo)致用戶查詢需求增加；其次是查詢接入方式的擴展迅速，越來越多的外部系統(tǒng)接入請求，CRM、網(wǎng)廳、掌廳、客服、自助終端、營銷查詢等；再次是數(shù)據(jù)導(dǎo)入越來越慢，數(shù)據(jù)量增加明顯。對外提供原始清單數(shù)據(jù)的傳遞壓力，大批量的數(shù)據(jù)導(dǎo)出。

體現(xiàn)在日常運營中的困難具體表現(xiàn)如下。

（1）客戶感知變差。月結(jié)清賬單提供延遲、實時查詢接口延遲、停復(fù)機不及時等。月底及促銷營業(yè)高峰業(yè)務(wù)辦理壓力巨大。

（2）投入成本縮減。高端小型機、存儲擴容的成本很高，投入不足會影響運營安全。數(shù)據(jù)庫及操作系統(tǒng)軟件成本壓力巨大。

（3）運營效率不高。煙囪式系統(tǒng)架構(gòu)擴展性差，資源無法共享。面對市場競爭，支撐系統(tǒng)快速擴展響應(yīng)能力有限。

表1 某省級電信運營商2013年業(yè)務(wù)增長數(shù)據(jù)指標(biāo)表

2 運營商IT支撐系統(tǒng)“去IOE”思路

2.1 運營商主要IT系統(tǒng)分類

運營商內(nèi)部IT系統(tǒng)根據(jù)主要計算特點可分為3類。

（1)面向用戶的并發(fā)請求處理部分：訂單受理、資料查詢、訂單處理等請求處理型應(yīng)用，位于系統(tǒng)Web 及APP層。

（2)面向網(wǎng)絡(luò)的重復(fù)性任務(wù)處理部分：如話單采集、數(shù)據(jù)抽取及格式轉(zhuǎn)換等。

（3)核心是復(fù)雜關(guān)系型計算部分：如計費應(yīng)用、各系統(tǒng)數(shù)據(jù)庫等。

2.2 常用“去IOE”解決方案分析

2.2.1 基于x86架構(gòu)的云資源池替代小型機

PC服務(wù)器虛擬化及資源池管理軟件基本成熟，云管理平臺具備基本管理能力，建立內(nèi)部IT系統(tǒng)云平臺技術(shù)條件具備。云平臺適合測試環(huán)境整合、各系統(tǒng)Web及應(yīng)用層的部署。開發(fā)測試環(huán)境整合場景，可有效提高測試環(huán)境利用效率；各系統(tǒng)Web層/應(yīng)用層適合基于PC服務(wù)器部署，同時借助應(yīng)用中間件對操作系統(tǒng)隔離的特性，現(xiàn)有應(yīng)用Web及應(yīng)用層從Unix小型機向基于PC服務(wù)器的Linux環(huán)境遷移技術(shù)可行。

通過服務(wù)器虛擬化方式實現(xiàn)多應(yīng)用共享部署；通過資源池管理及云管理平臺的自動化調(diào)度（應(yīng)用啟停、伸縮、遷移等），實現(xiàn)更加靈活的多應(yīng)用共享部署，提高基礎(chǔ)設(shè)施利用效率及系統(tǒng)可靠性。系統(tǒng)部署架構(gòu)進(jìn)一步集中，發(fā)揮云計算規(guī)模優(yōu)勢，提升IT集約化運營水平：進(jìn)一步提高系統(tǒng)部署物理集中度，發(fā)揮云計算的規(guī)模優(yōu)勢，提高基礎(chǔ)設(shè)施利用效率。

存在問題如下。

（1）由于云主機共享物理資源，一般在I/O性能上不如物理機，因此對于高I/O要求的可考慮物理機承載。

（2）由于虛擬化技術(shù)成熟性，在支持?jǐn)?shù)據(jù)庫Cluster/HA等方面尚不完善（如數(shù)據(jù)庫RAC支持存在一定問題），需要數(shù)據(jù)庫RAC的應(yīng)用可考慮用物理機承載。

（3）虛擬化技術(shù)本身支持HA技術(shù)，但由于虛擬化軟件無法感知應(yīng)用失效，因此不能依靠虛擬化HA解決應(yīng)用高可靠問題，需要在應(yīng)用層部署HA軟件。

（4）目前服務(wù)器虛擬化主要是一虛多，再加上虛擬化軟件本身消耗一定的系統(tǒng)資源，因此并非所有應(yīng)用都適合于遷移到虛擬機上，對于物理機CPU利用率大于50%的應(yīng)用不建議部署到虛擬機上。

2.2.2 開源數(shù)據(jù)庫軟件替代Oracle

通過部分場景替換Oracle方式進(jìn)行拆分實現(xiàn)。

2.2.3 分布式存儲替代集中式存儲

集中式存儲是目前資源池的主要存儲提供方式，主要通過硬件保障性能和可靠性，主流技術(shù)包括FC-SAN、 IP-SAN、NAS等，技術(shù)較為成熟，但部署成本較高，擴容不靈活，應(yīng)盡量選擇1～2 種技術(shù)方案，以便于存儲資源共享。

分布式存儲是基于x86服務(wù)器的新興存儲技術(shù)，主要通過軟件保障性能和可靠性，主流技術(shù)包括分布式對象存儲、分布式塊存儲、分布式文件存儲等，具備低成本、靈活擴容、高并發(fā)訪問等優(yōu)勢。其中對象存儲可用性高、適應(yīng)度好（可存儲各種大小數(shù)據(jù)）、存儲數(shù)量大；分布式塊存儲可滿足塊存儲和卷管理需求；分布式共享文件存儲滿足大容量文件共享存儲訪問需求；大數(shù)據(jù)文件系統(tǒng)主要存儲大數(shù)據(jù)文件。隨著大數(shù)據(jù)等應(yīng)用的不斷發(fā)展，分布式存儲需求正在不斷增加，應(yīng)統(tǒng)籌根據(jù)不同存儲需求提供分級存儲手段，降低存儲資源部署成本。

2.3 運營商IT支撐系統(tǒng)去IOE解決方案

綜合考慮客戶感知、成本、實施能力、后續(xù)運維等因素，選擇合適的場景、成熟的方案解決面臨的迫切問題，重點選擇海量數(shù)據(jù)查詢與處理、接入型、大并發(fā)、大數(shù)據(jù)分析等場景，按照 “互聯(lián)網(wǎng)化”的指導(dǎo)思想，全面借鑒、吸收互聯(lián)網(wǎng)企業(yè)先進(jìn)的技術(shù)架構(gòu)，硬件上采用x86平臺和本地盤，軟件上全面采用以LAMP（Linux+Apache+MySQL+ PHP）為代表的開源軟件嘗試“去IOE”。

本文2.1部分所提到的第（1）、（2）類系統(tǒng)由小型機向PC服務(wù)器遷移技術(shù)成熟，應(yīng)用改造量小，適合x86云化資源池部署，結(jié)合搭建大數(shù)據(jù)平臺部署數(shù)據(jù)挖掘等海量計算應(yīng)用。第（3）類數(shù)據(jù)庫及計費核心應(yīng)用涉及業(yè)務(wù)維度多、關(guān)聯(lián)關(guān)系及規(guī)則復(fù)雜，而且數(shù)據(jù)庫及計費應(yīng)用受當(dāng)前技術(shù)限制，仍需部署在小型機上，暫不適合遷移至云平臺。

2.3.1 核心系統(tǒng)輕量化與分布式重構(gòu)

借鑒互聯(lián)網(wǎng)IT的“拆分”、讀寫分離思路，混合架構(gòu)實現(xiàn)核心系統(tǒng)“部分去IOE”。

CRM域的查詢功能、計費域所有的采集預(yù)處理功能橫向整合到單一系統(tǒng)完成，簡化處理流程，節(jié)省運維人員投入。

（1）CRM核心輕量化：核心在線數(shù)據(jù)（“IOE”架構(gòu)）與歷史存檔數(shù)據(jù)（Hadoop架構(gòu)）分離，核心生產(chǎn)應(yīng)用與存檔歷史應(yīng)用分離。

（2）計費核心輕量化：云平臺分擔(dān)計費系統(tǒng)的歷史資料存儲及查詢。賬單、積分等數(shù)據(jù)剝離到云平臺。

（3）CRM電子單據(jù)、實名制證件影像、報賬電子單據(jù)、應(yīng)用日志等大數(shù)據(jù)存儲。

2.3.2 部分非核心應(yīng)用遷移至云平臺

承載實時及離線批量處理業(yè)務(wù)，包括清單處理、離線數(shù)據(jù)云存儲、電子化單據(jù)、賬單等。平臺資源自助申請、統(tǒng)一分配、統(tǒng)一監(jiān)控（如圖1所示）。

通過建立統(tǒng)一的、集中化的業(yè)務(wù)承載平臺，集中的為客戶和內(nèi)部生產(chǎn)提供詳單、賬單、訂單、用戶回執(zhí)、系統(tǒng)日志等歷史數(shù)據(jù)的查詢服務(wù)，滿足現(xiàn)有CRM、網(wǎng)廳、掌廳、客服、自助服務(wù)系統(tǒng)、營銷分析等系統(tǒng)對歷史數(shù)據(jù)的壓縮存儲、查詢性能以及節(jié)省資源等方面的要求。

圖1 應(yīng)用云平臺框架（CRM為例）

同時，清單處理量大幅增加、7×24 h不間斷服務(wù)。減輕因日益增長的用戶數(shù)、查詢請求、資源消耗等給生產(chǎn)系統(tǒng)，如計費、CRM等帶來的壓力。以CRM為例：

（1）歷史訂單：歷史訂單數(shù)量較大，保存在關(guān)系型數(shù)據(jù)庫中，對CRM系統(tǒng)的性能影響較大，可遷移到基于Hadoop的云存儲平臺，一方面減輕了CRM數(shù)據(jù)庫的壓力，另一方面提高了歷史訂單查詢體驗的感知。

（2）電子回執(zhí)：電子回執(zhí)數(shù)據(jù)存儲在Apache Hadoop的HDFS分布式文件系統(tǒng)中，提供更高的讀寫性能，節(jié)省RDBMS存儲空間及處理能力。

（3）應(yīng)用日志：對抽取到的應(yīng)用日志數(shù)據(jù)，基于Hadoop的MapReduce對業(yè)務(wù)系統(tǒng)日志進(jìn)行分析，得到業(yè)務(wù)系統(tǒng)的實時運行狀態(tài)數(shù)據(jù)，確保業(yè)務(wù)系統(tǒng)的穩(wěn)定運行。

2.3.3 建立混搭型大數(shù)據(jù)平臺

選取基礎(chǔ)數(shù)據(jù)量較大，關(guān)聯(lián)、聚合計算量較大的專題，此類數(shù)據(jù)轉(zhuǎn)移到Hadoop大數(shù)據(jù)平臺中。如基于清單級的計算分析。

Hadoop平臺與傳統(tǒng)數(shù)據(jù)庫能力互補，Hadoop在海量、非結(jié)構(gòu)化數(shù)據(jù)運算場景上具有優(yōu)勢（如表2所示），因此為了應(yīng)對越來越大的數(shù)據(jù)量，越來越豐富的數(shù)據(jù)類型，可逐步引進(jìn)Hadoop平臺，分擔(dān)傳統(tǒng)數(shù)據(jù)倉庫的壓力（如圖2所示）。

圖2 Hadoop與傳統(tǒng)數(shù)據(jù)庫混合平臺

但是目前基于Hadoop的數(shù)據(jù)挖掘工具和報表工具還比較少，所以建議將計算結(jié)果還是存放在傳統(tǒng)DB或者M(jìn)PP數(shù)據(jù)倉庫里，方便客戶端應(yīng)用訪問。

表2 主要數(shù)據(jù)庫軟件對比

2.3.4 選用成熟開源免費軟件

推進(jìn)成熟開源免費軟件替代部分商業(yè)軟件進(jìn)程（“去O”）。統(tǒng)一規(guī)劃、驗證開源免費軟件，包括CentOS、Hadoop、MySQL、Kettle、Ganglia、Xen、Luence。

PC集群+開源軟件+自主研發(fā)，顯著降低IOE軟硬件成本投入。

2.3.5 建立配套運維機制

統(tǒng)一規(guī)劃硬件配置，通過IT服務(wù)管理實現(xiàn)池化管理。同時培養(yǎng)自有技術(shù)力量，進(jìn)行運營式開發(fā)與集成。

3 運營商“去IOE”成效

初期在投入同比基本持平（成本結(jié)構(gòu)發(fā)生變化）的情況下，能夠從容應(yīng)對數(shù)據(jù)及服務(wù)量高速增長的考驗，響應(yīng)效率逐步提高。預(yù)計在技術(shù)、團(tuán)隊、應(yīng)用改造取得大規(guī)模進(jìn)展的情況下，IT系統(tǒng)建設(shè)成本會有明顯下降。

3.1 成本基本持平

某運營商應(yīng)用實踐表明，以擁有60臺左右PC服務(wù)器的云計算資源池為例，可以部署950～1 250個虛擬機，CPU利用率由傳統(tǒng)架構(gòu)的小于10%上升到大于40%，網(wǎng)絡(luò)利用率由傳統(tǒng)架構(gòu)的小于1%上升到大于10%。

操作系統(tǒng)功耗由傳統(tǒng)架構(gòu)的大于350 W下降到小于100W。以上述資源池為例，服務(wù)器滿負(fù)荷運行后，一年可節(jié)省電力約27×105～36×105kWh。

基礎(chǔ)設(shè)施投入顯著下降；云化釋放高端硬件；應(yīng)用改造大量投入。

3.2 感知顯著上升

以某運營商清單系統(tǒng)性能對比為例，如表3所示。

表3 Hadoop與MPP架構(gòu)對比

主要性能指標(biāo)有一個數(shù)量級的提升，數(shù)據(jù)永久在線，無單點故障，線性橫向擴展。清單云效果超越預(yù)期，系統(tǒng)平穩(wěn)運行。

關(guān)鍵服務(wù)能力提升。數(shù)據(jù)永久在線。

3.3 效率持續(xù)提升

提升業(yè)務(wù)系統(tǒng)部署效率，可做到即需即用。系統(tǒng)平均部署時間由180天下降到5天；提高業(yè)務(wù)系統(tǒng)的靈活度。

通過平臺化機制來統(tǒng)一解決IT的安全保障問題，設(shè)備發(fā)生故障后，可以快速恢復(fù)；設(shè)備負(fù)載過重時，可以分擔(dān)負(fù)載，大大提高業(yè)務(wù)系統(tǒng)的可用性和可靠性。

“加PC就能”的線性擴展架構(gòu)，預(yù)留充分?jǐn)U展能力。

運營式集成快速交付。

4 運營商“去IOE”風(fēng)險分析

基于“去IOE”模式的IT系統(tǒng)設(shè)計、運行維護(hù)、故障定位及處理和傳統(tǒng)模式有很大區(qū)別，同時應(yīng)用系統(tǒng)也要做大量改造，需要綜合考慮這些問題如何解決。

（1）人才技術(shù)稀缺。Oracle團(tuán)隊的經(jīng)驗和技術(shù)積累將大量丟棄；開源數(shù)據(jù)庫經(jīng)驗、技術(shù)和能力需要快速提高；開源業(yè)務(wù)中間如JBOSS的能力儲備。

（2）大量應(yīng)用改造?！叭OE”必然造成我們對同類產(chǎn)品的二次研發(fā)投入。在需要維持現(xiàn)有平臺對運營商日常需求的正常承接的背景下，“去IOE”的研發(fā)人員如何保障。

（3）架構(gòu)設(shè)計更綜合。小型機存儲的高冗余機制在PC和MySQL的組合中如何實現(xiàn)。Oracle物理級別一致性在MySQL語句模式中是否有問題。高端存儲的IO能力很強，PC能否替代。MySQL和Oracle對SQL的處理性能是否相同。分庫與分表按照什么維度分，需要去考慮后期二次拆分怎樣才方便。如何屏蔽分表給應(yīng)用帶來的復(fù)雜性，維度查詢問題，跨分表查詢問題這些需要提前考慮到。

（4）運維模式差異大。傳統(tǒng)的分工界面、工作流程、應(yīng)急預(yù)案等，都會隨著系統(tǒng)云化程度的加強而逐步變化，尤其是對于軟件的維護(hù)，將面臨巨大的，甚至是顛覆性的考驗。

（5）核心系統(tǒng)全面“去IOE”復(fù)雜度高：業(yè)務(wù)復(fù)雜、高度關(guān)聯(lián)；異常處理、數(shù)據(jù)一致性要求高。

（6）考核標(biāo)準(zhǔn)需要確立：故障責(zé)任如何劃分，源的運營責(zé)任如何確定。

5 結(jié)論

“去IOE”關(guān)系到技術(shù)架構(gòu)、管控體系、思維模式甚至企業(yè)激勵機制等方方面面，實際上是在運營商IT支撐體系中植入互聯(lián)網(wǎng)基因，推動企業(yè)的互聯(lián)網(wǎng)化，是一個全新的、十分復(fù)雜的課題。

（1）業(yè)務(wù)驅(qū)動的“去IOE”容易成功。以客戶感知、擴展能力、成本等因素驅(qū)動為主。穩(wěn)定運行、無擴容壓力的應(yīng)用不適合“去IOE”。

（2）互聯(lián)網(wǎng)思維是關(guān)鍵。混合架構(gòu)可快速見效，是近期解決業(yè)務(wù)問題的有效、可靠途徑。微創(chuàng)新帶來大收益，在投入同比基本持平的情況下，能夠從容應(yīng)對數(shù)據(jù)及服務(wù)量高速增長的考驗。

（3）“去IOE”適宜統(tǒng)一規(guī)劃與管控。技術(shù)資源稀缺。云規(guī)模效應(yīng)與大數(shù)據(jù)充分共享。

[1]SanjayGhemawat, HowardGobioff, andShun-TakLeung, Google, The Google File System.

[2]Borthakur D.Hadoop distributed file system.http://hadoop.apache.org/，2007.

[3]吳朱華.云計算核心技術(shù)剖析[M].北京：人民郵電出版社，2011.

[4]陳強.“去IOE化”與“一去兩化”[N].江蘇郵電報，2013.

[5]淘寶分布式服務(wù)框架[EB/OL].[2014-3-11].http://alibaba.github.io/dubbo-doc-static/Home-zh.htm

[7]Eric Brewer.Towards Robust Distributed Systems[R].Keynote at the ACM Symposium on Principles of Distributed Computing （PODC), 2000.

[8]Leslie Lamport: Paxos Made Simple, Fast, and Byzantine[C].OPODIS 2002:7-9.

[9]Leslie Lamport: The Part-Time Parliament [J].ACM Trans.Comput.Syst.（TOCS) , 1998, 16（2):133-169.

[10]Todd Lipcon.Design Patterns for Distributed Non-relational Databases [R].2009.

[11]王珊，薩師煊.數(shù)據(jù)庫系統(tǒng)概論[M].北京: 高等教育出版社, 2007.

[12]Julian Browne.Brewer`s CAP Theorem [EB/OL].（2009-01-11)[2012-06-20].http://www.julianbrowne.com/article/viewer/brewers-cap-theorem.

[13]Guy Pardon.A CAP Solution （Proving Brewer Wrong) [EB/OL].（2008-09-07)[2012-06-20].http://guysblogspot.blogspot.com/2008/09/cap-solution-proving-brewer-wrong.html.

[14]Basho.Why Vector Clock are Easy [EB/OL].（2010-01-29)[2012-06-20].http://basho.com/blog/technical/2010/01/29/why-vector-clocks-are-easy/.