摘要： 2013 SDCC 中国软件开发者大会在北京新云南皇冠假日酒店开幕，本次大会的主题为“软件定义未来”，阿里技术保障部DBA负责人——周宝方在大会上发表演讲，他表示，斯诺登事件让更多企业考虑去IOE的必要性，但是去IOE拥有很高的技术门槛，较大的额技术风险，水很深。

他认为， 集中式严重制约是去IOE的核心原因 ，而IOE本身限制了很多开发者技术的发挥和许多企业的长远发展。同时，他还认为，去IOE技术难以复制，对接去IOE技术的云计算平台更合适，去IOE需要信念，才能走得下去。

今年，SDCC 2013将围绕软件定义数据中心、大数据、开放平台等九大主题，解析各种平台技术，分享生态系统构建之道；邀请国内外业界领袖和知名技术专家就本年度主流技术、产品、应用实践等热点议题进行深入分享。

以下是周宝方演讲实录：

周宝方：大家好，很荣幸参加今天的大会，因为之前也是有很多故事，在互联网上，包括最近斯诺登的事件，确实再次把阿里的去IOE推了上来。我把阿里去IOE的过程思考走过的弯路跟大家做一个分享。

先自我介绍一下，在阿里我花名叫后羿，大家知道阿里是花名文化，我数据库做的时间比较长一点，在阿里整个后端技术整合，我负责整个阿里的数据库技术。在过去几年去IOE，我参与了这个战略的制定，也是实施者。

首先讲IOE（IBM、Oracle、EMC），去IOE的过程的话，简单跟大家展开一下，阿里在2010年到2013年整个这几年预算的指导思路演进的过程。为什么要这么做？其实从这点做是很容易大家能看出，阿里这几年在技术思路上的演进和变化。以及这中间所衍生出来一些技术逐步逐步成长，在中间都可以看得出来。这是2010年当时我在淘宝，当时我们做预算的时候，这是很重要预算指导的原则，当时确定这去IBM小型机，甲骨文、EMC，这中间很重要落脚主要是技术的投入，希望把去小型机的替代技术可以摸索起来，一会儿也会讲这中间的故事，也不是一蹴而就，这中间有一些背景。2010年我们摸索去小型机过程当中，背后一个思想是我们阿里在转变，转变过程当中最主要一个原因，我们希望以互联网的技术来解决电子商务这样一个应用。

2011年我们去小型机技术逐步积累过程当中，已经开始逐步逐步全面去IOE，这中间已经是开始，如果当年2010年不再购买小型机，那2012年我们不购买EMC的设备，背后是坚定的互联网技术逐步逐步往我们深入系统去IOE的技术。

2012年整个不再过多谈去小型机，我们认为去小型机已经翻过来了，这个随着我们基础技术的整合，这个阿里去IOE技术，正在向整个集团全面推进。同时去IOE，整个阿里去商用化整个技术的进程也开始全面的启动，这是简单列一下去LB设备，其实还有很多工作我们都展开。

整个阿里每年年底做预算，不是简单盘点钱的事，而是我们梳理未来技术一年的规划。很多的项目都是要逐步逐步PK过去，为什么用这些技术，有没有更合理的技术框架？

2013年我们坚定以云计算的思路逐步逐步应用到阿里上去。

总结一下这四年整个的过程，我们简单做一个总结，从最初我们在基础计算积累不够，我们通过付费方式换取时间，我们 买一些高帅富设备 ，解决发展。我们发现这些技术设备解决不了我们问题，我们开始采用 一些商业技术 ，商业技术之后就是 开源技术 ，开源技术之后我们能力在增强，我们有各种各样 多元化技术的思路 ，来驾驭我们整个阿里的在线系统。

