微服务架构在阿里的演化

摘要： 3 月 10 日，2017 阿里云网站行业热点问题和解决方案线下研讨会在上海举行。阿里云产品专家银时为大家带来《微服务架构如何实现网站服务垂直化拆分》精彩演讲。主要从服务化的缘起、微服务架构的形成，以及在大规模的服务化过程中所面临的一些挑战以及解决方案，跟大家分享整个微服务。

3 月 10 日，2017 阿里云网站行业热点问题和解决方案线下研讨会在上海举行。阿里云产品专家银时为大家带来《微服务架构如何实现网站服务垂直化拆分》精彩演讲。主要从服务化的缘起、微服务架构的形成，以及在大规模的服务化过程中所面临的一些挑战以及解决方案，跟大家分享整个微服务。

以下内容根据现场分享和讲师 PPT 整理而成。

关于讲师：

倪超，阿里花名银时，阿里巴巴企业互联网架构平台产品专家、国家认证系统分析师、IT 畅销书作者，著有《从 Paxos 到 ZooKeeper》一书，2015 年国内新书畅销榜 Top10。2010 年，以实习生身份加入阿里，入职中间件技术团队，经历了阿里中间件技术从 1.0 到 3.0 的变革，目前负责商用软件 EDAS。

关于 Aliware

Aliware 是阿里巴巴中间件技术品牌，包含 5 个中间件产品，主要是：EDAS、DRDS、MQ、ARMS、CSB。Aliware 从 2007 年开始，经历了 8 年多的双 11 大促，每次大促都能使产品体系更上一个台阶。像 JStorm、Dubbo、Rocketmq 等等一系列的开源产品，无论在 GitHub 还是 Apache 这些顶级项目上，都是非常火的项目。

服务化缘起

在 2007 年的时候，阿里技术研发团队大概是 500 人左右，主要业务是淘宝网站点，都是都在一个单一的 WAR 包进行部署，基于传统 JAVA EE 应用开发架构，使用的是 Oracle 数据库和 JBoss 服务器。当时整个淘宝网就是两个 WAR 包，一个是前台的，就是淘宝网；还有一个是后台的 CRM 系统，是给所有的客户支持人员使用的。

在当时那个阶段，我们面临着非常多的问题：
第一个问题，是系统的研发成本非常高。

首先，上百人维护一个核心工程，源代码冲突严重，协同成本极高。淘宝网当时是单独的一个 WAR 包，在运行的时候，就是一个工程，都是一份代码。无论是以前的 SVN，还是今天用了 Git 等一系列工具，代码冲突的问题是逃不掉的。

其次，项目发布周期太长。当年的淘宝网，是一个烟囱式的网站。它底层就是一个数据库，然后上层是所有业务逻辑的一个 DAO 层，专门负责访问数据库，再上层可能是业务层。所有模块的逻辑都在一个系统里面，都在一起部署。这样会因为某几个模块的开发效率低，影响整个站点的发布。

然后，错误难以隔离。这个是当时比较致命性的问题。比如说一个大的活动，我如果对时间的一个模块或者其中的一个 if 判断逻辑进行一些变更的话，整个活动页面会出问题，会导致整个站点都不可用。

第二个问题，是数据库能力达到上限。

淘宝早期是用 oracle 数据库，单机的 oracle 数据库连接数捉襟见肘，单机 IOPS 达到瓶颈，每天数据库 CPU90% 的负载运转，每年 Down 机最少一次。

第三个问题，是数据孤岛

当时淘宝、天猫、聚划算，万网等业务系统之间，数据是完全隔离的，数据不一致，无法复用，账号不统一，不能进行关联推荐，也无法进行大数据分析。

微服务架构的形成

在这三大问题出现之后，淘宝网开始做一些服务化探索。从 2007 年开始，进行了一些微服务架构改造。

RPC 框架：微服务架构的核心基础

在阿里内部做服务化的最底层、最核心的是两个框架，首先是 Dubbo 框架。Dubbo 框架 2010 年诞生，2011 年对外开源。现在阿里发展到了第三代 RPC 框架，在内部代号叫 HSF 的框架，目前 90% 以上的应用，都在使用这样一个框架。每年双 11 大促也在用。

消息队列：异步调用实现系统解耦

前面说到的 RPC 框架，重点是帮助我们解决，一个网站在进行服务化拆分的时候，各个模块之间的联系，需要通过 RPC 框架来进行一个同步化的调用，那么还有一些场景，它其实是不需要同步化调用的，是可以用异步去解决。

