各大厂分布式链路跟踪系统架构对比

  • 时间:
  • 浏览:1

Dapper是Google生产环境下的分布式跟踪系统,Dapper另一个多多多多设计目标:

Trace: 一次服务调用追踪链路。

直接向日志下发器发异步请求(有本地内存缓存),一台客户端会连向好多个服务端,当另一个多多多服务端出大问题,数据不让丢失。

最后另一个多多多稳定版本是2014年1月,前一天前一天抛妻弃子维护。

Client && Server:对于跨服务的一次调用,请求发起方为client,服务提供方为server

    以上几款链路跟踪系统都每个人满足了请求链路追踪的功能,但落实到你们都 每个人的生产环境中时,什么Trace系统处于诸多大问题:Google和alibaba的Trace系统不开源,但现阶段来说阿里是做得最好的,前一天用的是阿里的服务器,可考虑直接用阿里的追踪系统以节省开发代价;

Cs CLIENT_SEND,客户端发起请求

    在调用链的各个环节分别添加调用速度,可不上能分析系统的性能瓶颈,进行针对性的优化。通过分析各个环节的平均速度,QPS等信息,可不上能找到系统的薄弱环节,对许多模块做调整,如数据冗余等。

一条调用链的日志散落在调用经过的各个服务器上,首先可不上能了按 TraceId 汇总日志,但会 按照RpcId 对调用链进行顺序下发。用链数据固然求百分之百准确,可不上能允许上端的次责日志丢失。

Zipkin中针对 HttpClient、jax-rs2、jersey/jersey2等HTTP客户端封装了拦截器。可不上能在较小的代码侵入条件下实现URl请求的拦截、时间统计和日志记录等操作。

当所有服务端都挂掉,消息会存入queue,当queue满了,就丢弃了,没办法 做数据存储本地等工作。

Span: 追踪服务调基本特征,多span形成树形特征组合成一次Trace追踪记录。

Ss SERVER_SEND,服务端发送结果

Annotation:在span中的标注点,记录整个span时间段内处于的事件。

大范围部署,扩展性:作为分布式系统的组件之一,另一个多多多优秀的调用跟踪系统可不上能了支持分布式部署,具备良好的可扩展性

③dapper下发器将结果写到bigtable中,一次跟踪被记录为一行。 

Cat是直接将日志发往消费集群;hydra是发给日志下发器,日志下发器推到消息队列;Zipkin的client将统计日志发往消息队列,日志下发器读取后落地存储;Dapper和Eagle eye是记录本地文件,后台系统多多线程 定期扫描。

一次典型的分布式调用过程,如下图所示:

Exception 记录异常事件

调用耗时,调用结果,异常信息,消息报文等;

    大的互联网公司都有每个人的分布式跟踪系统,比如Google的Dapper,Twitter的zipkin,淘宝的鹰眼,新浪的Watchman,京东的Hydra等,下面来简单分析。

如可抓取和存储日志,记录本地文件,使用额外的后台系统多多线程 定期(时间间隔小)下发日志。许多最好的方式的优势在于对应用的性能影响小,方便做消息堆积;但会 可不上能了在每台业务server上都部署并管理日志下发agent,运维量比较大。

Span: 追踪服务调基本特征,表示跨服务的一次调用; 多span形成树形特征,组合成一次Trace追踪记录。

关于淘宝的鹰眼系统,主要资料来自于内次责享:

