130 秒揭秘 EDAS 3.0 如何平滑应对突发流量高峰,为您的业务保驾护航
"在 PaaS 层面,我们始终拥抱开源技术,并保持和社区版本兼容的时效性;在企业特性上,例如服务治理、应用监控等方面,我们提供一个稳定成熟的产品,来降低企业构建互联网化应用的门槛,例如企业级应用服务 EDAS3.0 就是这样一个典型的产品"
——阿里巴巴合伙人、阿里云智能基础产品事业部 高级研究员蒋江伟
EDAS3.0作为应用托管和微服务管理的PaaS平台,支持SpringCloud、ApacheDubbo、ServiceMesh等服务运行环境,提供应用开发、部署、监控、运维等全栈式解决方案,同时平台通过AIOps(智能运维)为托管应用提供性能和稳定性保障。
通常,企业在云上构建互联网应用,都会遇到以下这些问题:
- 如何来确定一个分布式系统的容量?
- 如何实现更加智能的弹性的伸缩,用最低的成本,实现最高的容量?
- 当系统出现问题时,如何进行快速定位和诊断?
带着这三个问题,我们来看看 EDAS3.0 的云原生架构是如何满足真实场景下的流控难题和单点故障引起的交易成功率下降的问题的,详情如视频所示:
戳这里、戳这里、戳这里看视频,这里是视频哦~
演示系统
视频中演示应用是模拟了一个电商购物交易系统主要包括:系统网关、交易中心、商品中心和购物车四个模块,各个模块之间选择了dubbo和springcloud作为微服务框架进行系统间交互。整个应用选择了阿里云ACK容器服务集群作为部署底座,同时将该集群一键托管到EDAS3.0平台进行微服务治理、应用监控、以及应用部署运维操作。
整个演示流程,我们按照电商大促活动前系统压测演练为背景,使用PTS(Performance Testing Service性能测试)来模拟用户请求流量,EDAS3.0通过限流降级、智能弹性、故障诊断以及异常实例摘除等功能为整个压测演练保驾护航。接下来,我们按照演示流程对每个环节中涉及到的技术进行一一解读分析。
容量探测
对于大促系统压测演练,首先我们需要知道压测目标值(这个需要产品和运营根据历史活动和用户量进行评估),视频中的目标值为8000TPS(Transaction Per Second, 每秒事务数)。明确目标值以后,我们需要进行压测获取单机水位,这里我们利用了最佳压力值结合接口RT(Response Time,接口返回时间)进行单机容量评估。
如上图所示,最佳压力值指的是系统在最佳性能运行,连续成功率低于98%的点的前一个量级,同时结合我们对接口的SLA的RT上限800ms可以得出单机TPS(Transaction Per Second, 每秒事务数)在850左右(视频中选择了4台机器压测)。可以看出单机容量评估流程需要一定人工经验以及反复测试才可以完成,目前EDAS3.0已经在和PTS合作针对压测场景进行自动化容量评估以及性能诊断。完成上述单机水位评估后,我们即可根据目标值对系统容量进行手动扩容,在EDAS3.0系统中可以完成上述操作。完成扩容以后,通过PTS模拟需要压测的目标值8000TPS,观察扩容后的系统指标RT和交易成功率是否符合预期要求。
性能优化
像大多数首次上线的应用一样,这个电商交易模拟系统作为一个全新demo系统也是经历了多轮压测以及性能调优才达到最后视频中展示的效果。作为一个典型的dubbo微服务系统,这里分享一下整个调优过程中两个比较典型问题的调试过程。整个调试过程我们主要借助EDAS3.0的应用监控中心、日志中心以及Arthas工具进行排查和诊断。
首先来看第一个问题,完成第一步容量探测此时PTS的压力值为3400RPS,紧接着直接进行扩容来进行下一步目标值压测,在完成扩容后可以看到RT监控指标反而有上升波动同时会出现一段时间请求错误,这个和预期不符的。我们利用EDAS3.0监控的接口快照链路定位到下游checkout服务问题,同时利用实例监控定位具体是扩容前某个pod问题。接下来在日志中心检查该pod相应日志发现了dubbo线程池满的错误日志,同时发现dubbo多次重试的错误日志。综合分析可以得出根因是,节点调用下游超时重试导致线程池沾满,针对这种情况我们将超时时间、重试次数以及dubbo线程池进行了调整,经过多轮压测后得到合适参数。
完成上述优化以后,由于后续限流降级的需求我们代码引入了AHAS的SDK,同样在容量探测完成以后直接进行手动扩容来进行下一步目标值压测的时候,再次出现短暂的失败率反而上升的问题。有了上一轮调优经验,这一轮我们也是轻车熟路配合Arthas的使用以及AHAS引入时间点,定位到这次问题主要是AHAS的SDK初始化会导致RPC首次调用耗时增加,同时扩容后新节点自身需要预热问题,大流量直接打在新节点上会导致超时失败。针对这两点问题,我们通过启动主动调用AHAS的SDK初始化方法以及修改dubbo的延时注册和预热配置进行解决。
作为一个交易核心链路新系统上线进行压测是必不可少的环节,这也体现了云上PTS的压测系统对于用户重要性,在压测过程中遇到问题我们需要进行一轮轮调优,调优过程中EDAS3.0的监控中心和日志中心起到了重要作用,将整个条有过程变得有章可循同时节省了排查时间。最后,我们可以看到微服务线程池配置、超时配置以及重试配置等是比较常见的微服务问题,未来我们EDAS3.0智能运维(AIOps)可以将这些问题排查变得更加自动化帮助客户节省更多时间。
限流降级
在当今日益复杂的应用环境下,应用设计应该遵循“面向失败”的设计原则,对上下游的依赖零信任。借助流量控制、熔断降级模块,应用就有能力对流量采取限流控制,并对下游依赖进行降级处理。
面对视频中超过系统预估容量的突增流量,服务限流降级功能显得尤为重要了,我们知道一旦突发高流量将系统打垮,后续恢复将十分艰难,重启应用的预热,流量迁移等等给用户带来不好体验。EDAS3.0提供的一键接入服务限流降级功能,只需要您在部署阶段勾选接入限流降级服务,您的应用即可享受流量防护模块给您的应用全方位保护。目前该防护模块支持主流的Java框架,包括HTTP和Dubbo,同时可以实时监控框架的QPS(Queries per Second,每秒查询数)、线程数、响应时间、异常数等指标。
完成上述接入以后,在EDAS3.0监控详情页的服务/接口监控的限流降级菜单可以对接口进行规则配置以及实时指标监控,有了限流降级模块的保护,应用就可以从容面对线上突增流量的出现。
智能弹性
在分布式应用管理中,弹性伸缩是很重要的一个运维能力。弹性伸缩能够感知应用内各个实例的状态,并根据状态动态实现应用扩容、缩容,在保证服务质量的同时,提升应用的可用率。在弹性伸缩方面,EDAS3.0提供了更加智能丰富的弹性扩缩策略,包括监控指标策略和自定义弹性策略。同时,针对业务周期性我们还提供了定时弹性来支持该特定业务场景。
视频演示流程中突发流量在限流降级模块的保护下,应用抵挡住了超过系统容量上限的流量。该应用同时配置了单机QPS自定义指标的弹性扩缩策略,智能弹性模块会根据当前外部最新请求量进行智能弹性扩容,从而将超过预估的流量一并吃掉,保证系统稳定性的同时也提升了用户使用产品体验。
离群摘除
在微服务架构中,当服务提供者的应用实例出现异常,而服务消费者无法感知时会影响服务的正常调用,并影响消费者的服务性能甚至可用性。离群实例摘除功能会检测应用实例的可用性并进行动态调整,以保证服务成功调用,从而提升业务的稳定性和服务质量。目前,EDAS3.0微服务治理中的离群摘除功能会在客户端统计服务的指标数据,比如调用次数和错误次数,根据用户的规则配置进行流量摘除。
智能运维
互联网时代,应用并发量激增,业务流程更加复杂,如何保证系统稳定性越发困难,系统可观测性越来越重要。EDAS3.0系统在满足应用运行态和发布态可观测性的基础上,又进一步做到了智能运维(AIOps)。目前,智能运维已成为了应对IT系统与日俱增的复杂性的很好的解决方案, 它基于大数据、数据分析和算法来提供洞察力,并为现代基础设施和软件所需的管理任务提供更高水平的自动化。全球最具权威的IT研究与顾问咨询公司Gatner公司最新AIOps报告预测到2023年,全球40%的DevOps团队会使用AIOps工具。EDAS3.0作为监管控一体化PaaS平台,已经在AIOps领域深耕多年,并将其落地在应用运行态和发布态等多个场景。
如上图所示Gartner总结当下AIOps中涉及的三个主要流程Observer、Engage和Act,EDAS3.0的智能运维(AIOps)也是依照上述流程进行整体诊断分析。
整体来看,EDAS3.0智能运维流程主要包含以下三个部分:异常检测、根因分析和诊断处理。其中,异常检测阶段选择了应用黄金指标中的RT(接口响应时间)和错误率作为检测目标,利用算法和应用历史指标数据进行异常检测分析。
在根因分析阶段,系统会根据单机、服务以及关联事件三个维度对异常进行解释和分析。通过三个维度指标检测最终会给出故障可能的原因,在复杂的微服务系统中可以很好的辅助运维人员对故障进行排查和复盘。
在完成根因分析以后,EDAS3.0智能运维系统会根据分析结果进行相应的修复建议、运维自动化处理,同时会给出一份诊断报告对本次故障进行问题定位分析帮助开发同学进行问题排查。诊断报告包含了故障定界、根因分析结果以及相应的建议或者推荐。
演示视频中,通过制造下游节点fullgc故障,从而引发上游接口RT(响应时间)的上升。EDAS3.0智能运维系统自动会检测到此次RT(响应时间)上升的异常,并会针对RT突增异常进行分析检测,最终根据检测结果进行相应的修复手段,如视频中所见在检测出是下游的单机fullgc问题后,智能运维系统通过EDAS3.0微服务治理提供的离群摘除能力将故障机器进行隔离,隔离后故障恢复。
最后综述,EDAS3.0作为分布式架构、数字化转型上云的首选在线业务应用托管平台,在微服务治理、应用发布变更以及智能运维等多个维度为用户应用提供智能化、自动化的解决方案,欢迎大家使用。
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
服务发现技术选型那点事儿
作者 | 张羽辰(同昭) 引子——什么是服务发现 近日来,和很多来自传统行业、国企、政府的客户在沟通技术细节时,发现云原生所代表的技术已经逐渐成为大家的共识,从一个虚无缥缈的概念渐渐变成这些客户的下一个技术战略。自然,应用架构就会提到微服务,以及其中最重要的分布式协作的模式——服务发现。模式(pattern)是指在特定上下文中的解决方案,很适合描述服务发现这个过程。不过相对于 2016 年,现在我们最少有十多种的方式能实现服务发现,这的确是个好时机来进行回顾和展望,最终帮助我们进行技术选型与确定演进方向。 微服务脱胎于 SOA 理论,核心是分布式,但单体应用中,模块之间的调用(比如让消息服务给客户发送一条数据)是通过方法,而所发出的消息是在同一块内存之中,我们知道这样的代价是非常小的,方法调用的成本可能是纳秒级别,我们从未想过这样会有什么问题。但是在微服务的世界中,模块与模块分别部署在不同的地方,它们之间的约束或者协议由方法签名转变为更高级的协议,比如 RESTful 、PRC,在这种情况下,调用一个模块就需要通过网络,我们必须要知道目标端的网络地址与端口,还需要知道所暴露的协议,然后...
- 下一篇
如何提升微服务的幸福感?
作者|亦盏 前言 随着微服务的流行,越来越多公司使用了微服务框架,微服务以其高内聚、低耦合等特性,提供了更好的容错性,也更适应业务的快速迭代,为开发人员带来了很多的便利性。但是随着业务的发展,微服务拆分越来越复杂,微服务的治理也成了一个比较令人头疼的问题,我相信下面这些场景大家或多或少都遇到过。 场景一:发布是天大的事情,每一次的发布,都会出现执行到一半的请求中断掉,上游继续调用已经下线的节点导致报错的现象。发布时收到各种报错,同时还影响用户的体验,发布后又需要修复执行到一半的脏数据。 上述场景还是在新版本没有任何问题的情况下,如果新版本有问题,则会导致大量业务直接请求到有问题的新版本,轻则修复数据,重则严重影响用户体验,甚至产生资损。最后不得不每次发版都安排在凌晨两三点发布,心惊胆颤,睡眠不足,苦不可言。 场景二:大半夜某个服务节点出现异常,上游仍旧不断地调用,出现很多异常和各种报警短信。被报警吵醒后,想直接在线上修复,有点难,想保留现场又害怕拖垮整个应用,只好先重启为上。 但是这只是治标不治本的方式,因为很难复现从而无法有效定位,可能明天又被吵醒,继续重启。上述场景还是建立在报警系...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
-
Docker使用Oracle官方镜像安装(12C,18C,19C)
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- CentOS8编译安装MySQL8.0.19
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- MySQL8.0.19开启GTID主从同步CentOS8
- CentOS7,8上快速安装Gitea,搭建Git服务器
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
推荐阅读
最新文章
- CentOS6,7,8上安装Nginx,支持https2.0的开启
- SpringBoot2全家桶,快速入门学习开发网站教程
- CentOS8编译安装MySQL8.0.19
- Docker安装Oracle12C,快速搭建Oracle学习环境
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题
- CentOS关闭SELinux安全模块
- CentOS7编译安装Gcc9.2.0,解决mysql等软件编译问题
- CentOS8安装Docker,最新的服务器搭配容器使用
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- CentOS7设置SWAP分区,小内存服务器的救世主