zipkin客户端源码

A. Dubbo filter扩展

filter其实是一种责任链模式，每个filter只负责完成自己职责的部分，解销前前除耦合，这种设计模式很利于扩展。
大家可能对Dubbo的filter不太熟悉，但是应该都写过Servlet的filter，让我们先来回顾一下Servlet的Filter：

我们重写doFilter，在chain.doFilter(request, response) 前后做一些切面的工作，比如防XSS攻击、CROS跨域请求处理、记录相关日志等，调用逻辑可以用下图来概括：

类似于Servlet中的filter，Dubbo也可以通过扩展filter来增强功能，Dubbo服务提供方和服务消费方均支持调用过程拦截，并且Dubbo 自身的大多功能均基于此扩展点实现，下面例举部分filter：
EchoFilter -> 用于provider的回声测试，检测服务是否正常
ContextFilter -> 用于provider接收RpcContext的参数
ConsumerContextFilter -> 用于consumer传递RpcContext的参数
ExecuteLimitFilter -> 用于provider的限流
ActiveLimitFilter -> 用于consumer的限流
ExceptionFilter -> 用于provider对异常进行封装
GenericFilter -> 用于provider的泛化调用，可用于集成通用服务测试框架或为其他语言调用服务提供Restful接口的支持
AccessLogFilter -> 用于provider 的access log记录
ClassLoaderFilter -> 用于provider切换当前的ClassLoader
MonitorFilter -> 用于bbo monitor模块对consumer和provider进行监控

Dubbo filter的调用逻辑可以用下图来概括：

那么Dubbo是怎么将多个filter串起来的呢？
答案就位于ProtocolFilterWrapper这个类的buildInvokerChain方法。

看明白这里首先要理解Dubbo的SPI扩展点机制，List<Filter> filters = ExtensionLoader.getExtensionLoader(Filter.class).getActivateExtension(invoker.getUrl(), key, group);这一行是获取Filter接口的所有被标注为@Activate的扩展点，然后基于回调让前一个filter调用后一个filter从而串成一个调用链，调用的先后顺序是由每个filter定义的order属性决定的（不声明默认为0），order值越小则调用优先级越高。

了解了Dubbo filter的作用和原理，那让我们来看看如何扩展：
Maven 项目结构：

src
  |-main
    |-java
      |-com
        |-xxx
           |-XxxFilter.java (实现Filter接口)

Dubbo自身的过滤器配置都放在resources/META-INF/bbo/internal下，我们扩展的过滤器一版放在resources/META-INF/bbo/下：
     |-resources
      |-META-INF
        |-bbo
          |-com.alibaba.bbo.rpc.Filter (纯文本文件，内容为：xxx=com.xxx.XxxFilter)

XxxFilter.java：

META-INF/bbo/com.alibaba.bbo.rpc.Filter：

xxx=com.xxx.XxxFilter

我司生产亏清环境中利用Dubbo filter扩展来记录服务调用日志和服务调用链追踪。

1.服务调用日志记录：
服务调用日悔枣志记录分为provider日志和consumer日志两部分，provider日志记录的是当前工程作为provider的服务提供日志，consumer日志记录的是当前工程作为consumer的服务消费日志，以下是部分consumer日志内容：

日志会记录每一次调用的consumer的ip、端口、调用时间、provider的ip、端口、接口请求的时间、调用的方法、调用耗时、调用结果（成功或失败，失败则打印异常）、方法入参（可选）、返回值（可选）等。
由于每次调用的入参和返回值的内容比较多，所以方法入参和返回值是否打印都是可以配置的，filter会根据当前配置的日志等级去打印。

2.调用链追踪：
Dubbo Filter结合brave + zipkin实现RPC调用链追踪和梳理项目间的依赖关系，filter中用brave向zipkin服务器异步发送http请求（也可以用kafka），zipkin服务器对数据进行分析汇总，很容易分析出性能的瓶颈在哪，效果如下：

如果有人对这些具体实现感兴趣，笔者会开放源码。

最后提醒一点，filter的实现中不要写太耗时的方法，会影响性能。

B. 手把手教你学Dapr - 4. 服务调用

通过使用服务调用，您的应用程序可以使用标准的gRPC或HTTP协议与其他应用程序可靠、安全地通信。

先问几个问题：

此时你会发现这些事情HttpClientFactory没有帮你完成，而在微服务中这些又是必不可少的能力，接下来看看服务调用都做了什么

先看一下两个服务之间的调用顺序

默认情况下，调用同一个命名空间的其他服务可以直接使用AppID（假设是：nodeapp）

服务调用也支持跨命名空间调用，在所有受支持的宿主平台上，Dapr AppID遵循FQDN格式，其中包括目标命名空间。

比如调用命名空间：proction，AppID：nodeapp

这在K8s集群中的跨名称空间调用中特别有用

通过托管平台上的相互(mTLS)身份验证，包括通过Dapr Sentry服务的自动证书转移，可以确保Dapr应用程序之间的所有调用的安全。 下图显示了自托管应用程序的情况。

