随着互联网的不断发展,企业的业务系统变得越来越复杂,原本单一的单体应用系统已经无法满足企业业务发展的需要。于是,很多企业开始了对项目的分布式与微服务改造,新项目也在开始的时候就会采用分布式与微服务的架构模式。,一个系统采用分布式与微服务架构后,会被拆分成许多服务模块,这些服务模块之间的调用关系错综复杂,对于客户端请求的分析与处理就会显得异常复杂。此时,就需要一种技术来解决这些问题,而这种技术就是分布式链路追踪技术。,随着互联网业务快速扩展,企业的业务系统变得越来越复杂,不少企业开始向分布式、微服务方向发展,将原本的单体应用拆分成分布式、微服务。这也使得当客户端请求系统的接口时,原本在同一个系统内部的请求逻辑变成了需要在多个微服务之间流转的请求。,单体架构中可以使用AOP在调用具体的业务逻辑前后分别打印一下时间即可计算出整体的调用时间,使用 AOP捕获异常也可知道是哪里的调用导致的异常。,但是在分布式微服务场景下,使用AOP技术是无法追踪到各个微服务的调用情况的,也就无法知道系统中处理一次请求的整体调用链路。,另外,在分布式与微服务场景下,我们需要解决如下问题:,上述问题就是分布式链路追踪技术要解决的问题。所谓的分布式链路追踪,就是将对分布式系统的一次请求转化成一个完整的调用链路。这个完整的调用链路从请求进入分布式系统的入口开始,直到整个请求返回为止。并在请求调用微服务的过程中,记录相应的调用日志,监控系统调用的性能,并且可以按照某种方式显示请求调用的情况。,在分布式链路追踪中,可以统计调用每个微服务的耗时,请求会经过哪些微服务的流转,每个微服务的运行状况等信息。,假定三个微服务调用的链路如下图所示:Service 1 调用 Service 2,Service 2 调用 Service 3 和 Service 4。,那么链路追踪会在每个服务调用的时候加上 Trace ID 和 Span ID。如下图所示:,小伙伴注意上面的颜色,相同颜色的代表是同一个 Span ID,说明是链路追踪中的一个节点。,把以上的相同颜色的步骤简化为下面的链路追踪图:,通过 Parent ID 就可找到父节点,整个链路即可以进行跟踪追溯了。,备注:核心原理部分内容来源:cnblogs.com/jackson0714/p/sleuth_zipkin.html,目前,行业内比较成熟的分布式链路追踪技术解决方案如下所示。,
© 版权声明
文章版权归作者所有,未经允许请勿转载。