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

简介: 消息队列和应用工具产品体系-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等持久化产品进行存储。

相关实践学习
通过轻量消息队列(原MNS)主题HTTP订阅+ARMS实现自定义数据多渠道告警
本场景将自定义告警信息同时分发至多个通知渠道的需求,例如短信、电子邮件及钉钉群组等。通过采用轻量消息队列(原 MNS)的主题模型的HTTP订阅方式,并结合应用实时监控服务提供的自定义集成能力,使得您能够以简便的配置方式实现上述多渠道同步通知的功能。
相关文章
|
前端开发 JavaScript 关系型数据库
如何开发生产小工单中的产品管理板块(附架构图+流程图+代码参考)
生产小工单中的产品管理板块是制造业数字化管理的关键环节,涵盖产品信息、生产工序、产品列表和基础设置四大功能模块。通过系统化管理,企业可实现对产品属性、工艺流程及资源配置的精准控制,提升生产效率并减少误差与浪费。本文详解了各功能模块的设计逻辑、业务流程及开发实现方案,并提供示例代码,助力企业构建高效、灵活的产品管理系统。
|
Java API 开发工具
灵码产品演示:软件工程架构分析
本演示展示灵码对复杂软件项目的架构分析与文档生成能力。通过Qwen3模型,结合PlantUML,自动生成系统架构图、微服务时序图,并提取API接口文档,实现高效、智能的代码理解与文档输出。
715 5
|
消息中间件 缓存 NoSQL
Redis 是一个高性能的键值对存储系统,常用于缓存、消息队列和会话管理等场景。
【10月更文挑战第4天】Redis 是一个高性能的键值对存储系统,常用于缓存、消息队列和会话管理等场景。随着数据增长,有时需要将 Redis 数据导出以进行分析、备份或迁移。本文详细介绍几种导出方法:1)使用 Redis 命令与重定向;2)利用 Redis 的 RDB 和 AOF 持久化功能;3)借助第三方工具如 `redis-dump`。每种方法均附有示例代码,帮助你轻松完成数据导出任务。无论数据量大小,总有一款适合你。
468 6
|
Cloud Native Java API
聊聊从单体到微服务架构服务演化过程
本文介绍了从单体应用到微服务再到云原生架构的演进过程。单体应用虽易于搭建和部署,但难以局部更新;面向服务架构(SOA)通过模块化和服务总线提升了组件复用性和分布式部署能力;微服务则进一步实现了服务的独立开发与部署,提高了灵活性;云原生架构则利用容器化、微服务和自动化工具,实现了应用在动态环境中的弹性扩展与高效管理。这一演进体现了软件架构向着更灵活、更高效的方向发展。
|
前端开发 NoSQL 关系型数据库
如何开发CRM系统中的产品管理板块(附架构图+流程图+代码参考)
本文深入解析了CRM系统中产品管理模块的设计与实现,涵盖系统架构、业务流程、核心代码及落地建议,助力企业构建高效的产品管理体系。
|
人工智能 自然语言处理 供应链
AI时代企业难以明确大模型价值,AI产品经理如何绘制一张‘看得懂、讲得通、落得下’的AI产品架构图解决这一问题?
本文产品专家系统阐述了AI产品经理如何绘制高效实用的AI产品架构图。从明确企业六大职能切入,通过三层架构设计实现技术到业务的精准转译。重点解析了各职能模块的AI应用场景、通用场景及核心底层能力,并强调建立"需求-反馈"闭环机制。AI产品专家三桥君为AI产品经理提供了将大模型能力转化为商业价值的系统方法论,助力企业实现AI技术的业务落地与价值最大化。
790 0
|
消息中间件 存储 大数据
阿里云消息队列 Kafka 架构及典型应用场景
阿里云消息队列 Kafka 是一款基于 Apache Kafka 的分布式消息中间件,支持消息发布与订阅模型,满足微服务解耦、大数据处理及实时流数据分析需求。其通过存算分离架构优化成本与性能,提供基础版、标准版和专业版三种 Serverless 版本,分别适用于不同业务场景,最高 SLA 达 99.99%。阿里云 Kafka 还具备弹性扩容、多可用区部署、冷热数据缓存隔离等特性,并支持与 Flink、MaxCompute 等生态工具无缝集成,广泛应用于用户行为分析、数据入库等场景,显著提升数据处理效率与实时性。
|
消息中间件 Java Kafka
初识Apache Kafka:搭建你的第一个消息队列系统
【10月更文挑战第24天】在数字化转型的浪潮中,数据成为了企业决策的关键因素之一。而高效的数据处理能力,则成为了企业在竞争中脱颖而出的重要武器。在这个背景下,消息队列作为连接不同系统和服务的桥梁,其重要性日益凸显。Apache Kafka 是一款开源的消息队列系统,以其高吞吐量、可扩展性和持久性等特点受到了广泛欢迎。作为一名技术爱好者,我对 Apache Kafka 产生了浓厚的兴趣,并决定亲手搭建一套属于自己的消息队列系统。
599 2
初识Apache Kafka:搭建你的第一个消息队列系统
|
存储 消息中间件 缓存
独特架构打造新一代消息队列Apache Pulsar
Apache Pulsar 是一个开源的分布式消息流平台,由雅虎开发并于 2016 年开源,2018 年成为 Apache 顶级项目。Pulsar 通过独特的架构提供多租户、持久化存储和批处理等高级功能,支持高吞吐量、低延迟的消息传递。其核心组件包括 Broker、Apache BookKeeper 和 Apache ZooKeeper,分别负责消息处理、持久化存储和集群管理。
855 1

相关产品

  • 应用实时监控服务