这篇文章算是今年年末的一个技术总结。谈谈技术圈一度的热门话题「去 IOE」这件事。 何谓 IOE ? 所 谓 IOE 是个简称。是指以 IBM 、Oracle、EMC 为代表的小型机、集中式数据库和高端存储的技术架构。其中 I 指 IBM p 系列小型机，操作系统是 AIX，IBM 专有的 Unix 系统；O 指 Oracle 数据库(RDBMS)；E 指 EMC 中高端 SAN 存储，曾经一度是 IT 企业很喜欢采用的技术架构。IOE 这个说法怎么来的? 据我所知应是来自阿里技术团队内部的称谓，然后才在整个业界流传开来。如果你去问国外技术专家什么是 IOE，对方肯定一头雾水。当然，随着国内案例逐渐被介绍到国外，或许某一天这个术语能输出价值观也说不定。 在小型机领域，只有 IBM 这一家，独步武林；HP 当初把宝押在安腾上，算是早早退出这个市场；Sun 日薄西山，SPARC 机器…那就更不必说了。另外，需要说明的是，IBM 也生产存储产品，但 IBM 的存储产品早期其实挺山寨，竞争不过 EMC ，而且有些用户会忌讳把所有的东西困在一家公司身上，尾大不掉。 起码在国内，EMC 的占有率应该更高。中高端存储这个领域，还有一家 HDS，不过曾经一度在阿里也载过跟头。数据库软件方面，在当初几乎没的选择，只有 Oracle 这一家，IBM 的 DB2 实在是不行，虽然号称市场占有率不错。国内用 Oracle 数据库支撑互联网应用的话，一般是采用 Data Guard 这个架构方案。 为何要「去 IOE」? 说 起「去 IOE」，跟阿里的王坚博士有直接关系。我无从得知他当时为什么要做出这个决定。但根据我的推断，当时淘宝、支付宝等公司每家技术体系各有特色，技术团队 也各是一套，只有去「去 IOE」，才有可能将淘宝、支付宝等公司的网站核心体系架构迁移到云上，体现阿里云的价值，某些管理者才有可能从集团公司层面对整个技术团队有更好的控制 力。否则，阿里云师出无名。注意，这个说法只是我个人臆测，肯定不是事实，只是逻辑上是说得通的。实际上，阿里云当时自己的活儿做的很垃圾，也幸亏这个 「去 IOE」运动进行并不那么快。当然这是后话了。 或许有人认为「去 IOE」会节约企业成本，实际上，当时的 Oracle 和 EMC 等软件成本已经足够低，硬件上，硬件上的每年的成本也是可控的，如果考虑迁移后总体成本，新硬件成本、开发人员成本、运维成本、时间成本等等，通通算下 来，未必能节约多少。这个不是我拍脑袋给出来的，而是跟不少技术人事后复盘，结论基本一致。 客观的说，当时「去 IOE」有一种公司政治的倾向，或者成为一个一窝蜂的运动，这很令人讨厌，或者说这事情出发点未必如何好，但令人意外的是，最后在阿里诸多优秀技术人才的努力下，却取得了一个令人惊讶的很好的结果，那么，就别管出发点如何了。 为何「去 IOE」是必要的? 从另外一个角度考虑，尤其从运维DBA的角度去审视，「去 IOE」 实际上是必须要进行的，或者说去「O」是必须的，因为当时存在的问题是，Oracle 数据库对用户 (DBA) 来说已经不够灵活，常用的 Data Guard 模式无法适应互联网公司快速增长，最基本的一点，读写分离就做不到，只能向上扩展(Scale Up)，拼硬件能力，几乎无法做到横向扩展。或许有人说，不是有 RAC 么? 但 Oracle RAC 是无法对付高并发下的 OLTP 应用的 – 一直到现在很多人都认识不到这一点，RAC 跑跑数据仓库什么的倒是不错。 注：有人会说 Orale RDBMS 11g 的 Data Guard 可以读写分离呀，这个所谓的读写分离可靠性其实是不够的，而且出现的时间也太晚了，此外，不够灵活。还会有人争论 Oracle RAC 怎么就不能应付 OLTP 呢? 别争论了，你非要说可以应付，没问题，但是在阿里体系的公司里，还真没人敢这么玩儿，为什么? 是做不到? 还是他们掉进坑过? 如果要动「O」，那么 「I」 和「E」就必须要动 – 相信不会有人在小型机上跑 MySQL 的，而且，只换掉「O」也没有意义，换汤不换药不会有成效。 随着中国电子商务的快速发展，整个阿里系其实已经在面对全世界增长最快最复杂的业务系统之一，这是机遇，也是挑战。旧有的技术架构已经不足以支撑更大的梦想。从这个意义上来说，去「IOE」是相当必要的。或许，这也是王坚博士以及一些人的初衷。 |
