共计 2681 个字符，预计需要花费 7 分钟才能阅读完成。
这篇文章将为大家详细讲解有关如何分析 Trace 中的 OpenTelemetry 和 TSW，文章内容质量较高，因此丸趣 TV 小编分享给大家做个参考，希望大家阅读完这篇文章后对相关知识有一定的了解。
OpenTracing 是针对应用程序和 OSS 软件包的最新开放式分布式跟踪标准。具有大规模构建微服务经验的开发人员了解分布式跟踪的作用和重要性：每个进程的日志记录和度量标准监视都有其位置，但是它们都无法重构事务在整个分布式系统中传播时所经历的复杂旅程。
Trace 的由来
Trace 并不是一个新的概念，随着软件商业化伊始，如何迅速定位生产环境是工程师们不断探索的方向。早期的软件架构大多为 CS 结构（Client and Server）。每个语言为了提供方便快捷的方式让工程师解决问题，在 Log，Debug 和 Trace 上一直没少下功夫。
大家最熟悉的 Java 代码里 printStackTrace() 就是标准的追踪逻辑，把调用关系和顺序整理的明明白白。随着 SOA（Service Oriented Architecture）的普及，标准化的服务间交互机制逐步建立起来，但大多数的应用还是跑在单体结构上，所以对于追踪和排障并没有带来巨大的变化。
紧接着发生的互联网的兴起和流量的几何级数暴增，服务之间的解耦，模块独立扩展性和业务团队的组织结构的变化，让软件体系结构发生了本质变化。打散了原有的单体应用，微服务几乎成为刚需。微服务的构架形态打乱了原本向对简单的在单体开发下的链路追踪和排障逻辑。
在这个背景下，分布式链路追踪应运而生成为了大部分公司业务监控和故障定位的强需求。这里就引出了我们下面要讨论的话题，也是目前业界最火的链路追踪项目之一的 OpenTelemetry。
OpenTelemetry 的前世今生
要说 OpenTelemetry 的故事，我们还要回顾一下过去 5 年的一些重要事件。
2016 年的 12 月 25 日圣诞节，OpenTracing 发布了 1.0 的版本，提供了面向 Tracing 的规范用于兼容微服务调用之间不同平台的中立 API，之后的 2 年里，各种外部组件，各种语言，各种框架，不断的贡献到了 OpenTracing 的生态里来，OpenTracing 也成为了 CNCF incubating 的项目。
看起来如此符合主流需求的项目却在 2018 年受到了来自谷歌的挑战。2018 年的 1 月 17 日，谷歌发布 OpenCencus（微软在 2018 年 6 月加入） ，作为一款独立于厂商的，面向微服务架构的性能采集和链路追踪平台。
从定位上来说，OpenCencus 不仅仅提供 Tracing 标准和 API 规范，还自集成了性能采集的组建，目标是打造一个集性能监控和链路追踪为一体的方案。而在生态上，OpenCensus 直接提供了大部分语言所对应的 SDK 和普遍使用的 Framework 的支持。从此开始，业界对于到底使用 OpenTracing 还是 OpenCensus 开始了一轮又一轮的讨论。
终于在 2019 年的 5 月 21 日，一条来自谷歌的官方声明传来，OpenCensus 和 OpenTracing 被并入到新的 CNCF 项目，新项目的名字叫 OpenTelemetry。而 OpenTelemetry 不仅仅做 Tracing，Metrics，还要针对 Logging 实现类似的中立解决方案，这个方案基本上吃下了排障流程的上中下游，致力于打造全方位的排障定位的规范。
目前 OpenTelemetry 是 CNCF 旗下的 SandBox 项目，同在 SandBox 下的比较有特色的几个项目包括 Chaos Mesh，Cert Manager 和 K3s。OpenTelemetry 对于 OpenTracing 和 OpenCensus 是全面兼容的，会制定出更加全面的规范，并且很多规范会贡献到类似于 W3C 当中去。
当前，业界最火热的几个链路追踪社区，如 Apache SkyWalking，Zipkin，Jaeger 都是基于 OpenTracing 发展起来的，也有逐步向 OpenTelemetry 拓展的趋势。这些开源组建一般都是从客户端接入开始，同时提供数据收集的方案（Data Collector）和数据处理的方案（Data Aggregator），最后把数据倒入到其他开源组建中，比如 Elasticsearch 和 Cassandra 等。对于大部分需要使用的客户来说，自建其实是比较麻烦的事情。比如 Jaeger 提供的实例构架图如下：
图一
为了达到一个理想的效果，这里需要客户自建的东西太多了，Kafka/ Flink/ DB/ Jaeger 组建。所以客户在大部分场景下希望云厂商提供一站式的服务，而不是让客户自己去拼装整个方案。
下面我们用腾讯云提供的 TSW（Tencent Service Watcher）组建举例，看看云上大厂们是如何帮助客户接入 OpenTracing 和 OpenTelemetry 生态和方案的。
基于 OpenTracing 的云上链路追踪基础设施 TSW
TSW 是 Tencent Service Watcher 的简写。是腾讯云提供的分布式全链路追踪的解决方案。TSW 的设计理念是拥抱开源和提供全链路解决问题的能力。
这里我们先谈一下拥抱开源，当前 OpenTelemtry 还处于 SandBox 项目阶段，所以 TSW 当前的数据协议是基于 OpenTracing 来设计的，全面兼容 Apache Skywalking，Zipkin 和 Jaeger 的客户端上报，为微服务体系的客户端 Tracing 上报选型提供的极大的便利。
随着 OpenTelemetry 的逐渐成熟，全面兼容 OpenTelemetry 的数据类型和功能也已经在 TSW 的排期中。这种设计为那些在十字路口徘徊的公司提供了最大的便利，不需要考虑客户端未来的兼容问题。而完全自研的后端体系，借鉴了 Jaeger 和 Skywalking 的设计，使用计算存储分离和多层查询的机制，提供了非常优秀的性能输出。
图二
除了提供链路拓扑的灵活视图和和调用链路的查询分析机制，TSW 还针对服务调用的上下游关系做了深度聚合，可以更直观的切分和对比同一调用在不同链路下的成功率和响应。
图三
图四
为了提供给研发团队最大的排障便利，TSW 目前在和云监控和日志服务做深度整合，未来会提供一站式的排障工作体验，避免了一个问题开多个页面的困扰和搜索不断要复制黏贴关键词的麻烦，旨在打造云上排障的一站式工作站。
关于如何分析 Trace 中的 OpenTelemetry 和 TSW 就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。
