浙江移动去IOE思考

中国移动通信集团浙江有限公司 信息技术部技术保障部 郭岳

2014年12月9日

自我介绍

 郭岳 （三少）

 Oracle 10G OCM（2009年）  中国移动通信集团浙江有限公司

信息技术部技术保障部数据平台组  中国移动集团专利评审专家  新浪微博：正牌三少  微信：qq379622  邮箱：guoyue@zj.chinamobile.com

第一部分 第二部分 第三部分 第四部分



去IOE背景及驱动 去I分析 去E分析 去O分析

什么是去IOE？



I指以IBM为代表的高端小型机、O指以Oracle代表的商用数据 库、E指以EMC为代表的高端集中式存储，“IOE”架构是指针 对企业关键应用，基于向上扩展(Scale-up)技术的高端商用产 品而设计的传统集中式系统架构。



购买价格便宜



自主可控



100 80 60 40 20 0



维护费用低



开放性



性能高



可扩展性好



IOE定性分析



应 件用

软



传统小型机



数 据 库

传统数据库（Oracle）



物 理 存 储 磁盘阵列



典型IOE”架构



去I



• 是指去掉以IBM为代表的小型机硬件设备，不再使用集中式技术架构，改为基于开放 式X86硬件平台的分布式技术架构



去O



• 是指以开源数据库以及大数据等方案替代Oracle、IBM等典型代表的商业数据库产品



去E



• 是指不再使用EMC、HP、IBM等公司提供的高端集中式存储设备，改为使用开放通用 的中低端存储或X86服务器本地存储



去IOE的实质是“分布式+开源”架构替代“集中式+封闭”架构，是系统云化的重要组成部分

去IOE驱动力分析



“去IOE”起源于互联网行业，由阿里巴巴公司于2010年最先发起



2010.1 三淘 启动去IOE



2011.7 商品 库完成去OE



2012.12 三淘 完成去IOE



2013.6 阿里 最大的现金流 结算系统去O



2010.7 商品 库完成去I



2011.9 交易 库完成去IOE



2013.5 支付 宝完成去IE



阿里“去IOE”有其自身内在驱动



容量驱动



• 通过去IOE，建立分布式的开放架构，实现系统能力线性扩展，有效支撑未来业务发 展，确保系统架构的先进性和能力领先



管理驱动



• 通过去IOE，减少在软硬件维保、技术支持、以及开发方面对供应商的依赖度，技术内 化，加强对核心能力的掌控



成本驱动 • 通过去IOE，引入标准化通用设备和开源数据库，大幅节省投资和运维成本，提升效益



业务驱动



• 阿里需要发展阿里云等业务，对外提供公有云服务，公有云的基础，需要低成本基础软 硬件平台的支撑



在去IOE中，去I和去E相对简单，能大幅节省成本，而去O较为复杂，不一定能节省成本。5

第一部分 第二部分 第三部分 第四部分



去IOE背景及驱动 去I分析 去E分析 去O分析

去I－驱动力分析

“去I”是指去掉以IBM为代表的小型机硬件设备，不再使用集中式技术架构，改为开放式X86硬 件平台的分布式技术架构



小型机集中式架构扩展性受限



X86服务器成本低于小型机



• 基于小型机的架构无法提供资源的线性增长， 基于X86服务器的分布式架构为Scale-out模 式，横向扩展能力强，资源增长量不受限制， 且可在不同厂商产品间扩展



• 采购成本：相同处理能力的小型机采购成本是 X86服务器的4-5倍

• 运维成本：单台X86服务器的年运维成本在数千 元左右（不含OS及虚拟化软件运维），而单台小 型机的年运维成本则在5-10万 甚至更高



驱动力分析



• 小型机设备相关技术集中于某 一厂商，，设备扩容或替换受 制于厂商；X86服务器为标准 化设备，设备扩容和替换不受 厂商限制，运营商可掌控力度 相对较大



• 小型机技术封闭且非标准 化，运营商无法掌控信息安 全，可能影响企业、国家利 益，有必要引入国产或定制 产品，增强信息安全管控力 度



加强核心能力管控，减少对供应商的依赖 引入国产或定制产品，保障信息安全

去I－技术难点分析及对策



小型机作为IT系统的主要计算设备承载了大部分的业务，但从扩展性、性价比、核心能力掌控等



角度而言已经不适宜当前发展



难点分析



解决对策



计算性能



• 单台X86服务器性能不足



• X86单个CPU处理能力一直在提升，目前已

达到或超越小型机单CPU处理能力 • 应用采用分布式架构，提升处理能力



