消息队列和应用工具产品体系-APM 系统简述和架构演化

本文涉及的产品
Serverless 应用引擎 SAE,800核*时 1600GiB*时
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
可观测链路 OpenTelemetry 版,每月50GB免费额度
简介: 消息队列和应用工具产品体系-APM 系统简述和架构演化

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

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


消息队列和应用工具产品体系-APM 系统简述和架构演化

 

内容介绍

一、APM系统简述

二、离线计算与实时计算的区别

三、架构演化

 

一、APM 系统简述

分布式架构中另一个非常重要的组件,应用性能管理系统以及阿里云的对应产品ARMS。APM也就是应用性能监控管理系统,作为运维的监控和管理工具,实际上已经存在了很长时间。但是APM作为一个细分领域单独提出来,还是在2010年左右。APM系统在发展阶段上可以大致分为两个阶段。其中,第一阶段的APM是在上世纪末推出的,可以用来监控和分析当时的比较典型的三层架构的应用和性能。不过,第一代APM相对比较笨重,基本以本地软件加硬件的形式来提供。需要用户投入大量的精力和成本来进行实质和维护。第二代APM的兴起主要是面向大量采用分布式架构消息总线和弹性虚拟化,云计算框架的应用。因此,第二代APM除了保有第一代APM的功能之外,还引入了拓扑逻辑的自动发现来更好地监控分布式架构应用。同时,为了适应敏捷开发持续交付带来的应用代码的频繁变化,第二代APM引入了自动插装技术,来实现监控代码的自动部署。用户不用修改任何的代码,或者仅仅需要修改少量的代码,即可以快速灵活的部署APM探针来实现监控,极大的节约了部署和维护APM的成本。相比较于第一代的APM,第二代APM另一个比较重大的变化是,在第二代APM中,终端用户的用户体验成为了关键的监测项目,这是由于互联网和移动互联网的应用交付产品下,越来越多的业务都依赖于应用本身的服务质量和最终用户体验,APM服务的SARS也是第二代APM的一个重大变化。原有的第一代APM产品基本上都是以私有化为部署的本地软件的形式进行提供的。而第二代APM的服务SARS化让用户可以以更便利、更低成本的方式来快速部署和使用以前价格昂贵、维护和部署非常困难的APM产品。在我们现有的监控系统中,APM到底能带来哪些不同的价值呢?我们可以从Gartner公司发表的调查报告:Gartner APM魔力象限对APM服务的五个维度来了解一下APM到底能做什么。这五个维度的定义从2012年推出至今,基本上没有太大的变化,下面我们逐一对这五个维度进行一下讲解。

 

图片1.png

 

· 作为应用程序性能管理和故障管理的系统化的解决方案

· 能够对企业的关键业务和IT系统的各个层面进行集中的监测、优化

· 提高企业应用的可靠性和质量

· 随着分布式系统和微服务的应用,APM成为系统运维管理和网络管理的一个重要方向

第一个维度是最终用户体验监测,这个维度要求从客户端到服务端来采集最终用户访问应用时的性能体验,包括客户端到服务端的网络延迟、应用享用时间、享用成功率和质量等。最终用户体验监测除了从真实用户的访问来进行之外,还可以通过主动似的模拟最终用户监测来进行应用可用性的评估。最终用户监测始终是APM最重要的维度,没有之一。这也是APM 与传统运维监测最重要的差别。传统的运维监测一般都是自下而上的监测,关注点在系统和服务层面,通过对基础架构、系统、服务、应用的监测来保障服务的高可用和应用的体验效果。而APM是自上而下的监控,关注点在最终用户的体验层面。通过对用户体验、网络、应用以及服务的监控来保证应用的高可用和体验效果。

第二个维度是应用拓扑的发现和可视化。这个维度的意思是指能够自动识别应用在执行的过程中涉及的软硬件架构和组件。并且可以描绘出应用交付链中互相通信的各个组件的访问路径,也就是我们常说的调用链路。这一个维度也是非常非常重要的,通过将应用的调用链路与拓扑图、调用图等图表可视化的方法可以直观的显示应用之间的拓扑逻辑。这个维度最重要的一个实践就是提供全链路的应用拓扑图。