应用程序可以控制哪些其他应用程序可以调用它们，以及通过访问策略授权它们做什么。 这使您能够限制具有个人信息的敏感应用程序不被未经授权的应用程序访问，并结合服务到服务的安全通信，提供了软吵启多租户部署。

在调用失败和瞬态错误的情况下，服务调用执行自动重试，并在回退时间段内执行。

注： 自动重试，默认是开启的，可以关。但如果不关且业务又不支持幂等是很危险的。建议服务的接口要设计支持幂等，这在微服务里也是一个标配的选择。

Dapr可以在各种托管平台上运行。 为了启用服务发现和服务调用，Dapr使用可插拔的名称解析组件。 例如，K8s名称解析组件使用K8s DNS服务来解析集群中运行的其他应用程序的位置。 自托管机器可以使用mDNS名称解析组件。 Consul名称解析组件可以激李在任何托管环境中使用，包括K8s或自托管环境

一图胜千言，就使用mDNS轮着调用

默认情况下，将跟踪应用程序之间的所有调用，并收集指标，以提供应用程序明碰迟的洞察力和诊断，这在生产场景中尤其重要。 这为您提供了服务之间调用的调用图和指标。

pythonapp 通过Dapr sidecar调用nodeapp，通过服务调用的API及gRPC代理依然是上面见到的那个调用流程，做到了语言无关

创建 ASP.NET Core空 项目，并修改 launchSettings.json ，让启动HTTP的启动端口变为5000

修改 Program.cs 文件

此时一共有4个服务

运行 Assignment.Server ：在目录 dapr-study-roomAssignment04Assignment.Server 打开命令行工具，并执行下面命令

调用服务：再打开一个新的命令行工具，并执行下面命令

可以发现4个命令都调用成功了，但是 Assignment.Server 输出结果有点意外

是的，没有 Hello World1! ，那怎么办呢？我们把Hello1的命令改一下

invoke调用的输出除了 App invoked successfully 以外还多了一行 Hello World1!

与此同时 Assignment.Server 的输出正确了

除此之外 invoke 还有一些参数，比如 --data , --data-file ，喜欢研究Dapr CLI的小伙伴可以继续尝试。不过一般情况下用SDK就可以了

创建 控制台应用程序 项目，使用NuGet包管理器添加 Dapr.Client SDK，并修改 Program.cs 文件

看几个细节

注：

使用命令行工具打开目录 dapr-study-roomAssignment04Assignment.Client ，然后执行命令

如果你不是用VS Code终端的PowerShell执行dapr run就可能遇到下面的错误

即便你没有遇到也建议了解一下如何支持非默认端口

因为上面使用dapr run的时候没有指定dapr http port，而默认client访问的是3500端口

解决的办法有两种：

再执行一次 dotnet run 就可以看到正确的输出结果了

篇幅太长了，举一反三吧。就是调用 InvokeMethodGrpcAsync ，然后dapr-http-port换成dapr-grpc-port，DAPR_HTTP_PORT换成DAPR_GRPC_PORT

还记得dapr init的时候docker里有个zipkin吧，通过zipkin可以看一下调用跟踪，通过浏览器打开下面地址

此时页面是空的

根据步骤操作一下就可以看到了

随便点开一行数据尾部的SHOW，就可以看到调用详情

Assignment04

https://github.com/doddgu/dapr-study-room

我们的目标是 自由的 、 易用的 、 可塑性强的 、 功能丰富的 、 健壮的 。

所以我们借鉴Building blocks的设计理念，正在做一个新的框架 MASA Framework ，它有哪些特点呢？

目前源码已开始同步到Github（文档站点在规划中，会慢慢完善起来）：

MASA.BuildingBlocks

MASA.Contrib

MASA.Utils

MASA.EShop

BlazorComponent

MASA.Blazor

QQ群：7424099

微信群：加技术运营微信（MasaStackTechOps），备注来意，邀请进群

C. SpringBoot&SpringCloud升级踩坑

最近遇到了一个项目，需求是升级springboot版本。项目用到了很多组件，redis、Apollo、zipkin以及SpringCloud的一套组件。升级过程踩了很多坑，我把自己遇到的问题整理了一下供大家学习交流。

SpringBoot 1.4.2 ——> 2.3.2
SpringCloud 1.3.1 ——>Hoxton.SR6
jedis 2.8.2 ——>3.3.0
Zipkin的版本仍然使用11.2.0.4的，没有做升级
Apollo-client也没有做升级，使用的是1.6.0的版本

首先，确保SpringBoot和SpringCloud版本对应起来。
在SpringBoot2.x之后的SpringCloud的依赖有一些变化
SpringBoot2.x之前

SpringBoot2.x之后

SpringCloud获取eureka实例的参数改变了
升级前：

升级后：

我们可以看到源码上注释说，这两个方法在3.0之后肆此不用了。如果我们自己写了dataSource就需要友清做出相应的修改。
jedis3.0之前的实现方式

