转载

这一轮,skywalking胜出

这一轮,skywalking胜出

原创:小姐姐味道(微信公众号ID:xjjdog),欢迎分享,转载请保留出处。

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

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

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

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

一、概述

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

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

答:

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

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

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

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

二、对比(skywalking&pinpoint)

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

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

PinPoint Skywalking
项目发起人 Woonduk Kang (韩囯) 吴晟(中囯)
性能损耗 高 低
用户 非常多 非常多
社区 非 apache + —般 apache孵化+ QQ官方交流群+活跃
文档 详细 详细
跟踪粒度 细 一般
代码侵入性 无 无
告警 支持 支持
JVM监控 支持 支持
UI丰富度 很高 一般
实现方式 字节码注入 字节码注入
兼容 OpenTracing 否 是
扩展性 低 高
Traceld 查词 不支持 支持
发布包 war jar
协议 thrift gRPC
支持语言 Java, PHP Java, C#, PHP, Node.js
存储 HBase+MySQL ES, H2, MySQL, TiDB, Sharding-Sphere
过滤追踪 filter配置 agent.config + apm-trace-ignore-plugin
组件 collector+Web+agent+存储 OAP+Web+agent+存储+zk
GitHub Star 9.4k 10.8k+

当看到 Hbase ……唔……嗯。走好……不送……告辞……   胜者—— skywalking !

这么草率当然有人不服,放出pinpoint的ui,诸位感受一下。

这一轮,skywalking胜出

这一轮,skywalking胜出

坐标:

https://naver.github.io/pinpoint/

感兴趣的小伙伴可私下尝试。

三、skywalking

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

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

名词解释

服务(Service):

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

服务实例(Service Instance):

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

端点(Endpoint):

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

架构

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

这一轮,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等)

这一轮,skywalking胜出

拓扑图

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

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服务名 & 发布系统名不同可能难以检索服务

这一轮,skywalking胜出

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

这一轮,skywalking胜出

调用链

通过【追踪】进入调用链查看界面,可通过服务、实例、请求状态等进行查询。具体说明如下:

1.查询默认按持续时间倒序

2.可按追踪id查询相关接口

3.可切换调用链展现形式以进行不同分析

4.可单机某个节点查看具体信息,如sql、堆栈信息等

这一轮,skywalking胜出

End

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

作者简介: 小姐姐味道 (xjjdog),一个不允许程序员走弯路的公众号。聚焦基础架构和Linux。十年架构,日百亿流量,与你探讨高并发世界,给你不一样的味道。我的个人微信xjjdog0,欢迎添加好友,进一步交流。

JAVA后端知识索引

1、

必看!java后端,亮剑诛仙

2、学完这100多技术,能当架构师么?

两篇索引,吊打全网,也是小姐姐味道系统化文章展开路径,定期梳理

Linux

Linux有“最常用”和“荒岛余生”两个系列,最爱的编辑器当然是 vim。 我整理了一份《最有用系列,百页精华》pdf,想要可以加我微信:xjjdog0。

Linux上,最常用的一批命令解析

csdn发布首日,即获1k+赞,点赞率1/8

最常用系列↓(更多见文末)

1、最常用的一套“Vim“技巧

2、 最常用的一套“Sed“技巧

3、 最常用的一套“AWK“技巧

基础架构

基础架构的范围,大多数是一些整体性的方案,但又比较深入底层原理。这方面的工作有两个特点:思路要全,内容要专。

这次要是讲不明白Spring Cloud核心组件,那我就白编这故事了

有比较精细俏皮的讲解

微服务不是全部,只是特定领域的子集

也有大而全的解决方案

解决方案:

1、 服务端开发学习路径图,心疼小哥哥们

2、 这么多监控组件,总有一款适合你

3、 “分库分表” ?选型和流程要慎重,否则会失控

4、 使用Netty,我们到底在开发些什么?

5、 ”MySQL官方驱动“主从分离的神秘面纱

6、 这可能是最中肯的Redis规范了

7、 发布系统有那么难么?

8、 也浅谈下分布式存储要点

7、 希望一个数据同步,包治百病

8、 如何使用postgis做一个高可用的附近的人服务?

9、 那些需要自己开发的安全需求

10、WebSocket协议 8 问

11、 JAVA多线程使用场景和注意事项简版

12、 上厅房,下厨房,ElasticSearch有的忙

13、 分布式消息系统,设计要点。画龙画虎难画骨

14、Kafka基础知识索引

15、 与亲生的Redis Cluster,来一次亲密接触

高并发相关(未完结):

1、高并发之限流,到底限的什么鬼 

2、信号量限流,高并发场景不得不说的秘密

3、没有预热,不叫高并发,叫并发高

4、这样的高可用,我不要!

细节深入:

这一轮,skywalking胜出

原文  http://mp.weixin.qq.com/s?__biz=MzA4MTc4NTUxNQ==&mid=2650520437&idx=1&sn=248b507ca079d81c0fb2cf00454f21ca
正文到此结束
Loading...