资深阿里程序猿深入讲解微服务架构在阿里的演化,越深入,越开心

Posted JAVA高级架构

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了资深阿里程序猿深入讲解微服务架构在阿里的演化,越深入,越开心相关的知识,希望对你有一定的参考价值。

关于 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 上面的主流程时间,优化用户体验。 
基于此,我们消息中间件主要会去解决三大类的问题。 
针对上面的技术我特意整理了一下,有很多技术不是靠几句话能讲清楚,所以干脆找朋友录制了一些视频,很多问题其实答案很简单,但是背后的思考和逻辑不简单,要做到知其然还要知其所以然。如果想学习Java工程化、高性能及分布式、深入浅出。微服务、Spring,MyBatis,Netty源码分析的朋友可以加我的Java进阶群:680130298,群里有阿里大牛直播讲解技术,以及Java大型互联网技术的视频免费分享给大家。 
第一个是可靠同步,它的消息是可靠并且有序的,这是在所有需要稳定性、提高交易链路上用到的。第二个是可靠异步,当有稳定性的诉求,也有吞吐量诉求的时候,可以采用异步的这些逻辑,通过异步反馈,让消息中间件反复去投递,确保稳定性。最后一个是单向,不关注稳定性,只关注吞吐量是否大。

大规模配置推送

资深阿里程序猿深入讲解微服务架构在阿里的演化,越深入,越开心

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

立体化监控

资深阿里程序猿深入讲解微服务架构在阿里的演化,越深入,越开心

监控是我们非常关注的事情,对于系统整体的性能指标也非常重要,所以,我们会尝试从不同层面收集信息,实现对应用立体化的监控,包括资源、容器和服务,具体包括以下三大方面: 
系统资源:负载,CPU、内存、磁盘、网络 
容器:堆内存、类加载、线程池、连接器 
服务:响应时间、吞吐率、关键链路分析

服务监控

资深阿里程序猿深入讲解微服务架构在阿里的演化,越深入,越开心

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

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

图为阿里巴巴核心服务

资深阿里程序猿深入讲解微服务架构在阿里的演化,越深入,越开心

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

大规模服务化挑战

资深阿里程序猿深入讲解微服务架构在阿里的演化,越深入,越开心

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

EDAS 鹰眼监控系统

资深阿里程序猿深入讲解微服务架构在阿里的演化,越深入,越开心
我们在排查一些线上问题的时候,其实不要求说能够非常快速智能化的帮我去解决问题,只要有这样一套系统能够帮我快速的去定位问题就可以,于是阿里内部做了 EDAS 鹰眼监控这样一个系统。

图中从上至下可以看出,鹰眼监控系统能够非常快速的定位故障在哪里,并且通过可视化的手段,能够在系统上面发现是由于哪台机器上的哪一段日志导致的。这是鹰眼监控做的第一个事情。 
资深阿里程序猿深入讲解微服务架构在阿里的演化,越深入,越开心

鹰眼监控做的第二个事情是什么呢?当我们把类似的请求调用链路全部汇总起来进行分析后,就可以在很短时间内进行数据采集,并且有数据化的运营出来。峰值的 QPS 是指今天在某一个业务高峰时,某一个业务的服务,在分钟级别的服务化的调用过程中,达到的最大的 QPS。如图中标记可以看出,即使页面暴露在最前端,但不一定是压力最大的,这就算数据可视化带给我们的价值。我们还要对数据进行决策上的帮助,数据最大的价值在于可以精准化的通知我们最大压力点。 
某个页面打开经过一系列的系统调用时,总会在某一个点出现问题,称之为易故障点。我们可以直观的看到在过去的一天里,到底所有的请求在哪一个组件的出错率最高,就可以针对性的解决。

EDAS 容量规划

资深阿里程序猿深入讲解微服务架构在阿里的演化,越深入,越开心

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

EDAS 限流降级

资深阿里程序猿深入讲解微服务架构在阿里的演化,越深入,越开心

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

    推荐阅读

  

  



以上是关于资深阿里程序猿深入讲解微服务架构在阿里的演化,越深入,越开心的主要内容,如果未能解决你的问题,请参考以下文章

25岁阿里120W年薪架构师推荐学习的750页微服务架构深度解析文档

阿里P7架构讲解:微服务设计

深入浅出解析阿里成熟的微前端框架 qiankun 源码图文并茂

阿里P8携手腾讯T4谈微服务架构实战:深入浅出Cloud+boot+Docker

深入浅出讲解MSE Nacos 2.0新特性

深入浅出讲解MSE Nacos 2.0新特性