消息队列和应用工具产品体系 - AHAS 产品概述

本文涉及的产品
云原生网关 MSE Higress,422元/月
容器服务 Serverless 版 ACK Serverless,317元额度 多规格
应用实时监控服务-用户体验监控,每月100OCU免费额度
简介: 消息队列和应用工具产品体系 - AHAS 产品概述

开发者学习笔记【阿里云云原生助理工程师认证(ACA)课程:消息队列和应用工具产品体系 - AHAS  产品概述】

课程地址:https://edu.aliyun.com/course/3112075/lesson/19044


消息队列和应用工具产品体系 - AHAS  产品概述

 

内容介绍:

一、 AHAS  产品应用高可用服务概述

二、四大功能模块

三、AHAS  应用场景

四、AHAS  应用防护简介

五、AHAS  架构感知简介

六、AHAS  故障演练简介

七、AHAS 功能开关简介

八、阿里云 AHAS 高可用整体解决方案

 

一、 AHAS  产品应用高可用服务概述

1、应用高可用服务(Application High Availability Service)

应用高可用服务是一款专注于提高应用高可用能力的  AHAS  产品。它结合了阿里巴巴开源的混沌测试工具和限流熔断降级工具。还包含了架构感知,流量防护功能开关,故障演练四大独立功能模块

image.png

 

二、四大功能模块

1、架构感知功能

架构感知功能可以自动感知应用的拓扑结构,并以可视化的方式直重建并持续记录应用和基础架构的依赖关系,以及组件之间的依赖关系。

2、流量防护功能

流量防护功能提供了专业化多样的限流手段,可以实现秒级的实时流量监控,同时具备立刻生效的规则管理功能。

3、故障演练功能

故障演练功能提供了基于真实线上故障的高可用能力演练服务。可以根据开发者的应用框架,智能推荐故障演练场景。

4、功能开关

功能开关模块能按照统一的方式定义管理业务运行时的功能切换。支持自定义任意类型的配置项。且自动根据类型做自动拆装,但无需关注类型信息。简化运行时的配置项使用流程。

 

三、 AHAS  应用场景

AHAS 应用场景不单包括了分布式微服务架构下的高可用场景同样适用于传统应用架构下的高可用场景。

1、微服务场景

spring cloud ,Kubermetes 等微服务架构已经成为了企业级应用的主流架构。而微服务天生的分布式调用方法对服务的高可用性提出了前所未有的挑战。借助 AHAS 开发者可以在零代码改动的前提下,快速使用高可用服务,包括架构可视化架构变化,追踪故障演练和流量防护的功能。同时 AHAS 支持阿里云容器服务 Kubermetes 应用的快速接入spring cloud 组件的快速发现,故障演练能力。也可以为springboard应用提供了一键流量服务功能。

2、传统应用场景

在传统应用场景下,由于缺乏高可用能力。对于传统的java单体应用和分布式应用而言,如何保证稳定性和连续性是个难题。 AHAS 提供了应用高可用保障所必备的架构,实时展现与追踪架构高可用性故障演练以及java应用代码零改动接入流量防护功能的能力。已经上线的应用也无需进行升级改造。此外,对于引入的开源或第三方组件 AHAS 可以进行自动化的智能评估并提供优化使用方面的指导。

 

四、 AHAS  应用防护简介    

1、 AHAS 的应用防护

AHAS 的应用防护功能是流量防护模块中最重要的功能。 AHAS 应用防护以流量为切入点,从流量控制,熔断降级,系统负载保护等多个维度来保障业务的稳定性。提供更专业稳定的流量防护手段,秒级的流量水位分布分析功能,是阿里巴巴双11技术体系中的核心组件,同时也是开源框架的商业化产品。 

AHAS 的应用防护主要用于秒杀场景消息削峰填谷,集群流量控制,实施垄断等场景中在一个常见的分布式应用中,业务的请求大致的传递结果如下图所示。

image.png

 

请求先经过终端达到gateway,再经过防火墙和网络负载均衡,其中还可能调用下游的其他服务或第三方应用才能达到前端网络服务。

