微服务监控实战（四）：链路追踪数据的采集及应用

如果你觉得这篇文章对你有帮助，请不要吝惜你的“关注”、“点赞”、“评价”、“收藏”，你的支持永远是我前进的动力~~~

这些问题你知道吗？

• 当前业务依赖了哪些服务、资源？

• 整个链路的依赖路径是怎么样的？
• 依赖关系是否合理？
• 当前业务最核心的服务是哪些？
• 一次业务请求处理的时间花在了什么地方？
• 一个新的业务上线，要给哪些服务分配多少资源？
• 哪些服务是出错率比较高的？
• 哪些服务是业务链路的瓶颈？
• 我调整一个接口到底影响了哪些服务、业务？
• 哪些业务使用了我的表？

如果回答不上来，那么可以说你的系统有很大的风险，一次小小的流量波动，一次小小的改动都可能导致系统的崩溃。

要回答这些问题，最好的工具就是链路追踪系统了

链路追踪系统的设计目标

Dapper： bigbully.github.io/Dapper-tran…

一个好的链路追踪系统有如下特点：

1. 低消耗：跟踪系统对在线服务的影响应该做到足够小。在一些高度优化过的服务，即使一点点损耗也会很容易察觉到，而且有可能迫使在线服务的部署团队不得不将跟踪系统关停。
2. 应用级的透明：对于应用的程序员来说，是不需要知道有跟踪系统这回事的。如果一个跟踪系统想生效，就必须需要依赖应用的开发者主动配合，那么这个跟踪系统也太脆弱了，往往由于跟踪系统在应用中植入代码的bug或疏忽导致应用出问题，这样才是无法满足对跟踪系统“无所不在的部署”这个需求。面对当下像Google这样的快节奏的开发环境来说，尤其重要。
3. 延展性：Google至少在未来几年的服务和集群的规模，监控系统都应该能完全把控住。

而SkyWalking就是一款满足如上特点的链路调用追踪系统。

SkyWalking架构

具体介绍可以参见其官网

SkyWalking的链路功能增强

在引入SkyWalking的时候，可以根据自己的场景进行裁剪、增强。如我们移除了不使用的中间件，启动速度有了明显提升；自动增强日志框架，在业务代码无感知的情况下，在日志输出中添加了traceId；去除了DB一些不关注方法的拦截，减少了链路长度；记录sql查询语句返回的行数，以便后续分析问题；web响应头返回traceId，在有异常时，前端弹窗中透出，业务方反馈给开发进行当时的链路排查，如此等等。

功能扩展

在链路追踪基础上，可以做很多事情。除了常规的问题快速定位、日志串联等，还可以做服务治理、性能优化、灰度发布、全链路压测、容量评估和规划、测试环境路由等更大意义的事情。