分布式系统中的Tracer

转载自:http://www.cnblogs.com/zhengyun_ustc/p/55solution2.html
　　　https://blog.csdn.net/u014229282/article/details/81097188
　　　http://www.aboutyun.com/thread-20646-1-1.html

Tracer 是一个用于分布式系统调用跟踪的组件，通过统一的 ID，将调用链路中的各种网络调用情况以日志的方式记录下来，以达到透视化网络调用的目的。这些日志可用于故障的快速发现，服务治理等等。

电商平台由数以百计的分布式服务构成，每一个请求路由过来后，会经过多个业务系统并留下足迹，并产生对各种Cache或DB的访问，但是这些分散的数据对于问题排查，或是流程优化都帮助有限。对于这么一个跨进程/跨线程的场景，汇总收集并分析海量日志就显得尤为重要。要能做到追踪每个请求的完整调用链路，收集调用链路上每个服务的性能数据，计算性能数据和比对性能指标（SLA），甚至在更远的未来能够再反馈到服务治理中，那么这就是分布式跟踪的目标了。

分布式系统的跟踪系统的目标要求有如下几点：

探针的性能消耗
　　APM组件服务的影响应该做到足够小。服务调用埋点本身会带来性能损耗，这就需要调用跟踪的低损耗，实际中还会通过配置采样率的方式，选择一部分请求去分析请求路径。在一些高度优化过的服务，即使一点点损耗也会很容易察觉到，而且有可能迫使在线服务的部署团队不得不将跟踪系统关停。
代码的侵入性
　　即也作为业务组件，应当尽可能少入侵或者无入侵其他业务系统，对于使用方透明，减少开发人员的负担。
　　对于应用的程序员来说，是不需要知道有跟踪系统这回事的。如果一个跟踪系统想生效，就必须需要依赖应用的开发者主动配合，那么这个跟踪系统也太脆弱了，往往由于跟踪系统在应用中植入代码的bug或疏忽导致应用出问题，这样才是无法满足对跟踪系统“无所不在的部署”这个需求。
可扩展性
　　一个优秀的调用跟踪系统必须支持分布式部署，具备良好的可扩展性。能够支持的组件越多当然越好。或者提供便捷的插件开发API，对于一些没有监控到的组件，应用开发者也可以自行扩展。
数据的分析
　　数据的分析要快，分析的维度尽可能多。跟踪系统能提供足够快的信息反馈，就可以对生产环境下的异常状况做出快速反应。分析的全面，能够避免二次开发。

一个请求完整的调用链可能如下图，经过多个系统服务，调用关系复杂。如下图：

　　在前端请求到达服务器时，应用容器在执行实际业务处理之前，会先执行埋点逻辑（类似 Filter 的机制），埋点逻辑为这个前端请求分配一个全局唯一的调用链ID，即TraceId。埋点逻辑把TraceId放在一个调用上下文对象里面，而调用上下文对象会存储在 ThreadLocal里面。
　　调用上下文对象里还有一个ID非常重要，在淘宝的EagleEye里面被称作RpcId。RpcId用于区分同一个调用链下的多个网络调用的发生顺序和嵌套层次关系。对于前端收到请求，生成的RpcId固定都是0。
　　当这个前端执行业务处理需要发起RPC调用时，会首先从当前线程ThreadLocal上面获取之前EagleEye设置的调用上下文。然后，把RpcId递增一个序号。在 EagleEye里使用多级序号来表示RpcId，比如应用A收到请求的RpcId是0，那么它第一次调用RPC服务B时，会把RpcId改成 0.1。之后，调用上下文会作为附件随这次请求一起发送到远程服务器。
　　服务端收到这个请求之后，会从请求附件里取出调用上下文，并放到当前线程ThreadLocal上面。如果服务B在处理时，需要调用另一个服务，这个时候它会重复之前提到的操作，唯一的差别就是RpcId会先改成0.1.1 再传过去。服务A的逻辑全部处理完毕之后，在返回响应对象之前，会把这次调用情况以及TraceId、RpcId都打印到它的访问日志之中，同时，会从ThreadLocal 清理掉调用上下文。

