自SpringCloud问世以来,微服务以席卷之势风靡全球,企业架构都在从传统SOA向微服务转型。然而微服务这把双刃剑在带来各种优势的同时,也给运维、性能监控、错误的排查带来的极大的困难。
在大型项目中,服务架构会包含数十乃至上百个服务节点。往往一次请求会设计到多个微服务,想要排查一次请求链路中经过了哪些节点,每个节点的执行情况如何,就称为了亟待解决的问题。于是分布式系统的APM管理系统应运而生。
什么是APM系统?
APM系统可以帮助理解系统行为、用于分析性能问题的工具,以便发生故障的时候,能够快速定位和解决问题,这就是APM系统,全称是(Application Performance Monitor)。
谷歌公开的论文提到的 Google Dapper可以说是最早的APM系统了,给google的开发者和运维团队帮了大忙,所以谷歌公开论文分享了Dapper。
而后,很多的技术公司基于这篇论文的原理,设计开发了很多出色的APM框架,例如Pinpoint、SkyWalking等。
而SpringCloud官网也集成了一套这样的系统:Spring Cloud Sleuth,结合Zipkin。
APM的基本原理
目前大部分的APM系统都是基于Google的Dapper原理实现,我们简单来看看Dapper中的概念和实现原理。
先来看一次请求调用示例:
1、服务集群中包括:前端(A),两个中间层(B和C),以及两个后端(D和E)
2、当用户发起一个请求时,首先到达前端A服务,然后A分别对B服务和C服务进行RPC调用;
3、B服务处理完给A做出响应,但是C服务还需要和后端的D服务和E服务交互之后再返还给A服务,最后由A服务来响应用户的请求;
如何才能实现跟踪呢?
Google的Dapper设计了下面的几个概念用来记录请求链路:
·Span:请求中的基本工作单元,每一次链路调用(RPC、Rest、数据库调用)都会创建一个Span。大概结构如下:
·Trace:一次完整的调用链路,包含多个Span的树状结构,具有唯一的TraceID
一次请求的每个链路,通过spanId、parentId就能串联起来:
当然,从请求到服务器开始,服务器返回response结束,每个span存在相同的唯一标识trace_id。
APM的筛选标准
目前主流的APM框架都会包含下列几个组件来完成链路信息的收集和展示:
·探针(Agent):负责在客户端程序运行时搜索服务调用链路信息,发送给收集器
·收集器(Collector):负责将数据格式化,保存到存储器
·存储器(Storage):保存数据
·UI界面(WebUI):统计并展示收集到的信息
因此,要筛选一款合格的APM框架,就是对比各个组件的使用差异,主要对比项:
·探针的性能
主要是agent对服务的吞吐量、CPU和内存的影响。如果探针在收集微服务运行数据时,对微服务的运行产生了比较大的性能影响,相信没什么人愿意使用。
·collector的可扩展性
能够水平扩展以便支持大规模服务器集群,保证收集器的高可用特性。
·全面的调用链路数据分析
数据的分析要快 ,分析的维度尽可能多。跟踪系统能提供足够快的信息反馈,就可以对生产环境下的异常状况做出快速反应,最好提供代码级别的可见性以便轻松定位失败点和瓶颈。
·对于开发透明,容易开关
即也作为业务组件,应当尽可能少入侵或者无入侵其他业务系统,对于使用方透明,减少开发人员的负担。
·完整的调用链应用拓扑
自动检测应用拓扑,帮助你搞清楚应用的架构
接下来,我们就对比下目前比较常见的三种APM框架的各项指标,分别是:
·Zipkin:由Twitter公司开源,开放源代码分布式的跟踪系统,用于收集服务的定时数据,以解决微服务架构中的延迟问题,包括:数据的收集、存储、查找和展现。
·Pinpoint:一款对Java编写的大规模分布式系统的APM工具,由韩国人开源的分布式跟踪组件。
·Skywalking:国产的优秀APM组件,是一个对JAVA分布式应用程序集群的业务运行情况进行追踪、告警和分析的系统。现在是Apache的顶级项目之一。
三者对比如下:
可见,zipkin的探针性能、开发透明性、数据分析能力都不占优,实在是下下之选。
而pinpoint在数据分析能力、开发透明性上有较大的优势,不过Pinpoint的部署相对比较复杂,需要的硬件资源较高。
Skywalking的探针性能和开发透明性上具有较大优势,数据分析能力上也还不错,重要的是其部署比较方便灵活,比起Pinpoint更适合中小型企业使用。
因此,本文会带着大家学习Skywalking的使用。
猜你喜欢:
原创文章,作者:ItWorker,如若转载,请注明出处:https://blog.ytso.com/253648.html