jedis之后我们的实现方式

可能是spring热部署的配置没有关好雹前闭

如果之前的项目没有这个问题，那我们加一个配置把重复的bean覆盖掉就好了

D. Zipkin介绍和使用

Zipkin是一个分布式链路跟踪系统，可以采集时序数据来协助定位延迟等相关问题。数据可以念配神存储在cassandra,MySQL,ES,mem中。分布式链路跟踪是个老话题，国内也有类似的框仔亏架，比如阿里的skywalking。 zipkin目前和SpringCloud生态结合紧密，有相关的支持。

主要包括客户端和一个管理服务端。在客户端采集数据后，发送给服务端，用来展示数据。在每个instrumented的客户端，写入了traceId，然后统一收集数据在服务端存储。这里instrumented翻译过来是仪器化，设备化，为了简单我把他称作 标识实体 ，代表一个接入了zipkin的客户端。

zipkin包括四个组件，collector，storage，search，webUI。其中collector中重点有两个

zipkin可以跟踪多种请求，如async方法,schele,rxjava等，都在 org.springframework.cloud.sleuth.instrument 包下，这里以web请求做介绍。在SpringCloud下用sleuth来做跟踪处理。具体通过一个拦截器 org.springframework.cloud.sleuth.instrument.web.TraceHandlerInterceptor 实现，如下

zipkin支持mem，MySQL，ES存储方式，以 io.zipkin.java:zipkin-server:2.6.1 为例，可以通过配置实现。具体配置项可以在 zipkin-server-shared.yaml 中查看，如下：

同时，举例用MySQL作为存储时的一张span对象表，如下：

一般来说，分布式的链路跟踪卖慎数据是比较大量的，建议采用ES来存储，方便支持分区，以及后期的扩展等，比如使用某些字段来存储非结构化数据。

以上就是所有内容，下面是一个请求和记录展示。

E. spring cloud sleuth 和 zipkin 链路跟踪

提供链路追踪。通过sleuth可以很清楚的看出一个请求都经过了哪些服务；可以很方便的理清服务间的调用关系。

可视化错误。对于程序未捕捉的异常，可以结合zipkin分析。

分析耗时。通过sleuth可以很方便的看出每个采样请高亩陵求的耗时，分析出哪些服务调用比较耗时。当服务调用的耗时随着请求量的增大而增大时，也可以对服务的扩容提供一定的提醒作用。

从官网得知 从2.1.0版开始，Spring Cloud Sleuth支持将跟踪发送到多个跟踪系统，且去掉了 spring cloud streaming，那如果只引入sleuth包，不同机器服务之间相互调用是否还能实现链路追踪？经过测试耐族答案是可以的，源码这里我没研究，但是从技术角度要自己实现，其实只要在 header 里添加一个值(唯一)，在上下游服务之间传递，便可行。

所以结论是如果只是单纯为了使用链路追踪在控制台看，只引入 sleuth 是已经足够的。

Zipkin是Twitter的一个开源项目，我们可以使用它来收集各个服务器上请求链路的跟踪数据，并通过它提供的API接口来辅助查询跟踪数据以分布式系统的监控程序，通过UI组件帮助我们及时发现系统中出现的延迟升高问题以及系统性能瓶颈根源。

Collector（收集器组件）-> 主要负责收集外部系统跟踪信息，转化为Zipkin内部的Span格式。

Storage（存储组件）-> 主要负责收到的跟踪信息的存储，默认为存储在内存中，同时支持存储到Mysql、Cassandra以及ElasticSearch。

API（Query）-> 负责查询Storage中存储的数据，提供简单的JSON API获取数据，主要提供给web UI使用。

Web UI（展示组件）-> 提供简单的web界面，方便进行跟踪信息的查看以及查询，同时进行相关的戚戚分析。

Instrumented Client 和Instrumented Server，是指分布式架构中使用了Trace工具的两个应用，Client会调用Server提供的服务，两者都会向Zipkin上报Trace相关信息。在Client 和 Server通过Transport上报Trace信息后，由Zipkin的Collector模块接收，并由Storage模块将数据存储在对应的存储介质中，然后Zipkin提供API供UI界面查询Trace跟踪信息。Non-Instrumented Server，指的是未使用Trace工具的Server，显然它不会上报Trace信息。

bff-web-data-platform 称为 appname -> 应用名称

368e435f7de29eff 称为 traceId -> 为了追踪一个请求完整的流转过程，可以给每次请求分配一个唯一的 traceId，当请求调用其他服务时，通过传递这个 traceId。

368e435f7de29eff 称为 spanId -> 发生的特定操作的ID

false 称为 exportable -> 是否应将日志导出到Zipkin。

无论是使用 sleuth 或是使用 zipkin 都会在控制台上输出这样的日志信息。

借鉴博客
2.1以下版本中文文档，可以借鉴

F. 分布式链路跟踪sleuth（zipkin+kafka+elasticsearch)