TraceId 生成规则参考
　　Tracer 通过 TraceId 来将一个请求在各个服务器上的调用日志串联起来，TraceId一般由接收请求经过的第一个服务器产生，产生规则是：服务器IP + 进程的ID + 产生ID时候的时间 + 自增序列。产生TracerId的机器的IP可以用一个十六进制的数字，每两位代表 IP 中的一段。时间可以用毫秒数表示，自增的序列可以是四位的数字表示。

RPC ID 生成规则参考
　　Tracer中的 RPC ID代表本次调用在整个调用链路中的位置，假设一个 Web系统A接收了一次用户请求，那么在这个系统的Tracer日志中，记录下的 RPC ID是0，代表是整个调用的根节点，如果A系统处理这次请求，需要通过 RPC依次调用B，C，D三个系统，那么在 B，C，D三个系统的Tracer服务端日志中，RPC ID也分别是0.1，0.2和0.3；如果C系统在处理请求的时候又调用了E，F两个系统，那么E，F两个系统对应的Tracer服务端日志是0.2.1 和0.2.2。

分布式系统中的Tracer相关推荐

分布式系统中节点之间的同步形成区块链
链客,专为开发者而生,有问必答! 此文章来自链客区块链技术问答社区,未经允许拒绝转载. 分布式系统中节点之间的同步形成区块链分布式系统由Tanenbaum定义,"分布式系统是一组独立的计算 ...
工作中感受到的消息中间件在分布式系统中的使用场景
经历以前在qunar实习,第一次接触消息中间件,那时候概念还不清楚,朦朦胧胧有个初步认识,现在正式工作了,又一次接触了消息中间件,初步总结几种场景. 场景 1.分布式系统中,不同系统之间传递消息. ...
分布式系统中只有两个难题
分布式系统抽象讨论编程语言时,我们使用通用术语并用函数.运算符.类.变量和指针来定义我们的程序.通用的词汇可以帮助我们避免每次都为了描述某些东西而发明新词.我们的定义越精确.越没有歧异,听众也就越容 ...
大型分布式系统中的缓存架构
作者:陈彩华来自:51cto技术栈(ID:blog51cto) 本文主要介绍大型分布式系统中缓存的相关理论,常见的缓存组件以及应用场景. 缓存概述缓存概述缓存的分类缓存主要分为四类,如下图: ...
分布式概念-如何访问到分布式系统中的服务
点击上方蓝色字体,选择"设为星标" 优质文章,及时送达之前的文章我们介绍了什么是分布式系统,以及分布式系统的一些特点和存在的问题. 我们知道的分布式系统是多台计算机通过网络链接, ...
大型网站架构系列：缓存在分布式系统中的应用（二）
缓存是分布式系统中的重要组件,主要解决高并发,大数据场景下,热点数据访问的性能问题.提供高性能的数据快速访问. 本文是缓存在分布式应用第二篇文章,介绍分布式缓存,Memcache,Redis,本地缓存 ...
一致性哈希算法及其在分布式系统中的应用
摘要本文将会从实际应用场景出发,介绍一致性哈希算法(Consistent Hashing)及其在分布式系统中的应用.首先本文会描述一个在日常开发中经常会遇到的问题场景,借此介绍一致性哈希算法以及这个 ...
大型网站架构系列：缓存在分布式系统中的应用（一）
缓存是分布式系统中的重要组件,主要解决高并发,大数据场景下,热点数据访问的性能问题.提供高性能的数据快速访问. 本文是缓存在分布式应用第一篇文章,介绍缓存的原理,缓存的分类,缓存的设计,CDN缓存(原 ...
在一个成熟的分布式系统中如何下手做高可用？
对于企业来说,随着规模越来越大,整个系统中存在越来越多的子系统,每个子系统又被多个其他子系统依赖或者依赖于其他子系统.大部分系统在走到这一步的过程中,大概率会发生这样的场景:作为某个子系统的负责人或者 ...

分布式系统中的Tracer

分布式系统中的Tracer相关推荐

最新文章

热门文章