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

本文涉及的产品
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
Serverless 应用引擎免费试用套餐包,4320000 CU,有效期3个月
应用实时监控服务-可观测链路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监测,评估网站服务质量和用户体验。
相关文章
|
11天前
|
监控 安全 API
使用PaliGemma2构建多模态目标检测系统:从架构设计到性能优化的技术实践指南
本文详细介绍了PaliGemma2模型的微调流程及其在目标检测任务中的应用。PaliGemma2通过整合SigLIP-So400m视觉编码器与Gemma 2系列语言模型,实现了多模态数据的高效处理。文章涵盖了开发环境构建、数据集预处理、模型初始化与配置、数据加载系统实现、模型微调、推理与评估系统以及性能分析与优化策略等内容。特别强调了计算资源优化、训练过程监控和自动化优化流程的重要性,为机器学习工程师和研究人员提供了系统化的技术方案。
132 77
使用PaliGemma2构建多模态目标检测系统:从架构设计到性能优化的技术实践指南
|
5天前
|
机器学习/深度学习 算法 数据可视化
基于深度混合架构的智能量化交易系统研究: 融合SSDA与LSTM自编码器的特征提取与决策优化方法
本文探讨了在量化交易中结合时序特征和静态特征的混合建模方法。通过整合堆叠稀疏降噪自编码器(SSDA)和基于LSTM的自编码器(LSTM-AE),构建了一个能够全面捕捉市场动态特性的交易系统。SSDA通过降噪技术提取股票数据的鲁棒表示,LSTM-AE则专注于捕捉市场的时序依赖关系。系统采用A2C算法进行强化学习,通过多维度的奖励计算机制,实现了在可接受的风险水平下最大化收益的目标。实验结果显示,该系统在不同波动特征的股票上表现出差异化的适应能力,特别是在存在明确市场趋势的情况下,决策准确性较高。
25 5
基于深度混合架构的智能量化交易系统研究: 融合SSDA与LSTM自编码器的特征提取与决策优化方法
|
16天前
|
机器学习/深度学习 人工智能 并行计算
【AI系统】Kernel 层架构
推理引擎的Kernel层负责执行底层数学运算,如矩阵乘法、卷积等,直接影响推理速度与效率。它与Runtime层紧密配合,通过算法优化、内存布局调整、汇编优化及调度优化等手段,实现高性能计算。Kernel层针对不同硬件(如CPU、GPU)进行特定优化,支持NEON、AVX、CUDA等技术,确保在多种平台上高效运行。
69 32
|
16天前
|
存储 机器学习/深度学习 人工智能
【AI系统】计算图优化架构
本文介绍了推理引擎转换中的图优化模块,涵盖算子融合、布局转换、算子替换及内存优化等技术,旨在提升模型推理效率。计算图优化技术通过减少计算冗余、提高计算效率和减少内存占用,显著改善模型在资源受限设备上的运行表现。文中详细探讨了离线优化模块面临的挑战及解决方案,包括结构冗余、精度冗余、算法冗余和读写冗余的处理方法。此外,文章还介绍了ONNX Runtime的图优化机制及其在实际应用中的实现,展示了如何通过图优化提高模型推理性能的具体示例。
45 4
【AI系统】计算图优化架构
|
6天前
|
机器学习/深度学习 前端开发 算法
婚恋交友系统平台 相亲交友平台系统 婚恋交友系统APP 婚恋系统源码 婚恋交友平台开发流程 婚恋交友系统架构设计 婚恋交友系统前端/后端开发 婚恋交友系统匹配推荐算法优化
婚恋交友系统平台通过线上互动帮助单身男女找到合适伴侣,提供用户注册、个人资料填写、匹配推荐、实时聊天、社区互动等功能。开发流程包括需求分析、技术选型、系统架构设计、功能实现、测试优化和上线运维。匹配推荐算法优化是核心,通过用户行为数据分析和机器学习提高匹配准确性。
30 3
|
3天前
|
前端开发 搜索推荐 安全
陪玩系统架构设计陪玩系统前后端开发,陪玩前端设计是如何让人眼前一亮的?
陪玩系统的架构设计、前后端开发及前端设计是构建吸引用户、功能完善的平台关键。架构需考虑用户需求、技术选型、安全性等,确保稳定性和扩展性。前端可选用React、Vue或Uniapp,后端用Spring Boot或Django,数据库结合MySQL和MongoDB。功能涵盖用户管理、陪玩者管理、订单处理、智能匹配与通讯。安全性方面采用SSL加密和定期漏洞扫描。前端设计注重美观、易用及个性化推荐,提升用户体验和平台粘性。
29 0
|
3天前
|
监控 Java 数据中心
微服务架构系统稳定性的神器-Hystrix
Hystrix是由Netflix开源的库,主要用于微服务架构中的熔断器模式,防止服务调用失败引发级联故障。它通过监控服务调用的成功和失败率,在失败率达到阈值时触发熔断,阻止后续调用,保护系统稳定。Hystrix具备熔断器、资源隔离、降级机制和实时监控等功能,提升系统的容错性和稳定性。然而,Hystrix也存在性能开销、配置复杂等局限,并已于2018年进入维护模式。
15 0
|
18天前
|
弹性计算 API 持续交付
后端服务架构的微服务化转型
本文旨在探讨后端服务从单体架构向微服务架构转型的过程,分析微服务架构的优势和面临的挑战。文章首先介绍单体架构的局限性,然后详细阐述微服务架构的核心概念及其在现代软件开发中的应用。通过对比两种架构,指出微服务化转型的必要性和实施策略。最后,讨论了微服务架构实施过程中可能遇到的问题及解决方案。
|
27天前
|
Cloud Native Devops 云计算
云计算的未来:云原生架构与微服务的革命####
【10月更文挑战第21天】 随着企业数字化转型的加速,云原生技术正迅速成为IT行业的新宠。本文深入探讨了云原生架构的核心理念、关键技术如容器化和微服务的优势,以及如何通过这些技术实现高效、灵活且可扩展的现代应用开发。我们将揭示云原生如何重塑软件开发流程,提升业务敏捷性,并探索其对企业IT架构的深远影响。 ####
42 3
|
1月前
|
Cloud Native 安全 数据安全/隐私保护
云原生架构下的微服务治理与挑战####
随着云计算技术的飞速发展,云原生架构以其高效、灵活、可扩展的特性成为现代企业IT架构的首选。本文聚焦于云原生环境下的微服务治理问题,探讨其在促进业务敏捷性的同时所面临的挑战及应对策略。通过分析微服务拆分、服务间通信、故障隔离与恢复等关键环节,本文旨在为读者提供一个关于如何在云原生环境中有效实施微服务治理的全面视角,助力企业在数字化转型的道路上稳健前行。 ####

相关产品

  • 应用实时监控服务