sleuth也不是一个新鲜的东西，说白了就是一个APM的一个浓缩版，spring Cloud Sleuth为 spring Cloud提供了分布式跟踪的解决方案，埋慧它大量借用了Google Dapper、 Twitter Zipkin和 Apache HTrace的设计

构建了ELK的日志系统和监控系统这两个能够快速的发现系统中的问题，但是由于微服务架构中系统众多，系统之间的交互还比较复杂，在产生了大量的日志之后，可以帮助我们定位问题，但是在紧急情况下难以帮助我们快速，是快速的定位和解决问题，这个就调用链的设计初衷，在微服务中，调用链比较长的时候，如果出现问题，很容易出现踢皮球的情况，这种情况下，打开调用链，一看，谁的就是谁的不说不闹，多好。
市面上比较常见的APM有：pinpoint,Twitter的zipkin,美团的Cat，Google的Dapper，这里值得表扬美团，继续和金服的pk吧，最牛的还是Google，他发表了一篇Dapper就有好多公司去研究，最终形成自己的产品，不由的让我想起他的GFS，bigTable在大数据前期google为大数据所做的贡献，向慷慨的人致敬，懂得分享的人最可爱，嗯，对···进入正题

简单说一下调用链的东西TraceID 链路ID 在整个调用链中这个东西是不变的
SpanId 步骤ID 经过一个node就会变
ParentSpanID 很同意理解，这个spanId是从哪个span来的，这个设计很重要的

复杂的东西spring boot已经给我们封装好了
#######sleuth客户端
在需要跟踪的微服务中pom.xml加上

在application.yml中添加

pom.xml添加

并且在启动类上添加

客户端和服务端都启动，进入到zipkin服务端

可以根据时间，服务名称去查询，点击可查看调用链详情

因为现在zipkin的调用数据都是存在内存中的，一旦zipkin server重启，则意味着之前的都没有了，在这并发高的，一会就把内存挤爆了，所以最终zipkin的数弯改答据是要持久化的，要么mysql，这里采用ES,毕竟在大数据检索面前ES比mysql好很多很多
还有在页面请求量大的时候zipkin和ES直接联通存数据，肯定会阻塞，这里就用kafka来解决这个问题

pom.xml需要引入

application.yml添歼羡加

再次启动，加入数据，观察ES-head

已经将调用链存进去了，这里要感谢spring 将调用链集成，方便我们应用

望指正，不吝赐教

G. OpenTelemetry、Spring Cloud Sleuth、Kafka、Jager实现分布式跟踪

分布式跟踪可让您深入了解特定服务纤核在分布式软件系统中作为整体的一部分是如何执行的。它跟踪和记录从起点到目的地的请求以及它们经过的系统。

在本文中，我们将使用 OpenTelemetry、Spring Cloud Sleuth、Kafka 和 Jaeger 在三个 Spring Boot 微服务 中实现分布式跟踪。

我们先来看看分布式追踪中的一些基本术语。

跨度：表示系统内的单个工作单元。跨度可以相互嵌套以模拟工作的分解。例如，一个跨度可能正在调用一个 REST 端点，然后另一个子跨度可能是该端点调用另一个，等等在不同的服务中。

Trace：所有共享相同根跨度的跨度集合，或者更简单地说，将所有跨度创建为原始请求的直接结果。跨度的层次结构（每个跨度在根跨度旁边都有自己的父跨度）可用于形成有向无环图，显示请求在通过各种组件时的路径。

OpenTelemetry ，也简称为 OTel，是一个供应商中立的开源 Observability 框架，用于检测、生成、收集和导出遥测数据，例如 跟踪 、 指标 和 日志 。作为 云原生 计算基金会 (CNCF) 的孵化项目，OTel 旨在提供与供应商无关的统一库和 API 集——主要用于收集数据并将其传输到某处。OTel 正在成为生成和管理遥测数据的世界标准，并被广泛采用。

Sleuth 是一个由 Spring Cloud 团队管理和维护的项目，旨在将分布式跟踪功能集成到 Spring Boot 应用程序中。它作为一个典型Spring Starter的 . 以下是一些开箱即用的 Sleuth 工具：

Sleuth 添加了一个拦截器，以确保在请求中传递所有跟踪信息。每次调用时，都会毁丛掘创建一个新的 Span。它在收到响应后关闭。

Sleuth 能够跟踪您的请求和消息，以便您可以将该通信与相应的日志条目相关联。您还可以将跟踪信息导出到外部系统郑瞎以可视化延迟。

Jaeger 最初由 Uber 的团队构建，然后于 2015 年开源。它于 2017 年被接受为云原生孵化项目，并于 2019 年毕业。作为 CNCF 的一部分，Jaeger 是云原生 架构 中公认的项目。它的源代码主要是用 Go 编写的。Jaeger 的架构包括：

与 Jaeger 类似，Zipkin 在其架构中也提供了相同的组件集。尽管 Zipkin 是一个较老的项目，但 Jaeger 具有更现代和可扩展的设计。对于此示例，我们选择 Jaeger 作为后端。

