从上一篇文章的反馈来看，大家还是喜欢八卦多过技术细节，那这一篇继续一些题外话，说说我对“去IOE”的看法。
对同一件事情，参与的没参与的人，讨论起来，都会有各自的立场。所以这里先申明一下，以下内容只是我个人的观点，与任何公司及组织及其他个人皆无关；限于个人记忆力，部分细节可能有出入，如有差错，纯属年老失忆。
淘宝当年从单个Java应用到服务化后的垂直分库，再到水平分库，一步一步走过来，每一步皆有其必然性。但从传播性和话题性上来讲，“淘宝技术架构升级”，显然不如“去IOE”这种标签化的短语有力量，短短几个字，既有动词“去”，又牵扯到当世三大企业服务厂商，想不吸引眼球当“网红”都难。
说起淘宝技术架构升级，2007年是一个绕不过去的时间点，呃，这么说的原因，当然很大一部分也因为我是这一年加入淘宝的。那一年的淘宝，意气风发，空降了几位很有影响力的高管，包括阿里巴巴集团现任CEO逍遥子、菜鸟现任CTO菲青、现任VP优昙（记不太清楚是07年底还是08年初了），还有已经离职的前技术VP空闻、前HR VP赵敏等。
2007年的淘宝技术架构，在Java层有一个大名鼎鼎的应用denali。真的是一个应用哦，淘宝前台业务大部分代码都堆砌在这一个应用中，牵一发而动全身。所以空闻和菲青来了以后，招了几个技术好手开始做服务化改造。于是有几个基础性的东西产生了： 毕玄主导HSF（High Speed Framwork）做为服务化的基础RPC框架，解决了服务化后各个应用之间的高性能通信需求；华黎主导的消息中间件Notify（后来Kafka出来后，又用Java重写了个MetaQ），解决了服务化后各应用之间异步依赖的消息通信需求。从产品命名上就可以看出来，包括后面的数据库中间件TDDL，当年淘宝的技术人员是有多土鳖了。有了这两大法宝，服务化和垂直拆分就水到渠成。
从2007年到2009年，马不停蹄的从denali中拆分出了用户中心UIC、商品中心IC、交易中心TC、店铺中心SC、评价中心、收藏夹等等垂直的服务中心，以及每个服务中心对应的上层应用，那些暂时拆不出来的一大坨，就都塞在一个叫Misc的数据库里面。数据库也从原来集中的商品和交易库垂直拆分成了十几套数据库，压力大的用IBM p950和EMC DMX高端存储，压力小一点的用IBM p550和EMC CX中端存储，2007年到2009年在每年业务至少翻番，系统压力翻几番的情况下，土鳖的淘宝技术人员，用土办法见招拆招，算是顺利度过了这段艰难时期，也奠定了后续的技术方向。这段时期当然也有很多插曲，包括各种宕机，甚至是机房两次断电等，那又是另外一个故事了。
时间到了2009年，数据库这么垂直的拆下去，到最后单个数据库只放一张用户表或者一张交易表，用最高端的小型机和最高端的存储，也快顶不住压力了，尤其是连接数。前端无状态的Java应用服务器现在已经能够随着业务压力加机器扩容了，但应用加机器都得要加连接数啊。Oracle是进程模式的，基本上一个连接数需要消耗8～10MB的内存，这样5000个连接数就需要50GB左右的内存，加上SGA，连接数的天花板近在眼前。
数据库当时采用的高端小型机＋高端存储＋Oracle，价格确实是不便宜。垂直拆分已经搞出了十几套这样的硬件，再来个水平拆分，DBA团队做预算的压力真是山大。所以开始把目光投向了MySQL。当时比较成熟的版本应该还是5.0，2008年底刚刚GA没多长时间的5.1算是新锐版本。我们开始在一些边缘系统尝试，也面向全国开始招MySQL DBA，但其实一个也没招到，只好从应届生开始培养。好在服务化垂直拆分做完以后，大量的关联查询都在应用服务层通过接口调用来解决，数据库基本上就只有基于主键的增删改查操作了，基本上也就相当于一个KeyValue存储在使用。所以说，服务化是数据库水平拆分很重要的一个前提。
但是，服务化只是一个前提。要做核心数据库如用户库和交易库的拆分，还必须要解决IOPS的问题。为什么要用高端存储？因为IOPS啊。传统机械硬盘在可接受的10ms响应时间内的IOPS峰值大约只有80～100。当时我们一个交易库使用的高端存储配置了480块硬盘，可以支撑大约4万～5万的IOPS，按照一台PC Server可以插16块硬盘来计算，需要30台机器。看起来也不多是吧？但这么大的动作做完，肯定需要至少能支撑2～3倍的余量才行啊，所以需要一下子拆分到至少64个节点128台机器，而且很可能两三年后就要朝着上千台的规模去了，而这个规模纯粹是因为IOPS，CPU却是大大浪费的。对于当时还只有十几套Oracle数据库的DBA团队来说，维护成本也犹如达摩克利斯之剑啊。
正所谓车到山前必有路。我们在Percona的mysqlperformanceblog.com上了解到了一款名叫FusionIO的PCI-E Flash闪存卡，小小一片印刷电路，竟然拥有超过十万甚至百万IOPS的能力，响应时间还能到1ms级别，这种法宝正好也开始进入中国了。于是我们相当激进的开始引入测试，并且一举上线，反正压力在身不得不前行，加上有主备复制，还有Notify做Oracle/MySQL异步复制新旧两套数据库系统并行的双保险，就这么搞成了。
所以说，所谓的“去IOE”，在当时其实有两个重要的前提条件：
1. 服务化的完成，数据库变成了简单的KeyValue存储模式；
2. PCI-E Flash卡的成熟，解决了IOPS的问题
PCI-E卡是好东西，可是也很贵，当时一片的价格要10万左右。Flash存储成熟后，英特尔也跑出来要分一杯羹，推出了传统IDE接口的SSD硬盘，虽然单个盘的IOPS比PCI-E卡下降了至少一个数量级，但价格也便宜了很多，而且一台机器上可以插多个盘。所以除了压力非常大的核心数据库，其他的数据库也就可以一股脑儿的从Oracle迁移到了基于SSD的MySQL上。反正迁移和拆分这事儿，一回生二回熟了。
水平拆分的架构升级帮助淘宝沉淀了另外一个神器：TDDL（Taobao Distributed Data Layer）。TDDL除了水平分库的路由功能，还有一个非常核心的模块叫动态数据源。因为原来需要在Java应用中显式的配置每个数据库的连接参数，每次修改都需要重新打包发布应用。水平拆分以后，数据库节点变多了，应用的机器也越来越多，这个事情就越来越不好玩。我就和华黎/沈询商量，能不能把数据库连接参数搞成动态可配置，这样DBA干拆库/主备切换这样的小动作时，应用的同学就不用陪着熬夜了。就这样，这帮靠谱的家伙就搞定了三层的动态数据源。
淘宝这一路的技术架构升级，沉淀出来，其实就三个东西，今天已经在阿里云上做为互联网中间件对外提供服务，这是一个好事情：
-
企业级分布式应用服务EDAS，就是HSF和阿里巴巴B2B团队搞的Dubbo（已经开源）的内部合体版本
-
消息队列MQ，就是Kafka的Java版本MetaQ
-
分布式关系型数据库服务DRDS，就是内部的TDDL
所以我一直认为，“去IOE”更准确的说法应该是淘宝技术架构的大升级；而云计算，则是传统IT架构的一次大升级。这两者相互之间也可以说是有传承的，都是在向着拥抱X86开放式体系，向着弹性升缩的方向升级。但“去IOE”这种简单粗暴的标签化提法，虽然在宣传上比较有效，但其实掩盖了很多的来龙去脉。