1.问题背景

   随着微服务架构的流行,服务按照不同的维度进行拆分,一次请求往往需要涉及到多个服务。互联网应用构建在不同的软件模块集上,这些软件模块,有可能是由不同的团队开发、可能使用不同的编程语言来实现、有可能布在了几千台服务器,横跨多个不同的数据中心。
 

1.1 微服务面临的问题:

  • 某个核心服务挂了,导致大量报错,如何快速确定哪里出了问题?
  • 用户请求响应延迟高,怎么确定是哪些服务导致的?
  • 应用程序有性能瓶颈,怎样确定瓶颈在哪里?
  • 如何准实时的了解应用部署环境(CPU、内存、进程、线程、网络、带宽)情况,以便快速扩容/缩容、流量控制、业务迁移
  • 如何统计各个调用的性能指标,比如:吞吐量(TPS)、响应时间及错误记录等
     

1.2 如何解决?

  • 方法一:业务端解决
    • 占用多个不同业务开发人员的大量时间与精力,并且未必能够快速的有效的解决问题

 

  • 方法二:分布式请求跟踪系统
    • 需要一些可以帮助开发人员理解系统行 为,快速定位问题的工具,分布式请求跟踪系统应运而生

1.3 分布式请求跟踪系统:

 

2.SkyWalking概述

2.1 SkyWalking 是什么?

APM(Application Performance Management & Monitoring)系统

分布式系统的应用程序性能监视工具,专为微服务、云原生架构和基于容器(Docker、K8s、Mesos)架构而设计。提供分布式追踪、服务网格遥测分析、度量聚合和可视化一体化解决方案。

2.2 SkyWalking 有哪些功能?

  • 多种监控手段。可以通过语言探针和 service mesh 获得监控是数据。
  • 多个语言自动探针。包括 Java,.NET Core 和     Node.JS。
  • 轻量高效。无需大数据平台,和大量的服务器资源。
  • 模块化。UI、存储、集群管理都有多种机制可选。
  • 支持告警。
  • 优秀的可视化解决方案。

​​​​​​​

2.3 SkyWalking 整体架构

整个架构,分成上、下、左、右四部分:

探针基于不同的来源可能是不一样的, 但作用都是收集数据, 将数据格式化为 SkyWalking 适用的格式.

平台后端是一个支持集群模式运行的后台, 用于数据聚合, 数据分析以及驱动数据流从探针到用户界面的流程. 平台后端还提供了各种可插拔的能力, 如不同来源数据(如来自 Zipkin)格式化, 不同存储系统以及集群管理. 你甚至还可以使用观测分析语来进行自定义聚合分析.

存储是开放式的. 你可以选择一个既有的存储系统, 如 ElasticSearch, H2 或 MySQL 集群(Sharding-Sphere 管理), 也可以选择自己实现一个存储系统. 当然, 我们非常欢迎你贡献新的存储系统实现.

用户界面对于 SkyWalking 的最终用户来说非常炫酷且强大. 同样它也是可定制以匹配你已存在的后端的
 

2.4 Tracing、Logging和Metrics

   在微服务领域,很早以来就形成了Tracing、Logging和Metrics相辅相成,合力支撑多维度、多形态的监控体系,三类监控各有侧重:

Tracing它在单次请求的范围内,处理信息。 任何的数据、元数据信息都被绑定到系统中的单个事务上。例如:一次调用远程服务的RPC执行过程;一次实际的SQL查询语句;一次HTTP请求的业务性ID;

 

Logging日志,不知道大家有没有想过它的定义或者边界。Logging即是记录处理的离散事件,比如我们应用的调试信息或者错误信息等发送到ES;审计跟踪时间信息通过Kafka处理送到BigTable等数据仓储等等,大多数情况下记录的数据很分散,并且相互独立,也许是错误信息,也许仅仅只是记录当前的事件状态,或者是警告信息等等。

 

Metrics当我们想知道我们服务的请求QPS是多少,或者当天的用户登录次数等等,这时我们可能需要将一部分事件进行聚合或计数,也就是我们说的Metrics。可聚合性即是Metrics的特征,它们是一段时间内某个度量(计数器或者直方图)的原子或者是元数据。例如接收的HTTP数量可以被建模为计数器,每次的HTTP请求即是我们的度量元数据,可以进行简单的加法聚合,当持续了一段时间我们又可以建模为直方图。

 

在Peter Bourgon的《Metrics,tracing, and logging》博客中,给出了如下关系图。

 

 

所以,日志系统,度量系统,追踪系统这三个纬度所关注重点是不一样的。一般来说日志系统是对我们应用或者系统事件做一个记录,这些记录是我们问题排查,取证的一些依据;度量系统是对某些我们关注事件的聚合,当达到一定指标我们会设置告警,会设置自适应机制,会有容灾等等;在追踪系统我们更关注请求的质量和服务可行性,是我们优化系统,排查问题的高阶方法。一般来说,它们的优先级依次降低。


 

2.5市面市面上主流监控对比:3.APM对比

 

cat

zipkin

pinpoint

skywalking 

依赖

  • Java 6,7,8
  • Maven 3.2.3+
  • mysql5.6
  • Linux 2.6以及之上(2.6内核才可以支持epoll)
  • Java 6,7,8
  • Maven3.2+
  • rabbitMQ
  • Java 6,7,8
  • maven3+
  • Hbase0.94+
  • Java 6,7,8
  • maven3.0+
  • nodejs
  • zookeeper
  • elasticsearch

实现方式

代码埋点(拦截器,注解,过滤器等)

拦截请求,发送(HTTP,mq)数据至zipkin服务

java探针,字节码增强

java探针,字节码增强

存储选择

mysql , hdfs

in-memory , mysql , Cassandra , Elasticsearch

HBase

elasticsearch , H2

通信方式

http , MQ

thrift

GRPC

MQ监控

不支持

不支持

不支持

支持(RocketMQ,kafka)

全局调用统计

支持

不支持

支持

支持

trace查询

不支持

支持

不支持

支持

报警

支持

不支持

支持

支持

JVM监控

不支持

不支持

支持

支持

优点

功能完善。

spring-cloud-sleuth可以很好的集成zipkin , 代码无侵入,集成非常简单 , 社区更加活跃。

完全无侵入, 仅需修改启动方式,界面完善,功能细致。

完全无侵入,界面完善,支持应用拓扑图及单个调用链查询。

功能比较完善(zipkin + pinpoint)

缺点

  • 代码侵入性较强,需要埋点
  • 文档比较混乱,文档与发布版本的符合性较低,需要依赖点评私服 (或者需要把他私服上的jar手动下载下来,然后上传到我们的私服上去)。
  • 默认使用的是http请求向zipkin上报信息,耗性能。
  • 跟sleuth结合可以使用rabbitMQ的方式异步来做,增加了复杂度,需要引入rabbitMQ 。

不支持查询单个调用链, 对外表现的是整个应用的调用生态。

  • 3.2版本之前BUG较多 ,网上反映兼容性较差 . 3.2新版本的反映情况较少
  • 依赖较多。

文档

网上资料较少,仅官网提供的文档,比较乱

文档完善

文档完善

文档完善

性能消耗

 

 

模拟了三种并发用户:500,750,1000。使用jmeter测试,每个线程发送30个请求。使用的采样率为1,即100%

​​​​​​​

 

 

Logo

权威|前沿|技术|干货|国内首个API全生命周期开发者社区

更多推荐