第三个维度是用户定义的事件剖析。这个维度要求从用户请求的角度来对业务中产生的监控事件进行追踪。例如当开发者发现性能问题时,可以通过一个特定的用户标识如用户名、手机号、用户ID等来追踪APP访问购物流程中每一个步骤的详细情况,采集每一个请求中最为详细的代码、服务、组件的访问性能和异常数据。这个维度要求APM可以根据要求对用户的访问事件进行完整的追踪。包括在整个请求过程中涉及到第二个维度中发现的服务和组件。

第四个维度是应用组件的深度钻取。这个维度要求对第二个维度里发现的服务和组件的资源消耗和事件提供足够细力度的监控。例如对应用访问数据库服务MQ服务等提供深度的监控。当发现有数据库服务查询性能问题时,可以提供包含完整的SQL语句、执行计划、数据波状态等在内的详细监控数据。

第五个维度是IT运营分析。这个维度其实就是运维数据分析。他要求使用以下技术的组合来进行运维数据的分析,包括复杂事件处理统计模式的发现与识别、非结构化数据引擎、非结构化数据索引、查询和推理、拓扑逻辑分析、多维数据库查询和分析。这里的数据分析技术都是为了对APM采集到的大量的、个维度的性能数据进行实时的运算和处理。从而对应用的运维和优化起到辅助决策和驱动作用的。例如,通过实时的智能机械和异常监测来驱动报警系统。

 

二、离线计算与实时计算的区别

第二代APM和第一代APM相比,另一个比较显著的特点在于,第一代APM往往使用离线计算技术来处理采集数据。而第二代APM基本上抛弃了离线计算模式,改为使用实时计算框架来处理采集数据。这里介绍一下离线计算和实时计算的区别。

 

图片2.png

 

· 互联网时代的APM系统,对数据实时性的要求非常高

· 相比较于传统离线计算小时到分钟级别的延迟,新一代实时计算框架毫秒级别的延迟才能满足需求

在过去的一段时间里,以Hadoop为代表的分布式离线计算平台以其良好的扩展性和易用性,几乎已经成为了海量数据处理的事实标准,获得了大面积的应用。特别是在拥有海量用户、众多产品和巨大流量的互联网公司,这种离线平台的核心特点就是先将所有的数据收集好,然后启动特定的计算任务,对这些数据进行计算。而任务的完成时间是计算复杂度,数据量不同而不同。从几分钟到几小时甚至几天不等。这种离线批量热处理的方式,在统计报表、用户分析等领域非常适合。但是随着用户对实质性需求的越来越高,离线批量计算的方式开始显现出了它的不足,甚至在有些场景下完全无法使用。比如在个性化精准推荐领域,最常见的问题就是如何统计当前10秒内某个地区25~35岁男性用户对某个特定广告的点击率。这个问题有几个明显的特征,第一,实质性要求非常强,几乎是要求毫秒级的响应延迟。

第二,计算的复杂度非常高,需要计算的维度也很多。以上面的例子来看,就是地区乘以年龄乘以性别乘以广告ID这四个维度的组合,而且还会任意增加。比如后面很容易增加学历,婚姻状况,收入水平,上网场景等等维度。第三,这种需求往往具有滑动窗口的概念,也就是计算的结果,会随着时间的推移,每秒钟都在变化。而这种需求用传统的批量计算,采取先收集数据再计算的方法,无论多大的海都不集群,都无法满足要求。因此,实时数据处理正越来越受到互联网公司的欢迎。作为海量数据处理的另一大利器,实时数据处理,专门为时延敏感的业务提供海量数据的实时处理服务。通过对海量数据的实时采集、实时计算、实时感知、外部变化,从事件的发生到感知变化到输出计算结果整个的过程中秒级完成。换句话说,需求方再也不用忍受为了一个新数据结构而等上几十分钟甚至一小时的情况。在实时数据处理场景中,所有的数据都在数据接入的过程中,以秒级的时间就已经被加工成用户希望看到的模式,供用户使用。

 

三、架构演化

从系统架构的角度看第一代APM和第二代APM的差别。

图片3.png

 

· 传统业务监控架构

· 定制复杂,对生产数据库有影响

· 多为离线计算,无法满足业务监控实时性

· 基础组建昂贵,需要定制化硬件和一体机

· 互联网实时业务监控架构