让我们设计三个 Spring Boot 微服务：

这三个微服务旨在：

这是为了观察 OpenTelemetry 如何结合 Spring Cloud Sleuth 处理代码的自动检测以及生成和传输跟踪数据。上面的虚线捕获了微服务导出的跟踪数据的路径，通过OTLP（OpenTelemetry Protocol）传输到OpenTelemetry Collector，收集器依次处理并将跟踪数据导出到后端Jaeger进行存储和查询。

使用 monorepo，我们的项目结构如下：

第 1 步：添加 POM 依赖项

这是使用 OTel 和 Spring Cloud Sleuth 实现分布式跟踪的关键。我们的目标是不必手动检测我们的代码，因此我们依靠这些依赖项来完成它们设计的工作——自动检测我们的代码，除了跟踪实现、将遥测数据导出到 OTel 收集器等。

第 2 步：OpenTelemetry 配置

OpenTelemetry 收集器端点

对于每个微服务，我们需要在其中添加以下配置application.yml（请参阅下面部分中的示例片段）。spring.sleuth.otel.exporter.otlp.endpoint主要是配置OTel Collector端点。它告诉导出器，在我们的例子中是 Sleuth，通过 OTLP 将跟踪数据发送到指定的收集器端点http://otel-collector:4317。注意otel-collector端点 URL 来自otel-collector图像的 docker-compose 服务。

跟踪数据概率抽样

spring.sleuth.otel.config.trace-id-ratio-based属性定义了跟踪数据的采样概率。它根据提供给采样器的分数对一部分迹线进行采样。概率抽样允许 OpenTelemetry 跟踪用户通过使用随机抽样技术降低跨度收集成本。如果该比率小于 1.0，则某些迹线将不会被导出。对于此示例，我们将采样配置为 1.0、100%。

有关其他 OTel Spring Cloud Sleuth 属性，请参阅常见应用程序属性。

OpenTelemetry 配置文件

我们需要项目根目录下的 OTel 配置文件otel-config.yaml。内容如下。此配置文件定义了 OTel 接收器、处理器和导出器的行为。正如我们所看到的，我们定义了我们的接收器来监听 gRPC 和 HTTP，处理器使用批处理和导出器作为 jaeger 和日志记录。

第 3 步：docker-compose 将所有内容串在一起

让我们看看我们需要启动哪些 docker 容器来运行这三个微服务并观察它们的分布式跟踪，前三个微服务在上面的部分中进行了解释。

运行docker-compose up -d以调出所有九个容器：

第 4 步：追踪数据在行动

快乐之路

现在，让我们启动customer-service-bff流程的入口点，以创建新客户。

启动 Jaeger UI， http://localhost:16686/ [url=https://link.hu.com/?target=http%3A//localhost%3A16686/%2C]按[/url]服务搜索customer-service-bff，单击Find Traces按钮，这是我们看到的创建客户跟踪：它跨越三个服务，总共跨越六个，持续时间 82.35 毫秒。

除了 Trace Timeline 视图（上面的屏幕截图），Jaeger 还提供了一个图形视图（Trace Graph在右上角的下拉菜单中选择）：

三个微服务在 docker 中的日志输出显示相同的跟踪 id，以红色突出显示，并根据其应用程序名称显示不同的跨度 id（应用程序名称及其对应的跨度 id 以匹配的颜色突出显示）。在 的情况下customer-service，相同的 span id 从 REST API 请求传递到 Kafka 发布者请求。

customer-service让我们在 docker 中暂停我们的PostgreSQL 数据库，然后重复从customer-service-bff. 500 internal server error正如预期的那样，我们得到了。检查 Jaeger，我们看到以下跟踪，异常堆栈跟踪抱怨SocketTimeoutException，再次如预期的那样。

识别长期运行的跨度

Jaeger UI 允许我们搜索超过指定最大持续时间的跟踪。例如，我们可以搜索所有耗时超过 1000 毫秒的跟踪。然后，我们可以深入研究长期运行的跟踪以调查其根本原因。

在这个故事中，我们从 OpenTelemetry、Spring Cloud Sleuth 和 Jaeger 的角度解压了分布式跟踪，验证了 REST API 调用和 Kafka pub/sub 中分布式跟踪的自动检测。我希望这个故事能让你更好地理解这些跟踪框架和工具，尤其是 OpenTelemetry，以及它如何从根本上改变我们在 分布式系统 中进行可观察性的方式。

H. sofa-rpc源码分析 4-全链路追踪技术

一、简介
sofa-rpc的全链路追踪技术是基于 Sofa-Tracer 实现的，Sofa-Tracer是基于ZipKin(谷歌Dapper)实现的，Sofa-Tracer参考了ZipKin的Trace-span设计；提供了相应的异步处理机制，每次会将父线程的上下文复制到子线程，为了防止多此异步调用的场景下，上下文的串用，不会再客户端相应阶段才清理上下文，而是会提带坦前清理。
sofa-rpc在Sofa-Tracer的基础上，提供了以下新的特性

