仍是补充下, I(小型机)提供的是可靠的计算服务, 经过软件Cluster或必定的一致性/可用性的牺牲, 是比较容易作到的, E提供的是持久化的状态快速迁移的问题, 在软件层作mirror或必定的快速切换能力也是能够显著下降成本的, O提供的是一整套的业务整合能力, 以及业务的ACID支持, 若是对ACID没有需求, 或者InnoDB就能够知足你的需求(非资金/订单类业务), 使用O从一开始就是个错误.
原文地址 http://dbanotes.net/arch/IOE.htmlhtml
这篇文章算是今年年底的一个技术总结。谈谈技术圈一度的热门话题「去 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」有一种公司政治的倾向，或者成为一个一窝蜂的运动，这很使人讨厌，或者说这事情出发点未必如何好，但使人意外的是，最后在阿里诸多优秀技术人才的努力下，却取得了一个使人惊讶的很好的结果，那么，就别管出发点如何了。ide
为什么「去 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」是至关必要的。或许，这也是王坚博士以及一些人的初衷。
为什么「去 IOE」成功了?
阿里几家子公司这么复杂的技术体系，「去 IOE」这事情堪比高速公路上给飞驰的汽车换轮胎，最后成功是至关不容易的。
成功的因素有哪些呢?
1.功不可没的固然是一群出色的技术人才，很了不得。我想这是无需多说的，面对这么复杂的业务环境，这个任务若是没有一批优秀的工程师是绝对作不到的，没有阿里 B2B 技术团队、淘宝团队、支付宝技术团队的前后投入以及合做实践也是绝对作不到的。要强调一下的是，阿里在在分布式事务上的处理能力和解决方案，这应该是独门绝技。在业界各类会议上也常常能看到这一群牛人出来分享，同行应该能感觉到。
2.开源软件的快速成熟。举个例子，这两年 MySQL 体系的软件进步至关惊人，各类经验证的解决方案如雨后春笋般涌现出来。这得益于很多知名互联网公司(好比 Facebook、淘宝)在使用 MySQL 的同时也将其技术改进回馈给技术社区，把技术方案分享给业界，业界在吸取这些技术的同时再次回馈给技术社区，造成正向的反馈，极大地提高了开源软件在商业领域的竞争力。
3.硬件革命。硬件的进步给技术体系的变迁作好了铺垫。最主要的关键词:「SSD」。若是没有「SSD」的技术成熟以及在商业应用上被广泛接受，「去 IOE」几乎是不可能作到的。要知道物理机械硬盘存储的性能数十年几乎没获得什么大的改进 – 固然每一年提高一点是有的。但 SSD 相比机械硬盘来讲，则是质的飞跃。我记忆深入的是，每一年作 I/O 容量规划的时候都会发愁，由于即便已经使用上了很高端的 EMC 存储设备，但实际上只要应用层 I/O 没有命中到存储内存，直接打到后面的磁盘上，几乎没什么抵抗能力。好比当时一个硬盘极限能撑 100 多个 I/O，100 块硬盘也不过是万把个 I/O 就不行了。 但这样的 I/O 「打击」对 SSD 来讲，则不是什么大问题。SSD 给解决「IOE」体系最大的瓶颈 – I/O 能力提供了硬件先决条件。
4.摩尔定律。这一点最初我不想说起，但不说起，就会有别人说，因此仍是补充一下。提到摩尔定律，重点要说的 X86 芯片的计算能力不断进步，而 IBM 的 Power 芯片虽然也在不断进步，但正式商用的节奏明显在控制。这就给 Intel 体系带来了机会和空间。
国内对「去 IOE」的反应
在出现阿里这个成功案例以后，技术圈非常震动，曾经一度讨论热烈，随后则是国内产业界对此出现了一些跟风的倾向，很多公司则打着「国产」软件的旗号出来蒙人，这是值得警戒的。去掉 Oracle 不意味着就要采用国产的垃圾数据库，由于 MySQL 以及衍生的各类分支数据库才是最佳选择。一样，不用 IBM 的小型机也不意味着国产服务器就迎来新机会，在用户那里，适合的解决方案才是最重要的。「去 IOE」不该该成为一个噱头。任什么时候候，「国产」都不该该是一个互联网企业选型所要优先考虑的因素。在全球化的今天，咱们应该忘掉「国产」，才有可能早点作出来更牛的软件来。
更可笑的，还搞出来一个什么「去 SOA」的组织，我以为这是不太正常的，实际需求为前提，不能本末倒置，难道是为了「去」而「去」么?
2014 之后会有更多公司「去 IOE」
从目前的种种趋势来看，在从此几年，国内一些互联网公司以及 IT 企业会逐渐的「去 IOE」化。相比几年前，如今的「去 IOE」的主要缘由则是：旧的「三件套」已经的确不适合互联网应用了。开源数据库更为可靠成熟，SSD 可靠性也获得验证，技术人才甚至都不须要从头开始进行储备 – 相似「沃趣科技」这样的团队已经可以提供足够好的技术支持服务，新的技术体系毫无疑问会让企业更有竞争力，整体成本更低。
上文提到的「沃趣科技」是由一群前阿里的工程师组成的技术团队，聚集了一群从数据库到存储到网络架构的专家，若是要找「去 IOE」技术顾问，彷佛他们是独一份(这里不是广告)。相比之下，IBM、Oracle、EMC 等公司近些年来，实际上对国内那些快速发展的互联网公司已经提供不了有力的技术支持了，IBM 拿苏宁电商练手更成为业内笑柄。或许这也是 IOE 们被抛弃的一个缘由，也多是一些创业团队的新机会。
一个时代过去了。
–EOF–
关于 IOPS 的数据补充：
机械硬盘如今最高号称能跑到 400 IOPS，但应该 200 左右(走 SAS 接口)也就是极限了; 单块 SSD(走 PCIe 接口)的最高记录是九百多万，用不了多久突破千万 IOPS 是没问题的，至关了不得, 即便百万量级也足够吓人了。(Refer)
IOPS
http://en.wikipedia.org/wiki/IOPS
评论：