如果你觉得这篇文章对你有帮助,请不要吝惜你的“关注”、“点赞”、“评价”、“收藏”,你的支持永远是我前进的动力~~~
这些问题你知道吗?
- 当前业务依赖了哪些服务、资源?
- 整个链路的依赖路径是怎么样的?
- 依赖关系是否合理?
- 当前业务最核心的服务是哪些?
- 一次业务请求处理的时间花在了什么地方?
- 一个新的业务上线,要给哪些服务分配多少资源?
- 哪些服务是出错率比较高的?
- 哪些服务是业务链路的瓶颈?
- 我调整一个接口到底影响了哪些服务、业务?
- 哪些业务使用了我的表?
如果回答不上来,那么可以说你的系统有很大的风险,一次小小的流量波动,一次小小的改动都可能导致系统的崩溃。
要回答这些问题,最好的工具就是链路追踪系统了
链路追踪系统的设计目标
Dapper: bigbully.github.io/Dapper-tran…
一个好的链路追踪系统有如下特点:
- 低消耗:跟踪系统对在线服务的影响应该做到足够小。在一些高度优化过的服务,即使一点点损耗也会很容易察觉到,而且有可能迫使在线服务的部署团队不得不将跟踪系统关停。
- 应用级的透明:对于应用的程序员来说,是不需要知道有跟踪系统这回事的。如果一个跟踪系统想生效,就必须需要依赖应用的开发者主动配合,那么这个跟踪系统也太脆弱了,往往由于跟踪系统在应用中植入代码的bug或疏忽导致应用出问题,这样才是无法满足对跟踪系统“无所不在的部署”这个需求。面对当下像Google这样的快节奏的开发环境来说,尤其重要。
- 延展性:Google至少在未来几年的服务和集群的规模,监控系统都应该能完全把控住。
而SkyWalking就是一款满足如上特点的链路调用追踪系统。
SkyWalking架构
具体介绍可以参见其官网
SkyWalking的链路功能增强
在引入SkyWalking的时候,可以根据自己的场景进行裁剪、增强。如我们移除了不使用的中间件,启动速度有了明显提升;自动增强日志框架,在业务代码无感知的情况下,在日志输出中添加了traceId;去除了DB一些不关注方法的拦截,减少了链路长度;记录sql查询语句返回的行数,以便后续分析问题;web响应头返回traceId,在有异常时,前端弹窗中透出,业务方反馈给开发进行当时的链路排查,如此等等。
功能扩展
在链路追踪基础上,可以做很多事情。除了常规的问题快速定位、日志串联等,还可以做服务治理、性能优化、灰度发布、全链路压测、容量评估和规划、测试环境路由等更大意义的事情。