· 基于日志的业务监控,解耦生产数据

· 基于流计算框架,能做到准实时

· 可视化的流计算定制接口,降低入门门槛

· 内置报表大屏定制组件以及数据持久层组件

如左图所示,传统的业务监控系统,其架构制定比较复杂,数据来源往往基于数据库层面。因此,对生产数据库往往会产生性能或安全性上的影响。同时,传统APM的各个基础组件价格昂贵,需要制定化硬件或一体机才能实现其功能。而在数据计算上,传统的APM大多是基于离线ETL工具和数据仓库系统构建的,无法满足企业的业务监控实时性要求。而新的一代互联网APM系统在数据源上大部分都是基于业务日志进行监控,这样做既可以解耦生产数据,又可以避免监控系统对生产数据库的影响。而在数据处理方面,互联网APM系统大多基于流计算框架进行数据处理。相比较于传统的离线技术,流计算能做到大致上的实时数据处理。同时,新一代的互联网APM系统,大多提供了可视化的流计算制定接口降低了使用APM系统的入门门槛。同时在系统中一般会内置报表大屏、制定组件以及数据化持久组件。但是也要看到的是当前的互联网实时业务监控系统的组件大多比较零散,采用开源组件搭积木的方式进行构架,缺乏端到端的整体打包方案,同时对业务的日志侵入式改造成本较高,业务方需要自行编制各个流计算、reduce、以及报表等实现。实现周期长且门槛高。

以右图为例,通过开源组件构建实时业务监控系统,一般需要如下的流程。首先通过Flume组件对大量的数据源进行日志采集。当日志采集完毕后,再将数据推入高吞吐、高负载的Kafka消息对立,进行日志的缓存和推送准备。而流计算引擎Storm是一个分布式高容错的实时计算系统,可以用来处理源源不断的消息,并将处理之后的结果推入到持久化介质中。在实时业务监控系统中,Storm负责从Kafka中消费数据并根据用户编写的流计算任务,对数据进行业务处理。经过Storm处理之后,数据结果会进入报表工具,以呈现业务大盘同时通过Hadoop、ES等持久化产品进行存储。