在这些中间环节中,都可能会产生流量过载的问题。表 AHAS 应用防护所支持的一部分的业务组件。涵盖了webservice微服务框架,rpc框架,客户端数据库缓存消息队列等开发中常用的功能组件涉及到了全域应用执行环境。

AHAS 应用防护在不同的层次。提供了以流量为切面的秒级实施流量分析,帮助运维人员采取针对性的防护措施,全面的保护应用整体运行环境的稳定。

2、服务提供方或消费方流控

AHAS 的应用防护可以从服务提供方或者服务消费方进行流量控制。

其中服务提供方限流是指在对外提供请求的服务或应用一侧进行流量控制。这种模式下的限流逻辑和传统限流概念基本一致。为了保证服务提供方不被激增的流量拖垮而影响了应用的整体稳定性开发者可以为服务提供配置qps模式的流控规则。

以左图为例。服务提供者a每秒最多能承受十次调用。当每秒的请求数超过十次时。 AHAS 将拒绝多余的请求,使其快速返回,并发异常提醒

同时提供方限流,还可以再细分成两种。分别为。服务接口限流和服务方法限流。其中,服务接口限流适用于控制整个服务接口的qps。不超过一定数值的情况。服务方法,限流可以针对服务接口中的某个方法的qps进行单独的限流控制。 

AHAS 支持的第二种限流方式是根据服务消费方限流。这种方式是指根据调用方的需求来分配服务提供方的处理能力。以右图为例,有两个服务消费者a和B都向服务提供者发起请求,这开发者希望优先服务消费方A对来自消费方B的请求进行限流,就可以通过对消费方B设置限流规则来实现这个目的。当使用服务消费者方限流时,如果微服务框架是默认框架如 double  AHAS 会自动解析double消费方的名称作为调用名称,以便线格框架可以通过名称来区分服务调用方。而对于非默认框架,则需要在原有的代码中加入相应的调用方名称设置,以便限流框架。可以做区分。

 

image.png

 

3、强依赖隔离和弱依赖降级

在限流降级中服务的依赖等级往往决定了限流降级的执行策略。依赖等级又可以分为两种。分别是强依赖和弱依赖。一般来讲,某一请求所依赖的第三方应用组件或内部方法出错时会影响整体的业务流程。则我们就把这种依赖称为强依赖。对于强依赖。开发者需要配置隔离原则。来保护系统的稳定性。

具体来说当强依赖出现不稳定时。可以通过配置并发线程数隔离原则。来限制不稳定的强依赖并发。 AHAS 会控制资源的线程数。当请求数超过一值时,将拒绝多余的请求直到堆积的线程处理完成,以此来达到信号量隔离的效果。

在某一请求所依赖的第三方应用出错时,并不会影响整体业务的流程。则我们对这种依赖称为弱依赖。对于弱依赖不稳定性一般说需要配置降级规则来保护系统的稳定性。具体来说就是如果应用以弱依赖的方式关联多个下游服务时,下游服务调用过慢则会严重影响当前服务的调用为调用端配置,基于平均响应时间或错误率的降级规则后。当调用链路中某个下游服务调用的平均响应时间或错误率超过预值时, AHAS 就会对此调用进行降级操作,拒绝多余的调用保护应用,不被调用端短板影响。

image.png

 

4、匀速请求实现同步调用的削峰填谷

消息队列最重要的功能之一就是在异步调用的过程中,为应用提供消息缓存的能力实现请求的削峰填谷。在同步远程调用时,同样会存在流量洪峰的问题。简单的采取限流的方式进行直接返回。同样会造成洪峰时服务调用成功率过低,而低谷时服务计算资源空前浪费的情况。因此 AHAS 提供了流控降级的排队等待功能。通过排队等待功能,可以把骤增的大量的请求匀速分配。以固定的时间间隔让请求通过。这样当消费端请求骤增时可以先将请求排队,以便服务提供者能以稳定的速度逐步处理这些请求起到削峰填谷的作用。例如某应用的请求处理能力是每秒十个。在某一秒内突然到来了30个请求。而接下来的两秒都没有请求。在这种情况下,直接拒绝20个请求应用在接下来的联网中就会空闲所以需要把骤增的请求平均到一段时间内,让系统负载保持在请求处理水位之内,同时尽可能多的处理更多请求。在图片中,黄色的部分表示超过消息处理能力的部分。把黄色部分的消息平均到空闲时间的处理。这样既可以保证系统负担,保持稳定状态,又可以尽量尽可能做的消息。通过配置流控规则可以达到消息匀速处理的效果。这里要注意的是。 AHAS 的同步排队功能和其他排队的功能最大的不同是避免长时间的等待造成的系统资源空转,同步排队等待会设置超时时间。当请求的预计排的时间超过最大时长时。 AHAS 将直接拒绝这部分超时的请求,例如配置匀速模式下的请求则每200毫秒处理一条请求,多余的处理任务将排队。同时设置了超时时长为5,则预计排队时长超过五秒,请求将直接被拒绝。

 