二、源码分析
ClientProxyInvoker.invoke //客户端调用入口，Trace生产流程

三、总结
1.sofa-rpc的全链路追踪依靠sofa-trace实现，包含上述说的trace/span、数据采样设计数行大、异步刷新机制等设计，核心薯竖功能还是在sofa-trace里

I. 深入探究ZIPKIN调用链跟踪——拓扑Dependencies篇

Zipkin的拓扑服务zipkin-dependencies是作为zipkin的一个独立的离线服务，也就是说，只启动zipkin服务，是没法看到拓扑的，还需要自己离线启动zipkin-dependencues服务。

其中ES配置参数如下：

Zipkin出了支持elasticsearch存储，还有mysql，cassard，详细配置信息请看 源码Readme

1、图中线条说明

服务之间的线条，遵循以下原则：

2、主调被调次数说明

点开每一个服务，可以看到主调被调，比如我在拓扑图中点击
某个服务，可以与此服务有直接调用关系的服务有哪些，效果如下：

其中Uses by表示此服务作为被调服务，被哪些服务调用了；Uses表示此服务调用了哪些其他服务。

在上面的图中点击某个主调或被调服务，即可看到具体的调用次数，以及失败次数，效果如下：

通过拓扑图，宏观上，我们可以快速了解服务之间的调用关系，同时也可以知道哪些服务间调用有问题，且可以知道出现问题的一个量级是多少（失败数，调用总数）。

Zipkin拓扑denpendencies是基于上报的链路span数据再次构建出的描述链路拓扑的一种新的数据结构。

构建链路的第一步就是读改渣取Span数据。Zipkin外部数据源支持三种，分别是Mysql，Cassandra，Elasticsearch，因此构建拓扑时，将从这三种数据源中读取Span数据。

读取Span数据源后，需要对其处理，计算出链路的拓扑。因为Span的数据量很大，普通程序计算处理无法完成任务，因此需要用到大数据框架。Zipkin官方选用的是Spark框架。Spark对Span数据进行处理，最后生成拓扑数据DenpendencyLink，然后持久化到存储中。

前端请求拓扑(DependencyLink)时，即按照查询条件，查询已经持久化后的DependencyLink，然后经过UI渲染，进行页面展示。

启动Zipkin-dependencies服务时，会传入几个参数，分别是时间day和存储类型storageType。Zipkin-dependencies服务是以天为单位进行建立拓扑，因此day将决定建立那一天的拓扑；而storageType将决定从什么储存中读取数据。

1、获取日期：

2、获取存储类型陵歼陪：

3、根据不同的存储启动不同的jOb:

不同的存储会定义不同Job类，因此有CassandraDependenciesJob，MySQLDependenciesJob，MySQLDependenciesJob，ElasticsearchDependenciesJob。 不同的Job主要区别在于读取Span的方式不同，而Spark对Span进行处理计算的方式基本都是相同的。 本文主要分析ElasticsearchJOb。

Job中主要逻辑都在run方法中，ElastichserchJob的Run方法定义如下：

主要步骤如下：
1、首先通过Spark的配置属性Conf，创建一个JavaSparkContext对象sc：

2、然后读取elasticsearch span数据源：

3、读取数据源后，就可以对Span进行处理了，首先按照TraceId 进行Group分组：

其中JSON_TRACE_ID Function定义如下：

4、Span按照TraceId Group 分组后，接着对尺蠢Span进行处理， 创建出DenpendencyLink。

5、上面方法最终返回的是个Map类型，将其转化为pari类型，再对其进行一个receByKey操作：

6、Spark对Span的计算操作到这儿基本就完成了，最后将DependencyLink转化为Jso形式：

7、对于计算好的拓扑Links，将其持久化到Elasticsearch中：

整个过程到此完毕，其中最复杂也是最核心的逻辑就是计算出链路拓扑Denpendencylink，此步骤在Function (logInitializer, decoder)中。接下来详细分析完成的工作。

首先介绍一下DenpendencyLink数据结构。DenpendencyLink就是最终与页面交互的拓扑结构数据单元，字端有：

DenpendencyLink类定义如下：

类的定义如下：

其中call方法中，首先完成对同一TraceId的Span解码：

然后，通过DependencyLinker类构造出DependendyLink，首先构造一个SpanNode Tree：

然后利用深度优先遍历方法遍历整个，统计出CallCounts和errorCounts:

其中callCounts和errorCounts定义如下：

最后，再通过callCounts和errorCounts生成List<DependencyLink>:

这样，最终构建出了DependencyLink。

本文为我的调用链系列文章之一，已有文章如下：

祝大家工作顺利，天天开心！

J. java培训课程有什么内容

