電信企業IT互聯網化目標架構及演進策略研究

李 嫚，喬宏明，姚文勝

（中國電信股份有限公司廣東研究院 廣州510630）

1 引言

互聯網改變了游戲規則，終端的日益強大改變了用戶行為，運營商在價值鏈中逐漸被管道化，在應用領域趨于邊緣化。運營商之間的競爭已從網絡規模、業務種類的競爭，延伸至服務能力、品牌的競爭，運營商是否能有效地提升服務水平、運營效率和管理能力，已成為競爭的關鍵。

運營商為了突破困境，適時提出了“去電信化”的發展思路，實現業務模式從傳統的語音經營轉向流量經營，實現從單業務到全業務、從自營到批發和代理、從單邊商業模式到多邊商業模式的轉型。

然而傳統IT運營模式已難以應對“去電信化”、“流量經營”等新要求的挑戰，為支撐傳統業務模式而建設的IT支撐系統以及IT運營體系勢必要做出改變。另一方面，隨著互聯網行業的爆炸式發展，傳統IT架構存在的對大型IT廠商技術依賴過多和成本過高等問題越來越突出，同時大型企業自身技術逐漸成熟，尤其是技術團隊自主研發能力不斷增強，因此產生了如何在未來新系統中實現技術可控與成本可控的“去IOE”思想。

騰訊、淘寶等企業憑借優秀的互聯網基因能很好地應對類似挑戰，取得良好業績。電信企業應思考“去電信化”趨勢，認真向優秀互聯網企業學習，適時推進IT體系的互聯網化，建立互聯網運營模式。通過建立以客戶為導向、隨需應變、開放、交互、智能的統一IT架構，采用小、快、靈的運營式開發模式，構建現代化的、適應互聯網時代發展模式的新型企業IT系統。

2 互聯網企業IT發展歷程

同許多傳統企業一樣，互聯網企業IT也面臨著巨大的挑戰。伴隨著互聯網技術和業務的發展，互聯網企業的競爭日益加劇，大量新的互聯網企業進入新興的互聯網領域，用戶量的增長對互聯網IT的沖擊不斷增強。為了提供更好的用戶體驗，互聯網企業的技術架構經歷了不斷變革的過程，逐步實現極致體驗的IT系統。互聯網公司的IT架構，特別是大型互聯網公司的技術架構，值得傳統電信企業學習和借鑒。通過研究淘寶、騰訊等公司的技術架構變革歷程，可以為電信IT技術架構互聯網化提供重要參考和依據。

為應對不同時期業務發展和企業戰略的要求，在過去10年中，淘寶對系統架構進行了3次大的調整和演變：2003年，整 個 網站采用LAMP（Linux+Apahce+MySQL+PHP）架構，應用系統分為前臺、后臺兩大部分，部署在PC服務器上。數據庫使用MySQL，采用讀寫分離的方式。但由于當時MySQL版本讀操作會鎖表，主從復制時會對主數據庫產生大量讀操作，使得主庫性能急劇下降，不能適應業務量增長的需要。2004-2008年，采用IOE架構，把MySQL遷移到Oracle，PC服務器升級到IBM小型機，低端存儲升級到高端存儲，在此期間，對數據庫進行分庫分表，冷熱分離，在應用程序和數據庫之間通過增加緩存層、CDN等措施來提高數據庫讀寫性能，但隨著業務的急速發展，系統只能進行垂直向上擴展（scale-up），存儲和性能仍然出現瓶頸。2009年后，嘗試采用“去IOE”架構，核心業務從Oracle逐步遷移到分布式MySQL集群，大量采用PC服務器和本地硬盤存儲并通過自主研發分布式服務層和中間件，搭建分布式技術架構，并成功應對了2012年和2013年的“雙十一”促銷。

