1.问题背景

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

1.1 微服务面临的问题：

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

1.2 如何解决？

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

 

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

1.3 分布式请求跟踪系统：

• 提出：

•  Google Dapper

  • 2014年4月

  • 《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》

• 中文链接：https://bigbully.github.io/Dapper-translation/
• 国内使用的产品
  • 阿里巴巴鹰眼(EagleEye)
    • 闭源
• 美团CAT
  • 开源
• 京东Hydra
  • 开源
• Twitter Zipkin
  • 开源
• Apache SkyWalking (APM)
  • 开源
• Pinpoint(APM)
  • 开源

 

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%

​​​​​​​