像这样的问题，我已经回答了很多次，现在很多新手，特别是刚刚进入学生的学生，不知道该从哪里入手，我整理了一些java的知识点，一共分为六个阶段，273个技能点，第一阶段、第二阶段、第三阶段、第四阶段是必须要掌握的，很多机构忽悠人，就只学到第四阶段，第五阶段和第六阶段就是高薪、高职的保障，就说说想高薪必须得把后面两个阶段的给掌握了，老铁看了点个赞。

第一阶段：java基本功修炼

1.认识计算机硬件

2.计算机组成原理

3.计算机软件知识

4.计算机网络知识

5.常用网络应用操作

6.认识计算机病毒

7.逻辑训练

8.初识Java

9.变量和数据类型

10.选择结构

11.循环结构for

12.循环结构do-while

13.循环结构while

14.多重循环及程序调试

15.循环进阶

16.一维数组及经典应用

17.二维数组

18.认识类与对象

19.方法及方法重载

20.封装与继承

21.方法重写与多态

22.项目实战-汽车租赁系统

23.抽象类和接口

24.异常

25.项目实战-QuickHit

26.Java中的集合类型

27.List集合

28.Set集合

29.HashMap集合

30.Iterator

31.Collections算法类及常用方法

32.enum

33.包装类及装箱拆箱

34.String、StringBuffer类常用方法操作字符串

35.Date、Calendar

36.Math类常用方法

37.IO/NIO

38.字节输入流(InputStream、FileInputStream、BufferedInputStream)

39.字节输出流(OutputStream、FileOutputStream、BufferedOutputStream)

40.字符输入流(Reader、InputStreamReader、FileReader BufferedReader)

41.字节输出流(Writer、OutputStreamWriter、FileWriter、BufferedWriter)

42.文件复制

43.Serialize、Deserialize

44.职场晋升力：四象限时间管理与精力管理

45.多线程(Thread、Runnable)

46.ThreadLifeCycle

47.线程的调度

48.线程的同步和死锁

49.ThreadPool

50.职场晋升力：团队合作

51.Socket(TCP、UDP)

52.XML概念、优势、规范

53.XML中特殊字符的处理

54.使用DOM读取、添加、删除、解析 XML数据

第二阶段：javaweb开发

55.搭建和配置MySQL数据库

56.数据库增、删、查、改语句

57.事务

58.视图

59.数据库备份与恢复

60.数据库用户管理

61.数据库设计

62.项目实战-银行ATM存取款机系统

63.走进 HTML和CSS

64.列表表格及表单美化

65.CSS 高级操作

66.Bootstrap

67.CSS 组件

68.JavaScript面向对象

69.JavaScript判断、循环

70.JavaScript闭包

71.JavaScript语法

72.Bootstrap综合案例

73.HTML5、CSS3

74.jQuery基础

75.jQuery基本操作

76.jQuery事件与特效

77.jQuery Ajax

78.jQuery插件

79.搭建Web 环境初识JSP

80.JSP九大内置对象

81.JSP实现数据传递和保存

82.JDBC

83.单例模式、工厂模式

84.MVC、三层模式

85.Commons-fileupload、CKEditor

86.分页查询

87.EL 与 JSTL

88.Servlet与Filter

89.Listener与MVC

90.Ajax 与 jQuery

91.jQuery的Ajax交互扩展

92.项目实战—使用Ajax技术改进新闻发布系统

93.反射

94.Linux系统的安装

95.在Linux中管理目录和文件

96.在Linux中管理用户和权限

97.在Linux服务器环境下安装软件和部署项目

98.职场晋升力：职场沟通

第三阶段： 企业级框架开发

99. MyBatis 环境搭建

100. SQL 映射文件

101. 动态SQL

102. MyBatis 框架原理

103.SpringIOC

104.构造注入、依赖注入、注解

105. Spring 整合MyBatis(SqlSessionTemplate、MapperFactoryBean、事务

处理)

106. Spring 数据源(属性文件、JNDI)、Bean 作用域

107. Spring 框架的运行原理

108.SpringMVC 体系概念

109.SpringMVC 之数据绑定、数据效验、

110.SpringMVC 之视图及视图解析

111.SpringMVC 之文件上传、本地化解析

112.SpringMVC 之静态资源处理、请求拦截器、异常处理

113.Oracle数据库环境搭建、安装

114.Oracle数据库 SQL、分页、备份、还原

115.Hibernate 概念、依赖

116.HQL查询语言

117.Hibernate 中配置关联映射

118.HQL连接查询与 Hibernate注解

119.Struts2概念、依赖

120.Struts2配置

121.OGNL表达式

122.Struts2拦截器

123.SSH框架整合

124.使用Maven构建项目

125.使用Struts2实现Ajax

126.Jsoup网络爬虫

127.多线程网络爬虫

128.反爬及反反爬策略

129.通用爬虫设计

130.Echart图表分析

131.IKAnalyzer分词

132.企业框架项目实战-代理商管理系统

133.企业框架项目实战-SL 会员商城

134.企业框架项目实战-会员管理系统

135.企业框架项目实战-互联网招聘信息采集分析平台

