本教程的这一部分将通过剖析其最后一个Struts即分布式跟踪来结束有关可观察性的讨论。
分布式跟踪（也称为分布式请求跟踪）是一种用于对应用程序进行概要分析和监视的方法，尤其是使用微服务架构构建的应用程序。 分布式跟踪有助于查明哪里发生故障以及什么原因导致性能下降。 – https://opentracing.io/docs/overview/what-is-tracing/
在分布式系统中，例如典型的微服务体系结构 ，在响应被组合并发送回之前，请求可以穿越数十个甚至数百个服务。 但是你应该怎么知道呢？ 在某种程度上， 日志能够提供这些见解，但是它们本质上是平坦的：难以理解调用或事件之间的因果关系，提取等待时间以及重构请求已通过系统的完整路径。 正是这种情况使分布式跟踪得以解决。
分布式跟踪的故事（如今已经知道）始于2010年 ，当时Google发表了著名的论文Dapper，即大型分布式系统跟踪基础结构 。 尽管Dapper从未开源，但该文件已成为其后设计的许多开源和商业项目的鼓舞人心的蓝图。 因此，让我们仔细研究一下分布式跟踪。
1.简介
2.仪表+基础架构=可视化
3. TCP，HTTP，gRPC，消息传递...
4. OpenZipkin
5. OpenTracing
6.勇敢
7.积家
8. OpenSensus
9. OpenTelemetry
10.干草堆
11. Apache SkyWalking
12.编排
13.第一英里
14.云
15.无服务器
16.结论
17.接下来
在深入研究细节之前，必须了解，即使分布式跟踪是一项了不起的技术，但它并不是神奇的技术，这一点很重要。 从本质上讲，它包含三个关键要素：
工具 ：特定于语言的库，通过跟踪功能有助于丰富应用程序和服务。
基础架构 ：跟踪中间件（收集器，服务器等）以及存储引擎，在该引擎中，跟踪被发送，收集，持久保存，并且以后可用于查询。
可视化 ：探索，可视化和分析收集的痕迹的前端。
实际上，这意味着在整个微服务团队中推出分布式跟踪支持不仅需要开发工作，而且还需要增加运营开销。 从本质上讲，它成为管理和监视的另一基础架构。 好消息是，它已经走出了关键的道路，大多数仪器库都旨在抵抗跟踪中间件故障。 最后，尽管可能会丢失一些痕迹，但无论如何都不应影响生产流程。
对于许多现实世界的应用程序而言，记录和持久保存每个单个请求的跟踪记录可能会非常昂贵。 例如，它可能会在针对性能进行高度优化的系统中引入不可忽略的开销，或者在具有大量请求的系统中对存储施加很大压力。 为了减轻影响并仍然获得有用的见解，广泛使用了不同的采样技术。
3. TCP，HTTP，gRPC，消息传递...
现代分布式跟踪实现所面临的挑战之一是微服务体系结构 （通常是分布式系统）采用的广泛的通信方式 。 上下文传播策略不仅因为协议不同，而且通信方式也大不相同。 例如，为通过HTTP协议使用请求/响应通信的服务添加跟踪工具比对Apache Kafka生产者和使用者或gRPC服务进行检测要简单得多。
作为平台的分布式跟踪可跨编程语言和运行时边界工作。 特定于语言的部分是仪器库，它们将应用程序，服务和分布式跟踪平台桥接在一起。 最幸运的是，就目前而言，您正在寻找的跟踪工具已经可以从社区，供应商或维护者那里获得。 但是，在极少数情况下，尤其是在使用尖端技术时，您可能需要自己动手。
4. OpenZipkin
Zipkin是Twitter工程师在Dapper发表论文之后实施的首批开源项目之一。 它很快就吸引了很多人的注意力 ，不久后又改名为OpenZipkin 。
Zipkin 是一个分布式跟踪系统。 它有助于收集解决服务体系结构中的延迟问题所需的时序数据。 功能包括该数据的收集和查找。 – https://github.com/openzipkin/zipkin
不管怎样 ， Zipkin如今已成为领先的分布式跟踪平台，并且为许多不同的语言提供了大量的集成。 JCG租车平台将使用Zipkin来收集和查询其所有微服务中的跟踪信息。
让我们先简单介绍一下典型的集成流程。 例如，对于我们决定在Go中实现的Payment Service ，我们可以使用zipkin-go工具。
reporter := httpreporter.NewReporter("http://localhost:9411/api/v2/spans"))
defer reporter.Close()
// create our local service endpoint
endpoint, err := zipkin.NewEndpoint("payment-service", "localhost:29080")
if err != nil {
log.Fatalf("unable to create local endpoint: %+v\n", err)
}
tracer, err := zipkin.NewTracer(reporter, zipkin.WithLocalEndpoint(localEndpoint))
if err != nil {
log.Fatalf("unable to create tracer: %+v\n", err)
}zipkin-go不仅提供了必要的原语，而且还具有与基于Payment服务 一样的基于gRPC的服务的出色检测功能。
func Run(ctx context.Context, tracer *zipkin.Tracer) *grpc.Server {
s := grpc.NewServer(grpc.StatsHandler(zipkingrpc.NewServerHandler(tracer)))
payment.RegisterPaymentServiceServer(s, newPaymentServer())
reflection.Register(s)
return s
}5. OpenTracing
Zipkin是第一个，但是受其成功启发的各种分布式跟踪平台的数量开始Swift增长，每个平台都在推广自己的API。 OpenTracing计划是在所有这些实施中建立共识的早期尝试。
OpenTracing 由API规范，已实现该规范的框架和库以及该项目的文档组成。 OpenTracing 允许开发人员使用不会将其锁定到任何一种特定产品或供应商的API来向其应用程序代码中添加工具。 – https://opentracing.io/docs/overview/what-is-tracing/
幸运的是，这种努力的好处已广为人知，从今天起，支持OpenTracing的分布式跟踪器的清单几乎囊括了所有主要参与者。
6.勇敢
Brave是基于JVM的应用程序中使用最广泛的跟踪工具库之一，通常与OpenZipkin跟踪平台一起使用。
Brave 是一个分布式跟踪工具库。 勇敢通常会拦截生产请求以收集计时数据，关联并传播跟踪上下文。 – https://github.com/openzipkin/brave
开箱即用， Brave提供的仪器数量非常可观。 尽管可以直接集成，但许多库和框架在Brave之上引入了方便的抽象，以简化惯用的工具。 让我们看看这对于不同的JCG租车服务意味着什么。
由于Reservation Service是基于Spring Boot构建的，因此可以受益于Spring Cloud Sleuth与Brave的出色集成。
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-sleuth</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-zipkin</artifactId>
</dependency>大多数集成设置都可以通过配置属性进行调整。
spring:
sleuth:
enabled: true
sampler:
probability: 1.0
zipkin:
sender:
type: WEB
baseUrl: http://localhost:9411
enabled: true另一方面， 客户服务遵循Project Hammock约定使用本机的Brave工具。 下面是一个代码片段，说明了如何配置它。
@ApplicationScoped
public class TracingConfig {
@Inject
@ConfigProperty(name = "zipkin.uri", defaultValue = "http://localhost:9411/api/v1/spans")
private String uri;
@Produces
public Brave brave() {
return new Brave.Builder("customer-service")
.reporter(AsyncReporter.create(OkHttpSender.create(uri)))
.traceSampler(Sampler.ALWAYS_SAMPLE)
.build();
}
@Produces
public SpanNameProvider spanNameProvider() {
return new DefaultSpanNameProvider();
}
}作为Zipkin服务器分发的一部分的Web前端允许可视化所有参与微服务的单个跟踪。
跟踪预订和客户服务
显然，分布式跟踪平台最有用的应用是加快故障排除和问题检测的速度。 正确的可视化在这里起着非常重要的作用。
跟踪中显示了预订和客户服务之间的问题
最后但并非最不重要的一点是，与许多其他分布式跟踪平台一样， Zipkin也在不断发展和创新。 下图显示了其工具中最近增加的一个新的替代Web前端，称为Zipkin Lens 。
通过Zipkin Lens进行预订和客户服务
7.积家
Jaeger是另一个流行的分布式跟踪平台，该平台由Uber开发，并在以后开源。
受到 Dapper 和 OpenZipkin 启发的 Jaeger 是由 Uber Technologies 作为开源发布的分布式跟踪系统 。 它可以用于监视基于微服务的分布式系统– https://github.com/jaegertracing/jaeger
Jaeger除了托管在Cloud Native Computing Foundation （ CNCF ）的保护下之外，还本地支持OpenTracing规范，并提供与Zipkin的向后兼容性。 实际上，这意味着我们为JCG租车服务所做的检测将与Jaeger跟踪平台无缝配合。
积家的预订和客户服务
8. OpenSensus
OpenCensus起源于Google ，该公司用于自动捕获来自大量服务的跟踪和指标。
OpenCensus 是一组用于各种语言的库，可让您收集应用程序指标和分布式跟踪 ，然后将数据实时传输到您选择的后端。 – https://opencensus.io/
总的来说， OpenCensus仅是一种仪器层，与Jaeger和Zipkin跟踪后端兼容（还有许多其他层 ）。
9. OpenTelemetry
我们在本教程的上半部分讨论了OpenTelemetry计划，仅涉及指标主题。 但说实话， OpenTelemetry是Jaeger和OpenSensus这两个完善的项目在一个保护伞下的共同努力的结果，从而提供了一个功能强大，功能强大的便携式遥测平台。
OpenTracing 和 OpenCensus 的领导者 共同创建了OpenTelemetry，它将取代这两个项目。 – https://opentelemetry.io/
截至撰写本文时，有关OpenTelemetry首次正式发布的工作仍在进行中，但计划中的早期版本将很快推出 。
10.干草堆
出生于Expedia的 Haystack是分布式跟踪平台的一个示例，它不仅可以收集和可视化跟踪。 它着重于分析操作趋势，服务图和异常检测。
Haystack 是一个由 Expedia 支持的开源分布式跟踪项目，旨在促进对微服务和网站中问题的检测和修复。 它将符合 OpenTracing 的跟踪引擎与组件化的后端体系结构 相结合，以 实现高弹性和高可扩展性。 Haystack还包括分析工具，用于可视化跟踪数据，跟踪跟踪数据中的趋势以及在跟踪数据趋势超过您设置的限制时设置警报。 – https://expediadotcom.github.io/haystack/docs/about/introduction.html
Haystack是一个模块化平台，可以部分使用，也可以整体使用。 Haystack UI是它异常有用且功能强大的组件之一。 即使您尚未使用Haystack ，也可以将Haystack UI和Zipkin一起使用， 以替代其自己的前端。
Haystack UI中的预订和客户服务跟踪
仅与Zipkin一起使用时，并非所有组件都可以访问，但是即使在这种情况下，也可以使用许多分析功能。
Haystack UI的趋势
Haystack可能是目前最先进的开源分布式跟踪平台。 我们已经看到了可能的一小部分，而其另一功能（ 自适应警报 ）将在本教程的下一部分中介绍。
11. Apache SkyWalking
Apache SkyWalking是成熟的开放源代码可观察性平台的又一个很好的例子，在该平台中，分布式跟踪起着关键作用。
SkyWalking ：一个开放源代码的可观察性平台，用于收集，分析，聚合和可视化来自服务和云本机基础结构的数据。 – https://github.com/apache/skywalking/blob/master/docs/en/concepts-and-designs/overview.md
值得注意的是， Apache SkyWalking工具API完全符合OpenTracing规范。 在后端级别， Apache SkyWalking还支持与Zipkin和Jaeger集成，尽管存在一些限制 。
对于JCG租车平台而言，用Apache SkyWalking替换Zipkin是无缝的，并且所有现有的仪器都可以按预期运行。
Apache SkyWalking中的预订和客户服务跟踪
12.编排
正如我们之前讨论的那样， 协调器和服务网格正在深入渗透到现代微服务体系结构的部署中。 服务网格背后的魔力是隐形和做事。 但是，当出现问题时，了解服务网格或协调器是罪魁祸首至关重要。
幸运的是，在构建和设计每个主要服务网格时都考虑到可观察性 ，并结合了所有三个Struts： 日志 ， 指标和分布式跟踪。 Istio在这里是真正的领导者，并具有Jaeger或/和Zipkin 支持 ，而Linkerd仅提供了一些通常与分布式跟踪相关的功能 。 从另一方面来说， Consul with Connect完全依赖于Envoy的分布式跟踪功能，并且没有超出此范围。
从服务网格到各个服务的上下文传播使您可以看到请求从系统进入请求到发送响应的最后一个字节的整个过程。
13.第一英里
您可能已经注意到，分布式跟踪通常只限于后端服务或服务器端应用程序的上下文。 前端几乎被完全忽略。 这种疏忽肯定会消除一些难题，因为在大多数情况下，前端正是启动大多数服务器端交互的地方。 甚至有一个称为Trace Context的W3C规范草案来解决这一差距，那为什么呢？
JavaScript应用程序的工具由许多分布式跟踪平台提供，例如， OpenSensus有一个 ， OpenZipkin和OpenTracing也有 。 但是，这些方法中的任何一个都需要一些分布式跟踪基础结构才能公开可用，以实际收集从浏览器发送的跟踪。 例如，尽管这种做法已被分析数据广泛接受，但由于跟踪确实确实可能包含敏感信息，因此仍然存在安全性和隐私问题。
14.云
分布式跟踪在基于云的部署中的集成曾经是一个挑战，但是如今，大多数云提供商都提供了专门的产品。
我们将从AWS X-Ray开始，它提供了请求在系统中传播时的端到端视图，并显示了底层组件的地图。 通常，应用程序和服务应使用X-Ray SDK进行分布式跟踪检测，但是某些平台（例如OpenZipkin或OpenSensus）具有与AWS X-Ray集成的扩展。
在Google Cloud中 ，由Stackdriver可观察性套件的成员Stackdriver Trace进行分布式跟踪。 特定于语言的SDK提供了用于直接与Stackdriver Trace进行交互的低级接口，但是您可以选择使用OpenSensus或Zipkin 。
Microsoft Azure中的分布式跟踪由Application Insights提供支持， Application Insights是较大的Azure Monitor产品的一部分。 它还提供了专用的Application Insights SDK ，应用程序和服务应与之集成，以释放分布式跟踪功能。 令人惊讶的是， Application Insights还支持通过OpenSensus进行分布式跟踪。
如您所见，每个云提供商在分布式跟踪方面都有自己的见解，在大多数情况下，您别无选择地使用他们的SDK。 值得庆幸的是，领先的开源分布式跟踪平台通过维护此类集成减轻了您的负担。
15.无服务器
越来越多的组织正在寻求无服务器计算 ，以降低成本或加快新功能或新产品的推出。 事实是， 无服务器系统为可观察性大喊大叫，否则对问题进行故障排除就更像在大海捞针。 很难弄清在高度分布式的无服务器系统中哪里出了问题，尤其是在级联故障的情况下。
这是分布式跟踪真正发挥作用的一个利基市场，对您很有帮助。 基于云的无服务器产品由特定于提供商的分布式跟踪工具提供支持，但是开源无服务器平台正试图在此追赶。 值得注意的是， Apache OpenWhisk带有OpenTracing集成，而Knative使用Zipkin 。 对于诸如OpenFaas或Serverless之类的其他程序，您此时可能需要手动检测功能。
16.结论
在本教程的这一部分中，我们讨论了第三个可观察性Struts，即分布式跟踪。 我们仅涵盖了必要的最低限度，但是，如果您有兴趣进一步学习，则有大量材料可供阅读和观看。
如今，在分布式跟踪的空间中发生了许多创新。 新的有趣工具和集成正在使用中（跟踪比较，等待时间分析， JFR跟踪等），希望我们能够很快在生产中使用它们。
17.接下来
在本教程的最后部分中，我们将讨论监视和警报。
翻译自: https://www.javacodegeeks.com/microservices-distributed-tracing.html
