2013年5月17日，阿里集团最后一台IBM小机在支付宝下线。这是自2009年“去IOE”战略透露以来，“去IOE”非常重要的一个节点。“去 IOE”指的是摆脱掉IT部署中原有的IBM小型机、Oracle数据库以及EMC存储的过度依赖。告别最后一台小机，意味着整个阿里集团尽管还有一些Oracle数据库和EMC存储，但是IBM小型机已全部被替换。2013年7月10日，淘宝重中之重的广告系统使用的Oracle数据库下线，也是整个淘宝最后一个 Oracle数据库。这两件事合在一起是阿里巴巴技术发展过程中的一个重要里程碑。
何谓IOE？
IOE 这个说法来自阿里技术团队内部的称谓，然后才在整个业界流传开来。IOE是传统IT三大件，指以 IBM 、Oracle、EMC 为代表的小型机、集中式数据库和高端存储的技术架构。
I 指 IBM p 系列小型机，操作系统是 AIX（IBM 专有的 Unix 系统）；
O 指 Oracle 数据库(RDBMS)；
E 指 EMC 中高端 SAN 存储。
为什么要去IOE?
阿里巴巴过去一直采用的是Oracle数据库，并利用小型机和高端存储设备提供高性能的数据处理和存储服务。随着业务的不断发展，数据量和业务量呈爆发性增长，传统的集中式Oracle数据库架构在扩展性方面遭遇瓶颈。
传统的商业数据库软件(Oracle,DB2)，多以集中式架构为主，这些传统数据库软件的最大特点就是将所有的数据都集中在一个数据库中，依靠大型高端设备来提供高处理能力和扩展性。集中式数据库的扩展性主要采用向上扩展(Scale up)的方式，通过增加CPU，内存，磁盘等方式提高处理能力。这种集中式数据库的架构，使得数据库成为了整个系统的瓶颈，已经越来越不适应海量数据对计算能力的巨大需求。
传统架构在主机端大多通过两台主机共享存储设备，平时其中一台主机使用存储通过数据库软件来管理。这样的架构只能有一台主机(RAC除外)上的数据库能够提供服务，另一台主机只能是作为热备冗余，不能启动数据库实例提供服务。所以，其处理能力就完全取决于这台主机的最大扩展能力，很难通过增加主机数量来增加处理能力。而单台主机的扩展能力毕竟是有限的，即使是某些厂商的大型机，同样也有其扩展限制。此外，传统架构对高端设备的依赖，无疑将直接导致系统成本的大幅度增加，甚至可能会导致系统被主机和硬件厂商所“绑架”，不得不持续增加投入成本。
在阿里看来，“IOE”实际上代表了一种高成本、高维护费、很不互联网(不擅长处理大规模高并发的互联网行为)的商用数据库系统，特别是阿里盘子越来越大，所需要付出的升级硬件和维护的代价也会越来越惊人，阿里巴巴采用数据切分(sharding)的策略，将部分海量数据应用从集中式Oracle切换到分布式MySQL集群，从纵向扩展到水平扩展，解决了数据库扩展性的问题，并用PC服务器替换了小型机。事实上，这里可以做一个不那么技术但比较简单的理解：传统的IOE代表的是集中式架构，而去IOE化其实就是推动分布式架构代替集中式架构，也就是更好的拥抱云计算—当然对阿里本身来说，用通俗的语言解读出阿里云甚至阿里的IT计算(甚至商业模式)发展路径：
1、鉴于类似双11这种超大规模并发行为的产生，背后需要的计算资源非常庞大，所以整个阿里对IT资源的投入都是非常大的。
2、当投入大量的资源应对高峰期高并发时，低峰低并发时就造成了计算资源的冗余，这个时候就可以以云计算的方式出租给中小企业。而当然企业就可能有更高的野心，比如把云计算作为主要的商业模式。但是对于那些对计算要求很高的公司，还不够。
软件决定整体架构，如果要动O，那么I和E就必须要动 – 相信不会有人在小型机上跑 MySQL 的。
Oracle RAC不能满足扩展要求么？
转自：可扩展的分布式数据库架构
几乎每个数据库产品都有集群解决方案，Oracle RAC是业界最流行的产品。其架构的最大特点是共享存储架构（Shared-disk），整个RAC集群是建立在一个共享的存储设备之上的，节点之间采用高速网络互连。Oracle RAC提供了非常好的高可用特性，比如负载均衡和应用透明切换(TAF)，其最大优势在于对应用完全透明，应用无需修改便可以切换到RAC集群。但是，RAC的扩展能力有限，首先因为整个集群都依赖于底层的共享存储，所以共享存储的IO能力和可用性决定了整个集群的可以提供的能力，其依然无法摆脱对 大型存储设备的依赖。Oracle显然也意识到了这个问题，在Oracle的MAA(Maximum Availability Architecture)架构中，采用ASM来整合多个存储设备的能力，使得RAC底层的共享存储也具备线性扩展的能力，整个集群不再依赖于大型存储的处理能力和可用性。
RAC的另外一个问题是，随着节点数的不断增加，节点间通信的成本也会随之增加，当到达某个限度时，增加节点可能不会 再带来性能上的提高，甚至可能造成性能下降。这个问题的主要原因是Oracle RAC对应用透明，应用可以连接集群中的任意节点进行处理，当不同节点上的应用争用资源时，RAC节点间的通信开销会严重影响集群的处理能力。所以使用 Oracle RAC有两个建议：1.节点间通信使用高速互联网络；2.尽可能将不同的应用分布在不同的节点上。基于这个原因，Oracle RAC通常在DSS环境中可以做到很好的扩展性，因为DSS环境很容易将不同的任务分布在不同的计算节点上，而对于OLTP应用，Oracle RAC更多情况下是用来提高可用性，而不是为了提高扩展性。
参考
