【云栖社区】业内对与阿里巴巴去IOE有着很多猜想，也有不同专家在技术分享中多少会提及一些。但从来没有人从故事的起点——2006年开始回忆和总结。有位朋友分享了2月25日阿里中间件技术部资深专家沈洵在DBA+社群的讨论文章。其中很系统地讲述了阿里去IOE的技术背景，以及后面的自主研发中关键点抉择。
沈洵，云栖社区专家， 阿里中间件技术部资深专家
-
2016全球敏捷运维峰会演讲嘉宾
-
08年加入阿里，参与过阿里巴巴的分布式数据库TDDL的以及分布式消息系统项目。
-
目前主要在负责阿里的云产品的技术与服务，包括分布式数据库DRDS， 分布式消息系统MQ，以及企业级应用服务框架EDAS
我是08年加入阿里的，有幸经历了阿里业务成长最快的那段时间，也留下了很多宝贵的记忆。今天在这里给大家讲讲我们几年前经历的那些有意思的故事。
首先来讲讲去IOE。对于阿里巴巴去IOE的过程，大家可能觉得就是老板们振臂一呼，大家齐头并进就把这事儿给做了。其实，很多事情你不在实际环境中，是不会明白我们当时的想法和感受的，也就无法完全理解我们的架构。
今天就让我带大家回到当时的场景吧。
系统的第一次选择-Oracle
时间大概是06年左右，淘宝的业务虽然还不算很大，但是增长非常迅速，我们刚刚在国内取得竞争上的领先地位。业务对于技术的要求是，需求能够快速满足，能够撑得住就行— 看看要求有多低。
然而，就这个需求都很难被满足，开始我们选择了开源的LAMP架构，然而随着系统的压力越来越大，我们现有的系统架构已经不足以满足业务的实际需要了，这时候我们的系统就面对了第一次选择。
那么，当时为什么会选择Oracle呢？ 我归纳起来主要原因是这么几个：
1）这是当年业内最好的选择
当年的企业级应用里面最为成熟的架构就是 Java 配合Oracle的企业级架构，有商业支持，系统应用广泛。在当时看起来，应用系统按需的进行scale up也确实是能够解决我们当时的系统问题。
2） ebay当时在使用这套架构
这是个非常重要的理由。我们有可以借鉴的国外先进经验。在公司的发展历程里面，业务的正常发展是第一位的事情，这个如果出现问题那么之前我们付出的一切努力就白费了。就像是双11这样的应用场景，如果真的因为系统架构问题导致我们的一些活动没能取得很好的结果，那么很可能就会丧失掉最关键的发展机遇。
当年的我们，还购买了SUN公司的技术支持，来为我们的技术发展保驾护航，我们选择了EJB来构造我们的企业金融级业务系统。
这样的系统架构经过了两年的发展后，大家突然发现似乎一个新的风潮出来了，当时有一本书叫《J2EE without EJB》。我们意识到对于那些复杂的概念，复杂的实现方式，原来困惑的不止我们一家啊。
于是我们在应用层做了一个重构，把EJB和相关的J2EE Server干掉了。 使用了一些开源的web server,基于spring来实现了我们的业务逻辑，下面还是用的Orale。当时，因为业务的增长实在太快，Oracle永远都是在最高处理容量上高位运行，出的奇葩问题也非常多，于是我们的DBA就被这种严酷的环境训练成了业内的精英，每个都是trouble shooting的高手。
走上自主研发之路
然而，我们最终发现，这种系统的运行模式是有瓶颈的，系统的主要问题就在某商业数据库上。我印象比较深的问题是这么几个：
1） O作为商业产品，本身也有性能的上限，无法实现水平扩展。可能有些人会有些疑问：哎？不是可以scale up来扩展么？ 确实如此，但如果一个硬件系统预计3年过保，然而业务的发展可能会让我们在第二年就必须考虑购买新的高端机型来升级的问题了。
2） 黑盒子。如果大家写过代码就会能体会到，对于没碰到过的场景，无论再怎么努力，也是无法预测可能出现的问题的。而当时我们还真就碰到了很多奇葩的问题，比如链接hung住，系统在某些极端情况下丢一个异常。然而查遍手册，却发现对于这个异常，某商业数据库给的提示是，理论上不会抛出。如果你看到了就联系售后支持 XD。
3）效率低，发现一个问题，翻译成英文发给对方，1个月以后才能收到回复。我们尝试，然后再发过去咨询。这种方式的效率实在是太低了。
我们真的是碰到了商业系统的边界了。然而我们真的是想使用商业产品的，毕竟商业产品比较有保障。我们环顾四周，发现已经合适的商品能够解决我们的问题了。
业务不等人，我们必须做出选择（后来我们管这种事儿叫高速公路换轮子）。当时我们希望能够在一些非重要的业务应用上，使用一些我们自己研发的系统，从而实现更符合我们业务要求的产品。
于是，我们选择了一个测试性应用，应用来上线我们的DRDS(TDDL)+MySQL产品。这个应用的的技术特性是，数据量非常大，系统可以接受偶发的离线，比较适合作为数据存储类产品的启动项目。
整个上线的过程还是挺顺利的。大家当时对DRDS这个产品的最大担心是，系统分了很多库和表，因此运维管理上会不会变得很复杂？我们实践下来发现，其实在良好的运维系统的辅助下， 分布式系统的运维能力跟单机系统其实差不了太多，更多的还是要不断实践。
一些旁路系统逐渐开始使用这套新架构。当时，DRDS还是个挺土的东西。现在可能有人研究过cobar和他的衍生产品，其实那就是DRDS5年前的样子。不支持跨机Join，分布式查询合并不支持，高可用切换不支持，bug比较多等等，都是当年成长路径中留下来的阵痛啊。
在做了一大批旁路系统以后，DBA的同学们和开发的同学们都越来越有信心了。于是就开始要做核心的系统了。可能有些人又会问了，做点周边不就行了，为什么要做核心啊？多危险。没错。但当时我们面对的抉择是，不做，肯定挂，做了，可能会挂。
我们并没有很激进的直接全部切换。某商业数据库并不贵，小型机才是成本的元凶，如果我们能把小型机去掉不也就可以节省成本了么。我们采用了一种稳定的的方案，用某商业数据库+小型机做主机，承担写入，而我们认为可能会挂掉的某商业数据库+PC Server 做备机，承担读取。这样，我们就既利用了某商业数据库+小型机的好处，又规避了可能风险。
于是，这个方案就开始在商品上面进行了实践了。最终却导致了一个比较严重的失败。而这次失败却成为了改变历史的起因。
改变历史的时刻
当我们用了半年的时间终于把这套架构做出来时，我们发现，当年的某商业数据库在AIX上面跑的很欢快，但在Linux pc机上竟然会出现系统hung住的情况，整个操作系统无响应。我们必须去给机房打电话关电源才能解决这个问题。于是我们项目组的同学们，排了个班，每个人一晚上，只要发现系统有问题，就给机房打电话让他们关电源。我们给商业支持服务发邮件，打电话，希望他们能够支持我们一下，然而我们却真的无法得到任何解决的建议，因为他们也没经历过这种情况。
这套系统就没有上线成功。我们进入了下一个周期，在半年内，必须把系统架构用DRDS+MySQL做出来，否则应用就会有危险！
这套系统在老板们的支持下，花费了几个月的时间终于做出来了。当时我们发现了一种很强大的东西叫PCI-E卡+SSD，性能很高，只比内存慢十倍，可惜就是成本太高，存TB级的数据实在是不是上算。于是我们又给某商业数据库发函，询问他们能不能帮忙支持一下，让这个PCI-E卡+SSD能做二级缓存，但是没有收到答复。
我们开始在市面上寻找能支持这个需求的商品。 我们发现FB开源了一个基于MySQL的flashcache卡的插件。拿过来做仔细研究，发现是可以支持的。赶紧测试一下，效果非常好，只用做简单修改。
于是我们决定用这套模型。上线后，系统非常平稳。后面有件印象最深的一件事，我看一个业务上线没有经过DBA的SQL审核，我很善意的提醒DBA说，这个还没审核呢，上线有风险吧？ DBA回答，非重要应用，现在系统容量buffer很足，先上线，不行后面再优化就好。 我立刻就明白了我们做这件事的价值。
因为这件事，我们也突然发现这种方式确实比原有的方案要好，系统的延迟低，性能好（MySQL其实在简单查询的时候性能会超越当时的Oracle），可控性好，需求响应快 。往后的道路就是，上一个系统，上一个系统，上一个系统.....而这件事，也就成为了转动历史的时刻。
这就是我想讲述的去IOE的故事。
运维现状
那么，阿里的现状是什么样子的呢？
我们的服务面向公司内的时候，一直都是采用DevOps的，开发和运维在一起。这样的最大好处是，我们可以对产品有持续改善。
答疑，部署，bug fix ,运维工具，都是我们开发的。这样效率非常高，可以在最佳的位置进行最合适的优化。
但是，我们发现，当这套系统向外输出的时，这种的模式便不能满足需求。因为外部企业内的环境复杂，运维和答疑和在阿里企业内部的实现难度不在一个数量级。所以我们目前在尝试实现运维能力产品化。希望我们将来能够与我们外部的运维合作伙伴一起，解决外部客户的实际问题。
Q & A
Q1：现在阿里在mysql方面发展到何程度了？
A1：MySQL上有不少自己的patch，也都提交到webscalesql里面了。目前所有积累都在DRDS+RDS上做产品化输出。mysql方面主要是一些高并发场景的优化。
Q2：去ioe用mysql据说多是因为成本和扩展性双重因素，成本是最先出现的考虑的因素吗？
A2：成本并不是主要考虑方向。小型机是比较贵的，oracle其实还好。但更多的时候是因为发现mysql跟Oracle一样能满足需求，而很多核心技术都积累在DRDS。
Q3：一般到什么样的数量级可以考虑去？
A3：能不做就不做。业务容量、性能、扩展性预计在1年以后会出现问题的时候再采取这种策略。
Q4：我看过你的演讲，你说传统行业（银行）已经开始接触阿里云，你对传统行业的运维和系统架构师有什么好的建议，如何转型？
A4：我觉得可以先利用一些实际的项目来感受一下新的编程方式和方法。其实它跟传统的构造模式差异并不大。主要还是对之前这10多年经验的总结而已。开发的方式一定是以简单为主的，不会弄的很复杂。因为互联网的架构模式基本上都是实践出来的，没有太多的顶层设计因素，所以不会像IBM那样厚重。
Q5：阿里开发和运维在一起，所以开发和运维的分工可能不会太难定义。有的公司开发和运维在两个部门，就容易出现问题。比如数据库是运维部门管，开发的sql在数据库里跑的慢了，是由于索引不佳等原因。阿里是怎么对这种情况进行责任分工的？
A5：目前来看 DBA的工作是单独分出来的水平团队，他会给所有的业务团队以支持。他们也会写一些自己用的运维系统，来支持他们的工作，比如自动sql审计，监控，日常运维等。
Q6：在分库分表后有没有出现某些节点数据增长比较快，是如何解决的？
A6：DRDS是可以支持动态扩容的。
Q7：以后的dba得怎么发展，面对自动化运维的到来？
A7：1）学点开发技能不是坏事。2）就我们的实践来看，数据库这套系统还是需要数据业务架构师的。索引调优和数据表设计什么的，还是比较专业的一件事。
Q8：请问dba需要学哪些开发技能？
A8：越多越好，其实如果写过数据库，数据库优化的很多原理就很容易精通了。
Q9：mysql在做分库分表的时候是用中间件还是业务逻辑分比较好。cobar有新版本么。
A9：结合比较好，cobar 大家可以继续依托来做二次开发 。
Q10：阿里内部团队分享是什么样一个机制，写文章吗，是强迫的么？
A10：老板会在一些时候号召大家做分享，但大部分时候不是强迫的，你也能看到很多博客做了一段时间就荒废了。 就是因为大家其实挺忙的。也会有很多人有自己的博客，大家可以从http://blog.sina.com.cn/s/blog_693f08470102vibt.html 看到。
Q11：在互联网公司里，团队的组织和成长方式如何？
A11：互联网公司内，团队也分水平团队和垂直团队（基于服务化架构做某一块服务）。水平团队（水平支撑），类似系统运维，dba，过程改进等等，都是水平团队支持全部的垂直业务。垂直团队，则其实什么都可以做，包括系统发布等等，权利都是下放到联排级的。水平团队因为人数的限制，也会逐渐开始将人工的服务都变成系统，提供给垂直团队。 所以，其实理论上来说，业务系统应该都是以系统通信得方式做接驳的，当然，实际的情况是里面还是有不少人工痕迹的。
Q12：阿里云mysql的架构核心还是主从么。主从切换有没有遇到binlog需要人肉的问题。怎么解决的？
A12：还是主从 。不用人肉，这些都是系统自动解决的。
Q13：为什么不采用jboss呢？
A13：jboss是j2ee的Ejb容器，当不用ejb的时候，再用jboss意义就不大了。我们最后一个使用的jboss组件是jboss的datasource，其实这东西挺稳定的，不过就是依赖太多了。
Q14：如果主写的过程中crash了，这部分binlog日志落盘后没到从。从切换成主了，开始写入。这部分binlog你们日志怎么处理的？
A14： 这个目前是回补策略。也有强一致的方案。
这是DBA+社群2月25日的分享。作为云栖社区的好友，DBA+将在2016年举办四场城市的2016全球敏捷运维峰会。首场是4月16日杭州，届时会有阿里专家分享技术实战经验。欢迎报名！2016年全球敏捷运维峰会官网链接
