Leoncom » 分布式服务的Trace——Google Da

对于分布式在线服务，一个请求须要通过系统中多个模块，上百台机器的协做完成单次请求，典型场景就是Search Engine的一次用户检索，单靠人力没法掌握整个请求中各个阶段的性能开销，更没法快速的定位系统中性能瓶颈。Google Dapper文章描述了普遍用于Google内部服务的Trace Infrastruce—Dapper(原文地址见这里，译文地址见这里)，文章自己的很易懂，没有复杂、精巧的实现机制(好像也是g公司publish出来的文章的特色)，有一些分布式在线服务经验的程序员均可以很好的理解(英文版)，这里就只抽一些点出来记录。而Zipkin是Twitter开源出来的一个Trace系统组件，实现中就参考了Google Dapper，项目主页见http://twitter.github.io/zipkin/。

Google Dapper

目标: 无所不在的持续跟踪(ubiquitous deployment,and continuous monitoring)，只有无所不在和持续，才能保证全部的问题都能被跟踪到，由于服务也是7*24的。为了作到这两点，Dapper对于这个Tracing组件，拆分出以下几个目标。

• 低消耗(Low overhead): 分布式在线系统对于性能、资源要求都很严格，Trace组件必须对服务影响足够小，不然必定不会被启用。
• 应用层透明(Application-Level Transparency): 应用层开发者不须要对Trace组件关心，Trace嵌入到基础通用库中，提供高稳定性，而若是Trace须要应用开发者配合，那可能会引入额外的bug致使Trace系统更加脆弱。
• 扩展性(Scalability): Google的服务在线集群数量可想而知，一次检索就可能跨越上百台甚至成千台机器，所以这个Trace Infrastructure的扩展性也很重要。
• 快速的数据分析(Analysis Quickly): 数据快速导出和分析，可以快速的定位系统的异常，及时应对，提高系统的稳定性。

典型检索场景：单次user检索贯串先后端多个模块，模块之间使用rpc进行通讯，以下图，request须要系统中由不一样团队、不一样语言构成的多个模块通讯协做完成，典型的一个自上而下的调用序列。Dapper的采集方式基于这种调用序列构成的树，拆分为不一样的span(一次rpc远程调用)，经过全局惟一的Trace Id串起来，span指向本身的parent span。

Trace组件的实践经验：

• 低采样率：在保证数据偏差的状况下，Dapper尽量采用低的采样率来保证Trace的low overhead，一方面会给应用层本身的Annotation标记留出更多的性能空间，也能够在硬盘上保存更长时间的数据。
• 带外数据收集(out-of-band)：Trace组件将span信息落地到本机，使用守护进程进行带外收集，能够避免Trace数据占用检索带宽。同时，并非全部的调用过程都是完美的嵌套(prefect nested)，有些组件会在下游返回结果前先向上游汇报一些结果，不适合将Trace结果与检索数据绑定。
• 数据隐私：Trace系统仅面向的是系统的性能开销诊断，考虑到隐私，Dapper只记录RPC的名称和性能开销，对于一些策略和业务数据，能够考虑使用相似Online Debug的系统实现，引入权限控制。
• 精简的基础lib：Dapper基础代码库很精简，便于植入各个通用库，保证稳定性和性能开销，在大部分控制流的基础库上进行了默认植入，来记录各个span的开销，其中C++的代码实现不到1000行。
• 控制Dapper数据采集守护进程的资源消耗：机器上的一些例行任务，例如数据统计脚本运行、外部数据的自动更新等，也会对部署在机器上的进程产生性能影响。所以，Dapper守护进程的性能数据采集，对使用的网络、CPU都很是谨慎，Dapper守护进程为内核scheduler最低的优先级。
• 开放API和易用的UI：方便的DAPI来访问导入到Bigtable中的采集数据，其余使用方可使用API来构建web应用、可执行的command等(根据经验，RESTFul是一个不错的选择)，而且默认提供一个良好的UI，便于查询。

Twitter Zipkin

Zipkin的项目主页上说到——Zipkin is a distributed tracing system that helps us gather timing data for all the disparate services at Twitter. It manages both the collection and lookup of this data through a Collector and a Query service. We closely modelled Zipkin after the Google Dapper paper。看Zipkin的Architecture文档，描述上也都实现了一些Dapper文章中核心的描述。

Zipkin Infrastructure

• Trace数据的收集系统，使用了Facebook开源的Scribe做为日志传输通路，将不一样service上的Trace数据传输到Zipkin/Hadoop。
• Zipkin的Storage系统最早使用的是Cassandra，后来加入了Redis, HBase, MySQL, PostgreSQL, SQLite, and H2等存储系统的支持，猜想这个也是Twitter当时放弃Cassandra转回MySQL有关。
• Twitter中普遍使用了一个叫作Finagle的Java Async RPC服务，将trace library嵌入到这个Finagle中就成为支持系统跟踪的一个天然而然的选项。这个Library也是基于Dapper文章中的几个概念(Annotation—包含host、时间戳的key/value；Span—一次特定的rpc调用，包含多个Annotation；Trace—由一组span组成，共享一个root span)。
• Client和Server在通讯时，会在tracing header信息中加上TraceId(标识整个trace)、SpanId(独立的RPC request)、可选的Parent SpanId(一个服务会调用多个下游RPC服务)以及Sample boolean变量(标识本次是否采集)。
• 经过Thrift Api来提供数据的访问查询功能，并搭建本身的UI(基于Rails，使用了d3js)。

按照主页上描述，Server接收到Client请求后，解析Trace头的处理逻辑流程图，本身画的简易流程图(字很丑- -)。

不管是Dapper的文章，仍是Zipkin的主页，对于分布式系统中Trace Infrastructure的描述都比较简单，只提到了一些必须的基础组件，以及每一个组件须要关注的问题。但结合实际工做中经验，这样完备的Trace系统对分布式在线服务的异常诊断、性能优化有很是大的帮助，而这样的Trace组件又对各个基础组件的要求很是高。健壮、完备的基础组件对于这样系统的搭建是很是有益的。