这一轮，skywalking胜出

了解xjjdog的都知道，在微服务trace方面，我在两家公司实施了uber的jaeger。但是，jaeger虽然可以搜集调用链信息并查询，但统计图表相对欠缺，尤其对于服务间调用关系部分，不够直观。

今天，我们来看一下skywalking，以及和它很像的pinpoint。说它们是近亲，是因为它们都是基于agent探针技术进行实施的。

如果你不了解探针是何方神圣，xjjdog以前也普及过一篇文章。

《冷门instrument包，功能吊炸天》

一、概述

引入微服务虽然解决了一部分问题，但大大增加了系统维护难度及复杂度。而调用链监控正是解决微服务复杂性所带来的一系列问题的强效手段。

那么问题来了：调用链有啥用？为什么上调用链？不上隔壁产品会不会来打我？

答：

1.解决出现问题后，难以定位。——对整个调用链路有个完善的监控

2.解决链路复杂。——清晰的链路图谱反映服务之间的依赖、调用关系

3.整体系统性能及运行情况，需要明确的体现，才能根据实际情况调整资源

目前市面面上主流的调用链有：jaeger,pinpoint,Zipkin,CAT,skywalking等等，本次仅针对需求进行介绍。

二、对比(skywalking&pinpoint)

以上提到的调用链监控功能都大差不差，那关键就在于我们想要的——服务拓扑，以及更加直观的展示。

于是其他选手被一波带走，这样场上就只剩两位参赛者了。到底谁nb，且听我慢慢道来。

当看到Hbase……唔……嗯。走好……不送……告辞…… 胜者——skywalking！ 这么草率当然有人不服，放出pinpoint的ui，诸位感受一下。

坐标： https://naver.github.io/pinpoint/ 感兴趣的小伙伴可私下尝试。

三、skywalking

不要问为啥是它，问就是信仰！就像装机用asus一样。但姑且还是介绍一下……

skywalking是一个开源的观测平台, 用于从服务和云原生基础设施收集, 分析, 聚合以及可视化数据，它提供了一种简便的方式来清晰地观测分布式系统, 甚至可以观测横跨不同云的系统.

名词解释

服务(Service)： 表示对请求提供相同行为的一系列或一组工作负载. 在使用打点代理或 SDK 的时候, 你可以定义服务的名字. 如果不定义的话, SkyWalking 将会使用你平台上定义的名字

服务实例(Service Instance)： 上述的一组工作负载中的每一个工作负载称为一个实例. 就像 Kubernetes 中的 pods 一样, 服务实例未必就是操作系统上的一个进程. 但当你在使用打点代理的时候, 一个服务实例实际就是操作系统上的一个真实进程

端点(Endpoint)： 对于特定服务所接收的请求路径, 如 HTTP 的 URI 路径和 gRPC 服务的类名 + 方法签名.

架构

SkyWalking 逻辑上分为四部分: 探针, 平台后端, 存储和用户界面。

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

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

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

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

四、限制

那么skywalking是否真的就天下无敌呢？成也探针，败也探针，限制就在它身上。

进程内传播在大多数情况下成为可能。许多高级编程语言(如 Java, .NET)都是用于构建业务系统. 大部分业务逻辑代码对于每一个请求来说都运行在同一个线程内, 这使得传播是基于线程 ID 的, 以确保上下文是安全的.

仅仅对某些框架和库奏效。因为是代理来在运行时修改代码的, 这也意味着代理插件开发者事先就要知道 所要修改的代码是怎么样的. 因此, 在这种探针下通常会有一个已支持的列表清单.支持服务列表：

https://github.com/apache/skywalking/blob/master/docs/en/setup/service-agent/java-agent/Supported-list.md

跨线程可能并非总是奏效 如上所述, 每个请求的代码大都运行在一个线程之内, 对于业务代码来说尤其如此. 但是在其他一些场景下, 它们也会在不同线程下工作, 比如指派任务到其他线程, 任务池, 以及批处理. 对于一些语言, 可能还提供了协程或类似的概念如 Goroutine, 使得开发者可以低开销地来执行异步操作, 在这些场景下, 自动打点可能会遇到一些问题。

五、使用

主界面

除一些图表、top榜之外。还可查看全局 或 某个服务 或某个节点的详细信息。(如 请求、JVM等)

拓扑图

如下图所示，为当前服务调用关系拓扑。但存在一定局限性，具体说明如下：

1.服务间必须要存在流量关系才会显示 2.默认显示10分钟内，最大显示1小时内服务调用。（后期可能会有优化） 3.需使用chrome，firefox等正经浏览器。搜狗/360等浏览器，无法显示拓扑 4.点击某个服务节点，将显示依赖关系 5.点击连线中点将显示请求信息 6.刷新按钮 将显示最近10分钟拓扑，并重置当前所有查询 及 操作 7.根据线条流向，可获知调用 <-> 被调用关系 8.因探针无法支持，部分服务显示为ip。如mysql，postgresql，memcached，redis，mongodb，kafka，xxl-job（显示图标） 9.红色节点表示最近存在请求失败的情况 10.显示的服务名，与发布系统名一致。若eureka服务名 & 发布系统名不同可能难以检索服务

若想看order-rpc服务的调用关系，可进行搜索，结果如下图【不要开自动刷新，会被无限重置】

调用链

通过【追踪】进入调用链查看界面，可通过服务、实例、请求状态等进行查询。具体说明如下： 1.查询默认按持续时间倒序 2.可按追踪id查询相关接口 3.可切换调用链展现形式以进行不同分析 4.可单机某个节点查看具体信息，如sql、堆栈信息等

End

以上就是skywalking的常用功能，更多方式各位大佬可自由探索。嗯嗯，现在我手里，除了jaeger，又多了一个推荐选项。任何东西，还是要试一试，才知道它到底是不是美妙呀。