相关实践学习
通过云拨测对指定服务器进行Ping/DNS监测
本实验将通过云拨测对指定服务器进行Ping/DNS监测,评估网站服务质量和用户体验。
相关文章
|
21天前
|
Ubuntu Linux
查看Linux系统架构的命令,查看linux系统是哪种架构:AMD、ARM、x86、x86_64、pcc 或 查看Ubuntu的版本号
查看Linux系统架构的命令,查看linux系统是哪种架构:AMD、ARM、x86、x86_64、pcc 或 查看Ubuntu的版本号
143 3
|
6天前
|
Cloud Native Devops 持续交付
探索云原生架构:构建高效、灵活和可扩展的系统
本文将深入探讨云原生架构的核心概念、主要技术以及其带来的优势。我们将从云原生的定义开始,了解其设计理念和技术原则;接着分析容器化、微服务等关键技术在云原生中的应用;最后总结云原生架构如何助力企业实现数字化转型,提升业务敏捷性和创新能力。通过这篇文章,读者可以全面了解云原生架构的价值和应用前景。
|
7天前
|
运维 Cloud Native Devops
云原生架构的崛起与实践云原生架构是一种通过容器化、微服务和DevOps等技术手段,帮助应用系统实现敏捷部署、弹性扩展和高效运维的技术理念。本文将探讨云原生的概念、核心技术以及其在企业中的应用实践,揭示云原生如何成为现代软件开发和运营的主流方式。##
云原生架构是现代IT领域的一场革命,它依托于容器化、微服务和DevOps等核心技术,旨在解决传统架构在应对复杂业务需求时的不足。通过采用云原生方法,企业可以实现敏捷部署、弹性扩展和高效运维,从而大幅提升开发效率和系统可靠性。本文详细阐述了云原生的核心概念、主要技术和实际应用案例,并探讨了企业在实施云原生过程中的挑战与解决方案。无论是正在转型的传统企业,还是寻求创新的互联网企业,云原生都提供了一条实现高效能、高灵活性和高可靠性的技术路径。 ##
17 3
|
8天前
|
缓存 运维 NoSQL
二级缓存架构极致提升系统性能
本文详细阐述了如何通过二级缓存架构设计提升高并发下的系统性能。
|
22天前
|
设计模式 存储 前端开发
揭秘.NET架构设计模式:如何构建坚不可摧的系统?掌握这些,让你的项目无懈可击!
【8月更文挑战第28天】在软件开发中,设计模式是解决常见问题的经典方案,助力构建可维护、可扩展的系统。本文探讨了.NET中三种关键架构设计模式:MVC、依赖注入与仓储模式,并提供了示例代码。MVC通过模型、视图和控制器分离关注点;依赖注入则通过外部管理组件依赖提升复用性和可测性;仓储模式则统一数据访问接口,分离数据逻辑与业务逻辑。掌握这些模式有助于开发者优化系统架构,提升软件质量。
33 5
|
19天前
|
微服务 API Java
微服务架构大揭秘!Play Framework如何助力构建松耦合系统?一场技术革命即将上演!
【8月更文挑战第31天】互联网技术飞速发展,微服务架构成为企业级应用主流。微服务将单一应用拆分成多个小服务,通过轻量级通信机制交互。高性能Java Web框架Play Framework具备轻量级、易扩展特性,适合构建微服务。本文探讨使用Play Framework构建松耦合微服务系统的方法。Play采用响应式编程模型,支持模块化开发,提供丰富生态系统,便于快速构建功能完善的微服务。
27 0
|
21天前
|
消息中间件 Java RocketMQ
微服务架构师的福音:深度解析Spring Cloud RocketMQ,打造高可靠消息驱动系统的不二之选!
【8月更文挑战第29天】Spring Cloud RocketMQ结合了Spring Cloud生态与RocketMQ消息中间件的优势,简化了RocketMQ在微服务中的集成,使开发者能更专注业务逻辑。通过配置依赖和连接信息,可轻松搭建消息生产和消费流程,支持消息过滤、转换及分布式事务等功能,确保微服务间解耦的同时,提升了系统的稳定性和效率。掌握其应用,有助于构建复杂分布式系统。
34 0
|
2月前
|
消息中间件 C语言 RocketMQ
消息队列 MQ操作报错合集之出现"Connection reset by peer"的错误,该如何处理
消息队列(MQ)是一种用于异步通信和解耦的应用程序间消息传递的服务,广泛应用于分布式系统中。针对不同的MQ产品,如阿里云的RocketMQ、RabbitMQ等,它们在实现上述场景时可能会有不同的特性和优势,比如RocketMQ强调高吞吐量、低延迟和高可用性,适合大规模分布式系统;而RabbitMQ则以其灵活的路由规则和丰富的协议支持受到青睐。下面是一些常见的消息队列MQ产品的使用场景合集,这些场景涵盖了多种行业和业务需求。
|
2月前
|
消息中间件 Java C语言
消息队列 MQ使用问题之在使用C++客户端和GBase的ESQL进行编译时出现core dump,该怎么办
消息队列(MQ)是一种用于异步通信和解耦的应用程序间消息传递的服务,广泛应用于分布式系统中。针对不同的MQ产品,如阿里云的RocketMQ、RabbitMQ等,它们在实现上述场景时可能会有不同的特性和优势,比如RocketMQ强调高吞吐量、低延迟和高可用性,适合大规模分布式系统;而RabbitMQ则以其灵活的路由规则和丰富的协议支持受到青睐。下面是一些常见的消息队列MQ产品的使用场景合集,这些场景涵盖了多种行业和业务需求。
|
5天前
|
消息中间件
手撸MQ消息队列——循环数组
队列是一种常用的数据结构,类似于栈,但采用先进先出(FIFO)的原则。生活中常见的排队场景就是队列的应用实例。在数据结构中,队列通常用数组实现,包括入队(队尾插入元素)和出队(队头移除元素)两种基本操作。本文介绍了如何用数组实现队列,包括定义数组长度、维护队头和队尾下标(front 和 tail),并通过取模运算解决下标越界问题。此外,还讨论了队列的空与满状态判断,以及并发和等待机制的实现。通过示例代码展示了队列的基本操作及优化方法,确保多线程环境下的正确性和高效性。
14 0
手撸MQ消息队列——循环数组

相关产品

  • 应用实时监控服务