更新分布式追踪

Observability/history.md

@@ -11,7 +11,7 @@ The information that you will use to determine whether an application is healthy
 遥测数据是指采样和汇总有关软件系统性能和行为的数据，这些数据（响应时间、错误率、资源消耗等）用于监控和了解系统的当前状态。
 :::
 
-遥测数据你不一定陌生，如果你在生活中观察仔细，观看电视台火箭发射的直播时，能注意到发射指挥大厅内回响起一系列这样的口令：“东风光学USB雷达跟踪正常，遥测信号正常”，软件领域的可测性和系统遥测数据本质和火箭一样，主要就是通过收集系统内部各类的遥测数据来了解系统内部正在发生的事情，帮助大家在 DevOps 中遇到的故障定位难、容量评估、链路梳理、性能分析等问题，提供一种所谓洞见的能力，本质上它就是一门数据收集和分析的科学。
+遥测数据你不一定陌生，如果你在生活中观察仔细，观看电视台火箭发射的直播时，能注意到发射指挥大厅内回响起一系列这样的口令：“东风光学USB雷达跟踪正常，遥测信号正常”，软件领域的可测性和系统遥测数据本质和火箭一样，主要就是通过收集系统内部各类的遥测数据来了解系统内部正在发生的事情，帮助大家在 DevOps 中遇到的故障定位难、容量评估、链路梳理、性能分析等问题，本质上它就是一门数据收集和分析的科学。
 
 
 ## 可观测性与传统监控
@@ -57,7 +57,7 @@ X 轴的右侧称为 Known Knows（已知且理解）和 Known Unknowns（已知
 	<img src="../assets/observability.png" width = "350"  align=center />
 </div>
 
-来自于 Cindy Sridharan 的《Distributed Systems Observability》著作中进一步将这三个类型的数据称为可观测性的三大支柱（three pillars），不过将它们成为支柱容易让人产生误解，支柱就像一个房子的均匀受力支撑点，缺一不可。而事实上这三者都可以独立存在，系统中也往往只存在 Logging、Tracing。
+来自于 Cindy Sridharan 的《Distributed Systems Observability》著作中进一步将这三个类型的数据称为可观测性的三大支柱（three pillars），不过将它们成为支柱容易让人产生误解，支柱就像一个房子的均匀受力支撑点，缺一不可。而事实上这三者都可以独立存在，系统中只存在 Logging、Tracing 也未尝不可。
 
 所以，在最新 CNCF 发布的可观测性白皮书中，将这些可观测的数据统一称为信号（Signals），主要的信号除了 Metrics、logs、traces 之外又额外增加了  Profiles 和 Dumps。
 

Observability/tracing.md

@@ -1,14 +1,16 @@
 # 9.4 链路追踪
 
-参阅 Uber 公开的技术文档信息，它们的微服务架构中大约有 2,200 个服务，这些服务相互依赖的链路关系引用 Uber 博客中的配图[^1]，供你直观感受。而分布式链路追踪所要做的事情就是通过请求粒度的轨迹追踪与数据透传，实现服务之间的确定性关联。
+参阅 Uber 公开的技术文档信息，它们的微服务架构中大约有 2,200 个服务，这些服务相互依赖的链路关系引用 Uber 博客中的配图[^1]，供你直观感受。而分布式链路追踪所要做的事情就是通过请求粒度的轨迹追踪与数据透传，实现规模级服务之间的确定性关联。
 
 <div  align="center">
 	<img src="../assets/uber-microservice.png" width = "350"  align=center />
 	<p>Uber 使用 Jaeger 生成的追踪链路拓扑</p>
 </div>
 
 
-分布式链路追踪诞生的标志性事件就是 Google Dapper 论文的发表。2010年4月，Benjamin H. Sigelman 等人在 Google Technical Report 上发表了《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》[^2]。Dapper 论文详细阐述了分布式链路追踪的设计理念，还提出了成为后续链路追踪系统设计的共识的两个概念：“追踪”（Trace）和“跨度”（Span）。一条 Trace 代表一次入口请求在 IT 系统内的完整调用轨迹及其关联数据集合。其中，全局唯一的链路标识 TraceId，是最具代表的一个属性。通过 TraceId 我们才能将同一个请求分散在不同节点的链路数据准确的关联起来，实现请求粒度的“确定性关联”价值。光有 TraceId 还不够，请求在每一跳的接口方法上执行了什么动作、耗时多久、执行状态是成功还是失败？承载这些信息的记录就是跨度（Span）。每一次 Trace 实际上都是由若干个有顺序、有层级关系的 Span 所组成一颗“追踪树”（Trace Tree），如下图所示。
+分布式链路追踪诞生的标志性事件就是 Google Dapper 论文的发表。2010年4月，Benjamin H. Sigelman 等人在 Google Technical Report 上发表了《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》[^2]。Dapper 论文详细阐述了分布式链路追踪的设计理念，还提出了成为后续链路追踪系统设计的共识的两个概念：“追踪”（Trace）和“跨度”（Span）。
+
+一条 Trace 代表一次入口请求在 IT 系统内的完整调用轨迹及其关联数据集合。其中，全局唯一的链路标识 TraceId 是代表性的一个属性，通过 TraceId 我们才能将同一个请求分散在不同节点的链路数据准确的关联起来，实现请求粒度的“确定性关联”。当前，光有 TraceId 还不够，请求在每一跳的接口方法上执行了什么动作、耗时多久、执行状态是成功还是失败？承载这些信息的记录就是跨度（Span）。每一次 Trace 实际上都是由若干个有顺序、有层级关系的 Span 所组成一颗“追踪树”（Trace Tree），如下图所示。
 
 <div  align="center">
 	<img src="../assets/Dapper-trace-span.png" width = "350"  align=center />
@@ -29,6 +31,11 @@ Zipkin 和 Jaeger 或多或少都对业务代码有侵入性，国内的工程
 	<p>Skywaling 链路分析</p>
 </div>
 
+和一般的规范标准不同，Opentracing 不是传输协议，消息格式层面上的规范标准，而是一种语言层面上的 API 标准。以 Go 语言为例，只要某链路追踪系统实现了 Opentracing 规定的接口（interface），符合Opentracing 定义的表现行为，那么就可以说该应用符合 Opentracing 标准。这意味着开发者只需修改少量的配置代码，就可以在符合 Opentracing 标准的链路追踪系统之间自由切换。
+
+
+不同的追踪系统使用不同的 API 和数据格式，使得在不同的系统之间切换和集成变得非常复杂，OpenTracing 的出现为开发人员提供了一种通用的编程接口，使得他们可以方便地在不同的追踪系统之间切换和集成，而无需修改现有的代码。 除了 OpenTracing，Google 也推出了一个名为 OpenCensus 的项目，
+
 
 随着分布式追踪技术的日益流行，有一个问题也日益突出，不同链路追踪系统和工具之间缺乏兼容性，如果使用了一个追踪系统，很难再切换到另一个。