比如淘宝网平台上的手机充值业务，看似是一个串行的充值流程，其实可以通过异步结构来解决。首先，通过同步调用帮助用户确保他的下单在电商平台已经完成；其次，通过消息组件进行异步解耦，使得那些耗时长的不是核心链路的一些东西，能够不占据消费者在使用网站、APP 上面的主流程时间，优化用户体验。

基于此，我们消息中间件主要会去解决三大类的问题。

第一个是可靠同步，它的消息是可靠并且有序的，这是在所有需要稳定性、提高交易链路上用到的。第二个是可靠异步，当有稳定性的诉求，也有吞吐量诉求的时候，可以采用异步的这些逻辑，通过异步反馈，让消息中间件反复去投递，确保稳定性。最后一个是单向，不关注稳定性，只关注吞吐量是否大。

大规模配置推送

在进行服务化拆分之后，需要将每一个服务使用的配置进行集中式管理。因此，我们研发了可靠的配置推送服务，能够在毫秒级时间内完成配置推送，同时支持变更历史记录和推送轨迹的查询。

立体化监控

监控是我们非常关注的事情，对于系统整体的性能指标也非常重要，所以，我们会尝试从不同层面收集信息，实现对应用立体化的监控，包括资源、容器和服务，具体包括以下三大方面：

系统资源：负载，CPU、内存、磁盘、网络

容器：堆内存、类加载、线程池、连接器

服务：响应时间、吞吐率、关键链路分析

服务监控

当原本在集中式的系统架构里面，每个页面会贯穿非常多的模块，每个模块都耦合在一个系统中，最终监控出的是表象，无法知道页面打开慢是哪个模块哪个功能逻辑上慢。现在，我们会对每一个服务接口、方法的实时调用情况进行监控，能够细致地将每一个服务的生命周期，每一个服务运行时的监控指标非常细化的监控出来，还会调用 QPS、响应时间进行统计，同时快速感知系统流量变化。

淘宝网围绕 EDAS 技术体系进行了一整套的服务化改造，在这个改造过程中，首先将数据复用度最高的数据进行拆分，剥离出用户中心这样的共享型的服务层，对上层所有业务进行用户相关的所有逻辑，接下来又陆续有千岛湖项目、五彩石项目，这些项目的背后都是一系列的服务化中心拆分出来的产物，后来经过 6-7 年的服务化演进，目前服务中心数已达 50 多个。

图为阿里巴巴核心服务化架构。自主创新走出技术困境，沉淀一大批成熟中间件技术，最底层为共享型中间件和组件，以及阿里云沉淀下来的技术支撑型产品；共享服务体系打破应用“烟囱式”建设方式，支撑业务快速创新；云化基础架构高效支撑业务增长，灵活的弹性伸缩带来巨大的成本节约。

大规模服务化挑战

随着服务化的拆分，所有的系统会变得越来越多，箭头指向就是底层的服务化中心，上层调用过来就是前端的业务系统。很多系统调用很多的服务中心，这时已经没有架构师能够人为的帮助我们进行服务依赖和架构梳理。

EDAS 鹰眼监控系统

我们在排查一些线上问题的时候，其实不要求说能够非常快速智能化的帮我去解决问题，只要有这样一套系统能够帮我快速的去定位问题就可以，于是阿里内部做了 EDAS 鹰眼监控这样一个系统。

图中从上至下可以看出，鹰眼监控系统能够非常快速的定位故障在哪里，并且通过可视化的手段，能够在系统上面发现是由于哪台机器上的哪一段日志导致的。这是鹰眼监控做的第一个事情。

鹰眼监控做的第二个事情是什么呢？当我们把类似的请求调用链路全部汇总起来进行分析后，就可以在很短时间内进行数据采集，并且有数据化的运营出来。峰值的 QPS 是指今天在某一个业务高峰时，某一个业务的服务，在分钟级别的服务化的调用过程中，达到的最大的 QPS。如图中标记可以看出，即使页面暴露在最前端，但不一定是压力最大的，这就算数据可视化带给我们的价值。我们还要对数据进行决策上的帮助，数据最大的价值在于可以精准化的通知我们最大压力点。

某个页面打开经过一系列的系统调用时，总会在某一个点出现问题，称之为易故障点。我们可以直观的看到在过去的一天里，到底所有的请求在哪一个组件的出错率最高，就可以针对性的解决。

