产品知识库–阿里巴巴Aliware十年微服务架构演进历程中的挑战与实践.docx

阿里巴巴Aliware十年微服务架构演进历程中的挑战与实践  1、目标 如今的阿里巴巴平台上，业务生态百花齐放，新的创新业务不断涌现，而这都得益于阿里底层的微服务架构高可扩展。而谁能想到，早在10年以前，偌大的淘宝网站点都是运行在单一的部署包内，往往对其中一个模块的改动都会牵一发而动全身。 自从2007年以来，在这近10年时间里，阿里巴巴技术团队一直在微服务的道路上摸索前进着，其间伴随着互联网和移动互联网的盛行，海量的用户一次又一次的洗礼了各个机构的IT系统，而在阿里，这种改变无疑更加频繁与剧烈——这些年下来，阿里中间件技术完成了从1.0到3.0时代的蜕变，并已经完成了将技术变成商业化产品，对于海量微服务的治理能力处于业界领先，形成了自主技术产品和品牌——Aliware。 在刚刚结束的Velocity China 2016大会上，阿里巴巴集团产品专家倪超，发表了题为《阿里巴巴Aliware十年微服务架构演进历程中的挑战与实践》演讲，深入介绍了阿里巴巴从集中式系统向大规模分布式系统演进过程中的微服务解决之道，并围绕EDAS介绍了高性能RPC框架和应用实时监控服务，最后分享了海量微服务带来的挑战以及针对双11大促的准备。  演讲者倪超，阿里花名银时，阿里巴巴企业互联网架构平台产品专家、国家认证系统分析师、IT畅销书作者，著有《从Paxos到ZooKeeper》一书，2015年国内新书畅销榜Top10。2010年，以实习生身份加入阿里，入职中间件技术团队，经历了阿里中间件技术从1.0到3.0的变革，目前负责商用软件EDAS。 2、服务化缘起 在2007年的时候，阿里技术团队规模大概是500人左右，当时的主要业务站点淘宝网，都在一个单一的WAR包进行部署，基于传统JAVA EE应用开发架构，使用的是Oracle数据库和JBoss服务器——而与此同时，淘宝网的业务每年翻倍增长。 在那个阶段，我们面临着非常多的挑战，总体归纳下来有三点： 第一个挑战是系统的研发成本非常高。上百人维护一个核心工程会碰到很多问题，包括源代码冲突严重、协同成本非常高等；同时，项目发布周期太长；所有的逻辑都是耦合的，错误难以隔离，如对淘宝网整个工程里的某个模块、某个系统功能进行一些改动时，整个系统都会面临非常大的技术风险。 第二个挑战是数据库能力达到上限。淘宝早期用Oracle数据库，单机的Oracle数据库连接数捉襟见肘、单机IOPS达到瓶颈、CPU 90%以上，数据库容量日趋饱和，每年Down机最少一次，长期高负荷运转，接近崩溃边缘 第三个挑战是数据孤岛。业务相关数据处于隔离状态，重复建设严重，数据不一致问题突出，无法复用，无法进行大数据分析建模。 3、微服务架构的形成 整个微服务架构落实到技术层面，就是把原本集中式的模块分散到分布式里不同的机制上运行，并且希望有这样一个框架能够将不同机器、不同机房、不同模块之间的服务化调用能够顺畅的构建起来，并且能够帮助组织服务发布、服务注册以及服务发现等过程。目前阿里生产环境使用的是第三代RPC框架：EDAS-HSF，在整个平台90%以上应用当中使用，历经8次双11大促大流量和高并发考验，支持分布式事务。而我们也将第一代RPC框架EDAS-Dubbo开源，目前已经成为国内最活跃开源软件之一、开源分支达4000多个。 基于高效的框架，系统能够通过消息队列实现异步调用实现系统解耦，实现服务的拆分化和大规模推送。进行服务化拆分之后，需要将每一个服务使用的配置进行集中式管理。因此，我们研发了可靠的配置推送服务，能够在毫秒级时间内完成配置推送，同时支持变更历史记录和推送轨迹的查询。 监控是我们非常关注的事情，对于系统整体的性能指标也非常重要，所以，我们会尝试从不同层面收集信息，实现对应用立体化的监控，包括资源、容器和应用，具体包括以下三大方面： 系统资源：负载，CPU、内存、磁盘、网络 容器：堆内存、类加载、线程池、连接器 服务：响应时间、吞吐率、关键链路分析 阿里巴巴目前是架构在Java平台上，作为包含Java运行环境的Java容器是监控的重点，我们会监控堆内存与非堆内存使用情况、线程运行情况(提前将线程情况全部显示出来)、连接器情况，类加载情况尤复杂，很多时候一个类进行初始化时，层层依赖其它类，对此，我们在应用启动时跟踪加载的类。  当原本在集中式的系统架构里面，每个页面会贯穿非常多的模块，每个模块都耦合在一个系统中，最终监控出的是表象，无法知道页面打开慢是哪个模块哪个功能逻辑上慢。现在，我们会对每一个服务接口、方法的实时调用情况进行监控，我们还会调用QPS、响应时间进行统计，同时快速感知系统流量变化。 淘宝网围绕EDAS技术体系进行了一整套的服务化改造，在这个改造过程中，我们首先将数据复用度最高的数据进行拆分，剥离出