2012年5月阿里巴巴集团”去 IOE”运动的思考与总结【转载+整理】

原文地址

什么是 IOE,IOE 只是一个简称,分别代表 IBM、Oracle、EMC,确切地说是 IBM 小型机、Oracle 数据库与 EMC 存储设备的组合。这“三驾马车”构成了一个从软件到硬件的完整的商用数据库系统,是同类产品中的最佳组合。

简言之,阿里巴巴“去 IOE”事件是用成本更加低廉的软件——用 MySQL 替代 Oracle,用 PC Server 替代 EMC2、IBM 小型机等设备,以减少 IOE 对自己数据库系统的垄断。IOE 整套系统维护费用非常昂贵,仅仅 Oracle 三年的费用就达到八位数,而阿里旗下的用户群每年都在增长,在应用云计算的过程中,IOE 并不适合云服务的横向扩展,即多个数据库系统同时运行,因此,云服务一旦扩张,这部分维护成本将非常高。

2013年5月17日,最后一台小型机在阿里巴巴支付宝下线,标志着阿里已经完成“去 IOE”化。上海财大经济学院副教授、高等研究院市场机制设计和信息经济研究中心主任李玲芳对《第一财经日报》称,阿里巴巴“去 IOE”为市场带来了一个成功范本,证明“去 IOE”是可能的。

除了降低成本,“去 IOE”化还有信息安全考虑。“棱镜门”事件引起了人们对信息安全的担忧,就8月25日(2013年),中国互联网络信息中心(CNNIC)官方微博称,CN 域名遭遇了最大一次规模的攻击事件。

【导读】

2012年5月7日,阿里巴巴集团正式公布技术团队合并的事情,涉及的部门:阿里巴巴运维团队、阿里巴巴 DBA 团队、阿里巴巴平台技术部、大淘宝运维团队、大淘宝 DBA 团队、大淘宝核心系统部、阿里云计算运维团队、阿里云计算 DBA 团队和阿里巴巴集团安全团队,从一些信息分析,上述技术团队合并之后,大淘宝员工将成为相关技术团队的掌舵者。“去 IOE”运动由阿里巴巴集团首席架构师某博士主导,阿里巴巴和淘宝技术团队内部非常有影响力的XX负责执行,合并后阿里巴巴集团内部所有子公司“去 IOE”运动,将继续深化。

个人就淘宝、阿里巴巴和支付宝“去 IOE”事件,以局外人的角度分析利弊。

淘宝和阿里巴巴去 Oracle 化事件引发数据库技术人员大讨论一文,只是把对阿里巴巴、淘宝等子公司内部人士以及外部人士的观点和建议整理出来,本文我们从几个不同的角度综合分析阐述“去 IOE”事件对阿里巴巴、淘宝等公司 DBA 团队和公司公司业务,以及互联网 DBA 从业者的影响……

(一) “去 IOE”事件中的 IOE 名词解释


(1)“I”是代表 IBM,即去 IBM 小型机(和存储设备),阿里巴巴、淘宝和支付宝主要是使用 IBM 小型机,其存储设备相对较少;

(2)“O”是代表 Oracle,即去 Oracle 数据库,采用 MySQL 和 Hadoop 解决方案,Oracle RAC 将会被 Hadoop 集群替代,其阿里巴巴 B2B 使用的 GreenPlum 集群,也将会在阿里巴巴集团完成运维团队和 DBA 团队合并之后,采用 Hadoop 集群解决方案替代;

(3)“E”是代表 EMC2,阿里巴巴 B2B、淘宝和支付宝都是用大量 EMC2 的存储设备,其性价比高,再就是少量 DELL 存储设备;

阿里巴巴集团内部最早进行 MySQL 替代 Oracle 支持数据服务的子公司是,阿里巴巴 B2B,用 PC Server 替代 EMC2 存储设备,替代 IBM 小型机。不过,替换步伐被合理控制,因多方面原因,内部也没有那么雄壮的决心。后来,淘宝也开始进行 MySQL 摸索和推广,并且高调宣传“去 IOE”。

 

