运营商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）大量应用改造。“去IOE”必然造成我们对同类产品的二次研发投入。在需要维持现有平台对运营商日常需求的正常承接的背景下，“去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/.