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

本文涉及的产品
函数计算FC,每月15万CU 3个月
注册配置 MSE Nacos/ZooKeeper,118元/月
应用实时监控服务-用户体验监控,每月100OCU免费额度
简介: 消息队列和应用工具产品体系-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监测,评估网站服务质量和用户体验。
相关文章
|
1月前
|
Cloud Native Java API
聊聊从单体到微服务架构服务演化过程
本文介绍了从单体应用到微服务再到云原生架构的演进过程。单体应用虽易于搭建和部署,但难以局部更新;面向服务架构(SOA)通过模块化和服务总线提升了组件复用性和分布式部署能力;微服务则进一步实现了服务的独立开发与部署,提高了灵活性;云原生架构则利用容器化、微服务和自动化工具,实现了应用在动态环境中的弹性扩展与高效管理。这一演进体现了软件架构向着更灵活、更高效的方向发展。
|
3月前
|
运维 Cloud Native 开发者
云原生时代下的微服务架构演化之路
【8月更文挑战第20天】在数字化转型的浪潮下,企业级应用纷纷拥抱云原生架构。本文将深入探讨微服务架构在适应云原生环境的过程中所面临的挑战与机遇,并分析如何通过优化设计、容器化技术及自动化运维,实现高效、灵活且可靠的系统构建。
178 65
|
2月前
|
消息中间件 弹性计算 运维
云消息队列RabbitMQ 版架构优化评测
云消息队列RabbitMQ 版架构优化评测
64 6
|
3月前
|
消息中间件 存储 Java
图解Kafka:Kafka架构演化与升级!
图解Kafka:Kafka架构演化与升级!
89 0
图解Kafka:Kafka架构演化与升级!
|
3月前
|
Cloud Native 持续交付 开发者
云原生之旅:从传统到现代的架构演化
本文将通过一次虚拟的旅行,带领读者穿越回过去,探索软件架构的发展脉络。我们将从单体应用开始,一路经过服务化拆分,最终抵达云原生的乐土。这不仅是一段技术演进的历史,也是对如何在不断变化的技术浪潮中保持初心与创新的启示录。
43 2
|
4月前
|
Kubernetes 关系型数据库 分布式数据库
PolarDB产品使用问题之PolarDB-X的架构形态有什么区别
PolarDB产品使用合集涵盖了从创建与管理、数据管理、性能优化与诊断、安全与合规到生态与集成、运维与支持等全方位的功能和服务,旨在帮助企业轻松构建高可用、高性能且易于管理的数据库环境,满足不同业务场景的需求。用户可以通过阿里云控制台、API、SDK等方式便捷地使用这些功能,实现数据库的高效运维与持续优化。
|
3月前
|
敏捷开发 测试技术 持续交付
阿里云云效产品使用合集之如何管理企业的组织架构
云效作为一款全面覆盖研发全生命周期管理的云端效能平台,致力于帮助企业实现高效协同、敏捷研发和持续交付。本合集收集整理了用户在使用云效过程中遇到的常见问题,问题涉及项目创建与管理、需求规划与迭代、代码托管与版本控制、自动化测试、持续集成与发布等方面。
|
4月前
|
供应链 Java 中间件
软件架构一致性问题之研发新产品创造价值如何解决
软件架构一致性问题之研发新产品创造价值如何解决
36 0
|
4月前
|
消息中间件 缓存 架构师
对抗软件复杂度问题之降低代码的复杂度,如何解决
对抗软件复杂度问题之降低代码的复杂度,如何解决
|
4月前
|
消息中间件 存储 缓存
架构设计篇问题之消息队列(MQ)在微服务系统中问题如何解决
架构设计篇问题之消息队列(MQ)在微服务系统中问题如何解决

相关产品

  • 应用实时监控服务