(二) “去 IOE”对淘宝、阿里巴巴 B2B 和支付宝等公司的价值


阿里巴巴集团与甲骨文公司的 Oracle 是三年无限制性的 License,总销价是三年 X 千万人民币(备注:不能告诉大家具体多少钱,属于商业机密, 望理解!),这部分开销对整个阿里巴巴集团而言并不算什么,花费最大地方是 Oracle 的“座驾”,主要是 IBM 小型机和 EMC2 存储设备的购买和保修费用。

随着淘宝、支付宝和阿里巴巴 B2B 的注册用户激增,用户数据越来越多,即使采用冷热隔离的方式也解决不了数据大容量、大并发的难题。淘宝启用了全亚洲最大的 Oracle RAC。阿里巴巴 B2B 中文站,数据量也因数据量大和业务要求,在每天早上 08:00—09:30 之间,CPU 使用率保持在 98%,LOAD 也超高,即使更换存储设备不久也会再次出现这样的状况。互联网公司的发展非常迅速,集中式数据库系统会逐渐成为业务瓶颈,花费重金升级硬件,在企业高速崛起的时候,可能不会太在意,若是企业占有市场份额足够大、步入平稳发展阶段或企业资金出现问题的时候,就不得不考虑成本, 采用满足企业发展需求,只需要合理地投入资金,考虑更加省钱的数据库软、硬件解决方案。

大淘宝、阿里巴巴 B2B 和支付宝等公司,98% 以上的软件系统和业务都是采用 Oracle 提供数据服务,电子商务领域阿里巴巴集团旗下公司拥有的总数据量和用户量是其他任何公司无法比拟的,DBA团队面临的压力和挑战也不言而喻,肯定要比其他公司更早地关注此方面成本和业务的双重压力。

阿里巴巴集团使用 License 最多的子公司是大淘宝,2010年及之前,还高调地要部署更多的 Oracle RAC,但随着阿里巴巴 B2B 将其中文站和数据量最大的 Offer 数据库,成功从 Oracle+IBM 小型机+EMC2 存储设备,迁移到 MySQL+PC Server,以及大淘宝核心系统部门招聘到@淘宝褚霸、@淘宝丁奇等能修改 MySQL 和 Hbase 源码,其产品线使用 MySQL 提供服务,使 MySQL DBA 的经验和技术大幅提高,也就有能力把产品线从 Oracle 迁移到 MySQL,而采用 Oracle 支持的数据分析业务则用 Hadoop 集群替代,这是给核心系统部和 DBA 团队建功立业的大好时机,同时,能解决大淘宝业务系统的压力和瓶颈,也能帮助大淘宝降低资金投入。搭配开发完善的自动化系统,可以大大简化数据库的管理成本,也能减少 DBA 团队的工作量。

阿里巴巴、淘宝和支付宝都曾尝试,将 Oracle 的“座驾”AIX 系统+IBM小型机+EMC2 迁移到 Linux 系统+PC Server 模式。若对 Oracle 不拆分的话,PC Server 根本无法承受这样的负载;若是对 Oracle 拆分,将需要增加购买大量的 License。从而不得不考虑将业务系统的 Oracle 迁移到开源 MySQL 和 Hadoop 平台上(注释:这两种开源产品能满足业务需求,以及相对其他开源产品更稳定和成熟)。

非常遗憾的是,阿里巴巴集团首席架构师王坚推行的是全面去商业数据库产品计划,也即整个阿里巴巴集团,可能除支付宝少数业务的数据库继续采用 Oracle 之外,其他都将换成 MySQL,为此,可能导致阿里巴巴 DBA 团队、大淘宝 DBA 团队、支付宝 DBA 团队等,在 Oracle 领域积攒十年的架构设计和运维维护经验瞬间付之东流,同时,这些 DBA 团队的 Oracle DBA 也将会有不少人员选择离开,否则只能转行为 MySQL DBA。

