分享链家全链路跟踪平台 LTrace 实践
如今的互联网服务，通常都是用大规模的分散式丛集来实现的。服务可能来自不同的研发团队、使用不同的程式语言来实现, 执行在上千台服务器上。随着链家的业务发展，公司的分散式系统变得越来越复杂，使用者的一次请求通常由多个系统协同完成处理，而且这些处理是发生在不同机器甚至是不同丛集上的，当请求处理发生异常时，需要快速发现问题，并准确定位到是哪个环节出了问题，这是非常重要的。
为了解决这样的问题，我们经过调研与测试，结合业界的实践经验 ， 开发了LTrace链家全链路跟踪平台，有效应对上面的问题，大幅度提升工作效率。目前已经在公司多部门的各条业务线专案中得到成功应用。基于请求链路采集到的全量丰富资料，我们能够直观的了解到专案间的链路关系，就能够进行问题的快速定位与瓶颈节点的快速排查，程式码效能问题一览无余。
链路跟踪，关键的核心是呼叫链，就是对一次请求进行跟踪。通过为每个请求生成一个全域性唯一的ID，将分布在各个服务节点上的同一次请求串联起来，还原出更多有价值的资料。在 我们设计实现LTrace平台过程中，遇到几项大的挑战。
稳定性挑战。我们的业务 系统对于稳定性、效能、资源要求极其严格，不能有太复杂的逻辑和外部依赖，并对业务系统性能几乎无影响，LTrace平台的稳定性不应该对业务系统的稳定性造成任何影响；高效能挑战。目前公司存在 众多复杂的分散式业务系统，数十 亿hits 生成的链路资料需要及时采集储存， 这就要求LTrace平台具备快速的资料处理能力 ；透明、易扩充套件、避免侵入业务。易于被使用方广泛接受、低耦合是很重要的，透明性用来隐藏实现策略，避免让使用者卷进细节，同时 具备良好的可扩充套件性 ；跨语言、多协议。在公司各部门中，存在 JAVA 、 PHP 等众多异构系统以及各种服务中介软件，因此LTrace平台要实现全链路跟踪，必须要支援跨语言、多协议。
功能简介
一， 呼叫链路我们通过对一次请求进行还原，形成一个完整的呼叫链路图，如下图。界面中展示请求依次通过的各个服务节点的情况。比如请求经过每个服务节点的IP、传送与响应时间点、处理结果与处理时长，网络传输时长、异常描述等资讯。
二，问题快速定位
再比如，我们现在可以在界面中快速的定位到问题出现的服务节点、机器IP与问题原因。以前我们遇到线上问题时，通常需要同时登入N台机器抓日志排查，有时还可能需要关联上下游专案一起排查。
三，瓶颈节点
再次，我们还能够快速定位瓶颈节点。如界面中红框部分显示的是链路呼叫的瓶颈节点，由于该节点的耗时，导致了整个链路呼叫的耗时延长，因此针对该节点进行优化，进而达到优化整个链路的效率。
四，程式码优化
除此，我们还能够检测到程式码中一些需要优化的地方。比如图中红框部分都是同一个界面的呼叫，甚至连请求引数都是一样的。这种呼叫如果优化成批量请求或者相同引数只请求一次，能够快速提升节点的服务质量。
对系统行为进行链路跟踪必须是持续进行的，因为异常、超时等的发生是无法预料的，异常超时可能发生在链路的任何一个节点上或者一次呼叫的网络中，而且可能是难以重现的。同时跟踪需要是无所不在，遍布各处的，否则可能会遗漏某些重要的点。基于此LTrace设计了三个最重要的设计目标：极低的额外开销，对应用的透明性，可扩充套件。同时产生的跟踪资料需要可以被快速分析，这样可以帮助我们实时获取各节点状态。
平台设计
一，平台架构
上图中，LTrace平台架构主要分为三部分：资料埋点上报、资料实时储存、资料前端展示。
左侧部分使用埋点中介软件完成资料的采集，并异步写入到本地trace档案，通过rsyslog传送资料到讯息服务中。至于取样策略，后面会有详细介绍中间部分资料汇集并存储，接受讯息伫列中资料并存储到Hbase与ES中。右侧部分在界面中检索资料，分析资料进行展示。二，基本概念
TraceId ：全域性唯一，用于标识一次请求，会在RPC呼叫的网络中传递。
SpanId ：签名方式生成:0, 0.1, 0.1.1, 0.2。用于标识一次RPC在分散式请求中的位置，比如0.2就是0节点服务呼叫的第二个服务。
Annotation ：基本标注列表，记录一次RPC生命周期中重要时刻的资料快照。
BinaryAnnotation：业务标注列表，如果专案需要带上业务资料（比如电话号码、UserId等），可以将需要的资料放入。
三，呼叫链-Trace树
我们将一次请求所形成的呼叫链路，标记成一棵Trace树，并用全域性唯一的TraceId来标记这棵树，如下图：
四，呼叫链-Span节点
对于一次分散式请求，总会存在多次呼叫关系（如图中箭头线），我们将每次呼叫（箭头线）标记成一个Span节点，并用SpanId来标记这个Span节点。
五，资料埋点
LTrace平台对应用开发者近乎零侵入，通过为不同的异构系统提供对应的埋点中介软件（如JAVA、 PHP 等）完成链路跟踪。在埋点中介软件，生成统一的TraceId等核心资料，并收集比如呼叫型别、机器IP、服务名称、耗时、层级关系、异常资讯、业务系统的自定义资料等。
在一次分散式请求中，都有四个埋点阶段，如下图。
客户端传送（Client Send）：客户端发起请求时埋点，需要传递一些引数，比如TraceId、SpanId等；服务端接收（Server Receive）：服务端接受请求时埋点，回填一些引数，比如TraceId、SpanId等；服务端响应（Server Send）：服务端返回请求时埋点，将埋点资料传递到后端执行绪；客户端接收（Client Receive）：客户端接受返回结果时埋点，将埋点资料传递到后端执行绪；六，示例
接下来我们通过一个示例进行详细描述，如下图，对于一次分散式请求，TraceId=12345。
在应用A收到客户端请求时刻为0ms，响应请求时刻为69ms，即是本次请求耗费时长69ms
七，资料储存
呼叫链路资料的实时查询主要是通过Hbase，使用traceID作为RowKey，SpanId + Type（c代表客户端、s代表服务端）能天然的把一整条呼叫链聚合在一起，提高查询效率。
一，低开销与取样
低开销是LTrace的一个关键的设计目标，如果一个 工具 价值未被证实但又对效能有影响的话，使用者通常不会接受它。取样可以降低开销，但是简单的取样可能导致取样结果无代表性，LTrace通过提供多种取样机制来满足效能和代表性两方面的需求。
最初我们的预设取样策略很简单，是在每100个请求中选择一个进行跟踪，这种策略对于那种请求量很高的服务来说，可以保证跟踪到有价值的资讯；但对于那些负载不高的服务来说，可能会导致取样频率过低，从而遗漏重要资讯，因此我们提供了自定义取样策略；对于异常、超时等这类极端的情况，我们认为这类资料非常有价值，因此我们决定在极端情况下全取样；另外，对于测试人员，我们提供了可对一次请求显示指定取样。这样取样就既灵活又高度可控。
此外，通过优化讯息、快取、储存结构、批量异步写入等方式，平台效能得到大幅度提升。
通过以上取样策略与效能优化手段，我们只需要线上原来几十分之一的机器数量，就能够实现原来数十倍机器相同的效果。
二，日志TraceId系结
我们通常为了便于在日志中跟踪一次请求，一般做法是在专案收到请求的入口放入一个RequestId。现在，应用方可以将TraceId系结到日志中，通过这个TraceId我们不仅能够将应用内一次请求给串联起来，同时还能够用这个TraceId到上下游应用中去进行串联。有时为了知道界面都有哪些上游在使用，通过在日志中记录呼叫方来源。LTrace就能够解决这个问题，通过在每次请求中输出当前请求已经过的应用名称列表，我们不仅能通过日志就能够识别这个请求的上游，还能知道这个请求所经过的所有上游应用以及请求入口。
三，支援自定义TraceId
为便于研发、测试人员进行线上线下问题的除错、排查，LTrace平台支援传递自定义TraceId，通过TraceId对问题进行跟踪。
四，支援多执行绪等场景
业务系统中，可能会存在一些对执行绪池的使用场景，而执行绪池的切换对于TraceId的传递是很困难的。在LTrace平台中，我们提供了显示API的支援方式，保证在多执行绪的场景下TraceId也能进行上下文传递。
五，业务方接入简单，稳定可靠
业务方接入LTrace平台，只需要花费几分钟阅读使用文件，新增几行配置，就能够投入使用。Trace系统的可用效能够达到99.99%以上，业务系统的稳定性不依赖LTrace平台的稳定性，即使LTrace平台出现异常，也不会对业务系统的稳定性造成任何影响。经验总结
使用LTrace平台，我们可以理清系统之间关系，帮助找到关键系统路径上的请求延迟，解决并提高整体效能；分析请求是否正确传送给了服务提供者，进行正确性检查；同时我们还将LTrace与公司的监控系统进行整合，如果异常发生了，我们会生成包含TraceId在内的详细异常资料并上报给监控系统，监控服务立即发出实时的问题报警，这样可以帮助快速发现异常以及异常的情况。以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多关注。
