鹰眼跟踪、EDAS燎原, 看高性能服务框架EDAS的架构实践
大型电子商务平台吸引了大量卖家和买家,图为2014年IPO时候截得的图,可以看到在阿里上有10亿多件商品等,现在仍然以非常高的速度在增长。
图为2003年到2010年淘宝网注册用户数,用户数从非常低的值逐渐涨到近40000万人,这些用户突然来到我们的网站,就会给网站非常多的访问压力。2003年到2006年我们主要是想尽方法以业务为核心积累技术,到后来互联网人群在高速增长,整个体系面临的技术挑战就会非常多,具体有以下四点:
业务需求爆发式增长 开发人员快速扩张 系统代码量越来越多 系统压力越来越大综合来看,一个技术性网站最重要的技术挑战在于考虑业务的高速增长、用户数量的高速增长导致下层原来看不见的问题变成了新的问题。
挑战与解决之道
阿里前期技术团队规模500人左右,单一War应用,是以PHP为核心构建的系统,PHP+MySQL+Linux+Apache标准的LAMP的系统架构,后来逐渐用一些开源的技术替换掉了原来的商业产品,随着业务的不断发展,不断的把新的代码加入到系统中,我们研发了一套分布式存储架构,搜索也是自己构建的。
技术问题
随着技术快速增长和演进,随着人员的增加,我们发现很多严重的问题展现出来。
业务支持缓慢,牵一发而动全身
很多人同时维护一个核心工程,不同人有不同的理解,会导致源代码冲突严重,很难做项目管理,协同成本非常高,进而项目发布周期就会很长,迭代速度变慢,且错误难以隔离。
数据库能力达到上限
只有一个数据库的问题是很大的,发布一个新的系统可能会导致宕机,由于数据库里本身的索引建错了,建错是因为库是重建的,Oracle的索引重建机制还没有来得及更新柱状图。所以,只有一个Oracle数据库时,连接数捉襟见肘,单机IOPS达到瓶颈,CPU 90%以上,每年宕机最少一次。
数据孤岛
多套用户体系导致用户不知道到底在哪个网站登录,我们想知道用户的画像,分析用户的购买行为,但两个不同网站的相同用户名不确定是否为同一用户,所以没办法进行后续的大数据分析。随着系统越来越多,我们发现大量的用户在系统出现时,比如查询用户的方法,在不同的业务系统里出现多次,每一次都不完全一样,数据隔离、重复建设,数据不一致,这是项目管理和代码管理的乱象。
基于EDAS进行服务化改造
没有任何服务化的经验去借鉴,我们只能一步一步的摸着石头过河。我们做了几个关键性的努力,首先是用户中心迁出,从一个大的系统里拆出一小块放到外面,这就是用户中心,用户中心是一个比较简单纯粹的处理用户登录的系统,当时在内部就有六、七种登录方式,我们把这些方式全部代理出来,变成一个单独的服务中心。如果我们不把系统代码进行革新,就没有办法支撑,紧接着,我们就开始做自己的中间件的研发,千岛湖项目产生时,EDAS、MQ、DRDS就随着它一步步的演进到现在。交易中心是整个系统里最复杂的业务流程,几乎和所有业务系统有关联,当它用一些中间件完成整个系统的突破时,我们就可以认为看起来中间件和应用都准备好了。接着我们进行了第三个五彩石项目,商城和淘宝各有一套购买流程,我们需要用EDAS进行服务化改造,把这两套流程融合到一起,使之能同时支撑两个不同的出口,完成下一步的延伸。
服务化以后的架构演进
服务化以后,开始时业务应用很少,随着系统往下延伸,很多人开始做服务化系统,服务之间也会进一步的复杂,从而会形成一个复杂的网状结构,那么,依赖很多,如何进行准确的梳理呢?
当系统变成网状结构后,一定会有一些业务系统是重要业务,一些业务系统是非重要业务,这些非重要业务突然出现小的故障时,整个系统就会宕机,我们成立了稳定性小组进行业务梳理,以交易流程为核心,哪些系统划成重要系统,哪些系统为非重要的业务系统,但是,系统在不断的变化,我们没有办法准确知道每一次变化后它的依赖关系是怎样的,很难进行梳理,必须通过系统的方式来解决问题。
鹰眼系统
我们把整个系统现象成一个高速公路的路网,流量进来就如同行驶的汽车,如何能够知道汽车从哪里进来又从哪里出去呢?在高速公路上做很多的关卡,这样可以准确的追踪到所有连接的道路和通信,这样,哪里有问题都可以通过非常简单的方式得到检测,而这个检测对于发现和解决问题是非常简单的一件事,才有可能摆脱在服务化以后,复杂的系统运维和管控。
阿里经过验证的件——EDAS
高性能服务框架
EDAS是一个高性能的服务框架,EDAS是由很多技术体系组成的一个整体包,如果想写一个web应用,使用这个开发套件,所有在业务开发需要的功能都集成在里面,所有和业务中间件相关的应用也集成到里面了,最关键之一就是HSF,HSF在阿里90%以上应用上使用,相对比较成熟,支持分布式事务,经历过七次双十一大促的考验,日均有千亿级的调用量。
同时,我们也支持Dubbo,Dubbo也是阿里开发出来的市面上应用非常广泛的开源软件,已经有4000多个开源分支。
分布式事务
在服务框架之上,还有分布式事务,在分布式应用里应该怎样完成单机应用中常见的一些事务操作呢?此时就需要使用分布式事务组件,它能够将服务和服务之间多个不同库之间的数据集中到一起去,从而提供一个整体的服务能力,看起来像写单机业务系统一样去写分布式事务服务框架。去中心化服务化框架,只是一个简单的开始。
分布式配置管理
可以在网站查询配置哪些机器收到、哪些机器没有收到,毫秒级推送,可以变更历史记录,推送轨迹追踪等。
立体化监控服务
资源+容器+应用 = 立体化监控服务
监控是我们非常关注的事情,对于系统整体的性能指标也非常重要,所以,我们会尝试从不同层面收集信息,具体包括以下三大方面:
系统资源:负载,CPU、内存、磁盘、网络 容器:堆内存、类加载、线程池、连接器 应用:响应时间、吞吐率、关键链路分析容器监控
容器监控要监控堆内存与非堆内存使用情况,类加载情况(对于排查线上启动问题非常方便),线程运行情况,连接器情况。
应用监控
应用监控主要从服务接口、方法的实时调用情况进行分析,以及调用QPS、响应时间分析,
快速感知系统流量变化,从而让我们知道系统的问题所在。监控和报警在这里得到很好的体现,但这仅仅算是刚刚进阶。
EDAS鹰眼跟踪
鹰眼监控就是解决内部非常复杂的多样链路的时候,怎样进行持续的收集、跟踪、统计,以帮助我们进行链路梳理的工具。比如从前面开始调用链路时有哪些异常,出现故障的地方都可以从这个调用链路上得到展现。
同时,通过海量调用链进行统计分析,得到链路各个依赖的稳定性指标。比如,某个地方的QPS很高,但这个系统不该有这么高的QPS,就可以认为这是一个依赖压力问题。
除了链路分析功能,EDAS还有容量规划的重要功能。通过线上真实引流到系统内进行压测分析,然后根据设定的运行水位计算系统承载的最高容量,从而到最后可以实现机器按需的上线和下线,把这些系统融会贯通在一起,就是整体的容量规划提供的功能。
EDAS限流降级
限流降级是阿里最有特色的功能之一,我们会面对非常强大的挑战就是双十一网购狂欢节,我们需要在成本和体验中选择一个好的平衡点,要利用这个平衡点我们必须要保证系统的可用性,不能因为用户多导致系统无法服务,就像排队买票一样,我们需要对自己的系统进行优化,具体表现在一下两方面:
限流:针对非核心服务调用者限制请求量 降级:针对系统的非核心服务依赖应用发布和管理系统
以前是集中化的发布方式进行管理的,这对于一、二百台机器是没有问题的。然而,现在需要同时发布五、六百台机器甚至更多,发布就会成为瓶颈。对此,我们内部引入EDAS燎原P2P发布系统,它能够让系统内进行P2P多点式的多host发布,使整个系统的应用发布能力得到快速提升。
EDAS燎原实现超大规模集群闪电发布,图中可以看出发布耗时随着机器数量增加变化趋势。采用EDAS燎原发布系统,随着应用实例的增加,发布的时间几乎保持不变。有利于进行紧急发布时候的业务处理,实现快速回滚。
阿里十年技术精华沉淀
综合来说,EDAS并不是简单的服务化工具,它希望在整个应用的编写周期里都可以进行操作,所以它结合了HSF、鹰眼、燎原等等。现在,它在公有云和专有云里都有输出。
阿里巴巴核心技术架构
阿里藏经阁天花板:高性能Java架构核心原理手册,一定要偷偷看 市面上讲Java框架的书很多,包括Sping Boot、Spring Cloud、Kafka等,但这些书通常只会让你技术的“量”增长,而“质”仍处于SSM的阶段。而且互联网上并没有体系化、结构化的提升技术的“质”的教材,于是这份阿里的高性能java架构核心手册就出来了!
高性能MySQL架构 在前面的文章里,分享了MySQL索引的原理及使用技巧、MySQL查询语句的优化等方面的知识。这些都是针对单个库的性能优化。在微服务和容器、云的时代,应用层可以很方便地水平扩展,用于支撑更大的并发量。
高性能 MySQL(一):逻辑架构 本篇文章主要描述了 MySQL 的服务器架构,以及对每一层服务进行简短的概述。我们可以使用一张图来表示 MySQL 的逻辑架构,这便于我们的理解与记忆。
相关文章
- 【华为云技术分享】HDC.Cloud|华为云Stack大咖说:如何实现微服务架构下的分布式事务
- ASP.NET Core微服务架构之Consul基础入门到实战
- 龙湖千丁基于 ACK@Edge 的云原生智慧停车系统架构实践
- EDA 事件驱动架构与 EventBridge 二三事
- 近万服务实例稳定运行 0 故障,携程微服务架构是如何落地的?
- 从零入门 Serverless | 架构的演进
- 理解RESTful架构
- Web应用扩展系列(1):架构篇(转)
- 为什么要微服务架构服务化?
- 架构那点事系列一 - 设计模式前章
- Atitit soa之道 艾提拉著作 SOA概念、技术与设计读书笔记 第3章 理解面向服务 10 第4章 理解面向服务架构 39 第5章 理解服务与微服务的层次 74 第6章 Web服务及微服务的
- 微服务架构的设计模式
- 一个关于微服务架构和monolithic架构的讨论
- 一个微服务架构的消费端
- DL之SqueezeNet:SqueezeNet算法的架构详解
- 带你了解 HBase 数据模型和 HBase 架构
- 基于CSE的微服务架构实践-Spring Boot技术栈选型
- 【成为架构师课程系列】怎样进行系统逻辑架构?
- 目前最新微服务架构技术栈选型
- 高并发架构演进之路(下)——一体化架构到微服务
- 8年Java老司机讲解——微服务架构VS单体架构