EDAS 容量规划

阿里内部如何去做一些容量性的一些规划？首先我们会去制造一些流量，通过真实流量压测部分单机性能，然后根据设定的运行水位计算系统承载的最高容量，从而到最后可以实现机器按需的上线和下线，把这些系统融会贯通在一起，就是整体的容量规划提供的功能。所有的压测在单机上都会定一些指标, 当我们进行集群中把一半机器流量全部引到另一半时候，所有流量的 QPS 就会翻倍，当单机性能如果没有达到运行水位时，就会继续引流，直到达到指标为止。

EDAS 限流降级

在整个双 11 期间，在不同的时间点，我们所面临服务的核心和非核心是不一样。比如在双 11 零点的时候是流量高峰，基本上来自于所有的支付环节，因此在那个阶段，我们要把所有的资源全部倾向于交易、倾向于支付。而到了第二天早上起床的时候，物流服务会成为核心。今天我们会从业务的角度，去发现网站的核心和非核心。EDAS 里面会有一个可视化的配置界面，去帮助你在某个阶段，哪个服务是核心服务，那么这个核心服务能够去调用更多的底层资源，但在其它点的时候，它就会被限流住。

在公有云和专有云提供商业化服务

微服务架构在阿里的演化相关推荐

阿里高级技术专家邱小侠：微服务架构的理论基础 - 康威定律
邱小侠阿里高级技术专家读完需要 10 分钟速读仅需 4 分钟邱小侠,阿里巴巴集团客户体验事业群高级技术专家,阿里花名肥侠.2014年加入阿里巴巴,现在负责客户体验驱动及创新中心有关商家业务的开 ...
从 0 到 1 实现支撑百亿级请求量的微服务架构演化
过去几年,架构领域最火的方向之一莫过于微服务.实践微服务的好处显而易见,比如其本身所具备的可扩展性.易维护性.独立自治.故障和资源隔离等诸多特性,可以大大提高产品研发效率.同时,基于微服务架构设计风格 ...
阿里技术专家：为什么说失败的微服务架构，大多死在分布式事务？
微服务因其高内聚.低耦合.高扩展.敏捷开发为很多企业所用,当然,没有任何一项技术是完美的.系统微服务化后,一个看似简单的功能,内部可能需要调用多个服务并操作多个数据库实现. 毫不夸张地说,分布式事务已 ...
微服务架构下分布式事务解决方案——阿里GTS
1 微服务的发展微服务倡导将复杂的单体应用拆分为若干个功能简单.松耦合的服务,这样可以降低开发难度.增强扩展性.便于敏捷开发.当前被越来越多的开发者推崇,很多互联网行业巨头.开源社区等都开始了微服务 ...
微服务架构下分布式事务解决方案 —— 阿里GTS
1 微服务的发展微服务倡导将复杂的单体应用拆分为若干个功能简单.松耦合的服务,这样可以降低开发难度.增强扩展性.便于敏捷开发.当前被越来越多的开发者推崇,很多互联网行业巨头.开源社区等都开始了微服务 ...
微服务架构：BFF和网关是如何演化出来的？
题图 from pixabay.com 1.介绍 BFF(Backend for Frontend)和网关Gateway是微服务架构中的两个重要概念,这两个概念相对比较新,有些开发人员甚至是架构师都不 ...
小麦助教：通过阿里云原生中间件产品组合，加速微服务架构落地
简介:通过深度的使用阿里云丰富的云原生中间件产品,助力小麦微服务架构的快速落地,借助可观测.消息等产品,极大地提升了开发和运维效率,使小麦在降本增效上有了新的突破,真正做到了只关注业务本身. 作者:神 ...
GTS来了！阿里微服务架构下的分布式事务解决方案
阿里妹导读:分布式事务已经成为微服务落地最大的阻碍,也是非常具有挑战性的一个技术难题. 为此,今天我们邀请阿里高级技术专家于皋,和大家深入探讨微服务架构下,分布式事务的各种解决方案,并重点为大家解读阿 ...
阿里微服务架构下分布式事务Seata
转载自阿里微服务架构下分布式事务Seata Seata 是什么? Seata 是一款开源的分布式事务解决方案,致力于在微服务架构下提供高性能和简单易用的分布式事务服务.在 Seata 开源之前,S ...

微服务架构在阿里的演化

微服务架构在阿里的演化相关推荐

最新文章

热门文章