大淘宝 DBA 团队、阿里巴巴 DBA 团队、支付宝 DBA 团队和阿里云计算 DBA 团队总共拥有的 MySQL DBA 人数,不会超过15人,而 Oracle DBA 有 80 人以上,其中 MySQL DBA 团队真正能干活的不会超过 X 个人,MySQL 在阿里巴巴真正支持业务发展的时间不超过三年(注释:淘宝成立初期采用 MySQL,能力问题而不得不迁移到 Oracle 平台;阿里巴巴 B2B 在 2009 年之前,也是少数边缘业务从 Oracle 迁移到 MySQL)。多数是 Oracle DBA 转行为 MySQL DBA 的兄弟,他们在 Oracle 方面确实经验丰富和能力超强,但是 MySQL 方面就不多加评论了……

小结:

一 直为 MySQL 社区的发展与壮大而努力,作为技术人员要说真话和大实话,不能因个人感情而做事情。个人认为阿里巴巴集团“去 IOE”是不得不要做的事情,但不是把所有的 Oracle 都迁移到MySQL 或 Hadoop 平台,而应该是对业务系统有选择地进行,以及迁移的步调要合理地控制,不宜过快过急,需要等待 MySQL DBA 团队的壮大,技术与经验的积累。否则,可能出现迁移过去之后不久,发现对业务发展和支持出现严重的问题,大淘宝内部的信息分析,他们已经基本度过危险的阶段,也有很多遇难杂症,但是支付宝的业务具有特殊性,要比淘宝的业务系统要求更高,恐怕是一个非常大的障碍。

阿里巴巴集团高调向外界传递去 Oracle 信息之后,新的 Oracle 数据库 License 谈判将会很变得艰难,甲骨文公司本来是把把阿里巴巴、淘宝和支付宝等公司作为中国标杆用户宣传,现在公开大规模地去 Oracle,可能会得到甲骨文公司的报复,为此可能要偿付更加昂贵的 License 费用。对于阿里巴巴价值观“拥抱变化”,是无处不体现,但是要合理地使用,不要被某些人利用搞成政治运动,而影响企业的稳定与发展。

 

(三) “去 IOE”对淘宝、阿里巴巴 B2B 和支付宝等公司的 DBA 团队影响


大淘宝是“去 IOE”最迅速、最彻底的公司,相关技术人员也将会得到更多的晋升和加薪机会,阿里巴巴 B2B DBA 团队很早进行的部分业务系统“去 IOE”,使得相关人员受益(注释:也包括我个人,阿里巴巴 B2B 对 MySQL DBA 的渴望而有机会加盟,机缘巧合是 MySQL 成功使用之后离开了),而支付宝是“去 IOE”进展最慢的公司,为此高层不得不选择派遣相关人员,加速支付宝公司“去 IOE”。

阿里巴巴集团最后可能保留少数业务产品线,继续使用 Oracle 提供数据服务,以及 MySQL 自动化完成之后,将导致阿里巴巴集团DBA 团队出现资源严重富余,Oracle 迁移 MySQL 过程与完成之后,将会出现 DBA 人员的流失,这对阿里巴巴集权的 DBA 团队而言是一种损 失,往往选择离开的 Oracle DBA,越是优秀和有成长潜力的,可能早就更多 DBA 人员处于混日子的状态。

“去 IOE”事件对 MySQL 团队和核心系统部门的发展,是非常有利和促进作用。越来越多的业务系统和核心系统,采用 MySQL 提供数据服务,MySQL DBA 面临的挑战与压力将会越来越大,DBA团队的自动化水平能力也将会迅速得到提高,否则无法管理规模庞大的 MySQL 集群和 Hadoop 集群。

整个阿里巴巴集团能读懂、编写和优化MySQL源码的DBA或开发人员,总数不会超过X个人,这对阿里巴巴集团“去 IOE”也是一项挑战,毕竟开源数据库产品没有商业数据库产品那样经过严格的测试流程而稳定,购买甲骨文官方提供的MySQL服务,绝对不是淘宝、阿里巴巴和支付宝DBA团队的行事风格,一定会想办法自己修改和优化MySQL源码,相信阿里巴巴集团会投入更多的资源引进相关的技术人才,这对MySQL团队的技术提高也非常有帮助。

