今天我们聊聊 Trace 之 OpenTelemetry And TSW |概览

腾讯云中间件团队

修改于 2021-03-25 11:03:31

1.5K0

修改于 2021-03-25 11:03:31

导读：OpenTracing 是针对应用程序和 OSS 软件包的最新开放式分布式跟踪标准。具有大规模构建微服务经验的开发人员了解分布式跟踪的作用和重要性：每个进程的日志记录和度量标准监视都有其位置，但是它们都无法重构事务在整个分布式系统中传播时所经历的复杂旅程。

作者介绍

徐为

腾讯云 CSIG 微服务产品中心产品架构师

多年一线研发、架构设计经验

目前专注于腾讯云微服务中间件的研究推广在多个跨国企业从事IT相关工作超过15年

Trace 的由来

Trace 并不是一个新的概念，随着软件商业化伊始，如何迅速定位生产环境是工程师们不断探索的方向。早期的软件架构大多为 CS 结构（Client and Server）。每个语言为了提供方便快捷的方式让工程师解决问题，在 Log，Debug 和 Trace 上一直没少下功夫。

大家最熟悉的 Java 代码里 printStackTrace() 就是标准的追踪逻辑，把调用关系和顺序整理的明明白白。随着 SOA（Service Oriented Architecture）的普及，标准化的服务间交互机制逐步建立起来，但大多数的应用还是跑在单体结构上，所以对于追踪和排障并没有带来巨大的变化。

紧接着发生的互联网的兴起和流量的几何级数暴增，服务之间的解耦，模块独立扩展性和业务团队的组织结构的变化，让软件体系结构发生了本质变化。打散了原有的单体应用，微服务几乎成为刚需。微服务的构架形态打乱了原本向对简单的在单体开发下的链路追踪和排障逻辑。

在这个背景下，分布式链路追踪应运而生成为了大部分公司业务监控和故障定位的强需求。这里就引出了我们下面要讨论的话题，也是目前业界最火的链路追踪项目之一的 OpenTelemetry。

OpenTelemetry 的前世今生

谈 OpenTelemetry 和它的故事之前，还必须先说一下谷歌2010年发布的文章《A Large-Scale Distributed Systems Tracing Infrastructure》。

这篇文章在当时的研发圈子引发的轰动不亚于之后的 Kubernetes 的基石 Borg ，OpenTelemetry 在设计上是有很大一部分借鉴了这篇文章。但是 Dapper 和 Borg 都是比较前沿的理念，普罗大众往往还需要几年才会去尝试标准化这类问题的解决方案。而 OpenTelemetry 和 Kubernetes 还有一点也不一样，它并不是打败了一些对手之后脱颖而出的。

要说 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 的设计，使用计算存储分离和多层查询的机制，提供了非常优秀的性能输出。