運營商IT支撐系統“去IOE”思路探討

周龍，陳喜珠，彭江強

（湖南省郵電規劃設計院有限公司，長沙 410001）

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

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

（1）集中式強大單點遠遠不能滿足爆炸式業務增長應用模式的出現，導致系統不能滿足業務需求。

（2）“IOE”的技術限制了其它技術潛力的發揮。有很多底層細節企業根本無法掌控。

（3）“IOE”設備對機架、電力、網絡有特殊要求，要單獨為它設計，成本偏高。

（4）數據庫安全問題。包括數據的路由、數據安全、規?；\維、異步數據同構等問題。

“IOE”所代表的IT架構一方面約束了互聯網巨頭在業務靈活配置等方面的企業長遠發展，另一方面也帶來極高的擴展壓力以及天價的包括部署、維護在內的總成本，所以需要采用新的互聯網技術和架構取代傳統“IOE”架構。

1 運營商“去IOE”驅動力

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

近年來，移動互聯網環境同樣給運營商支撐系統帶來了數據量爆發性增長。海量數據與高并發對運營商現有支撐系統架構已經形成沖擊。客戶感知、成本投入、運營效率成為運營商支撐系統建設需要考慮的突出問題。

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

體現在日常運營中的困難具體表現如下。

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

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

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

表1 某省級電信運營商2013年業務增長數據指標表

2 運營商IT支撐系統“去IOE”思路

2.1 運營商主要IT系統分類

運營商內部IT系統根據主要計算特點可分為3類。

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

（2)面向網絡的重復性任務處理部分：如話單采集、數據抽取及格式轉換等。

（3)核心是復雜關系型計算部分：如計費應用、各系統數據庫等。

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

2.2.1 基于x86架構的云資源池替代小型機

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

通過服務器虛擬化方式實現多應用共享部署；通過資源池管理及云管理平臺的自動化調度（應用啟停、伸縮、遷移等），實現更加靈活的多應用共享部署，提高基礎設施利用效率及系統可靠性。系統部署架構進一步集中，發揮云計算規模優勢，提升IT集約化運營水平：進一步提高系統部署物理集中度，發揮云計算的規模優勢，提高基礎設施利用效率。

存在問題如下。

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

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

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

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

2.2.2 開源數據庫軟件替代Oracle

通過部分場景替換Oracle方式進行拆分實現。

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

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

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

2.3 運營商IT支撐系統去IOE解決方案

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

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

2.3.1 核心系統輕量化與分布式重構

借鑒互聯網IT的“拆分”、讀寫分離思路，混合架構實現核心系統“部分去IOE”。

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

（1）CRM核心輕量化：核心在線數據（“IOE”架構）與歷史存檔數據（Hadoop架構）分離，核心生產應用與存檔歷史應用分離。

（2）計費核心輕量化：云平臺分擔計費系統的歷史資料存儲及查詢。賬單、積分等數據剝離到云平臺。

（3）CRM電子單據、實名制證件影像、報賬電子單據、應用日志等大數據存儲。

2.3.2 部分非核心應用遷移至云平臺

承載實時及離線批量處理業務，包括清單處理、離線數據云存儲、電子化單據、賬單等。平臺資源自助申請、統一分配、統一監控（如圖1所示）。

通過建立統一的、集中化的業務承載平臺，集中的為客戶和內部生產提供詳單、賬單、訂單、用戶回執、系統日志等歷史數據的查詢服務，滿足現有CRM、網廳、掌廳、客服、自助服務系統、營銷分析等系統對歷史數據的壓縮存儲、查詢性能以及節省資源等方面的要求。

圖1 應用云平臺框架（CRM為例）

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

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

（2）電子回執：電子回執數據存儲在Apache Hadoop的HDFS分布式文件系統中，提供更高的讀寫性能，節省RDBMS存儲空間及處理能力。