image.png

 

5、通过流量塑性实现冷系统预热启动

对于新启动服务实力或者长期处于低水平状态的服务。如果要进入大流量满负荷工作状态,往往需要经过加载应用程序的资源申请系统资源,建立外服务连接等一系列准备操作。而这些准备操作往往需要一定的执行时间且需要占用额外的系统资源。在系统没有完成准备工作之前,就贸然将系统负载水位拉高。很有可能出现瞬间把服务压垮,导致服务崩溃的情况发生。因此,为了利于这种情况的发生。就可使用 AHAS 中的冷启动功能。来避免流量骤增导致水位瞬间升高,引起了系统不可用的情况。通过配置能冷启动规则。可以让通过的流量缓慢增加。在一定时间内逐步增加预先上限。给老系统一个预热时间,避免老系统被压跨。以图为例。为了保证服务的顺利预热。可以 AHAS 中配置冷启动规则。配置系统的峰值流量为480,预热时间为2s。这样在应用启动后会 AHAS 首先从峰值流量的三分之一作为流量上线开始允许应用通过。开始允许请求通过,并在两秒之内。将允许通过的流量逐步增加到峰值流量。这样就避免了冷系统被压垮的情况发生。

 

image.png

 

五、AHAS  架构感知简介

1、架构感知功能

架构感知功能可对云上的资产和资源做有效的掌握。当开发者在系统中安装了 AHAS 探针之后。 AHAS 就能自动识别系统中的进程容器和主机。自动采集和分析操作系统以及第三方标准接口信息。再通过这些信息捕捉接口和接口之间的进程级调用关系。

同时,架构感知可以根据自身的特征库算法智能识别进程所使用的技术组件。分析出应用组件对基础架构的依赖关系组件之间的依赖关系,组建之间的进程拓扑,容器主机关系。最后在服务器容器进程这三个维度上架构感知可以以可视化的方式。整体展示应用和系统架构之间的拓扑关系

 

image.png

 

2、架构感知常用视图

架构感知可以通过四种视图来展现资源和应用之间拓扑关系,它们分别是云资源视图,Kubermetes 资源视图,应用视图和风险视图。

(1)云资源视图。

云资源视图通过调用云产品的open api方法。构建云产品之间的逻辑拓扑关系。现已覆盖ecs云虚拟主机。Rds云存储。

cdn节点加速dns域名解析,消息队列,缓存,负载均衡,网关,应用防火墙等产品。主要负责展示产品之间的基本物理关系和逻辑关系。

(2)Kubermetes 资源视图。

当开发者为 AHAS 应用安装指针之后。能自动识别系统中组建的依赖关系。通过采集开关 Kubermetes 语言信息。构建 Kubermetes  资源的物理拓扑关系。同时, Kubermetes  资源视图,支持自建开发Kubermetes  集群和阿里云容器服务 Kubermetes  集群。

(3)应用视图

应用视图页面,通过采集主机的进程与网络数据,来展示主机部署应用的拓扑关系。 AHAS 将主机进程分为四位,分别是服务间的虚拟进程,操作系统进程,阿里云服务进程,用户进程。开发者可以通过筛选进行类型来查看进程的拓扑图和详细信息。

(4)风险视图

风险视图中集成了云资源视图与智能顾问风险巡检的结果。在云视图的基础上,增加可视化风险结果。用于呈现云服务架构的风险分布和风险趋势。在风险视图中,除了显示某个云产品的详细信息。还会显示包括事件,告警风险等相关的信息。同时,开发者还可以通过自动巡检功能。自动的产品进行智能巡检和风险告警。

 