可靠性



• X86服务器可靠性一般不超过 99.99%，低于UNIX服务器



• 通过集群技术以及云化技术，确保整体可 靠性



应用迁移



• X86服务器采用linux操作系统，小 型机采用UNIX操作系统，基于C++ 架构的应用移植性较差



• C++架构向Java架构迁移 • 软件模块化，降低耦合度



去I主要难点在于技术架构，应用层会涉及部分代码重构，而数据库层则需通过数据库



云平台等新技术手段实现去I

去I－技术路线

去I技术路线以直接替换为X86服务器为主，部分系统迁移至数据库云平台，OLAP主 要迁移至大数据平台



应用层

64％

数据层

36％



IO性能要求不高

26％

核心OLTP及高 IO性能要求

45％

OLAP

29％



100％ 26％

45％ 10％ 19％



路线1：直接替换 为X86服务器

63％



路线2：数据库云 平台

23％



路线3：大数据平 台



14％

第一部分 第二部分 第三部分 第四部分



去IOE背景及驱动 去I分析 去E分析 去O分析

去E－驱动力分析

“去E”是指不再使用EMC、HP、IBM等公司提供的高档集中式存储设备，改为主要使用开放通 用的X86服务器的本地存储



传统集中式存储设备扩展性受限



X86服务器本地存储成本低于传统盘阵



• 传统集中式存储设备单点扩展存在容量上限和 接口带宽等限制，面对PB级的海量存储需求， 难以通过线性扩展满足需求；基于X86服务器 本地存储的分布式存储能实现容量、处理能力 和I/O带宽的线性扩展



• 采购成本：传统高端盘阵集采价格约为2万元 TB,而采用X86服务器本地存储的成本约为传统 盘阵成本的15％

• 运维成本：X86服务器本地存储年运维成本较 低，传统盘阵年运维成本则会 高出十几倍甚至几十倍



驱动力分析



• 传统存储设备相关技术集中于 某一厂商，运营商无法掌控， 设备扩容或替换受制于厂商；X86服 务器存储为标准化设备，设备扩容和 替换不受厂商限制，运营商可掌控力 度相对较大

•

加强核心能力管控，减少对供应商的依赖



• 传统存储设备技术为封闭式 非标准化，运营商无法掌控 信息安全，影响企业、国家 利益，有必要引入国产或开 源产品，增强信息安全管控 力度

引入国产或定制产品，保障信息安全

去E－技术难点分析及对策



传统高端集中式存储是目前运营商IT系统中数据存储的主要介质，但从扩展性、性价比、核心能



力掌控等角度而言已经不适宜当前发展



存储性能



难点分析

• 单个普通本地存储IOPS达不 到中高档存储设备IOPS能力

• 本地存储整体存储性能不及中 高档存储设备



解决对策

• 采用SSD、Fusion IO等技术提升单个 存储能力，比如引入数据库云平台

• 利用分布式存储技术提升整体存储性能 （SDS－技术尚未成熟，待继续研究）



可靠性



• X86服务器本地硬盘故障率相 对较高，可靠性下降



• 采用分布式文件系统或分布式存储，将 数据分布在多份副本上，提升数据可靠 性



容灾技术



• 传统盘阵下基于底层复制，去 E后需要研究适用X86平台的 容灾备份技术



• 采用基于开源的存储复制技术或数据库 复制技术（如ADG等）



去E主要难点仅限于技术架构，对应用基本无影响，但是进度依赖于技术手段的成熟度

去E－技术路线

数据存储类型主要分为数据库与文件系统两大类，不同的存储类型，不同的的性能和容量要求需要 采用不同的去E技术，任何一种单一技术都难以适应浙江公司全部数据采集、存储、处理的需求，多 种技术并存才是发展趋势



数据库

79%

文件系统

21%



OLTP-低容量 10%

OLTP-中容量 40%

OLAP-中容量 19%

OLAP-高容量 10%

低容量 5%

中容量 11% 5% 高容量



10% 9%



路线1：数据库云 平台

50%

路线2：MPP

9%

路线3:中低端存 储

15%

路线4： 分布式文件系统 (如:HDFS)

26%



注：路线3远期目标为SDS软件定义存储，但考虑该技术目前尚未成熟，将继续跟踪研究

第一部分 第二部分 第三部分 第四部分



去IOE背景及驱动 去I分析 去E分析 去O分析

数据管理软件的发展历程



数据管理软件综合组织数据，供多个用户共享，有较高的数据独立性和安全控制机 制，到现在主要经历了四个阶段，人工管理阶段、文件系统阶段、数据库阶段和大 数据阶段，逐步完善、发展。