（3）應用日志：對抽取到的應用日志數據，基于Hadoop的MapReduce對業務系統日志進行分析，得到業務系統的實時運行狀態數據，確保業務系統的穩定運行。

2.3.3 建立混搭型大數據平臺

選取基礎數據量較大，關聯、聚合計算量較大的專題，此類數據轉移到Hadoop大數據平臺中。如基于清單級的計算分析。

Hadoop平臺與傳統數據庫能力互補，Hadoop在海量、非結構化數據運算場景上具有優勢（如表2所示），因此為了應對越來越大的數據量，越來越豐富的數據類型，可逐步引進Hadoop平臺，分擔傳統數據倉庫的壓力（如圖2所示）。

圖2 Hadoop與傳統數據庫混合平臺

但是目前基于Hadoop的數據挖掘工具和報表工具還比較少，所以建議將計算結果還是存放在傳統DB或者MPP數據倉庫里，方便客戶端應用訪問。

表2 主要數據庫軟件對比

2.3.4 選用成熟開源免費軟件

推進成熟開源免費軟件替代部分商業軟件進程（“去O”）。統一規劃、驗證開源免費軟件，包括CentOS、Hadoop、MySQL、Kettle、Ganglia、Xen、Luence。

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

2.3.5 建立配套運維機制

統一規劃硬件配置，通過IT服務管理實現池化管理。同時培養自有技術力量，進行運營式開發與集成。

3 運營商“去IOE”成效

初期在投入同比基本持平（成本結構發生變化）的情況下，能夠從容應對數據及服務量高速增長的考驗，響應效率逐步提高。預計在技術、團隊、應用改造取得大規模進展的情況下，IT系統建設成本會有明顯下降。

3.1 成本基本持平

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

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

基礎設施投入顯著下降；云化釋放高端硬件；應用改造大量投入。

3.2 感知顯著上升

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

表3 Hadoop與MPP架構對比

主要性能指標有一個數量級的提升，數據永久在線，無單點故障，線性橫向擴展。清單云效果超越預期，系統平穩運行。

關鍵服務能力提升。數據永久在線。

3.3 效率持續提升

提升業務系統部署效率，可做到即需即用。系統平均部署時間由180天下降到5天；提高業務系統的靈活度。

通過平臺化機制來統一解決IT的安全保障問題，設備發生故障后，可以快速恢復；設備負載過重時，可以分擔負載，大大提高業務系統的可用性和可靠性。

“加PC就能”的線性擴展架構，預留充分擴展能力。

運營式集成快速交付。

4 運營商“去IOE”風險分析

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

（1）人才技術稀缺。Oracle團隊的經驗和技術積累將大量丟棄；開源數據庫經驗、技術和能力需要快速提高；開源業務中間如JBOSS的能力儲備。

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

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

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

（5）核心系統全面“去IOE”復雜度高：業務復雜、高度關聯；異常處理、數據一致性要求高。

（6）考核標準需要確立：故障責任如何劃分，源的運營責任如何確定。

5 結論

“去IOE”關系到技術架構、管控體系、思維模式甚至企業激勵機制等方方面面，實際上是在運營商IT支撐體系中植入互聯網基因，推動企業的互聯網化，是一個全新的、十分復雜的課題。

（1）業務驅動的“去IOE”容易成功。以客戶感知、擴展能力、成本等因素驅動為主。穩定運行、無擴容壓力的應用不適合“去IOE”。

（2）互聯網思維是關鍵?；旌霞軜嬁煽焖僖娦?，是近期解決業務問題的有效、可靠途徑。微創新帶來大收益，在投入同比基本持平的情況下，能夠從容應對數據及服務量高速增長的考驗。

（3）“去IOE”適宜統一規劃與管控。技術資源稀缺。云規模效應與大數據充分共享。

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

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

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

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

[5]淘寶分布式服務框架[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]王珊，薩師煊.數據庫系統概論[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/.