下面跟大家说一下去IOE的历程，这个图大家比较熟悉，所有典型的IOE的架构都长的很像，通过前端应用服务器联上数据库的系统。数据库底层通过交互机做接连，存储之间做一个HH的镜像，很多IOE的系统基本上长的大同小异。最初这个系统是什么样子？商品库最初放在一个系统当中，随着商品越来越大，一个系统已经容纳不了那么多，承载不了业务发展，我们考虑业务做垂直拆分，拆分完以后并没有解决我们问题。商品库垂直化拆完以后我们进入另外一个层面，对于这中间疯狂增长，我们疯狂对它进行水平拆分，这时候我们系统进入几何基数，上涨的交易。我们商品每年在往上翻，交易系统也是如此，这是对我们来说成本上面临非常大的压力。

我们很清楚一个IBM小型机，比如说P570、P590，满配的基础上价格大家清楚什么样级别，应该是五六百万的级别。当时市场的售价差不多在这样一个级别，在满配的基础上。这个只是说在这里一个很小的单元，需要这么多的价格，如果是按业务增长速度发展下去的话，这个相当于给某些厂商打工了。所以这是当时我们面临的现状，在OLap层面，现在网上也找得到，当时有那么一阵子甲骨文推淘宝有20个节点的RAC，好像是亚洲最多的RAC的集群，我们转换的时候换了一个思路，逐步放弃了RAC，而是用云来处理我们阿里的大数据。对于大数据底层处理的技术，我们传统的技术厂商技术基因决定这个不能彻底解决我们问题，这种矛盾在互联网行业特别明显。

讲一下去IOE核心的原因。之前在网上一直好像是有很多版本，其实都不正确，我做一下总结。

1、集中式强大单点远远满足不了，阿里特别是当时淘宝爆炸式业务增长应用的模式。所以这个给我们带来很多痛苦。这里举到稳定性的方面，当你很多系统都放在一个强大的单点里面，你一个单点出现故障的话，意味着影响面比较大，所以我们更倾向于这种 分布式 的这种架构。当一个单点出现问题的时候，它也只是影响局部的一部分，而在这个过程当中对局部的单点我们做非常灵活HH的策略，在稳定方面我们碰到了问题。在IDC切换方面我们遇到一些问题，中国IDC切换现状比较恶劣，各种各样条件不太好，对于我们而言经常要做一个事情就是容灾切换，当你应用系统三天两头碰到网络电力各种原因做快速切换的时候，这中间涉及数据库是成百上千的节点时候，你IOE的系统根本没办法满足你瞬间满足快速灵活的切换，这是当时让我们很头疼的点。还有类似阿里的双十一，我们几周时间让我们时间做到几倍这样策略，尽管我们IOE体现有限容量扩展性，但是毕竟这是比较有限的。所以集中式严重的制约了阿里业务的发展。另外秋游一些原因我们也正在面临的，比如说我们技术面临失控，这个怎么理解？比如说在双十一情况下，可能全球范围没有达到这样高程度并发的时候，会出现非常极端的一些问题。而这种问题你如果要求助于那些厂商，厂商也要拿具体业务数据做定制化的开发这中间来来回回时间成本是我们阿里难以承受。

比如说阿里双十一凌晨那一瞬间可能几个亿的交易就过去了，我们工程师到最后除了等待，什么都不能做，那我们做不到这种层面。所以说IOE确实让我们当时的技术面临失控的风险。

2、另外确确实实我感受到IOE的技术限制了技术潜力的发挥。这中间大家可以看到我们有很多技术，即便对这些技术把玩非常娴熟，毕竟是产品技术，这产品有很多底层细节你根本无法掌控。

3、IOE是专用的设备，对机架、电力、网络要求，要单独为它设计。像阿里快速发展，我们那时候要买服务器都是问题，你机房要摆那么过高帅富的设备，我们有很多小型机要进来，要用起重机给吊进来，这个成本难以承受的。阿里去IOE核心原因，我们总结一下大致有这么一些。非要增加一点就是安全。