20世纪50年 代中期以前



人工管理阶段



数据的管理基本是手工的，分散的，数据不保存在机器 中，计算机还没在数据管理中发挥应有的作用，这种管 理方式严重影响了计算机的使用效率。



20世纪50年 代后期至60 年代中期



文件系统阶段



60年代后期 数据库阶段



2000年以后 大数据阶段



各个文件之间是孤立的，不能体现与现实世界事务之间 的内在联系，各个程序之间不能共享相同的数据，造成 数据冗余较大，并容易产生相同数据的不一致性，数据 的表示和处理能力差，文件的结构和操作比较单一，不 丰富。

提供了完整的数据管理机制，保证了数据和程序的逻辑 独立性，用户共享冗余度小，保证了数据的安全和完整 性。主要经历了网状数据库、层次数据库、关系型数据 库三个阶段。

大数据时代，在大数据4V的冲击下，传统的关系型数 据库已经无法满足实际应用的需求，因此数据管理技术 出现了分化发展，其核心思想是引入了分布式技术。

分布式架构的关键约束——CAP理论



一个分布式系统不可能满足一致性、可用性和分区容忍性这三个需求，最多只 能同时满足两个。

——Eric Brewer



 CAP理论：


 Consistency（一致性）：分布式系统 中，所有节点在同一时刻看到同一个值。


 Availability（可用性）：每个请求都会收 到一个应答，无论该应答是成功还是失 败。


 Partition Tolerance（分区容忍性）：即



A

Availability



CAP理论并不意味 着必须抛弃三个要 素之中的一个。三 者可以在程度上进 行衡量。 如：可用性可以从 0%到100%之间进

行变化。



便在网络中断，消息丢失的情况下，系统



照样能够工作。



C



CAP 理论



P



Consistency



Partition Tolerance

数据管理软件发展趋势

• 大数据时代的到来，海量数据的3V（数量Volume、速度Velocity、多样Variety）挑战着传 统数据库曾经非常成功的“一种架构支持多类应用”模式。在互联网和大数据应用的冲击 下，世界数据库格局正在发生革命性的变化，通用数据库（OldSQL）一统天下变成了 OldSQL、NewSQL、NoSQL共同支撑多类应用的局面。



一种架构支持多类应用

分析



事务



OLDSQL 查询



大数据时代 架构多元化



多种架构支持多类应用



NewSQL C&P

分析+查询



OldSQL C&A 事务



NoSQL A&P

分析+查询



• OLDSQL阵营在逻辑架构不变的情况下引入了分布式技术和虚拟化技术，以提升处理性能（一体机、云平台）； • NEWSQL阵营通过把传统关系型数据库转变为MPP（shared-nothing）架构，在保证了强一致性的前提下，提升

了海量数据处理能力，但是由于分布式事务的问题，导致很难应用在OLTP场景； • NOSQL阵营则通过降低一致性要求，引入多结构化数据处理能力，提高海量数据的离线处理和在线处理能力。

数据管理软件发展趋势



OldSQL



NewSQL



NOSQL



事务处理 计算能力 数据存储



强一致性 结构化



单机结构



SMP架构



强一致性或弱一致性



最终一致性



非结构化



MPP架构



流计算

与传统的先收集后计算不同，在流计算过程中，高级软件的运算法则在 接收流数据时就开始对其进行分析。流计算提供了一组通用原语，可被 用于“流处理”之中，用来处理源源不断的消息，并将处理之后的结果 保存到持久化介质中。或用于“连续计算”，对数据流做连续查询，在 计算时就将结果以流的形式输出给用户。

传统上认为大数据技术= NewSQL+NoSQL（含流计算）。但是这些技术均不 能解决海量数据下OLTP场景的问题（业界一般采用应用分布式改造的方案）

数据管理软件发展趋势



传统关系型数据库



大数据和互联网业务（数据量大、实时性高、多结构化）对传统的关系型数据



库带来的挑战，从Oracle 、DB2包打天下，变成根据不同应用场景发展了不同



的分支技术。



• 应用分布式改造，如使用TDDL



将多个单点的数据库虚拟化成一



联机事务



无法满足高并发事务请求



个（本质上还是降低了一致 性）；



• 硬件架构云化，如PBData（提



升了存储的性能）



即时查询



无法满足海量数据即时查询



• NoSQL：如Hadoop（Hbase） • NewSQL：列存储MPP数据库，

如Gbase（压缩比高）



联机分析



无法满足海量多结构数据 联机分析

无法满足在线数据实时处理



