Zipkin使用MySQL数据库进行存储，这反过来又需要创建一个OpenShift 共享存储。假定已经有了:
SpringCloud 微服务 使用 Sleuth+ Zipkin 的应用架构实现链路追踪的逻辑图如下：
在官方的demo中提供了docker镜像启动和jar包启动，但如果要做个性化开发的话必须通过自建项目然后引入zipkin server依赖进行启动。 前面两种启动方式官网都有详细的教程，这里就不介绍了。下面主要介绍一下自建项目引入zipkin server依赖启动的方式。
Zipkin是一种分布式跟踪系统。 它有助于收集解决服务体系结构中的延迟问题所需的计时数据。 功能包括收集和查找此数据。
随着微服务架构的流行，系统变得越来越复杂，单体的系统被拆成很多个模块，各个模块通过轻量级的通信协议进行通讯，相互协作，共同实现系统功能。
参考：腾讯云手动实验https://cloud.tencent.com/developer/labs/lab/10195
spring cloud gateway是spring cloud家族最新的api网关，之前用的是netflix zuul 1.0，netflix 2.0最终没有孵化出来，于是spring自己开发了现在的spring cloud gateway，与zuul 1.0不同的是spring cloud gateway是基于spring5 springboot2以及proactor技术栈开发的第二代网关，由于本文重点不是spring cloud gateway，这里就不再赘述，详情参考https://spring.io/projects/spring-cloud-gateway，某个接口返回慢时我们需要分析具体原因，到底在哪个环境出了问题或者速度被拉慢，在分布式系统中调用链追踪的功能不可或缺，这方便我们更快的找到问题出处，解决问题。zipkin是一款不错的调用链追踪工具，类似的还有skywalking以及pinpoint，本文讲述zipkin环境的搭建
微服务架构是一个分布式架构，它按业务划分服务单元，一个分布式系统往往有很多个服务单元。由于服务单元数量众多，业务的复杂性，如果出现了错误和异常，很难去定位。主要体现在，一个请求可能需要调用很多个服务，而内部服务的调用复杂性，决定了问题难以定位。所以微服务架构中，必须实现分布式链路追踪，去跟进一个请求到底有哪些服务参与， 参与的顺序又是怎样的，从而达到每个请求的步骤清晰可见，出了问题，很快定位。
在实际应用中，你做了那么多 Server 端，写了 N 个 RPC 方法。想看看方法的指标，却无处下手？
本文简单介绍了如何利用Zipkin对SpringCloud应用进行服务分析在实际的应用场景中，Zipkin可以结合压力测试工具一起使用，分析系统在大压力下的可用性和性能。
和市面上其它分布式链路追踪系统一样，Zipkin 也是根据 Google 论文《Dapper，大规模分布式系统的跟踪系统》(https://bigbully.github.io/Dapper-translation/) 作为理论，进行设计。
我们知道,微服务之间通过网络进行通信,但在我们提供服务的同时,不能保证网络一定是畅通的。相反地，网络是很脆弱的，网络资源也有限，因此我们有必要追踪每个网络请求，了解它们经过了哪些微服务，延迟多少，每个请求所耗费的时间等。只有这样能更好地分析系统瓶颈，解决系统问题。
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
配套资料，免费下载 链接：https://pan.baidu.com/s/1la_3-HW-UvliDRJzfBcP_w 提取码：lxfx 复制这段内容后打开百度网盘手机App，操作更方便哦
从spring boot 2.0开始，官方就不再支持使用自建Zipkin Server的方式进行服务链路追踪，而是直接提供了编译好的 jar 包来给我们使用
今天这篇文章陈某介绍一下链路追踪相关的知识，以Spring Cloud Sleuth和zipkin这两个组件为主，后续文章介绍另外一种。
环境说明 操作系统：CentOS 7.2 64位 1Zipkin简介 zipkin是一款开源的分布式实时数据追踪系统（Distributed Tracking System），基于 Google Dapper的论文设计而来。其主要功能是聚集来自各个异构系统的实时监控数据。 2 应用场景 故障快速定位 通过分析调用链，可以将一次请求的逻辑轨迹完整清晰的展示出来，通过在开发中在业务日志中添加调用链ID，可以通过调用链结合业务日志快速定位错误信息。 服务可用性 通过分析各个环节的平均时延，QPS等信息，可
这个demo使用Spring Sleuth来收集tracing 数据并将其发送到OpenZipkin, OpenZipkin作为OpenShift服务部署，并由一个持久的MySQL数据库镜像支持。可以从Zipkin控制台查询tracing 数据，该控制台通过OpenShift route公开。日志集成也可以使用trace id将相同业务请求的分布式执行捆绑在一起。
微服务架构是一个分布式架构，微服务系统按业务划分服务单元，一个微服务系统往往有很多个服务单元。由于服务单元数量众多，业务的复杂性较高，如果出现了错误和异常，很难去定位。主要体现在一个请求可能需要调用很多个服务，而内部服务的调用复杂性决定了问题难以定位。所以在微服务架构中，必须实现分布式链路追踪，去跟进一个请求到底有哪些服务参与，参与的顺序又是怎样的，从而达到每个请求的步骤清晰可见，出了问题能够快速定位的目的。
Zipkin分布式跟踪系统；它可以帮助收集时间数据，解决在microservice架构下的延迟问题；它管理这些数据的收集和查找；Zipkin的设计是基于谷歌的Google Dapper论文。 每个应用程序向Zipkin报告定时数据，Zipkin UI呈现了一个依赖图表来展示多少跟踪请求经过了每个应用程序；如果想解决延迟问题，可以过滤或者排序所有的跟踪请求，并且可以查看每个跟踪请求占总跟踪时间的百分比。
业务复杂的微服务架构中，往往服务之间的调用关系比较难梳理，一次http请求中，可能涉及到多个服务的调用(eg: service A -> service B -> service C...)，如果想分析各服务间的调用关系，以及各服务的响应耗时，找出有性能瓶颈的服务，这时zipkin就派上用场，它是Twitter公司开源的一个tracing系统，官网地址为： http://zipkin.io/ , spring cloud可以跟它无疑集成。 使用步骤： 一、微服务方 1.1 添加依赖jar包 comp
在前面：微服务调用链追踪中心搭建 一文中我们利用 Zipkin 搭建了一个微服务调用链的追踪中心，并且模拟了微服务调用的实验场景。利用 Zipkin 的库 Brave，我们可以收集一个客户端请求从发出到被响应 经历了哪些组件、哪些微服务、请求总时长、每个组件所花时长 等信息。
Spring Cloud Sleuth 主要功能就是在分布式系统中提供追踪解决方案，并且兼容支持了 zipkin，你只需要在pom文件中引入相应的依赖即可。
Spring Cloud 是一站式微服务解决方案。很多公司都在使用 Spring Cloud 组件。我们想要学习 Spring Cloud 微服务架构，就需要学习他们的组件。包含：注册中心、负载均衡、熔断处理、过程调用、网关服务、配置中心、消息总线、调用链路、数据监控等等。
上一篇简介了ZipkinServer的搭建，但是从Spring boot2.x版本后，Zipkin官网已经不再推荐自己搭建定制Zipkin，而是直接提供了编译好的jar包。详情可以查看官网：
在微服务架构下，一个http请求从发出到响应，中间可能经过了N多服务的调用，或者N多逻辑操作， 如何监控某个服务，或者某个逻辑操作的执行情况，对分析耗时操作，性能瓶颈具有很大价值， zipkin帮助我们实现了这一监控功能。
一个良好的监控，应该有一个人类亲和的界面，这个界面就是Zipkin。本文详细讨论Sleuth如何与Zipkin配合使用。
分布式微服务时代，方便了业务的快速增长和服务的稳定，但是系统出现问题后，面对同业务多服务排查起来令人头大。这时候领导就想着集成分布式追踪系统。Zipkin 是 Twitter 的一个开源项目，基于 Google Dapper 实现。可以使用它来收集各个服务器上请求链路的跟踪数据，并通过它提供的 REST API 接口来辅助我们查询跟踪数据以实现对分布式系统的监控程序，从而及时地发现系统中出现的延迟升高问题并找出系统性能瓶颈的根源。除了面向开发的 API 接口之外，它也提供了方便的 UI 组件帮助我们直观的搜索跟踪信息和分析请求链路明细，比如：可以查询某段时间内各用户请求的处理时间等。
上篇文章我们介绍了Spring Cloud Sleuth 链路追踪, 可以在输出的log中增加唯一请求的标识以及spanid, 然后可以采用ELK来对数据做集中管理，但是无法提供直观的调用链的展示，本章将介绍使用ZipKin来对数据进行展示。 ZipKin可以很直观的看出一个请求的调用链，从哪个服务开始，到哪个服务，期间用了多少时间等等信息。 首先我们需要创建一个ZipKin的项目，集成ZipKin的ui用于数据的展示和收集, pom.xml配置如下： <dependency> <groupId>i
在构建应用程序时，了解系统的行为方式是运维它的重要部分——这包括能够观察应用程序的内部调用、衡量其性能并在问题发生时能够立即找到问题。这对任何系统来说都是具有挑战性的，对于由多个微服务组成的分布式系统更是如此，其中由多个调用组成的流可能在一个微服务中开始，但在另一个微服务中继续调用。可观测性在生产环境中至关重要，在开发过程中对于了解瓶颈、提高性能和跨微服务执行基本调试也很有用。
前文搭建的Zipkin Server是没有后端存储的——数据会存储在Zipkin的内存中。这一般不适合生产，本节来探讨如何将Zipkin中的数据持久化。
指定版本，在git查看相应版本，参考： https://github.com/openzipkin/zipkin
在大型系统的微服务化构建中，一个系统被拆分成了许多模块。这些模块负责不同的功能，组合成系 统，最终可以提供丰富的功能。在这种架构中，一次请求往往需要涉及到多个服务。互联网应用构建在 不同的软件模块集上，这些软件模块，有可能是由不同的团队开发、可能使用不同的编程语言来实现、 有可能布在了几千台服务器，横跨多个不同的数据中心，也就意味着这种架构形式也会存在一些问题:
当下，已经有很大一部分公司完成了单体架构向微服务架构的迁移改造，并在疲于应对大量微服务间通信问题时，开始考虑采用Service Mesh微服务架构作为服务与服务直接通信的透明化管理框架，以插件式的方式实现各种业务所需的高级管理功能。
Zipkin 是由推特开发的分布式链路追踪系统，用于对 Sleuth 产生的日志加以收集并采用可视化的数据对链路追踪进行分析与图表展示，Zipkin 是典型的 C/S（客户端与服务端）架构模式，需要独立部署 Zipkin 服务器，同时也需要在微服务内部持有Zipkin客户端才可以自动实现日志的推送与展示。
本文是上篇文章《Node.js 应用全链路追踪技术——全链路信息获取》的后续。阅读完，再来看本文，效果会更佳哦。
本项目是sleuth和zipkin在spring cloud环境中使用，其中sleuth和zipkin是通过RabbitMQ进行通信，同时zipkin的数据是存储在mysql中。
随着业务发展，系统拆分导致系统调用链路愈发复杂一个前端请求可能最终需要调用很多次后端服务才能完成，当整个请求变慢或不可用时，是无法得知该请求是由某个或某些后端服务引起的，这时就需要解决如何快读定位服务故障点，以对症下药。于是就有了分布式系统调用跟踪的诞生。现今业界分布式服务跟踪的理论基础主要来自于 Google 的一篇论文《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》，使用最为广泛的开源实现是 Twitter 的 Zipkin。
一般来说要解决这两个问题或者与之类似的问题，就需要用到调用链监控工具。那么调用链监控工具是怎么实现问题的快速定位的呢？这就需要我们理解调用链监控的基础实现原理，我们来看一张图：
Zipkin是一款开源的分布式实时数据追踪系统（Distributed Tracking System），基于 Google Dapper的论文设计而来，由 Twitter 公司开发贡献。其主要功能是聚集来自各个异构系统的实时监控数据。分布式跟踪系统还有其他比较成熟的实现，例如：Naver的Pinpoint、Apache的HTrace、阿里的鹰眼Tracing、京东的Hydra、新浪的Watchman，美团点评的CAT，skywalking等。
如果应用程序在运行过程发生问题，大多数开发人员都难以跟踪日志。这可以通过用于Spring Boot应用程序的Spring Cloud Sleuth和ZipKin服务器来解决。
docker-compose.yml参考官方配置，如下地址： https://github.com/openzipkin-attic/docker-zipkin/blob/master/docker-compose.yml
虽然在SpringBoot2.0以后官方不推荐我们自定义Zipkin服务端，而是使用官方提供的jar包。但是作为开发者来说，如果不能去看一看源码，修改一些自定义的配置的话就好像生命掌握在别人手里一样，哪天碰到一个莫名奇妙的bug可就不开心了。所以本例中使用zipkin最新2.11.8release版本来构建一个服务端
PS：5年前就见过别人演示这种系统，当时才开始搞分布式系统，现在想想确实没有你想不到的功能，只有你做不到的，分布式链路跟踪确实是开发和运维的神奇，良好的定位问题，线上问题的发现。
在微服务架构中，随着业务发展，系统拆分导致系统调用链路愈发复杂，一个看似简单的前端请求可能最终需要调用很多次后端服务才能完成，那么当整个请求出现问题时，我们很难得知到底是哪个服务出了问题导致的，这时就需要解决一个问题，如何快速定位服务故障点，于是，分布式系统调用链追踪技术就此诞生了。
众所周知，Spring Cloud Sleuth有两种方式整合Zipkin： HTTP直连Zipkin方式 MQ方式，架构如下图： Spring Cloud Edgware及更高版本中
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
即时通信 IM