騰訊公司的TBOSS相當于運營商的MBOSS，經歷了10年的發展，從“煙囪型”架構逐步進化為面向服務的架構（SOA）。出于成本控制的考慮，TBOSS從起步開始就摒棄了IOE架構，堅持以PC集群承載其核心業務，約1 200個節點的PC集群支撐百億級賬戶、10億級日交易、毫秒級響應、一分不差準銀行級賬務。TBOSS同樣經歷了3個階段的演變：2000-2007年，支撐中國移動及中國電信增值業務，采用關系型數據庫，各個系統以“煙囪式”構建，技術上以C++、Net、Spring等為基礎；2008-2010年，面對全互聯網產品的支撐，改成了面向服務的系統架構，采用的技術基礎是分布式緩存、消息隊列、數據拆分、NoSQL數據庫、Hadoop等；2011年至今，面向海外及全互聯網產品的支撐，采用了云化架構，通過SOA向外提供服務，使系統更加具有柔性。

通過淘寶和騰訊的案例不難看出：是業務的發展推動了技術架構的不斷變革，架構設計原則需根據業務而調整，“去IOE”是架構調整過程的副產品。淘寶在保有IOE架構情況下，為解決業務問題，先縱向拆分、后讀寫分離，最后才實現橫向拆分擴展。為保證擴展能力，將數據一致性從高一致性弱化為最終數據一致性原則。這些都是業務和IT雙向驅動的結果。

同時，體系架構的變革需要強大的技術儲備，采用開源需重新面對很多商業技術已解決的難題。體系架構的變革對開發和運維方面都將帶入更多的全局復雜性，例如資源管理、作業分割調度、數據分配、消息機制、一致性保障、異常處理等，在操作系統層、數據庫產品層已經由商用技術解決的問題，會由應用開發者重新面對。這些都是阿里集團不得不打造規模龐大的基礎核心技術研發和應用開發團隊的根本原因。

3 電信企業與互聯網企業IT差異

傳統企業可以借鑒互聯網技術成果，卻不一定能完全效法其架構模式和發展路線。本文從用戶發展規模、業務特征、IT特征等多個維度對電信企業和互聯網企業進行全方位對比，從而探索與電信企業特征相適配的IT架構。

從用戶及業務量發展趨勢來看，通常互聯網企業用戶和交易量會急速增加，對IT的主要挑戰是提供最佳產品體驗并扛住高增長帶來的海量用戶、海量訪問、海量數據的壓力。以淘寶為例，每天有7億次的頁面訪問、40億次的用戶訪問、400萬筆有效交易，為了應對海量和高速增長的壓力，淘寶網必須不惜一切代價拆分系統，以其可承受成本實現高速業務規模增長。而電信企業和淘寶網的發展階段缺少可比性，電信行業基本飽和，用戶和收入規模穩步增長，總用戶量雖已超過4億戶，但分省部署架構下，大省用戶規模也在3 000萬～5 000萬戶，短時間內不可能有飛躍性突破，性能壓力相對不大；同時，為提供“電信級”服務，企業對IT的主要要求是保持穩定運營，同時快速支撐復雜多變的業務需求。這種復雜性包括套餐的復雜性、產品使用過程的復雜性等，這些是互聯網IT當前無需面對的。

從商業模式和業務特征來看，互聯網企業多數采用以“免費服務+廣告”為基礎的后向收費模式，對前向客戶只需提供“盡量好”的服務承諾，企業對數據丟失、服務中斷風險敏感度低。而電信行業為國家指定基本通信服務提供者，通常為前向收費模式，需要提供“必須好”的服務承諾，企業對數據丟失、服務中斷等風險敏感度高。互聯網企業的業務特點相對簡單、自助化程度高，基于幾個關鍵環節的極度簡化謀求與傳統行業的差異化，業務間關聯關系少，業務間沒有復雜的捆綁。例如淘寶不同店鋪、商品、用戶、交易、支付間沒有復雜關聯。而電信需要提供全面化、多樣化、高覆蓋的電信服務，業務關聯關系復雜且多變：跨本地網、跨業務、不同客戶之間存在捆綁、交叉優惠。