• NewSQL：MPP数据库，如Aster • NoSQL： 如Hadoop（Hive，

Spark）

• NoSQL：流处理软件，如Storm

去O－驱动力分析



O是指以Oracle为代表的国外商用数据库，是目前运营商IT系统中数据处理的主要基础软件。 去O主要是指以开源、国产数据库以及大数据等方案替换国外商用数据库软件



传统商业数据库扩展性受限？

• 传统国外商业数据库的扩展基于节点数的增 加，不仅成本提升，而且节点数的增多也可能 会引发通信同步问题，难以实现线性扩展



传统国外商业数据库采购及服务成本高？

• 传统国外商业数据库采购、服务价格高，而且 历年采购的oracle许可量较大，运维成本较大



• 传统国外商业数据库的核心技 术掌握在国外供应商手中，无 论从安全还是业务发展角度来 看，都将制约运营商对核心能 力的管控



驱动力分析



• 传统数据库技术为封闭式非 标准化，运营商无法掌控信 息安全，影响企业、国家利 益，有必要引入国产或开源 产品，增强信息安全管控力 度



掌控核心能力，减少对供应商的依赖？ 引入国产或开源产品，保障信息安全√

去O－政策驱动



信息安全风险是指在信息化建设中，各类应用系统及其赖以运行的基础网络、处理的 数据和信息，由于其可能存在的软硬件缺陷、系统集成缺陷等，以及信息安全管理中 潜在的薄弱环节，而导致的不同程度的安全风险。




 国家战略

2014年2月27，中央网络安全和 信息化领导小组宣告成立。中共中央 总书记、国家主席、中央军委主席、 中央网络安全和信息化领导小组组长 习近平强调：制定实施国家网络安全 和信息化发展战略、宏观规划和重大 政策，不断增强安全保障能力。




 棱镜门

棱镜计划（PRISM）能够对即时通信和 既存资料进行深度的监听。许可的监听对 象包括任何在美国以外地区使用参与计划 公司服务的客户，或是任何与国外人士通 信的美国公民。被指参与PRISM项目的公 司包括：FaceBook、Google、苹果、微 软、雅虎、DropBox等。



从国家战略以及棱镜门时间可以看出，在运营商核心系统中大规模使用国外商用 产品，会带来信息技术安全隐患，长期看不利于信息安全以及信息化发展战略。 如需要增强运营商核心系统安全保障能力，需要逐步替换掉目前适用的国外商用 产品，这其中就包括Oracle数据库。

去O－核心能力掌控



数据库分布情况



teredata 1%

sybase 0%

db2 11%



TimesTen 14%



oracle 74%



IT支撑系统Oracle数据库占比73.86%。 Oracle数据库广泛用于业务支撑域、管理支撑 域、经营分析域、运营管理域等各个系统中。 在技术架构层面，对数据库的核心能力掌控， 是要对Oracle数据库的方案设计、集成安装、 运行监控、问题分析、优化等方面具有自主掌 控的能力。



浙江移动业务支撑Oracle数据库核心能力简介：

 局方4人持有Oracle最高等级认证（OCM），所处岗位涵盖规划、开发支持、维护等系统运行 的全生命周期；

 截至目前，Oracle数据相关专利3项，专利申请号获得10项，双奖成果1项，集团研发成果1 项；

去O－核心能力掌控

运营商在核心能力掌控上，需要特别考虑的是是否我们去O，就能提升核心能力掌控？

运营商一般没有自己的 核心开发团队，大范围 去O，会导致核心能力 进一步向开发商倾斜



目前Oracle有着良好的 技术生态环境，且浙江

移动已经有完善的DBA 培养环境，在数据库核

心能力掌控上，具备一

定的能力

去O－成本分析



成本分析（定性）



第三方技术服 务



Oracle Licnese



第三方高级人 天服务

原厂高级人天 服务



原厂高级 服务



基本服务



阿里DBA人数变化

200 200





50 50



0 去O前



去O后



•浙江公司目前每年Oracle数据库的投资和成本基本稳定

•阿里集团去O完成后，DBA人数增加了3倍，从原来的50人增加到200人

如果浙江公司进行产品去O，投资和成本变化如下： 1：系统改造需要进行投资，预计投资超过1亿； 2：全部去O后，每年Oracle数据库投资和成本有一定程度的节省； 3：由于去O需要增加技术支持人员，目前技术保障和开发管控人员共计16名DBA，需要增加至 64名DBA。 总结：不考虑系统改造投资，去O后会导致每年成本增加至少千万；

去O－技术路线分析

