在11月30日-12月1日举行的电力行业信息化年会上，阿里巴巴数据库负责人周宝方做题为《阿里“去IOE”战略》主题演讲，分享了阿里巴巴在去IOE过程中的经验与技术演变。以下为文字实录。
阿里巴巴数据库负责人周宝方
大家好，我先简单介绍一下自己，我在阿里的花名是后羿，在阿里大家知道花名文化，在我们内部通常用花名相互称呼。就像刚才刘总介绍的，我过去十多年主要是数据库方面做一些事情，过去四年主要做一件事帮助阿里实现去IOE，今天重点讲阿里从以前的基础架构，碰到的问题及演变。
首先简单介绍阿里过去几年做预算过程当中一个指导原则，很多人可能不是很清楚，为什么把这个提出来?其实每年年底我们在做完双十一，双十二之后，随机起动一件工作，从集团层面做未来一年预算制定和规划，我们会把预算计划提交我们CTO内部去，其实不是简单对这中间财务做盘点，而是未来一年整个案例技术走向、产品规划中间来做一个系统性盘点，所以其实去IOE也是来自于我们那一年预算盘点。
2010年我在淘宝，当年做预算时候，我和我老板在制定预算初稿过程当中，提那么一句，我说我们现有这种系统架构采用了大量的IOE系统，其实我们可以来尝试一下用非主流方式，比如说PC来逐步替代我们架构，当时只是在预算初稿当中提一句，但我们CTO是希望能够明确写下来，作为我们未来几年预算很重要基点，并且提出来说既然有这么考虑，不妨我们就决心迈更大一点，以后再也不采购小型机，这整个过程作为阿里去IOE发端，一会儿也会讲到。
作为第一年也就是2010年，刚才说预算2009年年底，2010年时候我们制定指导原则主要是解决小型机问题，这里中间提出来，在去小型机过程中我们也提出逐步积累，对于数据库、以及EMC高端存储经验积累。大家看2011年时候，其实从我们整个一个去IOE来讲，去小型机技术已经掌握，2010年时候全面推动，IOE全面技术替换，背后主导思路希望回归互联网根本，以互联网技术解决电子商务性应用场景解决。
2012年时候，我们基本上解决了当时淘系主流核心应用场景的去IOE工作，随着后期我们对支付宝、B2B以及阿里整合过程当中，整个团队上升到集团层面来全面推动，在各个领域来推动战略。
2013年时候大家可以看到我们已经不再提去IOE，我们内部已经基本上把这些问题已经解决了，剩下其实已经只是一些长尾，或者一些小应用，那推动云计算战略，或者更多让内部IT逐步对接到云计算平台上来。
那经历这几个阶段，大家看一下阿里自身技术经历了几个阶段，从最初商用技术，IOE，商用技术，在我们企业发展一个起步阶段，是以金钱来换取时间，随着后期自身技术积累一定程度，我们逐步考虑以自身技术来解决这些问题，从最开始开源入手逐步过度到自主技术，当自主技术逐步成熟时，自主技术逐步往云计算平台走，最终云计算支撑整体庞大业务。后期无论是开源或自主技术也好，云计算平台是我们阿里主流的一个技术基础。
刚才从过去4年我们预算指导原则角度来让大家看到，整个这几年我们技术发展的一个演进主线，现在归到去IOE整个历程，这张图可以看到，网上也有照片发出来，这是一个传统IOE架构，这个架构大家可以看到基本上每个公司大同小异的，在这里我们可以看到，这里前面是，中间一排黑色小型机，中间是网络设备，在下面一层，这是高端存储。这里一台小型机，IBM小型机差不多500万到600万之间，在下面是高端存储，拿IMC来说，一台价格大家也猜一下，也同样差不多价钱。我们这个核心系统，每一台如果正常跑起来，都需要做HA，必须让这个设备再乘以2才能够跑下去，这是常规配置，你还没有提业务发展过程当中你需要对接数据仓库，还没提到软件费用，以及这中间互联过程当中这中间交换机，以及对网络端口占用和带宽，以及IDC额外付出这些费用。
从淘宝应用角度来看，最初淘宝在发展之初所有应用都放在几个集中库当中，随着业务快速发展，这中间有一些商品系统发展非常快，每年是以翻一番速度增长，我们首先在这里碰到瓶颈，怎么解决?最初尝试垂直拆分，我们以应用的纬度来逐步把应用放到各个库当中去，每个库基本上是以IOE价值来支撑，那这中间还有一些体量大的应用，比如说像交易、商品、店铺、用户，他们发展速度非常快，尤其以商品库为主，我们解决垂直拆分发现还没有解决问题，类似于像商品还在每年翻一番速度增长，意味着第一年要一拆二，第二年二拆四，再往后每年再翻一番，这里列出很少一部分，大家可以看每一个点刚才500、600万加500、600万乘以2，再乘以上面很多软件费用，大概是2000多万一个结点，如果大家考虑整体规模到最后几何奇数往上长，如果是这样走下去的话，其实企业发展利润基本上保护费已经交出去了。
那回归到我们去IOE的核心原因，首先是说为什么我们做重大决定?大家可以看到，IOE这种体系他是一个强大单点，这个点他处理能力很强，似乎看起来也具备很强这种稳定性，扩展能力也还可以，但是你可以想到如果说是整个一个淘宝，这么大应用，都依赖于一台机器，一两台机器，网络他会出现波动，我这个电源也有可能被拉闸限电，或者CPU都会出现问题，如果出现这种问题，你要影响到用户稳定，如果以这种体系一个库里面，比如说1亿两亿用户，相当于所有鸡蛋都放在一个篮子里，影响面相当大的，这其实是我们最初，在稳定性方面所面临的一个非常急迫问题，一个点出现任何波动影响面都会非常大。
其实从ITC角度来说，我们当时也面临一些切肤之痛，我们经常与运营商打交道，对于互联网企业经常会有挥之不去的问题，比如大家用的微信，就会突然收到消息说某些城市，因为施工挖断光缆导致一些应用要停机多少多少小时，或者某个城市因夏天政府要限电所以机房必须关电，这种情况阿里非常常见，甚至说有的时候网络，突然没有征兆断一下，对于我们IBM系统的话，有可能某一个省大规模下线，或者说空调设备不给力，对我们而言可能需要做到一种能力说，无论哪一种异常情况，我们应用随时随地里做快速跨IDC这种切换。那熟悉我们IOE系统人可能很清楚，当你的SGA，把他开辟到大到超过100个GE的时候，你要赶紧关闭，并且重新提供这个过程，就有可能需要十多分钟，还没有算上当你应用规模大到一定规模时候，你业务重新来切换过程，这种人力协调这样成本，你动不动有可能用半个小时或者近一个小时就拿双十一前半个小时，因为之前也有一些数据放出来，前几分钟就是几个亿，十几个亿过去了，那如果说淘宝断网一个小时两个小时，有很多依赖于淘宝谋生计一些人，可能他收益人会下降，有可能会演变成群体事件，其实对我们而言，这种ITC风险，我们是需要IT架构上来找他们，这其实带给我们不测因素。另外类似于双十一很短时间系统容量扩大原来好几十倍，所以这个是一直制约着我们业务快速前行的一个隐患。
另外商用的产品，对于我们而言，他拥有很好的用户体验，但是唯独当你出现任何底层问题，你需要依赖厂商才能解决，就像我刚才举例子双十一前面，前面30分钟如果出现任何一个问题，我们需要借助厂商力量才能解决黄花菜都凉了，所以这反过来要求我们需要很强把控能力，能深入进我们交换机也好，网络也好，我们的工程师在这儿中间把控起来，但是商用设备摆在这里面给我们黑盒子，他里面怎么运作的，我们可能拆出他原理，但是搞不定他。其实有很多时候，其实会有这么一个情况，当我们碰到问题的时候，这厂商拿着我们数据回去，然后几周时间发给我们，这中间周期非常长，从这个过程中可以看到一点，他们所设计这种场景，其实已经触及不到像阿里互联网这么大规模高并发场景时候，其实他需要典型用户推动他产品进步的，所以在这个时候相当于我们是花钱替别人交学费，所以当我们的开发人员会受到限制。
另外说IOE这些骄气设备，他对环境影响，对环境要求非常高的，他需要专用的机房设备，要铺上钢板，甚至要专用电源，集中部署的时候，对于已经建成机房甚至破门而入，要敲大的洞把他掉进来，就这种情况，如果说应对双十一突然某一个应用场景，要临时做一个决定要推广一个很大促销的话，我们很难做到说是临时即兴系统进行扩容，应对业务快速变化，所以专用设备对我们而言成本非常高。
第四点大家可以想到刚才一个点，就是数千万费用，这个点在阿里有几十个甚至上百个，如果这条路走下去这是一条不归路，所以整体来看成本是我们做这个决定，最初考虑一个因素，当我们做完这个事情之后，回过头来看成本恰恰是最次要因素，这套体系严重拖后腿。
这里简单列一下，从非常好用的商用设备，到开始DIY去做自己一套技术架构，这里讲一下什么原因让我们做这件事，刚才跟大家提到一点在做预算会上有那么一段故事，大家想想，虽然看起来从故事来看，貌似有一定的偶然性，但是联系到我们刚才所碰到各种各样的切肤之痛，业务实际情况已经需要直面很多传统方式难以解决各种难题时候，其实回过头看，我们来做决定有着必然性，从外部环境讲PC机和FLASH技术是成熟的，一台PC机他处理能力与以前一台小型机处理能力不相上下，而Flash技术性价比也越来越高，这些已经为我们做这个决定创造了很好外部环境。
另外我们在2009年内部做应用改造，改造过程中把一些相对来说比较通用一些技术中心化，以强有力的方式去对接，各种各样应用，比如说我们在中间已经沉淀下来，我们内部几大C，IC、TC，IC是属于我们商品，TC是交易系统，我们把这些很重要核心往下沉，把他具体应用剥离起来，把他做成很强大一个服务，所以这些外部环境逐步具备时候，已经可以开始做这些事了。
简单说下第一个做去IOE系统，也就是商品库，外部觉得阿里做这件事情轻而易举，但我们内部争论非常大，首先做这件事情从全球范围之内没有成功经验借鉴，包括我们第一次做决定说要用PC技术代替小型机时候，所有人都反对，大家觉得这种决定不靠谱，当你做这个决定，其实意味着我们要在很多技术可行性上要做非常完备的铺垫和调研，我们分成三步来完成我们最大商品库去IOE，完成这个之后我们认为已经基本掌握整个去IOE相关核心技术，首先把一部分读力量拆出去，另外去小型机过程当中同时去IOE，其实对我们来说难度很大，先把小型机去掉，当我们已经在积累信息时候逐步往前迈。
简单列几个数字，在商品库解决这些问题我们哪些收获?第一，我们后面连续两年几乎可以做到稳定性100%，连续两年对外服务从没中断过，这个难度要求非常大，传统企业几乎没有一个企业能做到。第二我们成本，用原来20%成本把容量做到原来500%到600%，这中间的差距大家一比较就可以看出来。另外类似于像双十一我们整个系统扩容非常简单，甚至我们大部分可以让机器去干，自动化支撑体系中间发挥非常大作用。
这里简单列一下我们去IOE过程当中对于阿里几个很重要一些关键结点，从这张图上可以看到我们的从起动第一个，我们从商品库分几个完成去IOE，这中间用大概一年多时间，一年半，但是后期我们完成了，我们积累经验之类，后期的其他核心的系统，我们的节奏推进非常快，并且随着后期我们团队整合过程当中，就在几个月我们阿里最大现金流系统，一天大概数亿资金在这上面流过。
这里几张是我们，前面一个是淘系在做去IOE，其实很简单就几张照片，但是最后我们的，这是支付宝最后一台小型机下线，当这个点完成之后，因为阿里所有系统都跑在PC机上，这个PC机和市场上买的普通PC机，PC服务器没有任何区别，他就是标准机，没有任何复杂技术在这中间。
我们把原来一大堆高富帅设备最后变成只需要买这种非常简单标准PC机，我PC机像IBM买，向华为买，华三买，任何一家谁价格低，只要符合我标准都可以采用它，这个是简单去IOE后的逻辑，这个图上，基本上可以看出我们怎么样解决，稳定性和不丢数据的，这里不展开。
因为大家可以看到，刚才跟大家讲其中一些故事，当我们做完这些事情以后，我们总结去IOE带给我们相关战略价值，首先做完这件事，我们业务架构变得非常轻便灵活，我们业务不会被任何一种技术所绑架，这靠我们逐步摸索一套技术在自主可控方面，真正能够给阿里做到保驾护航;另外当我们解决这些问题之后，自然而然有一大堆基础工程技术沉淀下来，一些产品沉淀下来，以及培养一大批人，从长期业务、企业发展来看，这些工程师这些产品是非常重要一个战略资产，同时从安全性角度来看，因为之前大家所知道棱镜门事件发生之后，大家知道有很多黑盒子摆在你面前的时候，你根本不清楚里面是怎么运作的，那最后一个就像刚才说成本，我们花很少的钱去解决问题，同时当我们解决这些问题之后，发现所获得能力用钱远远解决不了的。简单列一下，我们做完这件事情之后沉淀下来相关核心技术，第一我们自己的开源系统上的积累，以及自主分布式系统上积累，甚至云方面的积累都已经沉淀下来，另外我们已经掌握一整套把一个强大单点数据能很好分配到一个分布式系统当中，并且在这中间已经掌握一套方法，在分布数据库里这方面保障问题，当你系统面对一两个强大单点时候，拆到十百个上千个甚至更多系统当中去，你需要一整套，完全另外一种思路来驾驭他，你的技术保障体系和支撑平台这中间是需要颠覆性的思考。
做一个小结，现在很多人很简单肤浅看待这件事情，好像这就是一个系统从A系统迁到另外一个系统去就能解决，其实远远还不仅如此，他是个战略性系统工程，当我们搞定他的时候，我们发现公司思路发生很大转变，另外他需要我们的工程师对全方位在架构以及技术细节上能够Hold得住，风险大家可以想象非常大，我们做这件事情基本上前无古人，没有任何现成经验可供我们借鉴，事后发现我们收益非常大，要做决定需要强组织上保障，阿里一直我团队主导这件事，他对传统技术的一种颠覆，要做这个事，他影响范围非常广，我们需要决策者来认可这个事，并且支持，你能够想象到有很多反对声音，这个收益刚才提出过了，有一些现在大家在外面也能够接触到或感觉到一些观点，在我看来是有为阿里做这件事情初衷，从我角度借这个场合跟大家分享几个观点，第一有很多人在提阿里去IOE就提说My SQL，远不止这样，阿里有一整套非常完备很成熟的自控技术，而开源技术仅仅是补充而已，所以我们不想为My SQl做广告，第二有很多人强调阿里这件事情有很大的隐性成本，甚至有些人用小数点后面1.7万人解决这件事情，这是严重夸大事实，因为阿里工程师一共都没有1万人，也就8、9千人，想通过夸大成本来左右很多人一些判断，另外阿里在做这件事情的时候是在通过，因为每个应用他都是有一个周期，一个应用他从上线之后再过几年面临很多功能不符合要求需要改造他，我们这种利用，周期性改造机会完成技术架构改造，并不是为了去IOE而去IOE，我们顺应软件自然周期，在这个过程当中完成我们技术战略转型。
另外去IOE在我看来，用简单的国产化IOE去IOE我认为价值不大，最终解决还是要怎么来解决一个强大单点带给企业风险问题，如果说是用国产IOE设备来简单替换的话，我相信对于一个企业而言他还是没有摆脱这个问题，没有解决这个问题。
另外也是有几点体会，也就说阿里在做这件事情，他本质是以一种自主可控的这种PC架构，非常廉价PC架构，来解决规模化计算问题，并且在这中间会有余量的对外进行计算输出，其实这就是云，另外提到云，我们可以看到基本上国内很多人对外宣称自己是云计算服务商，借着旗号推自己设备，个人技术成长价值，特别对技术人员需要公司发展整合起来，做这个事情确实门槛非常高，而且风险很大，很多人觉得好像开源面临很高成本时候，开源就很好救命稻草，其实从我们自身经历看，开源只是解决你入手时候成本为零，但是你后期要维持和发展他的时候，你发现成本不低的，成本不是在钱上，而是说对技术要求非常高的。另外我们也不激进认为说所有企业都需要和我们一样去IOE，我觉得不现实，但是我们还强调建议，规模性企业需要好好考虑一下，因为你所面临问题和阿里大同小异，那去IOE，我们现在逐步逐步也在接受这方面经验，云计算平台认为更适合去IOE，这中间有兴趣来做这件事情一定有非常坚强信念走下去，他有很多阻力，讲到这里基本今天要讲一些观点基本结束了。谢谢大家!
提问环节
提问者：非常感谢周总，我们阿里提出去IOE战略，这一点非常认可，我想问一下，阿里在去IOE过程当中也是很谨慎的，先去I，可能再去E，再去O，阿里做这个事情过程给我们一些经验，比如去I时候，OE怎么配合?这个过程能给我们分享一下?
周宝方：我可以大概总结一下，其实去小型机本质上把单点去掉，一个单点对外输出计算能力相对而言比较大，随着新的硬件技术逐步起来之后，我们就是要解决说，这种廉价技术能量同样强，这中间用到我们数据库水平下面这些技术，当你在一个单点情况下，你数据一致性不需要考虑的，但是你被拆到很多系统当中去的时候，你一致性的问题一定是解决，甚至你影响业务风险很大点，你如果解决不好他，有可能这个系统风险就非常大，这需要很小心翼翼的去做技术上梳理，当然这中间有很多经验，如果各位感兴趣可以找时间跟大家做这方面分享。
提问者：我想问一个简单问题，目前双十一这样一个交易规模，问一下您前面谈到采用分布式计算，是不是放到几个数据中心，或者给一个概念认为多少台PC服务器来支持到2013年这样反馈量，这是第一个问题。第二个问题我想了解分布式计算，除数据库那一面，你们用自己研发其他技术?
周宝方：第一问题具体数字不能告诉你，但是我可以告诉你量级，应该是上万，但是我们很多技术可以弹性化，也就说我们做完之后，当我们扛过这个高点，有很多可以突出来。
提问者：是淘宝自己还是电信的?
周宝方：以合作为主，另外你刚才提到了说，你想问这中间开源为主，还是我们自主技术为主，其实现在PPT上提到，我们当前是开源技术和自主技术以及云计算平台都是并行的，那逐步我们会以自主技术为主。
提问者：咱们用分布式计算，从传统观念来说认为这种需求没有必要?
周宝方：这个问题其实质量很高的，其实是这样的，确实在分布系统当中，我们在做任何数据部署时候，其实已经考虑到跨IBC的部署。
提问者：现在已经实现还是考虑?
周宝方：基本遵守这一原则。
提问者：我想问一下阿里云这一块，在做过程中你们现在除结构化数据去O这一块，非结构化数据这一块使用，尤其是跨IBC怎么样提高效率在哪方面做应用?
周宝方：对于非结构化，如果你关注阿里技术的话，阿里在云计算对外输出时候有一个飞天平台，飞天平台有几块，类似于OTS，已经做对外商用计算输出，这是自主技术，另外其实我们也有一些团队在开源存储领域做投入，所以在这一块其实优化也好什么，这个其实不大会这么说，按特定场景，不会特地为了优化而去优化，当他解决我们问题时候。
提问者：解决应用需要，并不需要产品?
周宝方：其实阿里技术都是解决场景问题为主，就目的非常强，当我们使用过程当中你碰到任何问题，有信用问题，有可用性问题，已经满足不了我们应用，就会提一个项目解决他，目的性非常强，当然如果说是确实我们为了考虑节省IDC大规模提升，这种项目也有。
提问者：阿里去IOE外界很神话，学习去IOE也有一段时间，认为最难去O，您在去O过程中，肯定除一些技术方面攻克，有一些从管理层可能会遇到一些难题，您觉得这些难题积累方法论具不具备可推广性，在其他企业里，是否有技术团队，您这边总结这些方法论，能不能完成去O这项工作?
周宝方：其实很多人是会来区分说是去I、去O去E哪个最难，对我们来说我们有很多项目，其实你尽管看到在用，但是替代他很容易，这中间背后很核心思想怎么来看待数据库?在我们来看数据库他其实就是在线存储，当你大规模使用这种情况下，你是在刻意更多在使用他的一些，就说某些产品所特有有些，其实你是非常依赖他，我们更多去O过程中对存储而言，对数据库而言，我们更多把他当做存储，把他当做KB系统，而其他更多业务从数据当中截网拆出去，比如说背后存储过程摘掉他，其实很多人没有经历这种场景他觉得很难的，但其实从我们角度而言，其实有很多，其实没有想象当中那么难。