image.png


六、 AHAS  故障演练简介

AHAS 的故障演练是cosplay的云上商业版本。作为 AHAS 一部分。故障演练与 AHAS 其他功能组成了一套完整的高可用保障服务。可以帮助用户实现包括架构,业务,人员的全面提升。故障在其中承担着问题发现,问题验证,高可用经验沉淀的功能。

AHAS 的故障演练的信用场景有五个。

(1)衡量微服务的容错能力。通过模拟调用延迟,服务不可能用或机器资源满载等情况。查看发现故障的节点或实力是否被自动隔离下线,流量调度是否正确,预案是否有效。同时,观察系统整体的qps或rt是否受到影响。在此基础上可以缓慢增加故障节点范围,验证上下游服务限流降级,熔断等是否有效。最终故障节点增加了请求服务超时。估算系统融容错红线衡量系统的容错能力。

(2)是验证容器编排配置是否合理。通过模拟服务,增大资源负载。观测系统服务的可用性。验证负载配置,资源限制,资源限制配置以及po下部署的容器是否合理。

(3)检测paas层是否健壮。通过模拟验证调度系统的有效性,模拟依赖的分布式存储不可用,验证系统的容错性,模拟调度节点不可用,测试调度服务是否自动迁移到可用节点,模拟主节点故障测试主备切换是否正常?

(4)检验监控告警的时效性。通过对系统注入故障,检验监控指标是否准确?监控维度是否完善,告警阈值是否合理和告警是否快速?告警接收是否正确,通知渠道是否可用等,提高监控告警的准确性和时效性。

(5)定位与解决问题的应急能力。通过故障突袭。随机系统注入故障考察相关人员对问题的应急能力以及问题上报处理的流程是否合理,达到以站养站,锻炼人定位与解决问题的能力。

 

image.png

 

AHAS 故障演练又被称为 AHAS  chaos。在 AHAS  chaos 内部。包含着丰富的故障场景。从常见的基础设施资源,如 CPU 内存磁盘的故障,以及应用级别的故障注入和云原生领域的演练场景。无论是需要设置集群级别,大规模故障,还是应用请求级别的细力度故障都可以在中找到合适的场景。下图是提供的部分故障场景。同时支持演练,包含多个定义的故障场景。还可以制定这些场景的运行方式。选择依次进行故障或者同时进行故障,通过不同的策略配置来达到不同的故障注入效果。

image.png

 

在演练执行阶段, AHAS  chaos将故障演练分为四个环节。分别是安装探针,创建演练,执行演练和停止演练。通过四阶段的流程,覆盖用户从计划到还原的完整演练的过程。可以通过可视化的方式清晰的呈现给用户。

在安装探阶段,需要在指定的演练机上安装故障演练探针。这个作用是下发故障演练执行命令。在创建演练阶段,开发者需要配置演练基本信息演练对象和演练全局参数,在创建演练时可以同时选择多个故障类型。在执行演练阶段, AHAS  chaos 将故障注入,可以通过演练实时演练,演练参数,演练日志等检查故障注入的效果是否符合预期。停止演练,当故障演练结束时,主动终止或演练出现异常后,系统回到恢复状态,自动清理相关故障。使故障之下恢复到演练前的状态。

 

七、AHAS 功能开关简介

AHAS chaos 功能开关是一个轻量级的动态配置框架。

1、AHAS chaos 功能

通过功能开关可以动态管理代码中的配置项。并根据需求为应用开启或关闭部分功能或设置某个系统指标的阈值。通常业务代码中包含了许多的配置项。这些配置项用于控制各式各样的业务逻辑,例如一个布尔类型的变量控制某功能的开启,一个list控制访问白名单和黑名单等。开发者通常希望可以动态实时的去查看和修改,并希望不需要编代码来进行管理。此时可以利用 AHAS 的功能来实现实时修改和查看对应的配置。与传统配置中心不同,开发者使用 AHAS 功能开关无需关注配置项目解析逻辑,只需声明对应变量并加上 AHAS 功能开关的注解,在功能配置台就能进行动态管理。

功能开关通常应用在以下场景中。