第四阶段： 前后端分离开发

136.GitHub

137.Git基础(checkout、pull、commit、push、merge等)

138.Git进阶(多分支协作)

139.GitLab

140.IDEA的使用

141.Maven介绍(概念、仓库、构建、命令)

142.使用Maven构建WEB项目

143.使用Maven构建多模块项目

144.使用Maven搭建私服仓库

145.Scrum框架介绍(三个角色、三个工件、四个会议)

146.ScrumTeam组建团队

147.产品需求和用户故事

148.每日立会

149.使用敏捷-Scrum方式开发管理实战

150.前后端分离、分布式集群架构、垂直架构

151.SSM（SpringMVC+Spring+MyBatis）整合实战

152.Git、Maven私服Nexus

153.第三方接入技术（微信、阿里）

154.MySQL电商实战

155.Redis（缓存服务）

156.搜索引擎-Solr

157.集成APIDoc工具-Swagger

158.图片自动化处理：Tengine+LUA+GraphicsMagic

159.手机、邮箱注册

160.单点登录 Token

161.OAuth2.0认证

162.Jsoup网络爬虫(多线程爬虫/代理 IP爬虫)

163.ExecutorService线程池

164.IK中文分词

165.Postman

166.ReactJS

167.webpack

168.职场晋升力：简历撰写

169.程序猿面试宝典之项目面试

170.大型互联网旅游电商项目实战-爱旅行

第五阶段： 分布式微服架构开发

171.SpringBoot环境搭建

172.SpringBoot常用技能

173.SpringBoot整合Redis

174.SpringBoot整合Mybatis

175.微服务架构及架构设计

176.消息队列

ActiveMQRabbitMQ

177.分布式事务

178.分布式锁 Redis-setnx

179.Zookeeper注册中心

180.基于 ActiveMQ实现高并发

181.Docker环境搭建

182.Docker镜像加速

183.Docker容器管理

184.Docker镜像管理

185.Docker容器文件备份

186.Dockerfile

187.Docker私服仓库

188.真实互联网高并发电商项目实战-双十一抢购

189.可视化监控 Portainer

190.DockerCompose 容器编排

191.DockerCompose扩容、缩容

192.DockerSwarm集群编排

193.Jenkins安装、插件配置

194.Jenkins配置普通任务

195.Jenkins配置管道任务

196.Jenkins自动发布服务

197.Spring CloudEureka

198.Spring CloudFeign

199.Spring CloudRibbon

200.Spring CloudZuul

201.Spring CloudConfig

202.Spring CloudHystrix

203.Spring CloudSleuth

204.Spring BootAdmin

205.Eureka注册原理探秘

206.SpringCloud 大坑解读

207.Zipkin

208.Zipkin整合RabbitMQ

209.Zipkin整合MySQL

210.ELK日志收集

211.Kafka

212.Elasticsearch映射管理

213.Elasticsearch查询/复合查询

214.Elasticsearch集群/集群规划

215.Elasticsearch聚合

216.Elasticsearch集群监控

217.Elasticsearch插件

(Head/BigDesk)

218.Mycat读写分离

219.Mycat一主多从

220.Mycat多主多从

221.Mycat数据分片

222.Redis

223.Redis-Redlock

224.Elasticsearch环境搭建

225.Elasticsearch客户端

226.Elasticsearch索引管理

227.Elasticsearch文档管理

228.Mycat集群

229.Jmeter 并发测试

230.Jmeter 生成测试报告

231.微信登录

232.微信支付

233.支付宝支付

234.网络地图

235.Sonar本地检测

236.Sonar+Jenkins线上检测

237.CI/CD

238.SpringBoot改造爱旅行项目实战

239.大型互联网票务类电商项目实战-大觅网

240.ES6概念(les、const)

241.ES6对象和数组

242.ES6函数扩展

243.VUE环境搭建

244.VUE.JS指令

245.VUE 交互

246.VUE 实例生命周期

247.VUE 组件

248.VUE项目环境配置及单文件组件

249.VUE 路由

第六阶段：cc服务

250. Spring Cloud Gateway

251. Consul

252. Nacos

253. Eureka、Consu、lNacos、Zookeeper 对比分析

254. Prometheus + Grafana

255. ES 分布式存储原理

256. NoSQL 数据库解决方案(Redis、MongoDB)

257. OAuth2.0 认证( authorization code 模式)

258. OAuth2.0 认证( implicit 模式)

259. OAuth2.0 认证( resource owner password credentials 模式)

260.OAuth2.0认证( clientcredentials模式)

261.NAS/FastDFS分布式文件存储

262.Python基础

263.Python爬虫

264. 大数据及 Hadoop 概述

265. 分布式文件系统 HDFS

266. 分布式计算框架MapRece

267. 分布式列式数据库 HBase

268. Hadoop 综合应用

269. 面试大局观

270. 职业规划

271. 项目面试

272. 具体业务场景化解决方案

273. 更多技术专题持续增加中

有不清楚的可以私信我