小结:

(1)Oracle 团队的经验和技术积累将大量丢弃;

(2)Oracle 团队的 DBA 流失不可避免;

(3)MySQL 团队的 DBA 经验、技术和能力,将被迫加鞭快马提高。

 

(四) “去 IOE”对数据库行业的影响


淘宝“去 IOE”事件网络曝光之后,引起更多 Oracle DBA 从业人员的恐慌,使他们最担忧的是互联网行业的其他公司效仿淘宝和阿里巴巴去 Oracle 的壮举,而出现蝴蝶效应。

对甲骨文公司而言,不会失去一位非常重要的中国客户,只是可能失去部分 License 费用收入而已。毕竟阿里巴巴集团旗下的支付宝某些业务系统肯定会用 Oracle 平台,至少阿里巴巴 B2B 的 CRM 系统短期内不得不考虑继续使用 Oracle 平台(注释:CRM 系统太复杂,也很难有人搞清楚)。

淘宝、阿里巴巴和支付宝公司用 MySQL 和 Hadoop 分布式平台,替换 Oracle 和 Greenplum 并行数据库的行为,不可避免会影响互 联网行业企业的数据库平台选型,也会导致 Oracle 行业的从业者担忧。唯一办法,就是澄清这些事情的来龙去脉,使不明真相的群众懂得去分析类似的事情,而不跟风做错误的决定,不过互联网行业采用开源数据库的大趋势是必然的,互联网行业采用开源技术解决方案也是必然发展趋势。

淘宝、 阿里巴巴 B2B 和支付宝用 MySQL 支持核心业务系统,其中阿里巴巴 B2B 已经使用 MySQL 支持中文站Offer数据库,淘宝的核心业务之一 订单都是 MySQL 提供数据服务,必将将会促使更多企业使用 MySQL,从而会促进 MySQL 领域的从业者发展和薪资待遇的提高,对 MySQL 社区和 MySQL 技术的进步也会有一定的促进作用。

MySQL 搭配 PC Server 和 Linux 操作系统的模式,以及再加上一些特殊的软件硬件技术——SSD 硬盘和 Fusion-IO,尤其是经过淘宝、阿里巴巴 B2B 和支付宝等业务的洗礼之后,使 MySQL 的解决方案丰富和成熟, 也会促使 DELL、华为、惠普(注释:不过这家企业的硬件设备实在是太差,尤其售后服务)等公司大力发展 PC Server 业务。也会推动 IBM、EMC 等存储设备厂商进行技术革新,最后,也会推动甲骨文公司和 MySQL 社区共同推动 MySQL 数据库产品支持更大的 数据存储容量和并发处理能力。

 

(五) 总结


淘宝、阿里巴巴B2B和支付宝等公司去 Oracle,改用 MySQL 和 Hadoop 分布式平台支持数据服务业务的分析和总结,就写到此了。希望个人写的本篇文章,对技术圈的朋友们有帮助,同时,也做到了独立性和公正性透彻地分析“去 IOE”运动。作为一位 MySQL 数据库技术的从业者,要感谢淘宝高调公布“去 IOE”,采用 MySQL 搭配 PC Server 的方式支撑大并发大数据量的核心业务,为互联网行业的 MySQL 从业者提供了参考模板,也希望其能继续完善 MySQL 数据库平台和 Hadoop 分布式平台的自动化解决方案,也能继续对外开放。最后一点,希望阿里巴巴集权推进这样的事情,是能保持雄心和壮志,继续把适合采用 MySQL 开源数据库和 Hadoop 分布式平台支持的业务迁移过来,请莫出现反复的行为。

posted @ 2013-11-09 23:57  船长&CAP  阅读(1451)  评论(0编辑  收藏  举报
免费流量统计软件