《分布式会话跟踪系统架构设计与实践》由会员分享，可在线阅读，更多相关《分布式会话跟踪系统架构设计与实践（19页珍藏版）》请在金锄头文库上搜索。
1、分布式会话跟踪系统架构设计与实践前言随着美团点评的业务发展，公司的分布式系统变得越来越复杂，我们亟需一个工具能够梳理内部服务之 间的关系，感知上下游服务的形态。比如一次请求的流量从哪个服务而来、最终落到了哪个服务中去？ 服务之间是RPC调用，还是HTTP调用？ 一次分布式请求中的瓶颈节点是哪一个，等等。简介MTrace，美团点评内部的分布式会话跟踪系统，其核心理念就是调用链：通过一个全局的ID将分布在 各个服务节点上的同一次请求串联起来，还原原有的调用关系、追踪系统问题、分析调用数据、统计系 统指标。这套系统借鉴了 2010年Google发表的一篇论文dapper，并参考了 Twitter的Z
2、ipkin以 及阿里的Eagle Eye的实现。那么我们先来看一下什么是调用链，调用链其实就是将一次分布式请求还原成调用链路。显式的在后端 查看一次分布式请求的调用情况，比如各个节点上的耗时、请求具体打到了哪台机器上、每个服务节点 的请求状态，等等。它能反映出一次请求中经历了多少个服务以及服务层级等信息（比如你的系统A调 用B，B调用C，那么这次请求的层级就是3 ），如果你发现有些请求层级大于10,那这个服务很有可 能需要优化了。网络优化如上图所示，红框内显示了一次分布式请求经过各个服务节点的具体IP,通过该IP就可以查询一次分布 式请求是否有跨机房调用等信息，优化调用链路的网络结构。瓶颈查询
3、mil= 一 n it-O iw Q* iTB定位系统瓶颈服务再比如上图，红框部分显示的是系统调用的瓶颈节点，由于该节点的耗时，导致了整个系统调用的耗时 延长，因此该节点需要进行优化，进而优化整个系统的效率。这种问题通过调用链路能很快发现下游服 务的瓶颈节点；但是假如没有这样的系统，我们会怎样做呢？首先我会发现下游服务超时造成了我的服 务超时，这时我会去找这个下游服务的负责人，然后该负责人发现也不是他自己服务的问题，而是他们 调用了其他人的接口造成的问题，紧接着他又去找下游的服务负责人。我们都知道跨部门之间的沟通成本很高的，这么找下去会花费大量的不必要时间，而有了MTrace之后，你只需要点开
4、链路就能发现超 时问题的瓶颈所在。优化链路提高系统并行度或优化系统调用我们再来看下上面这张图，红框部分都是同一个接口的调用，一次请求调用相同的接口10几次甚至是几 十次，这是我们不想看到的事情，那么整个系统能不能对这样的请求进行优化，比如改成批量接口或者 提高整个系统调用的并行度？在美团点评内部我们会针对这样的链路进行筛选分析，然后提供给业务方 进行优化。异常log绑定通过MTrace不仅能做上述这些事情，通过它的特性，还能携带很多业务感兴趣的数据。因为MTrace 可以做到数据和一次请求的绑定以及数据在一次请求的网络中传递。比如一些关键的异常log，一般服务 的异常log很有可能是因为上游或
5、者下游的异常造成的，那就需要我们手动地对各个不同服务的异常log 做mapping。看这次的异常log对应到上游服务的哪个log上，是不是因为上游传递的一些参数造成了 该次异常？而通过MTrace就可以将请求的参数、异常log等信息通过traceld进行绑定，很容易地就 把这些信息聚合到了一起，方便业务端查询问题。透明传输数据业务端往往有这样的需求，它希望一些参数能在一次分布式请求一直传递下去，并且可以在不同的RPC中间件间传递。MTrace对该类需求提供了两个接口：put(map data) put On ce(map data) put口 -聯磬凹左亩%na召maK。 puCOnce口 -
6、聯磬亩%na召汨aK睜。9些M345BgzbiZCPFrta?gput口、service 召曲7 putlzlKNuid123456K-、Mm冒皤召wxrttK、凹记m爲逮A 召ffiHget(=uid=)sm 艸淨牺瞬塔、smsn 召ffiamatpuronce口、service 召諭油 7 putonceDaKpidHlllll、M汨妙亠血勞、凹龙mwB召KHget(=pid=)s谢艸琳牺聯熒严应制ffl爲改0召禅舜牺-1曲2d以上的两种接口可以用于业务自定义传递数据，比如通过传递一个服务标识，用于AB test，下游的所有 服务获取到test的标识就会走test的策略，即上游服务可以传递
7、一些参数，控制所有下游服务的逻辑。 当然业务也可以通过该接口传递一些临时性的数据。系统架构基本概念traceld全局唯一，64位整数，用于标识一次分布式请求，会在RPC调用的网络中传递。spanld签名方式生成：0, 0.1, 0.1.1, 0.2。用于标识一次RPC在分布式请求中的位置，比如0.2就是0节点服务 调用的第二个服务。annotation业务端自定义埋点，业务感兴趣的想上传到后端的数据，比如该次请求的用户ID等。数据埋点埋点SDK提供统一的SDK，在各个中间件中埋点，生成tracelD等核心数据，上报服务的调用数据信息。生成调用上下文；同步调用上下文存放在ThreadLocal,
8、异步调用通过显式调用API的方式支持；网络中传输关键埋点数据，用于中间件间的数据传递，支持Thrift, HTTP协议。业内有些系统是使用注解的方式实现的埋点，这种方式看似很优雅，但是需要业务方显式依赖一些AOP 库，这部分很容易出现问题，因为AOP方式太过透明，导致查问题很麻烦，而且业务方配置的东西越多 越容易引起一些意想不到的问题，所以我们的经验是尽量在各个统一的中间件中进行显式埋点，虽然会 导致代码间耦合度增加，但是方便后续定位问题。其次，为了整个框架的统一，MTrace并非仅支持Java 种语言，而AOP的特性很多语言是不支持的。Agen t透传数据，用作数据转发；做流量控制；控制反转
9、，很多策略可以通过age nt实现，而不需要每次都升级业务代码中的SDK。Age nt仅仅会转发数据，由Age nt判断将数据转发到哪里，这样就可以通过Age nt做数据路由、流量 控制等操作。也正是由于Age nt的存在，使得我们可以在Age nt层实现一些功能，而不需要业务端做 SDK的升级，要知道业务端SDK升级的过程是很缓慢的，这对于整个调用链的系统来说是不可接受的， 因为MTrace整个系统是针对庞大的分布式系统而言的，有一环的服务缺失也会造成一定的问题。目前MTrace支持的中间件有：公司内部RPC中间件 http中间件 mysql中间件 tair中间件mq中间件数据埋点的四个阶段
10、 Client Send :客户端发起请求时埋点，需要传递一些参数，比如服务的方法名等Span span = Tracer.clientSend(param); Server Recieve :服务端接收请求时埋点，需要回填一些参数，比如traceId，spanldTracer.serverRecv(param); ServerSend :月服务端返回请求时埋点，这时会将上下文数据传递到异步上传队列中Tracer.serverSe nd();异步队列异歩队列2. Server Receive服务第播收话求井生成上下文3业务端自定义埋点自己感兴 趣的数据4. Server Send 逼务卓返回苗
11、求结果 归档上下文异步EA列上报clients 上下文数据|异步賦列上报SBwrfflf上下文 数据Client Recieve :客户端接收返回结果时埋点，这时会将上下文数据传递到异步上传队列中Tracer.clie ntRecv();k Client Send 客户端发起谓求 生成调用上下文5. Client Receive 容户錢怨收返回结果 归档上下文埋点上下文上图CS、SR为创建上下文的位置，CR、SS为归档上下文的位置。上下文归档上下文归档，会把上下文数据异步上传到后端，为了减轻对业务端的影响，上下文上报采用的是异步队 列的方式，数据不会落地，直接通过网络形式传递到后端服务，在传递
12、之前会对数据做一层压缩，主要 是压缩比很可观，可以达到10倍以上，所以就算牺牲一点CPU资源也是值得的。具体上报的数据如图 所示：我们之前在数据埋点时遇到了一些问题：异步调用O异步10造成的线程切换，不能通过ThreadLoca I传递上下文。o显式的通过API进行埋点传递，切换前保存，切换后还原。O提供封装好的ThreadPool库。数据量大，每天千亿级别的数据o批量上报o数据压缩o极端情况下采样数据存储Kafka使用我们在SDK与后端服务之间加了一层Kafka,这样做既可以实现两边工程的解耦，又可以实现数据的延 迟消费。我们不希望因为瞬时QPS过高而引起的数据丢失，当然为此也付出了一些实效
13、性上的代价。实时数据Hbase调用链路数据的实时查询主要是通过Hbase，使用tracelD作为RowKey，能天然的把一整条调用链聚 合在一起，提高查询效率。离线数据Hive离线数据主要是使用Hive，可以通过SQL进行一些结构化数据的定制分析。比如链路的离线形态，服务 的出度入度（有多少服务调用了该服务，该服务又调用了多少下游服务）前端展示前端展示，主要遇到的问题是NTP同步的问题，因为调用链的数据是从不同机器上收集上来的，那么聚 合展示的时候就会有NTP时间戳不同步的问题，这个问题很难解决，于是我们采取的方式是前端做一层 适配，通过Spanld定位调用的位置而不是时间，比如0.2 一定是发生在0.1这个Span之后的调用，所 以如果时间出现漂移，就会根据Spa nld做一次校正。即判断时间顺序的优先级为最高是spa nid,然后是 时间戳。总结核心概念：调用链；用途：定位系统瓶颈，优化系统结构、统计系统指标、分析系统数据；架构：埋点上报、收集计算、展示分析。分布式会话跟踪系统主要的特点就是能关联服务之间的联动关系，通过这层关系可以延伸出来很多有意 义的分析数据，统计数据。为优化系统结构，查询系统瓶颈问题带来了极大的便利。全文完