4、安全。怎么理解安全？大家想想斯诺登事件，成本是我们比较次要的原因。说起去IOE相关技术的难点，当时我们也逐步逐步在摸索过来，首先我们解决是把一个数据库，特别对专业数据库我们逐步逐步要剥离，把数据库当做一个存储来用，不是这中间一大堆的应用逻辑。这中间怎么做事物的拆分，做数据的类别，怎么做数据的路由和，数据安全，规模化运维，异步数据同构，都是我们面临非常实际的问题。

有关去IOE的话题，我们这次有两场来讲，主要从宏观战略方面讲我们阿里为什么去IOE，明天有一场跟大家讲去IOE过程当中相关核心技术细节。这个简单给大家介绍一下我们当时面临一些难点。

跟大家介绍一下去IOE，在阿里内部Kickoff前后的故事。外部环境有这样几点，2009年2010年我们发现硬件技术突飞猛进的在发展，当时PC和小型机的处理能力不相上下。阿里内部我们做服务化，我们把各个应用系统，已经真正以服务化的方式来做了改造，所以对于我们几大C的应用系统，我们可以很确定对某几个库做底层的改造，上层做好服务商松偶合改造。我们2009年11月份做2010年的预算，当时我在预算当中提了一句，我们接下来正在尝试PC技术替代小型机的技术。当时我和我老板郑飞在当年预算，也是把这句写上去了，我们CTO抓住了这句话，既然已经思考这个问题，不如坚定写下来，说以后再不买，并且往这个方向来靠。所以当年的预算就2009年11月份预算其实是我们整个阿里去IOE的发端。中间故事其实都是来源于那一年预算，去IOE从当年的去小型机开始的。

首个在淘宝的核心业务系统上来做去IOE的是我们的商品库，这是在整个阿里去IOE历史上最漫长的一次技术的尝试。我说首个吃螃蟹这样一个项目。它有很重要的意义，它为未来后期整体去IOE的技术，这个过程当中摸索，逐步逐步一些技术上的探索，都是奠定了很好的基础。其实我们整个去IOE方面技术的成熟，主要的摸索其实来自于我们的商品库。它大概经历了三个阶段。

1、我们首先是之前就已经完成了对我们商品库Oracle，做了读写分离，我们当时说把读的流量从我们图库切到搜索上面，虽然有几秒的延迟，当时做这个决定内部压力和质疑声非常大，经过严密评估切过去之后发现效果还是比较好。我们把读的那部分已经切完之后，剩下部分我们尝试对小型机来做进一步的改造。作为预算我们接下来半年进入实质性去小型机的阶段，这中间大概花了半年时间，我们完成去小型机摸索的过程。完了以后我们剩下一年立刻展开去IOE的过程。阿里商品库的去IOE经历了这么几步，首先是读写分离，把读那部分分掉。第二步是我们去小型机，小型机去完，我们紧接着尝试去Oracle和EMC。我们去小型机在业内没有任何前任经验可借鉴的东西，当时质疑声非常大，我们后期做这个技术认证的过程当中我们逐步逐步在这中间积累了信心和经验。

整个列一下我们阿里系去IOE过程当中几个关键事件。我们20101月份启动，大概2011年7月份我们完成商品库的去IOE，分两步。我们差不多花了一年多的时间完成了商品库，可是后面交易其他一些核心系统，去IOE的过程花的时间很短。

这里可以看到一个动作，当我们这个技术逐步逐步积累成熟的时候，我们到后期的时候在推动这个技术战略的节奏是非常紧凑非常快的。随着后期整个数据库的融合，像B2B，阿里金融、以及支付宝都在全面推动去IOE，以至于今年6月4号整个阿里现金流系统，我们广告结算系统已经彻底摆脱了IOE的一个技术体系。

这是当年首批小型机下降的仪式，说是仪式很简单就是拍几张照，冷冷清清，当时我们只是自己觉得这件事情是对的，其实对这件事情关注人并不是那么多，只是一群人一直在这个方向上坚持下去。这是我们几个月前阿里最好一台小型机下线的仪式，可以看到在这个过程当中我们整个阿里技术高管全部参加进来。小型机作为工程放在我们支付宝的楼下大厅供大家展览。

