有一个传说，以前叫做去IOE。
“2015年11月11日20:00，浙江移动手机营业厅充值1折秒杀活动顺利结束，DCOS平台充分展现了其在应对业务高峰时的能力优势，顺利通过双11考验。”
很显然，去IOE的传说已经在浙江移动变成了现实，那么运营商如何实现了自己去IOE的理想呢？
能够改变世界的，都将是伟人；
能够去IOE的，都不是一般人。
再次纠正去IOE认知
对于在O领域摸爬滚打了10多年的王晓征，现在是中国移动浙江公司信息技术部副总经理、中国移动的知名IT专家。11月19日在首届“天玑数据2015精英论坛”的演讲中再次提到去IOE认知与哲学，在他看来去IOE不是一种风气，而是一种真正的实践与学问。
从各种信息表明，移动、联通、电信还是都有不同程度的去IOE实践。但这种实践的过程首先需要有明确的认知，IOE架构的特点霸道的地方在于，基于向上扩展(Scale-up)技术的高端设备以及围绕着它们开发的专有硬件、大型数据库和商业中间件。当前用户纷纷开始云计算实践，IT系统云化的本质是以云计算技术为驱动，基于分布式架构，将系统进行基础软硬件标准化、应用软件服务化改造，从而打破信息孤岛，实现资源共享、动态调整，提高资源利用率、降低建设成本。
王晓征再次纠正业界存在的去IOE认知，现场侃侃而谈。
不论去IOE对不对，先谈一谈对定义的理解。去IOE广义的理解，是要去掉小型机、商业闭源数据库、高端集中式存储阵列。以IBM、Oracle、EMC为代表的传统IT巨头提供的是整体解决方案，去IOE的本质是“分布式+开源+ Scale-out”架构替代“集中式+封闭+ Scale-up”架构，从而转变成彻底的云计算服务模式。
思路明确了，方向走对了，去IOE目标才能逐渐靠近。
不过，即便去IOE的目标一致，但隔行如隔山，每个行业的去IOE还是有许多不同之处的，如果拿同一个标准和方法去套用每个行业，最终的结果和拿着框框买鸭蛋一样。
阿里去IOE不具备普世性
去IOE是来自互联网行业的概念，由阿里巴巴公司于2010年最先发起。必须看到阿里巴巴的去IOE方案绝对是一种创举，但也得认识到它不具备普世性，具体情况具体分析才是王道。以去O为例，盲目去O是莽撞，就像七伤拳，打得越多伤得越重。
这里需要指出的是：阿里业务爆发性增长，对系统的扩展性具有极大的需求，并且商业产品的采购以及服务成本高，同时，阿里云是公有云，需要采用开源产品降低成本，才能展示实力，加上阿里也有自己的IT技术资源与积累。可见，阿里去IOE的驱动力很强，这是刚需，也有自己的技术能力去搞定开源与IT系统的事情。
三大因素驱动运营商去IOE
相对来说，作为传统的运营商，需要的是稳定可靠高效的IT，又是什么驱动力让其也要去IOE呢？
王晓征分析认为运营商去IOE来自几个方面的原因：
首先，我们都处于一个移动互联网时代，像运营商这样传统行业的IT系统也不可能独善其身。定会遇到各种互联网流量冲击，其中因业务驱动带来的诸多挑战也是其中的原因。这就需要建立分布式的开放架构，实现系统能力线性扩展，有效支撑未来业务发展，确保系统架构的先进性和能力领先。
其次，是运营商自身的技术能力驱动。即使运营商没有阿里那样的技术研发能力，但像浙江移动也一直考虑在合理情况下是不是可以降低对供应商的依赖度，使用一些更开放的架构去解决移动供应链的问题。最终实现技术内化，加强对核心能力的掌控。
再次，也是成本问题，运营商照样需要开源节流，降低成本也是大家考虑的重点之一。但成本这个词有着很多的内容，并非价格就可以代表。这就需要考虑引入标准化通用基础设施和配套的新一代技术架构，优化投资和运维成本结构，提升技术掌控力，提升整体效益。
再者，运营商都属于国企，信息安全和社会舆论都很重视。有些事情阿里可以做，但运营商不能做，这就是政策原因。但两者去IOE发展的方向是一致的。
上面一张图，是否让你秒懂运营商和阿里去IOE的驱动力？呵呵
对于阿里，对于运营商，大家对于去IOE有着不同的驱动、不同的能力，必然带来不同的选择。如果选择相同，就需要想想是不是哪里出了问题？
既然去IOE已经成为一种选择，那么到底该如何一个一个地去I、去O、去E呢？其中的技术难点在哪里？有何良策可依呢？
去I：技术架构是关键
小型机作为IT系统的主要计算设备承载了大部分的业务，但从扩展性、性价比、核心能力掌控等角度而言已经不适宜当前发展。X86单个CPU处理能力一直在提升，目前已达到或超越小型机单CPU处理能力。应用了分布架构和云计算技术，是否可以用一个数据中心去替代某一台大机？这在理论上是可行的，不过，应用采用分布式架构，提升处理能力，必须对应用代码进行改造。
比如在近年来运营商做的很多核心系统云化的尝试本质上也可以看成是一种相对私有化的、有限度的云计算架构创新。一般的做法是采用传统的IT架构思路对应用进行云化改造，底层往往是基于虚机化方式去实现IAAS层的标准化，然后将应用进行私有化的分布式和集群化改造。这种路线的进一步演进的必然结果就是DCOS的横空出世。
三条路线，简单明了，亲们觉得这三条去I路如何？
那么，去I技术路线就非常明确了，应用层确实可以替换成廉价X68服务器，不过需要指出的是任何指望应用层完全透明的云化改造都是“耍流氓”，云化必然带来对应用的侵入，无非是用什么技术方案如何侵入的问题，理论上应用侵入越小，云化就越不彻底。（比如常见的将应用简单迁移到虚机，应用伸缩完全依赖于虚机的伸缩，这就是一种非常原始的云化方案）。数据层也可以采用X86服务器或者是数据库一体机来实现云化改造，分析型业务则主要迁移到大数据平台，基本上就是这些基本路线，无非是大家根据什么情况去做什么样的选择。
总之，去I主要难点在于技术架构，应用层会涉及部分代码重构，而数据库层则需通过数据库云平台等新技术手段实现去I。
延展几句话，IOE架构的基石是稳定的基础设施，去IOE架构的基础是不稳定的基础设施，那么就需要在一个不稳定的基础设施上建立一个稳定的系统，同时没有强大的软件支持就很难实现。比如浙江移动与天玑科技联合研发的DCOS（数据中心操作系统），以分布式集群资源调度（Apache Mesos和Apache Hadoop YARN）为基础，结合容器（Docker）技术构建的一个标准化的高效平台，支持多种计算框架，具备敏捷开发、快速部署和弹性伸缩的特性。
浙江移动DCOS技术架结合行业主流技术方案，通过关键技术选型，即以容器为基础封装各类无状态应用和运行环境，以Mesos为核心实现容器资源的分布式调度与协调。DCOS已经成为了浙江移动的第三代PaaS中的核心组件。
为此，今年双十一期间，DCOS的首次实践在浙江移动手机营业厅充值秒杀活动中，成功应对业务高峰，顺利通过双11的实战考验。
去E：SDS代表了未来
传统高端集中式存储是目前运营商IT系统中数据存储的主要介质,但从扩展性、性价比、核心能力掌控等角度而言已经不再是用户的不二选择。
去E主要难点仅限于技术架构，对应用基本无影响，但是进度依赖于技术手段的成熟度。
看完上图后，去E你们觉得还有什么路可以走吗？
去E需要在存储性能、可靠性和容灾方面考虑对策。传统架构中，在IOE架构中的存储提出了相当多的可靠性要求，既要高性能，又要稳定和可靠，还要能够支撑各种各样数据安全的复制。从表面上看去E似乎也都有出路，比如说数据库在OLTP的场景下往往可以采用数据库一体机，当然也可以用SDS或者分布式文件系统去搞定。
其实，分布式文件系统与SDS在某种意义上有着类似的架构思路，说到底E针对的就是数据，无非要在平衡CAP原理的情况下，用各种各样不同的技术路线来解决数据的安全问题，这是基本思路。
王晓征认为，去E最终可能是一件比较靠谱的事情，但过程具有挑战性。
为什么呢？
实际上，如果一个产品采用了封闭架构，那么从理论上说，这种架构对供应商有利，而对用户不利。因为供应商往往会搞定整个产品的解决方案，而不会为一个架构创新。
传统存储采用了一个集中化的架构，很难想像HP和IBM的存储是否可以互换硬件？那么如何才能对用户比较有利呢？目前的一个大方向就是采用标准化硬件搭建，借助软件定义存储去实现。可是，事情又说回来了，市场上有那么多SDS，用户怎么知道哪一个厂商SDS经过了商业化定制，真正能够稳定和安全。因此，这对实际要采用SDS的用户来说算是一个很大的挑战，可见，SDS代表了未来，然而前途是光明的道路是曲折的，对用户和存储厂商都是一种挑战。
去O：四大误区与四条道路
去O是去IOE中争议最大的一个问题，现在大家对去O存在4大误区：一是认为去O能省成本；二是认为去O能降低对供应商依赖；三是认为去O是解决数据库可扩展性问题的主要途径；四是认为去O主要问题在于数据运维。
从运营商角度来看，如何纠正去IOE这四大误区呢？
一方面，去O费成本，去O肯定会导致成本增加，但操作得当可以提升核心能力掌控；
二方面，去O很可能会加大对供应商依赖，简单去O会降低对数据库原厂的依赖，但会增加对新数据库以及应用系统开发商的依赖；很少有哪个数据库的生态环境达到O记的水平，而良好的生态环境正是降低对原厂依赖的关键。如果连O的掌控都做不到，去O换成任何一个数据库，很可能更掌控不了。走都走不好何谈去跑？
三方面，去O主要困难是数据架构管控能力，因为去O的主要困难不是新数据库的运维，而是数据一致性和性能方面的挑战，本质上是数据架构管控的争夺；
四方面，解决数据库扩展问题不一定要去O，对于数据库扩展问题，可以通过Scale-out+Scale-up 等多种技术手段解决，不可一概而论。
Oracle是一个最强大的关系型数据库，它的单点处理能力、数据安全性和开发支持能力等都是比较强的。想要把单点处理能力解决掉的话，当然数据库一体机的Scale-up方案是一种选择，不过，从Scale-out角度上说，就必须要走分布分表的方案。
其实，阿里分布式关系型数据库服务(Distribute Relational Database Service,简称DRDS)本质上在走这种技术架构，但是这种技术架构对用户应用有着很大侵入，这一点必须任何到。
去O的数据库产品选型上，想要彻底去除国外商业数据库，使用O以外的商业数据库来实现去O，这是投机取巧的选择，不具备太大的意义；采用纯国产数据库，需要审慎对待，国产数据库在企业级应用环境下的稳定性以及性能还未得到长时间运行验证，风险高，同时选择国产数据库，会进入到产品的细小分支，后续支持力度可能会存在问题；国内厂商收购的国外数据库，其本质暂时仍然是国外数据库，国人完全掌控需要一段时间；采用开源数据库，叫好不叫座。开源数据库是互联网去O的主流选择，但需要较高的技术掌控门槛，然而，对于开源定制版数据库，相对靠谱。本地自主掌控运维优化能力，把代码级能力交给合作伙伴或体系内自主研发团队，实现合作共赢的方式。
目前，MySQL和PostGreSQL是业界去O的两个典型选择，但是在维护以及开发维护均有较大差异。PostGreSQL提供的维护支持功能丰富，适合大型数据库系统，而MySQL则较为简易、灵活。
PostGreSQL在表结构、SQL语法支持、程序代码支持上更贴近Oracle，开发人员更易接受。因为PostGreSQL世界上最大的开源数据库，具备很多类似Oracle的优点，比如优化器强大、稳定，支持复杂查询，支持多种表连接方式，维护调优工具丰富。
基于这些分析和对比，去O可以有四条路可以走：
一是直接采用开源定制产品进行替换，比如浙江移动使用的大云RDB产品，以开源PG-XC为蓝本，在软硬件层面进行优化定制；
二是打造统一数据路由Scale-out平台，分库分表，提升横向扩展能力；
三是立足于Scale-up数据库云平台，持续研究创新，提升单点硬件的支撑能力，为去O打造硬件基础；
四是打造数据架构管控能力，组建产品DBA小组，全面参与项目规划与开发，实现充分利用缓存以及数据库读写分离技术，有效减轻对数据库性能的直接依赖。
浙江移动去O四步走
实践出真知。从?浙江移动去O的推进实践过程来看，从易到难，分三阶段，遵循“研究、验证、上线”的科学发展观，步步为营，稳步推进去O。
第一步，研究验证开源MySQL和PostGerSQL在OLTP与OLAP场景下的适用性，外围系统先行试用PostGreSQL/MySQL，积累开发、运维经验，在合适的外围系统中试用，积累开发、运维使用经验，逐步推进到核心系统。
第二步，在一阶段积累的去O基础上，逐步推进到部分核心系统，研究分布式内存数据库+关系型数据库结合的去O方案，在关键系统中验证可行性。实现去O里程碑的事情，浙江移动基于BC-RDB的统一用户管理系统正式上线，采用基于开源PG定制版的BC-RDB数据库，标志着浙江移动对开源定制版产品的掌控开始。其中，数据分布采用Sharding方式，对数据切分进行了尝试。在与Oracle高度兼容的存储过程、复杂SQL移植方面，积累了去O割接经验。
第三步，视情况逐步推进到核心系统。对浙江移动来说，去O已经不再是一个技术难题，但需要根据自身需要去综合考虑必要性和推进程度。
大家都知道，支撑域中绝大部分的数据库系统都采用集中式IOE架构，而基于X86设备的通用数据库云平台是一个很好的解决方案，这种解决方案国内已经有天矶、华为等多家公司推出了自己的成熟产品。例如浙江移动联合天玑数据共同研发成功的PBData，在经分报表、统一酬金、稽核等系统通过验证测试，总体性能提升达到3-8倍。
从实际应用效果来看，数据库云平台意义非常重要，在很多场景下可以既满足性能提升要求，也实现应用完全透明情况下的数据库去IE，或者应用轻度改造下的数据库去IOE，从而实现大幅降低风险，提升系统处理能力，增强扩展能力，大幅降低采购成本。
去IOE的理性世界观
通过详细的分析和长期的实践，王晓征在充分总结浙江移动去IOE的体会上，形成了一个比较清晰的去IOE世界观。
去I应激进，很省TCO。倒逼开发团队，提升应用架构，DCOS很好玩，提升性能、扩展性、可用性，可维护性不是梦。
去E应淡定，较省TCO。数据库云技术+大数据技术解决大部分问题。SDS，前途光明过程曲折。
去O应谨慎，让去O回归理性，回归技术。阿里去O方案是创举却不具备普世性。没有最好的技术只有最合适的技术。需要结合自身实际情况选择“最适合”的技术，量力而行。
总之一句话：对于大部分用户来说，去IOE综合成本不会降低，只是结构变化，但自主可控能力可望得到明显提升。（阿明）