從IT定位和特征來看，互聯網企業IT系統就是業務，基于IT關鍵技術能力打造差異化核心競爭力，并且一般為技術主導型企業，技術組織自我掌控能力較強，自主開發應用甚至核心基礎技術，并承擔技術風險。而電信企業靠核心網、業務網的技術領先、規模和質量構成差異化核心競爭力，IT部門通常為技術應用者，一般依賴供應商提供成熟的商用技術產品或技術開發服務。從系統劃分來看，互聯網企業系統劃分較細，因為業務被極度細分、簡化，作為一個個產品由獨立應用系統支撐，甚至一個功能就作為一個產品獨立支撐（例如購物車、收藏夾、搜索、推薦、支付）。而電信企業業務復雜且強調融合支撐，用較少的復雜大系統支持多種業務、多種功能、多個業務流程，導致關鍵業務系統的業務模塊間關聯性強，體現在數據庫表多、表間關系復雜。從系統的架構模式來看，互聯網企業通常采用“業務特點→技術特點→技術架構”的自頂向下的架構設計模式，以體現差異化、精細化。而電信企業通常采用低風險的以“通用架構+標準化產品”為基礎的適應“差異化業務需求”的架構模式。從系統的擴展能力要求來看，互聯網企業要求大容量的橫向擴展能力，兼顧高可用性，以特殊措施減少或補償數據不一致性問題。而電信企業通常以高數據一致性為前提，兼顧系統高可用性，當前分省模式下業務量沒有互聯網行業大，高性能集群方案基本可以滿足。

4 中國電信IT互聯網化目標架構及演進策略

基于電信企業和互聯網企業的業務及IT特征的分析，充分借鑒互聯網IT的演進變革經驗，本文研究提出適合電信企業自身發展特點的IT目標：以支撐集約運營和IT能力互聯網化為核心構建全網統一能力，建立與企業集約運營相適應的集團級IT系統和集團IT能力開放平臺，實現全網IT能力以“互聯網方式”對外開放，實現“設備層云化部署、數據層編碼統一、接口層標準統一”，實現全網數據高效共享。

IT技術架構目標從邏輯上包括門戶層、應用層、服務層、數據層、基礎設施層五大部分，如圖1所示。

門戶層：實現客戶接觸互聯網化。門戶層應充分借鑒互聯網/移動互聯網門戶網站用戶界面設計理念和技術，為客戶、員工和合作伙伴提供友好、簡便、客戶感知一致的界面，并為第三方合作者提供IT內部能力訪問接口。

應用層：實現應用軟件服務化。應用層由管理支撐系統（management support system，MSS）域、業務支撐系統（business support system，BSS）域、運營支撐系統（operation support system，OSS）域、企 業 數 據 應 用 （enterprise data application，EDA）域、專業公司IT體系等幾部分組成。應用層繼續按照“模塊化、松耦合、可配置”的技術思路，采用面向服務的體系架構（SOA），實現各應用程序的不同功能單元通過定義良好的接口和契約提供服務并相互協作，通過服務的重用和組合，快速支撐新業務和新流程。

服務層：實現IT能力互聯網化。服務層包括企業服務總線、服務目錄和能力開放平臺。企業服務總線實現系統間（特別是跨域系統和分級部署系統間）服務調用和數據傳輸。在應用系統服務能力封裝的基礎上，通過企業服務總線和統一服務目錄，實現相關服務能力跨系統共享，并以可管可控的標準服務的形式向外部第三方（如供應商和合作伙伴）系統開放，形成企業級的IT能力開放平臺。

數據層：實現數據模型和編碼統一化。數據層重點關注企業數據模型、主數據管理等跨應用域的數據架構相關內容。在規劃期內，需統一全網客戶、產品、渠道、賬戶、資源數據模型和主數據編碼，實現信息和數據在企業范圍內的準確、一致和共享。

基礎設施層：實現基礎設施云化。基礎設施層主要包括主機、服務器、存儲等硬件設備、IT專網(DCN)、IT容災、IT安全、IT服務管理平臺、移動應用管理平臺等。在規劃期內，需通過對計算、存儲和網絡等資源的虛擬化、標準化和自動化，促進資源共享，提高資源利用率。