去IOE后的相关技术架构，很简单，一批真正高富帅的机器最后转化为一对PC机。这中间核心思路是真正以随处可见PC的机的技术，替代一些专用集中的商用设备。对互联网行业其实就像是它所需要资源非常多，增长非常快，任何专用设备都有可能拖慢我们设备。

这是一个典型去IOE之后整体的架构，这里可以看到我们应用系统通过我们分布式数据层访问到我们数据，一方面是我们分布式缓存另外一方面是TFS。DB之间的部署是跨IDC部署的，底层做了数据的分布。DBC容灾由我们另外一套系统完成的。调动系统控制整个切换系统，最后达到我们数据层做底层切换。在整个阿里其实我们复杂庞大数据库都是由这样底层的模型堆积起来。

大家可以看到这个里数据的HH，首先大家可以看到就是说在我们这里，在分布式缓存这个我们命中率在90%以上，我们的毒只有10%不到落到DB层面，DB层面整个命中率又会是差不多90%这样一个命中率。就是说这中间如果我一个节点或者中间一块盘坏掉，对于整个上层的应用，对可用性的影响其实是微乎其微的。即便我们一个单点出现故障，我们底层的HH系统可以做到从一个IDC切到另外一个IDC，秒级可以做到数据弥补和检查，在这个逻辑图上可以看得很清楚。

和去IOE相关的战略价值。回过头我们做完这件事我们确实感触比较深，我们感觉自身是受益者。我们有这么几点战略受益跟大家做分析。

首先去IOE整个架构体系赋予阿里非常灵活的技术架构，类似像双十一非常残酷这样业务促销，其实对于阿里而言都相对而说很淡定做业务的扩容。我们做完这个技术是说我们真正技术自主可控起来，在明天我们介绍相关技术可以看到，我们数据库技术有很多数据点我们深入参与，并且从零开始做，无论从存储层面，从分布式数据处理，以及我们规模化研发支撑体系和自动化运维平台，都有大量的经验和产品的积累。

真正完成这件事情以后我们技术可以做到自主可控，同时又很多工程技术人才积累下来，我们现在回过头看这些人才是阿里很重要的竞争力核心之一，可以让我们成本降得最低。

举个例子，刚才我提到商品库，我们可以用原来IOE时代20%的成本把这个容量做到原来5到6倍，大家可以看一下，这中间真正是说我们做了这件事，从成本上可以给企业带来的竞争力。我们经常谈和竞争对手怎么样讲，背后技术带给企业的竞争力，很重要就是说单笔交易我们真正比竞争对手便宜多少，我们完成这个技术改造之后，我们可以用很低的成本支持我们业务快速成长。中间其实需要我们工程师做这些事情。成本解决我们有很多技术环节都是我们人深度参与进去，碰到斯诺登事件的时候至少我们觉得相对安全。

简单给大家介绍一下，这里不展开，去IOE相关的一些核心技术。首先是存储技术。存储技术我这里给大家辟谣。说到阿里去IOE，就说阿里用mysql，错了，阿里去IOE，mysql只是其中一个，有Oceanbase、RDS。在大数据库不用考虑一致性的问题，其实对于大型分割系统而言这些都是你要考虑，这中间很多技术点需要我们做这件事情的工程师逐步逐步解决的问题。数据流解决什么？真正个别应用系统的数据同步，在IDC情况下怎么做到高存储，这个怎么快速的存储这是要解决第三大技术。

第四个技术原来只需要你搞搞几十台的Oracle设备就可以，现在你面临数百台，数千台，对于运维体系，都是全新一套体系，你需要有一套架构可以架构它，你需要有一套平台，对研发支持的人员把这个复杂性对上层分装好，这里我们研发体系、分装体系会做很多技术。阿里并不是以Mysql技术，还有很多技术。