Cr CLIENT_RECIEVE,客户端收到响应

    前一天 Brave 的注入可不上能了依赖底层框架提供相关接口,但会 固然可不上能了对框架另一个多多多多全面的了解,只可不上能了知道能在什么地方注入,并能在注入的前一天取得什么数据就可不上能了。就像上端的例子,你们都 根本可不上能了了知道 MySQL 的 JDBC Driver 是如可实现的也可不上能做到拦截 SQL 的能力。但会 Pinpoint 就不然,前一天 Pinpoint 几乎可不上能在任何地方注入任何代码,这可不上能了开发人员对所需注入的库的代码实现有非常深入的了解,通过查看其 MySQL 和 Http Client 插件的实现就可不上能洞察许多点,当然这也从另外另一个多多多层面说明 Pinpoint 的能力确实可不上能非常强大,但会 其默认实现的越多越多插件前一天做到了非常细粒度的拦截。

    针对底层框架没办法 公开 API 的前一天,确实 Brave 也固然全部无计可施,你们都 可不上能采取 AOP 的最好的方式,一样并能将相关拦截注入到指定的代码中,但会 显然 AOP 的应用要比字节码注入简单越多越多。

    以上什么直接关系到实现另一个多多多监控的成本,在 Pinpoint 的官方技术文档中,给出了另一个多多多参考数据。前一天对另一个多多多系统集成语句,没办法 用于开发 Pinpoint 插件的成本是 30,将此插件集成入系统的成本是 0;但对于 Brave,插件开发的成本可不上能了 20,而集成成本是 10。从许多点上可不上能看出官方给出的成本参考数据是 5:1。但会 官方又强调了,前一天有 10 个系统可不上能了集成语句,没办法 总成本可是我我 10 * 10 + 20 = 120,就超出了 Pinpoint 的开发成本 30,但会 可不上能了集成的服务越多,许多差距就越大。

日志的下发和存储有许多开源的工具可不上能选泽,一般来说,会使用离线+实时的最好的方式去存储日志,主可是我我分布式日志下发的最好的方式。典型的出理 方案如Flume结合Kafka等MQ。

    通过阿里云提供的EDAS结合ARMS可不上能打造立体化监控体系,其中EDAS用于应用管控层面,用于控制链路和应用;而ARMS更关注业务运营层面,如电商交易、车联网、零售;实际上,监控可不上能了全方位关注业务、链路、应用、系统,通过ARMS与EDAS相互补全,形成了立体化监控体系。

Annotation: 在span中的标注点,记录整个span时间段内处于的事件。

    Pinpoint 与 Zipkin 都有基于 Google Dapper 的那篇论文,但会 理论基础大致相同。Pinpoint 与 Zipkin 有明显的差异,主要体现在如下好多个方面:

功能、数据跟踪模型与hydra例如。Zipkin一种不开源,开源社区的是另外一套scala实现,依托于finagle许多RPC框架。架构如下:

BinaryAnnotation:可不上能认为是特殊的Annotation,用户自定义事件。

    Twitter的OpenZipkin使用scala开发,但会 确实现基于twitter组织组织结构的RPC框架finagle,第三方依赖比较多,接入和运维的成本非常高。

用户自定义类型:

    随着互联网架构的扩张,分布式系统变得日趋比较复杂,越多的组件开始英语 英文走向分布式化,如微服务、消息收发、分布式数据库、分布式缓存、分布式对象存储、跨域调用,什么组件一齐构成了比较复杂的分布式网络,那现在的大问题是另一个多多多请求经过了什么服务后其中再次出先了另一个多多多调用失败的大问题,只知道有异常,但具体的异常在哪个服务引起的就可不上能了进入每另一个多多多服务上端看日志,另另一个多多多的出理 速度是非常低的。

全量采样,系统繁忙的前一天对性能影响较大(前一天达到10%的影响)

    从短期目标来看,Pinpoint 确实具有压倒性的优势:不让对项目代码进行任何改动就可不上能部署探针、追踪数据细粒化到最好的方式调用级别、功能强大的用户界面以及几乎比较全面的 Java 框架支持。但会 长远来看,学习 Pinpoint 的开发接口,以及未来为不同的框架实现接口的成本都还是个未知数。相反,掌握 Brave 就相对容易,但会 Zipkin 的社区更加强大,更有前一天在未来开发出更多的接口。在最坏的情況下,你们都 也可不上能每个人通过 AOP 的最好的方式添加适合于你们都 每个人的监控代码,而固然可不上能了引入越多的新技术和新概念。但会 在未来业务处于变化的前一天,Pinpoint 官方提供的报表有无能满足要求可是我我好说,增加新的报表也会带来不可不上能预测的工作难度和工作量。

Trace:一次全部的分布式调用跟踪链路。

①各个服务将span数据写到本机日志上;

BinaryAnnotation: 属于Annotation一种类型和普通Annotation区别,这键值对形式标注在span中处于的事件,和许多许多相关的信息。

注意Dapper与Eagle eye都有开源。

下发即系统在当前节点的上下文信息,可不上能分为客户端下发、服务端下发,以及客户端和服务端双向型下发。下发日志通常要含有以下内容:

Annotation类型:保留类型

低损耗:服务调用下发一种会带来性能损耗,这就可不上能了调用跟踪的低损耗,实际中都有通过配置采样率的最好的方式,选泽一次责请求去分析请求路径

延展性:Google大慨在未来几年的服务和集群的规模,监控系统都应该能全部把控住。

鹰眼下发和心成日志:

    与dubbo框架集成。对于服务级别的跟踪统计,现有业务可不上能无缝接入。对于细粒度的兴趣点,可不上能了业务人员手动添加。架构如下:

出理 分为有一个阶段:

低侵入性,应用透明:作为非业务组件,应当尽前一天少侵入前一天无侵入许多业务系统,对于使用方透明,减少开发人员的负担

    最后可不上能了考虑日志下发(直接发送、记录到本地再上传)、日志接收(消息队列,直接进入ElasticSearch)、数据清洗(Logstach、Storm、SparkStreaming)、日志存储(Mysql、Hbase、ElasticSearch)、页面展示(自研还是直接用第三方的)。

②dapper守护系统多多线程 进行拉取,将数据读到dapper下发器里;

预留可扩展字段,为下一步扩展做准备;

各术语在一次分布式调用中,关系如下图所示:

开源项目已于2013年6月停止维护。

架构简单。可不上能实现另一个多多多Trace系统的所有功能。架构如下图所示:

    调用链绑定业务后查看具体每条业务数据对应的链路大问题,可不上能得到用户的行为路径,经过了什么服务器上的哪个服务,汇总分析应用在越多越多业务场景。

Zipkin与许多Trace系统的不同之处于于:

Sr SERVER_RECIEVE,服务端收到请求

与CAT例如。支持自适应采样,规则粗暴简单,对于每秒钟的请求次数进行统计,前一天超过30,就按照10%的比率进行采样。

 

    前一天都有用阿里的服务,你们都 可不上能借鉴什么开源实现的思想, 自行开发Trace系统。那是每个人从0开始英语 英文开发还是基于开源方案二次开发? 这上端也要考虑到跨平台,如NET和java环境,尽量减少原系统的侵入性或只可不上能了更改大量的代码即可接入,在这里可不上能基于zipkin和pinpoint进行二次开发,功能可参考阿里的系统。

TraceId、RPCId、调用的开始英语 英文时间,调用类型,协议类型,调用方ip和端口,请求的服务名等信息;

    京东和点评的确实开源,但会 前一天多年没办法 维护,项目依赖的jdk版本以及第三方框架过于陈旧等等,不适合用在生产环境中;

    通过调用链跟踪,一次请求的逻辑轨迹可不上能用全部清晰的展示出来。开发中可不上能在业务日志中添加调用链ID,可不上能通过调用链结合业务日志快速定位错误信息。

    通过可视化分布式系统的模块和你们都 之间的相互联系来理解系统拓扑。点击某个节点会展示许多模块的详情,比如它当前的情況和请求数量。

汇总得到各个应用节点的调用链日志后,可不上能针对性的对各个业务线进行分析。可不上能了对具体日志进行下发,进一步储处于HBase前一天关系型数据库中,可不上能进行可视化的查询。

鹰眼的实现小结:

应用级的透明:对于应用的系统多多线程 员来说,是可不上能了了知道有跟踪系统这回事的。前一天另一个多多多跟踪系统想生效,就可不上能了可不上能了依赖应用的开发者主动配合,没办法 许多跟踪系统显然是侵入性太强的。

跨服务的跟踪功能与点评组织组织结构的RPC框架集成,这次责未开源。

对于最好的方式调用、sql、url请求等粒度较小的兴趣点,可不上能了业务人员手写代码实现。

低消耗:跟踪系统对在线服务的影响应该做到足够小。

Trace调用模型,主要有以下概念:

    分布式调用链确实可是我我将一次分布式请求还原成调用链路。显式的在后端查看一次分布式请求的调用情況,比如各个节点上的耗时、请求具体打到了哪台机器上、每个服务节点的请求情況等等。

Transaction是最重要的事件消息类型,适合记录跨越系统边界的系统多多线程 访问行为,比如远程调用,数据库调用,也适合执行时间较长的业务逻辑监控,记录次数与时间开销。Transaction可嵌套。

Event 记录普通事件