企业规模化微服务分布式追踪落地实践

PegRandolph 发布于1年前

本文整理自「论道云原生之 Spring Cloud 中国技术沙龙」DaoCloud 微服务开发工程师 谭建 和 DaoCloud 前端工程师 王垚 带来的议题《企业规模化微服务分布式追踪落地实践》。

作者简介

企业规模化微服务分布式追踪落地实践   谭建

DaoCloud 微服务开发工程师 

谭建, DaoCloud 微服务开发工程师,在 DaoCloud 参与微服务产品研发,现专注于公司微服务项目配置中心和链路追踪以及开源社区的建设。

企业规模化微服务分布式追踪落地实践

王垚

DaoCloud 前端工程师

王垚, DaoCloud 前端工程师,在 DaoCloud 参与微服务产品研发,国内前端容器化实践者,致力于公司微服务项目前端以及开源项目的建设,推动团队前端技术演进,现专注于前端集成化和可视化探索。

规模化服务带来的挑战

企业规模化微服务分布式追踪落地实践

首先,回顾一下服务开发架构的发展历程,最初我们开始学习编程或者开发的时候,可能都是从主机模式着手,随后学习基于 C/S 架构的开发模式,接着是 J2EE 的流行到现在的微服务和基于容器的微服务,以及目前比较热门的基于流程编排的开发架构。但我们发现,虽然开发、迭代、交付的效率得到了很大的提升,但是系统或者应用变得更加复杂。

企业规模化微服务分布式追踪落地实践

因此,规模化微服务给我们带来了什么样的挑战呢,总体来说大致可以分为以下几点

  • 需要在分布式系统下确保我们的服务发现/注册中心的可用性。

  • 必须面对容器化环境给我们系统带来的挑战

  • 多个服务之间的依赖关系变得复杂无比,需要通过一定 DevOps 手段来对系统进行治理。

企业规模化微服务分布式追踪落地实践

同时,规模化微服务对 APM 也产生了一定的影响:

  • 微服务的规模和动态性使得数据收集的成本大幅度提高,例如 CPU 、内存和网络传输的开销。

  • 大量的监控数据对后台数据处理分析的产生影响,服务体量非常大的情况下,出现了问题之后,如何快速定位到发生问题的根本原因上。

  • 对于可视化和关联分析的要求方面,传统 APM 缺少好的手段。

Distributed Tracing System & Open Tracing

企业规模化微服务分布式追踪落地实践

要了解分布式追踪,需要先了解几个概念,这张图是开源社区或者国内团队交流的时候经常会拿出来展示的一个图:

  • Metrics 指标性统计: 例如统计一个服务的 TBS 的正确率、成功率、流量等,这是常见的针对单个指标或者某一个数据库的。

  • Tracing 分布式追踪: 这里提到的是一次请求的范围,也就是从浏览器或者手机端发起的任何一次调用,甚至可以再推广一点,是一次业务流程,比如说一次订购的过程,从浏览商品到下定单、支付、物流,最后交到我们手上。这是一个流程化的东西,我们需要轨迹,需要去追踪。

  • Logging 日志记录: 程序在执行的过程中间产生的一些日志,会一帧一帧地输出,这是日志记录。

如果要做一个监控产品,首先要明确自己的定位,每个领域的侧重点是不一样的,并且这些领域之间会有交叉点。比如 Metrics 和 Logging,例如对于某个指标的统计,如果通过日志的方式去做了搜集,最后统计了这些 Metrics 的信息,以及这些 Metrics 信息和对应的 Logging 的关系。那么这属于 Metrics 和 Logging 之间的范围。如果要去做Tracing、 Metrics 和 Logging 中间的这些点,需要清楚是否付出这么大的代价。因为每占到这个圆中的一个部分,系统复杂度、内存的开销、后端的存储都需要付出相应的代价。随着指标数、内容的加入,系统所要投入的研发技术难度也在逐步上升。

企业规模化微服务分布式追踪落地实践

谈到分布式追踪,那么必然会提及到 Google 的《Dapper》论文,在论文中,提到了一个简单的调用链中从用户请求到后端的每次调用和响应的大致流程,以及我们应该怎样将这个调用链串联起来,并通过怎么样的方式来记录这些调用数据,右边提供了一种参考的可能,Dapper daemon 从客户端处采集信息,将数据发送到 Dapper Collectors收集器里面,收集器将数据进行清洗之后存放至 Bigtable 等数据库进行结构化存储。可以发现,目前流行的一些分布式追踪方案的整体架构也和这个流程很类似,包括Zipkin、Pinpoint、Skywalking 等。

企业规模化微服务分布式追踪落地实践

Open Tracing 是一套分布式追踪协议,与平台,语言无关,统一接口,方便开发接入不同的分布式追踪系统。

一个完整的 Open Tracing 调用链包含 Trace + span + 无限极分类。

企业规模化微服务分布式追踪落地实践

几种开源的分布式追踪方案

一、 RocketBot UI & Skywalking

企业规模化微服务分布式追踪落地实践

二、Zipkin & Pinpoint

企业规模化微服务分布式追踪落地实践

各个方案比较:

企业规模化微服务分布式追踪落地实践

使用Skywalking实现全链路监控

企业规模化微服务分布式追踪落地实践

Skywalking 的整体架构图,与 Dapper 整体架构大同小异,Skywalking主要包括了探针,Collector收集器,数据存储和界面展示四大模块。

企业规模化微服务分布式追踪落地实践

这里对 Skywalking 探针做个介绍。

假设有三个服务,服务 A 调用服务 B,随后,服务 B 接着调用服务 C,最终服务 C 链接 Mysql 数据库。在整个流程中,Skywalking 是怎样将调用链串联起来的呢?