我们去完IOE相关技术的沉淀，我们做完这些这样以后我们有很多技术沉淀下来，这是为阿里进一步扩大业务范围积累很好经验和基础。同时很多的经验在我们来看，阿里去IOE的经验属于全社会的经验，我们非常希望把我们中间的经验和思考，在以后有机会合适的情况跟大家做这样一个分享。

小结一下，首先阿里去IOE是战略性的系统工程，会深远的影响到一个公司。它需要我们真正的技术人员，是以真正的说，不是像甲方的心态，所有东西都是有人帮你支持，而是把所有事情当做自己的事情，全方位在架构和细节层面把控住这个事情。

IOE是风险极大，受益很高的事情，做成这件事需要很强组织上的保障。比如说它需要有一个坚定的在这方面可以走出去，逐步逐步拿结果的团队，无论是技术上，以及碰到困难，都能够逐步逐步解决，影响相关团队往前走。

另外做这件事情需要我们决策者坚定支持，当你推动这件事情你一定面临很多方面压力，阻力同样也会非常之大。所以这需要坚定支持者，受益也会很大，做完这件事情，无论从成本，还是安全性，技术的可控性，以及团队能力积累都是非常明显的改观。

下面说一下体会，我觉得这几件事情做完确实说大家外面风言风语，有很多不是很正确的观点，从我们角度来说想和大家分享几点体会。

1、去IOE对某些厂商会有误伤，但是对于阿里而言，我们本质上以自主可控分布式的Commodiry、PC架构代替集中专用的IOE架构。我们做这件事情不是为了做而做，而是说我们也不是简单说说为了降低成本，或者因为某些是外国的技术，我们就不用。某些国内技术阻碍我们阿里业务发展我们同样会干掉它。

去IOE对于个人的技术成长，有非常明显拉动作用。这中间因为这毕竟是一个技术方案的转变，这其实设计到一个个人的技术的方向和企业的技术方向，如果说不是很好的切合起来的话，有可能你会成为一个阻力。特别是在快速变化，业务快速推进这样一个业务场景当中，就是这两个方向怎么切合，或者我们技术人员如何站在最高的角度帮助企业做转型的推动，是推动技术的变革非常重要的。

去IOE水很深风险很大，现在网上有很多人说开源怎么着，在我们看来开源只是解决了你入水的时候零成本的问题，你后期要驾驭它的时候你会面临很高它的运维以及发展的成本。这是需要很强的技术团队才能帮助你Hold，如果你没有做好准备之前不要轻易的去IOE。

另外就是说在我们看来并非所有企业都适合去IOE，但是规模化的企业我们建议去IOE，理由跟阿里类似。当你企业大到一定程度，当你企业快速发展的时候，你面临问题跟阿里快速发展面临问题都是大同小异的。

去IOE相关技术难以复制，很难像盒装软件一样我给你一个光盘你回去安装一下就立马干掉了，也不是一个简单的数据迁移，从A迁到B你这个就完成了。这需要做很多很多数据梳理和技术改造，人员在底层要很多技术梳理。去IOE技术阿里内部操作的，很难复制的。在我们看来做这个事情需要一个平台，这个平台如果能够有对接去IOE技术，这个会使你去IOE的门槛和成本降低。

做这个事情要耐得住寂寞走下去，你碰到阻力都会告诉你很难，你要放弃很容易，如果要一步一步走下去确实你需要做很多的功课，要内心足够强大才可以做这件事情。在宏观层面的去IOE，我们经历过的一些事情，中间一些思考和一些观点，简单跟大家分享一下，明天会有一些相关核心技术环节，感兴趣的同学可以一起听一下，谢谢大家！

参考推荐：

阿里周宝方：集中式严重制约是去IOE的核心原因

2013阿里技术嘉年华：阿里去IOE实践

2013阿里技术嘉年华： 阿里分布式数据库服务原理与实践

原文： 阿里“去IOE”核心技术剖析