首先是运行时动态调整日志级别。在特定场合下。有时开放者需要动态的调整日志级别,以便输出更多的日志信息排查现场问题或者减少日志打印带来的性能消耗。在不同的应用场景下,开发者可以随时调整日志级别得到更有效的信息。

其次是主动降级业务场景。通常业务功能包含了许多的业务逻辑。其中可以区分出一些核心逻辑和非核心逻辑。在高并发场景下,例如618双11等场景。为了提升系统性能。系统需要减少非必要系统的资源消耗。对非必要的业务功能进行主动降级。最后是快速实现黑白名单场景。黑白名单是常用的控制访问规则。可以实现对不同用户的身份识别和过滤。以达到控制用户权限的目的。

 

image.png

 

2、功能开关操作流程

功能开关的使用流程是比较简单的,在正式使用功能开关之前,需要先对功能模块进行引入工作。

首先在应用工程文件中加入引用。接下来再将应用程序接入功能开关接入的流程有两种方式可以选择。第一种是通过的sdk方式进行接入。这种方式下,需要通过全局静态函式进行模块初始化。第二是通过spring进行接入。这种方式只需要再加入springboard switch的泡米用。既通过注解的方式实现模块初始化。

在功能模块引入工作完成之后,既可以开始功能开发模块。具体的使用步骤如图描述的。首先在代码中加入功能开关控制的变量。然后在变量上加入功能开关的特定注解。变量的属性值可以被读取。读取变量取值后,还可以通过控制台对变量属性进行修改。在修改配置之后,属性值会推送到功能开关所控制的变量之上。实现业务逻辑的动态切换

 

 

image.png

 

 

八、阿里云 AHAS 高可用整体解决方案

阿里云提供了 AHAS ,pts等工具,从规划,线上管控、演练和容灾等各个阶段,提供了一系列的应用服务来保障业务的高可用性。

在规划准备阶段,开发者需要对系统进行架构设计和容量评估。开发者可以使用 AHAS 的架构感知功能来自动构建架构拓朴并使用pps加速平台来进行系统的规划。

在线上控管执行阶段。开发者需要时刻管控系统的流量。控制业务逻辑。当遇到流量洪峰或功能异常时。服务要有足够的强壮性同时运维人员和开发者能迅速感知异常及时切换业务逻辑。这时 AHAS 提供的流量防护和功能功能。则可以帮助开发者实现管控线上业务的能力。在演练排查阶段,开发者需要主动进行故障注入,以模拟和演练小概率异常情况下出现的问题。进而发现并验证系统设计中是否存在问题。同时锻炼系统和相关人员的应急能力。而 AHAS 将阿里内部多年的经验浓缩成了专家经验。通过专家经验。围绕系统架构的弱点。自动生成有针对性的演练场景,极大的提高了开发者演练效率和成功率。而在容灾防护阿里云同样提供了同城双活和异地双活等方案助力开发者建立稳定的系统容灾方案

 

 

image.png