上图包含了一些 Open Tracing 的概念,也包含了一些 Skywalking 本身的概念,比如 TraceSegment,这主要是为了处理类似于 Java 这种多线程的问题。这里一共会产生四个 Segment,其中有一个是在 Servie B 中的新的线程产生。

那么,首先从调用Service A 开始,探针会在请求入口处创建一个入口 Span,并携带本次请求的相关数据,比如操作名称,对方主机 ip 和端口等。

入口 Span 创建完毕过后,会将该 Span 注入到一个追踪上下文里面,这个上下文在随着服务 A 发起调用的时候随着 Http 请求头部传递给 Service B 的 Segment,Service B 在接收到请求会解读追踪上下文,然后重复 Service A的步骤,唯一不同的是 Serive B 中会额外的创建一个 Segment。同样的 Service C 重复 Servie B 的步骤。当整个调用完成过后,会将追踪上下文发送到 Collector 收集器。

企业规模化微服务分布式追踪落地实践

关于 Skywalking 6.0.0版本的特性:

  • 去掉了 5.x 版本中一些不太方便使用的地方,

  • 增加了接收不同追踪系统追踪数据的功能

  • 增加了 Service Mesh Probe 支持从 Istio 控制面中采集应用与应用之间的调用、监控遥测数据。

企业规模化微服务分布式追踪落地实践

主要了解一下 Skywlaking 如何与 Istio 结合,左边是一个 Istio 官方图,Servie A 与 Service B 之间的调用会通过 Proxy,而 Proxy 之间的交互也会通过 Mixer,只要 Proxy 有数据,那么 Mixer 就有数据,Skywalking 探针就会从 Mixer 中采集走数据到 Skywalking Collector 后端。

这样的好处是,整个流程是对应用是无感知的,没有应用探针的概念,没有多语言的概念,所有的流程都建立在应用之外。不再需要比如在启动 Java 应用的时候通过 javaagent参数指定探针包,真正的实现零侵入性。

在企业应用中的分布式追踪

企业规模化微服务分布式追踪落地实践

首先,在企业应用中的分布式追踪 ,一个链路追踪系统应该具备这样一些功能:

  • 故障快速定位

  • 各个调用环节的性能分析

  • 数据分析

  • 生成服务调用拓扑图

企业规模化微服务分布式追踪落地实践

这里介绍一下  DaoCloud 的微服务治理平台

  • 非侵入式的多语言探针

  • 兼容 Open Tracing 规范

  • 可视化拓扑图展示,快速梳理调用链(如下图)

  • 告警缓慢或不稳定的应用程序、实例和服务

  • 轻量级且强大的后端聚合分析功能

  • 支持手动采集数据、与日志系统集成、自定义插件

  • 孵化特性:支持分析其他监控系统的数据格式,比如 Zipkin JSON, Thrift,Protobuf v1 和 v2 等特点。

企业规模化微服务分布式追踪落地实践

企业规模化微服务分布式追踪落地实践

Skywalking 给开发带来了什么

企业规模化微服务分布式追踪落地实践

平时开发中,大多数都会采用这种方式:后端定义接口并提供给前端,前端连接接口并获取后端返回数据处理数据再用于展示。

企业规模化微服务分布式追踪落地实践

而 Skywalking 的后端不同于平常的后端,它引入了一个新的接口规范:GraphQL 。GraphQL 官方定义如下

  • 描述你的数据

  • 请求你所要的数据

  • 得到可预测结果。

GraphQL 是从 sql 发展而来,类似于前端发出一条 sql ,后端返回一个json。更优的是 GraphQL 自身支持图结构,因此可以支撑起图数据。这点在 Skywalking 中主要运用于拓扑图的数据返回。GraphQL 的模型可以很灵活的进行扩展的,而这种拓展不依赖于后端,后端的工作仅仅是声明有什么服务,前端就能够按需使用后端定义的内容。传统 restful 完全由后端控制,前端无法根据需要的功能做扩展。同时,开发不再围绕 ui 做功能。GraphQL 为后端提供了一种能力,这种能力是范围性的。项目需要什么功能,就设计这个功能,前端具体怎么用由前端自己发挥。

企业规模化微服务分布式追踪落地实践

Rocketbot 开源项目 完美搭配 Skywalking)

企业规模化微服务分布式追踪落地实践

开源项目 Rocketbot 是我们为 Skywalking 定制的一款新型的UI项目,在交互上和拓扑图联路追踪上做了很大程度的优化。界面更加的清新美观,将服务和应用的界限模糊化,定制了新的业务流程,使操作简单化。

企业规模化微服务分布式追踪落地实践

  • Rocketbot代码仓库:

    企业规模化微服务分布式追踪落地实践

  • Live Demo:

    企业规模化微服务分布式追踪落地实践

想了解更多关于 Rocketbot 的内容可以加入微信交流群哦,关注 道客船长 公众号并回复关键词 Rocketbot 即可获得进群方式~

  3 步不再错过技术干货 

企业规模化微服务分布式追踪落地实践

点击 [道客船长]

企业规模化微服务分布式追踪落地实践

企业规模化微服务分布式追踪落地实践

企业规模化微服务分布式追踪落地实践

再点击 右上角

企业规模化微服务分布式追踪落地实践

企业规模化微服务分布式追踪落地实践

点击 [设为星标]

企业规模化微服务分布式追踪落地实践

企业规模化微服务分布式追踪落地实践

查看原文: 企业规模化微服务分布式追踪落地实践

  • heavypanda
  • biglion