以阿里为代表的互联网业界与我们所选择的两种去IOE解决思路，其实就 对应了两种技术架构的选择，分别是Scale-Out 和Scale-Up。

Scale-Out架构

重新构建应用，利用分布式处理架构，把业务压力进行水平分摊

• 采用开源或国产数据库软件，并采用X86设备，彻底去“I”、“O”、“E” • 应用需要不同程度地重新设计与开发，以适应新数据库的特点，工作量大，现有技术积累

和资源归零，风险较大

Scale-Up架构

在应用完全透明的前提下，保留现有集中式数据处理方式，提升垂直性能

• 基于X86设备构建逻辑上仍然传统集中式数据处理，但是物理上具备水平扩展能力的高性 能资源池，解决性能问题

• 能够去“I”“E”，在保留“O”的前提下 ，对应用完全透明，相对风险低，工作量小

去O－阿里的业务规模以及解决方案



以阿里集团旗下最具代表性的淘宝公司的业务发展规模和解决方案为例，剖析阿里去 O的解决方案



淘宝全年交易额（单位：亿）



7000 6000 5000 4000 3000 2000 1000







10.7 34





2003年12月 2004年12月 2007年12月 2009年12月 2011年12月



400 300 200 100



双11交易额（单位：亿）

350.19



2012/11/11



2013/11/11



随着业务的发展，阿里不得不进行全分布式架构改造，提升系统Scale Out能力，提升系统整体性能：



传统商业数据库扩展性受限

• 阿里业务爆发性增长，对数据库的扩展 性具有极大的需求



传统国外商业数据库采购及服务成本高

• 随着阿里云都公有云业务的开展以及业 务量增加，采用商业数据库采购及服务 成本将成为阿里迫切需要解决的问题



• 阿里具有自己的开发团 队，其采用小数据库大 中间件的方式，能掌控 系统的核心能力



阿里自有核心 开发团队



• 阿里云等公有云业务开 展，需要采用开源数据 库产品，满足不同客户 的需求



掌控核心能力，减少对供应商的依赖



采用开源系统，满足业务需求



阿里的应对方式：  业务部门制定业务补偿机制  以大中间件小数据库的架构进

行技术改造，以Scale Out为

主，Scale Up为辅 • 开发异构数据迁移工具 • 改造应用实现数据路由 • 改造应用实现数据同步 • 改造应用(TDDL)实现分布式事

务处理 • 开发管理系统实现规模化运维

去O－浙江移动的业务规模以及解决方案



以下数据揭示浙江移动近三年的用户数以及营业数据（数据来源于经分系统）：



用户数（定性）



收入（定性）



2011年12月31日



2012年12月31日



2013年12月31日



2011年12月31日



传统商业数据库扩展性受限



传统国外商业数据库采购及服务成本高



CRM已经完成半分布式改造，BOSS即将完成



全分布式改造；



对应用架构进行改造的代价将远远高于对技术



后续业务的爆炸性增长将主要冲击BOSS系统；



架构进行改造；



以数据库为例，通过使用数据库云平台，提升



单点Scale Up，底层也实现了Scale Out；



系统中已经全面使用了缓存技术，缓存技术能



大幅降低数据库压力，也是阿里等互联网企业



普遍使用的方式；



浙江移动不掌控



核心开发团队



浙江公司不掌握核心开发团 队，去O会导致核心能力进一 步向开发商倾斜



采用国产或开源数据库，能 提升信息安全



掌控核心能力，减少对供应商的依赖



引入国产或开源产品，保障信息安全



2012年12月31日



2013年12月31日



基于现状和对未来业务的

预估，我们需要的解决方

案如下：  负有政治责任，不能随

意采用业务补偿机制  使用Scale Up还是

Scale Out方式需要根

据业务灵活选择；  不掌握核心开发团队，

尽量在技术层面解决；  采取从外围系统开始，

演进到CRM系统，最

终演进到要求数据强一

致性的BOSS系统

去O－最终选择

 阿里是去IOE的技术先行者和创新者；  阿里对去IOE的宣传去IOE并非单纯的技术出发点；  去IOE我们应该从技术角度分析； 
 综合对比分析阿里集团和浙江移动情况，我们要吸取阿里集团

去IOE的精髓，同时，结合自身系统特点，走出一条浙江移动 特色的去O之路，采用Sacle Up和Sacle Out相结合，两者并 重的方式，尽量从技术层面解决碰到的问题，不对业务进行大 改造，从外围系统演进到CRM，最终推进到BOSS系统的方 式，逐步实现去O的最终目标。

Q&A