相关文章
|
5月前
|
消息中间件 测试技术 RocketMQ
消息队列 MQ产品使用合集之在异步发送消息函数sendMessage()中出现了错误,错误代码为-3,该如何解决
消息队列(MQ)是一种用于异步通信和解耦的应用程序间消息传递的服务,广泛应用于分布式系统中。针对不同的MQ产品,如阿里云的RocketMQ、RabbitMQ等,它们在实现上述场景时可能会有不同的特性和优势,比如RocketMQ强调高吞吐量、低延迟和高可用性,适合大规模分布式系统;而RabbitMQ则以其灵活的路由规则和丰富的协议支持受到青睐。下面是一些常见的消息队列MQ产品的使用场景合集,这些场景涵盖了多种行业和业务需求。
|
5月前
|
消息中间件 监控 Oracle
消息队列 MQ产品使用合集之启动Namesrv节点时,遇到报错,该如何解决
消息队列(MQ)是一种用于异步通信和解耦的应用程序间消息传递的服务,广泛应用于分布式系统中。针对不同的MQ产品,如阿里云的RocketMQ、RabbitMQ等,它们在实现上述场景时可能会有不同的特性和优势,比如RocketMQ强调高吞吐量、低延迟和高可用性,适合大规模分布式系统;而RabbitMQ则以其灵活的路由规则和丰富的协议支持受到青睐。下面是一些常见的消息队列MQ产品的使用场景合集,这些场景涵盖了多种行业和业务需求。
|
5月前
|
消息中间件 Java RocketMQ
消息队列 MQ产品使用合集之当SpringBoot应用因网络不通而启动失败时,该如何解决
消息队列(MQ)是一种用于异步通信和解耦的应用程序间消息传递的服务,广泛应用于分布式系统中。针对不同的MQ产品,如阿里云的RocketMQ、RabbitMQ等,它们在实现上述场景时可能会有不同的特性和优势,比如RocketMQ强调高吞吐量、低延迟和高可用性,适合大规模分布式系统;而RabbitMQ则以其灵活的路由规则和丰富的协议支持受到青睐。下面是一些常见的消息队列MQ产品的使用场景合集,这些场景涵盖了多种行业和业务需求。
|
5月前
|
消息中间件 存储 Java
Java中的消息队列应用与性能优化
Java中的消息队列应用与性能优化
|
5月前
|
消息中间件 网络协议 JavaScript
消息队列 MQ产品使用合集之报错提示是"the internal error!",是什么原因导致的”
消息队列(MQ)是一种用于异步通信和解耦的应用程序间消息传递的服务,广泛应用于分布式系统中。针对不同的MQ产品,如阿里云的RocketMQ、RabbitMQ等,它们在实现上述场景时可能会有不同的特性和优势,比如RocketMQ强调高吞吐量、低延迟和高可用性,适合大规模分布式系统;而RabbitMQ则以其灵活的路由规则和丰富的协议支持受到青睐。下面是一些常见的消息队列MQ产品的使用场景合集,这些场景涵盖了多种行业和业务需求。
|
4月前
|
消息中间件 监控 Java
在Java应用中实现微服务间的消息队列通信
在Java应用中实现微服务间的消息队列通信
|
4月前
|
消息中间件 存储 Java
Java中的消息队列应用与性能优化
Java中的消息队列应用与性能优化
|
5月前
|
消息中间件 Java API
消息队列 MQ产品使用合集之遇到"No topic route info in name server for the topic"错误,该如何处理
消息队列(MQ)是一种用于异步通信和解耦的应用程序间消息传递的服务,广泛应用于分布式系统中。针对不同的MQ产品,如阿里云的RocketMQ、RabbitMQ等,它们在实现上述场景时可能会有不同的特性和优势,比如RocketMQ强调高吞吐量、低延迟和高可用性,适合大规模分布式系统;而RabbitMQ则以其灵活的路由规则和丰富的协议支持受到青睐。下面是一些常见的消息队列MQ产品的使用场景合集,这些场景涵盖了多种行业和业务需求。
|
5月前
|
消息中间件 Java Shell
消息队列 MQ产品使用合集之启动broker&proxy的时候会报错,该怎么办
消息队列(MQ)是一种用于异步通信和解耦的应用程序间消息传递的服务,广泛应用于分布式系统中。针对不同的MQ产品,如阿里云的RocketMQ、RabbitMQ等,它们在实现上述场景时可能会有不同的特性和优势,比如RocketMQ强调高吞吐量、低延迟和高可用性,适合大规模分布式系统;而RabbitMQ则以其灵活的路由规则和丰富的协议支持受到青睐。下面是一些常见的消息队列MQ产品的使用场景合集,这些场景涵盖了多种行业和业务需求。
|
4月前
|
消息中间件 C语言 RocketMQ
消息队列 MQ操作报错合集之出现"Connection reset by peer"的错误,该如何处理
消息队列(MQ)是一种用于异步通信和解耦的应用程序间消息传递的服务,广泛应用于分布式系统中。针对不同的MQ产品,如阿里云的RocketMQ、RabbitMQ等,它们在实现上述场景时可能会有不同的特性和优势,比如RocketMQ强调高吞吐量、低延迟和高可用性,适合大规模分布式系统;而RabbitMQ则以其灵活的路由规则和丰富的协议支持受到青睐。下面是一些常见的消息队列MQ产品的使用场景合集,这些场景涵盖了多种行业和业务需求。

相关产品

  • 应用高可用服务