借鑒互聯網公司的成功經驗，技術體系中逐步探索LAMP解決方案在特定業務場景的應用。在綜合考慮投資保護、技術成熟度、人員培養、整體成本等因素的前提下，針對邏輯簡單、重復處理的查詢型業務處理系統，可以逐步從傳統架構剝離出來，移植到LAMP架構進行分布式處理。近中期宜采用LAMP和IOE架構相結合的方式，組合出“復雜業務支撐穩定”、“簡單業務快速響應、低成本擴展”的架構模式，更適合中國電信的實際需求。中遠期在基礎條件具備的情況下，可考慮完全“去IOE”模式的探索。具體演進如圖2所示。

實施策略上，門戶層大力推進客戶端的Web化，增加移動客戶端的接入；應用層以開源中間件替代商業中間件；服務層逐步形成自主研發分布式服務框架、分布式數據層等分布式系統核心的組件；數據層逐步由MySQL/MariaDB集群、NoSQL和分布式文件系統替代集中式的Oracle RAC；基礎設施逐步以PC服務器替代小型機，以開源OS替代商業OS。

5 中國電信IT互聯網化配套舉措

為推動中國電信IT互聯網化工作，保障新架構體系的正常運轉，需要進一步落實業務、管理、隊伍建設等相關配套措施，具體包括以下4個方面。

·落實運營式開發成本費用，有針對性地增加成本性支出。將IT運營服務性支出納入日常成本費用，以加快運營性IT開發的審批，快速響應業務需求。同時要建立適合運營迭代式開發的工程建設流程和制度，在現有面向業務需求的年度工程項目管理之外，設立面向基礎技術跟進和研發的常態化機制和經費，推動技術能力持續轉型。另一方面，逐步降低設備的采購投入，減少小型機采購，提高資源利用效率，并將硬件投資轉化為對IT人員、軟件等的投入。

·儲備自主研發能力，打造核心開發運營團隊。整合企業內部IT相關部門、供應商、分公司力量，通過自有人員+外包人員混合的模式，探索市場化的機制建立新興業務領域的IT團隊，逐步實現對一線的快速響應和對數據、服務、架構的有效管控，實現主動適應互聯網的運營開發。打造敏捷運營的團隊，建立具有互聯網開發經驗的集團級開發、運營團隊，實現日常運營需求的快速、迭代開發。

·簡化產品套餐，梳理規則流程，降低業務復雜度。一方面可減少復雜業務捆綁和交叉優惠、繳費支付關系，實現以簡單折扣為主的營銷策略，降低業務復雜度。另一方面，應清理極少用戶套餐、無效套餐，減少業務規則，降低計算量。

·探索IT人員激勵方式的轉變，推進IT體制機制的變革。首先引入市場化機制解放隊伍活力與激情，加速培養自有互聯網化IT專才。采取專題競標等市場化手段，以數據和移動應用為切入點，依托能力開放平臺和大數據平臺支持內部開發能力提升，激活IT隊伍內部潛力。其次，以投入驅動供應商轉向開源開放技術路線，增強“去IOE”能力，引導其產品“去IOE”，以逐步壯大LAMP技術團隊。

6 結束語

卓越的IT架構一定是適應企業業務發展需要的IT架構。傳統電信企業可以借鑒優秀互聯網公司的IT建設經驗，但一定要結合自身業務發展規律和企業戰略部署要求。本文研究提出的混搭架構模式，更適合中國電信目前的實際需求，中遠期在基礎條件具備的情況下，可考慮完全“去IOE”模式的探索。

1 張勤.開源IT系統及應用架構寶典.北京：人民郵電出版社,2010

2 Rajaraman A，Ullman D J.大數據：互聯網大規模數據挖掘與分布式處理.王斌譯.北京：人民郵電出版社，2012

3 付強.基于SOA企業IT架構重組解決方案的對比研究.科技信息,2013（8）

4 王德才.開源軟件和虛擬化技術在數據中心IT架構中的應用.中國科技信息,2008（11）

5 陶然，陽建州，宋漢征.Apache VCL和VMware vCloud Director在線資源申請云平臺的比較.計算機與現代化,2013（12）

6 劉偉.對分布式計算、網格運算和云計算分析.科技信息,2013（9）