基于 SkyWalking 的腾讯云微服务观测最佳实践
导读:在微服务大行其道的环境下,分布式架构和微服务框架给系统性能分析和问题定位带来了非常大的挑战。如何通过汇聚业务系统各处理环节的实时数据,实现对应用的全链路性能监测成为服务治理的一大难题。本文主要基于智慧零售腾讯有数产品的业务背景分享基于 SkyWalking 的腾讯云微服务观测实践,希望给有这方面需求的同学一些启发。
作者介绍
陈俊洪
腾讯智慧零售部 运营开发工程师
擅长数据资产管理、微服务治理等
背景
众多的微服务缺乏统一的管理规范(监控、调用链追踪)
- 多账号公有云,自研云,内网 k8s
- 多个部署平台 TAF, TKE, TKEX
在线服务异常无法快速定位
- NFS 日志挂载方式
- 缺乏统一的 web 管理界面
缺少服务性能诊断
- 无法及时发现某些不合理的调用,如频繁进行数据库操作、循环依赖等。
目标
基于上述背景,希望能构建一个组件平台具备如下核心功能
经过调研,我们发现 SkyWalking 这一款用于微服务(Docker, Kubernetes, Mesos)框架下的分布式应用行为监控工具刚好能满足我们的需求。
核心原理
skywalking_architecture
SkyWalking 的架构主要含3部分:上报端 Client, 数据接收端 Collector 和 web 展示 UI。
核心原理有以下几点:
- 使用 Java Agent 探针技术进行 jvm 与行为数据采集
- 内部使用 HTTP 和 gRPC 协议进行通信
- 使用 GrapHQL 和 HTTP 进行 UI 展示
- 支持的存储有 H2(仅使用于小数据量的调试,一般不建议使用)和 Elasticseach
服务上报实践
腾讯有数的后台服务目前主要使用的是 SpringBoot 技术栈,为了降低后台同学的额外开发成本,我们考虑整体的服务治理时尽量避免代码入侵。常规的服务启动命令为:
$ java -Dspring.profiles.active=dev -jar target/youshu-app.jar
引入 SkyWalking 的 Agent 进行数据上报后的启动命令只需要添加 “-javaagent” 参数指定 Agent 的绝对路径即可,如:
$ java -javaagent:/e/apache-skywalking-apm-bin/agent/skywalking-agent.jar -Dspring.profiles.active=dev -jar target/youshu-app.jar
可视化的 UI 提供调用关系拓扑图和调用链路 Trace, 实例图如下:
skywallking-topology
skywalking-trace
腾讯微服务观测平台:TSW
确定了组件之后,如何能让开发同学更专注于业务功能开发,而不需要关注 SkyWalking 底层服务的日常运维?一方面为了响应集团统一上云的大趋势,另一方面为了降低团队内的运营成本,我们最后决定借助腾讯云的能力,由专业的团队负责服务的 SkyWalking 日常运营。
对比开源的 SkyWalking, 通过腾讯云 TSW 的架构图,我们可以发现以下几点:
- 数据采集(Client):上报方式更为灵活,可选择使用 TSW 探针,或选择使用开源采集端用于采集数据。若您希望由开源迁移上云,您可保留 Client 端的大部分配置,仅更改上报地址即可。
- 数据处理(Server):数据上报到 Server 端时,首先会由 Pulsar Function(消息队列)削峰填谷。对不同开源客户端上报的数据,Adapter 适配器会将数据转换为统一的 Opentracing 兼容格式,以供后续使用。统一数据格式后,链路数据会被直接存储,同时会根据数据的使用场景,分配给实时计算算子与离线计算算子。实时计算算子为您提供实时监控、统计数据展示,并对接告警平台快速响应。离线计算算子处理长时段大量数据的统计汇聚,利用大数据分析能力提供业务价值。
- 存储(Storage):存储层的设计可满足不同数据类型的使用场景,适配 Server 层的写入与 Data Usage 层的查询与读取请求,同时存储层增加了 HBase 和 HDFS 的存储方式。
- 数据使用(Data Usage):提供腾讯云统一的控制台操作、数据展示、告警提供底层支持。
TSW 系统架构图
TSW 基于开源 Agent 进行数据上报
由于我们的后台服务基于腾讯云 TKE 部署,因此需通过挂载 nfs 云硬盘的方式进行 Agent 的配置管理。
step1: 修改 docker 服务的启动命令
$ java -javaagent:/nfs_data/XXX/XXX/agent/skywalking-agent.jar -Dspring.profiles.active=dev -jar target/youshu-app.jar
step2: 将开源 agent 下载后上传到 nfs 挂载点对应的目录,如 “/nfs_data/XXX/agent/”
step3: 修改对应的配置信息 config/agent.conf
# 腾讯云TSW默认上报地址
collectorXXXXXX
# 基于腾讯云账号分配的唯一token
agent.XXXX@
# 上报的服务名称可自定义
agent.service_name=XXX-api
step4: 重启服务待有流量进来之后可验证界面是否有对应的拓扑图(也可通过查看 logs/xxx 查看是否上报异常)
TSW分布式依赖拓扑图
TSW接口请求的耗时详情
主流APM组件对比
业界存在众多应用性能管理组件为什么选择 SkyWalking 呢?具体可参考如下对照表:
Agent探针的性能分析
关于 Agent 的引入,我们跟很多同学一样也非常关心其对服务性能方面的影响到底有多大?这里基于官方的测试统计,我们发现针对一个 web 的应用,只提高了 10% 左右的CPU负荷。
Agent性能分析图
总结
应用性能管理只是服务治理中的一部分,本文以腾讯有数业务的后台服务现状为背景,为了解决当前遇到的服务调用监控、服务链路追踪和服务性能诊断的3大问题,先后介绍了开源 SkyWalking 和腾讯云 TSW 的系统架构及相关实践。
参考资料
1. 详解 Java Agent 探针:
https://zhuanlan.zhihu.com/p/135872794
2. 腾讯微服务观测平台产品概述:
https://cloud.tencent.com/document/product/1311/50754
3. Agent 探针性能揭秘:
https://github.com/SkyAPMTest/Agent-Benchmarks/blob/master/README_zh.md
4. Skywalking:
http://skywalking.apache.org/
往期推荐
《拥抱 Agent,“0” 代码玩转 Trace 之 OpenTelemetry 系列第二弹!》
《今天我们聊聊 Trace 之 OpenTelemetry And TSW |概览》
扫描下方二维码关注本公众号,了解更多微服务、消息队列的相关信息!解锁超多鹅厂周边!