【.com原稿】沉迅，阿里巴巴中间件&稳定平台高级技术专家，在淘宝工作八年，主要是负责以下产品：淘宝分布式数据库（TDDL/DRDS）、分布式消息系统（Notify/ONS）等，让我对整个分布式互联网架构有了更深入的了解。本文分享了阿里技术架构的演进和过程中遇到的问题以及企业级信息系统架构的演进。阿里技术架构的演进及过程中遇到的问题2003年，淘宝最初的架构构建是基于PHP的，实践发现系统的抗压能力比较弱。因为淘宝是企业级系统，所以选择了JavaBean这个当时非常重要的企业级技术。之后将整个Web容器、EJB等完整系统引入淘宝，并聘请有经验的工程师一起做架构。淘宝在技术方面也取得了长足的进步。在架构构建的过程中，讨论最多的就是如何划分模块。随着技术的不断发展，2006年淘宝技术从EJB过渡到Spring，如下图：目前这款产品已经开源，顶层使用JBoss，中间使用Webx，然后是Spring，OR-Mapping，底层使用Oracle数据库。我们用Search做搜索引擎，是因为当时我们收购了雅虎，把雅虎的搜索引擎接入了淘宝。现在采用这样的分布式存储方式似乎很普遍。当时业务持续高速发展，一些问题也逐渐暴露出来。这里主要分享工程维护、人员变动、数据孤岛、数据集能力不足等问题。工程维护和人员变动随着业务的不断增长，技术团队的项目会越来越多，源代码也会以更快的速度膨胀。多个项目之间，源代码冲突严重，相互协作的成本不可估量，因为工作没有边界。假设项目完成，核心人员离开，项目维护也会成为问题。新人入职，学习老代码的难度也可想而知。数据孤岛数据孤岛是企业普遍存在的问题。当时天猫还叫淘宝商城，不是以淘宝为基础，而是一个完全独立的集团。后来因为一些原因想把两个系统合并，但是由于各自独立的业务系统、用户ID、数据存储格式等不同，操作起来比较困难。而且数据本身质量不高，很难做统一分析。数据库容量达到上限后，使用小型机+Oracle，CPU使用率90%以上，每年至少宕机一次。这主要是因为有大量的新业务写入，频率为两周一次，不断产生新的SQL。在新的SQL中，如果有慢SQL，就会出现宕机。当时我们用的小型机重启需要20分钟，换个地方也需要20分钟。关于连接数，如下图所示：当时后台Oracle的连接池是有限制的，大概8000个，一旦超过就会出问题。因为数量超过数量，链接占用的内存会非常大，连接数多的单点风险系统非常高。阿里对DBA相关问题的应对综上所述，当时阿里的DBA面临着维护人员众多、团队职责不清、数据无法共享的问题。高级问题。好在当时阿里正处于成长期，所以这个时候通过招一些技术高手解决了问题。基于EDAS的服务化改造针对阿里巴巴DBA们遇到的问题，从硅谷请来技术人员尝试以服务化的方式解决。当时国内只有用友做过服务，效果不是很好。没有参考，只能小心翼翼的往前走。如下图所示，阿里以服务化的方式对系统进行专业化划分的关键战役有3个。用户中心服务用户中心首选做服务，因为用户中心是最小的集合，最简单明了，而且因为确实有业务需求，我也想验证一下这个服务的概念是否正确。在服务化之前的用户中心，有六种不同的查询方式。看起来遍历方式差不多，但是可能某个参数不一样，因为数据来自不同的团队。服务化的原则是可以保持不变，可以简化，采用的传输方式是HTTP。但是这样不行，因为除了面向服务的HTTP，其他内容没有变化，所以需要部署LoadBalance。为了保证LoadBalance尽量稳定，选择硬件F5进行配置。将前端传入的用户流量发送到F5，新增VIP接口，请求通过F5转出。这里发现一个很严重的问题，就是用户每登录一次，就会出现一个节点，跳转之后流量会翻倍。但是F5是一个非常昂贵的设备。如果以后一切都变成面向服务的，用F5就不可行了。千岛湖项目配置F5负载均衡不可行。另一种思路是从中心化的单点模式转变为真正去中心化的模式。当时阿里把这个方法叫做softload，做的是分布式负载均衡。在将交易中心做成服务化的时候，需要使用物相关的方法来保证整个流程的稳定性和一致性。当时采用的是最终一致性设计方法。之后通过实践反复修改优化，得到稳定的消息系统。凭借消息系统的研发经验，类目属性等中心也将服务。之所以叫千岛湖项目，是因为大家辛苦了。完成项目后，他们前往千岛湖旅游。随着彩石项目千岛湖项目的完成，底层架构和中间件都稳定了，接下来要做的就是把庞大的系统变成一次性服务。这个时候淘宝商城和淘宝需要合并，所以当时整个体系是完全分裂的，也就是淘宝3.0。从那以后，4.0就再也没有出现过，采用的是面向服务的架构。基于DRDS的分布式数据库改造DRDS建设的初衷是从Oracle分析数据，同步到MySQL。当时大家觉得Oracle很稳定，整个系统不会丢数据，所以有必要把Oracle放到主机上。但是我也发现了一个问题。首先，小型机的成本较高，需要在后端增加大量的PC来实现读写分离。还有就是看似稳定的Oracle，在Linux环境下的表现并不是很好，尤其是两者还存在很多兼容问题。下面是传统数据库到分布式数据库的改造图：最终选择了分布式MySQL架构来解决问题，使用Facebook技术团队开发的开源项目Flashcache机制对MySQL进行加速，完成整个业务的部署。在Linux环境下，MySQL比Oracle更稳定，运维成本也比较低。以上就是做服务中心的好处，显而易见。经过一段时间的改造，技术架构发生了很大的变化，如下图所示：整个技术架构的最底层是由EDAS、DRDS、ONS组成的基础应用架构。电子商务、物流、移动IM、地理信息、医疗等都有自己的能力，并且都打通了能力，形成了一个IT共享的业务架构层来支撑上层业务。一旦业务需要配合，底层技术可以快速响应。比如淘宝和滴滴，从谈合作到成功完成项目只用了不到五天的时间。当时是一款内网打车软件。使用本软件打车，可以实现通过公司账号叫车，免去贴发票的麻烦。这件事确实凸显了技术可以帮助企业解决一些问题。虽然淘宝可能已经没有4.0版本了，但是现在每一个应用系统都在为未来做好准备。企业级信息系统架构的演进通过对阿里技术发展历程的总结，我们发现这些通过实践得到的技术架构可以为部分企业提供借鉴。所以它被规划为一个产品——企业级信息系统。云计算时代，企业信息化的演进不仅仅是IT系统上云，更重要的是业务与信息系统的深度融合，改变业务运营和创新模式。下图展示了企业级信息系统的演进过程：将业务云从虚拟机模型转变为分布式互联网架构进行重构，重构后给企业带来的主要价值是解决了一些原有的效率问题.因此，互联网架构平台是企业云化演进的使能平台。下图为企业级互联网架构平台对应的底层架构：底层为基础框架，主要涉及EDAS、MQ、DRDS三大产品：EDAS主要职责是编写和发布业务应用程序。MQ在异步解耦的过程中用来编辑消息，保证事物的一致性。有了大量的用户和数据之后，DRDS负责将它们分散到各个应用中去。三款产品自上而下很好地支持业务编写、相互通信、下层数据的构建。CSB（CapabilityOpennessPlatform）的主要职责是对外开放阿里微不足道的运营，保证内部数据的安全和开放，同时与现有系统对接，进入系统。云业务的能力部分是与客户一起设计和构建的。整个系统到端的核心要点是成本、稳定性和效率。阿里在过去十年的业务高速增长中，在这三个方面积累了很多经验。希望这些经验可以帮助一些企业少走弯路。下图是企业级互联网架构的关键特征：随着机器数量的增加，性能必须线性增长，可靠性呈指数级增长，运营成本必须保持对数增长。这些是真正的互联网架构的关键特征。如果系统不能很好地解决这些问题，那将是一个无法规模化的系统，也无法满足未来用户的增长需求。写在最后，为什么会有这些互联网系统？互联网架构为什么会有这些特点？很简单，因为阿里的软件和服务最终都是为了用户。当用户呈指数级增长时，如果没有良好的可扩展性，系统就会死亡。什么是企业互联网？也就是如果只靠互联网模式往前走，成本和研发效率都会成为问题。根据以往的经验，经过反思，希望通过软件让互联网业务写作变得更简单，更好地满足企业快速成长的需求。以上内容根据王靖宇老师在WOTA2017“云服务架构”专场的演讲内容整理而成。2008年加入淘宝后，一直从事中间件和稳定平台工作至今。目前负责阿里巴巴的分布式数据库，原名TDDL，现在在阿里云上使用更名为DRDS，阿里巴巴的分布式消息服务（Notify/MetaQ），以及阿里巴巴企业级互联网架构平台的新产品开发。【原创稿件，转载请注明原作者及出处为.com】【责任编辑：王雪艳电话：（010）68476606】
