fix typo

Observability/signals.md

@@ -4,13 +4,13 @@
 
 - **指标（metrics）**：量化系统性能和状态的“数据点”，每个数据点包含度量对象（描述监控内容，如请求数）、度量值（具体数值，如 100 次/秒）和时间戳（采集时刻），例如，“2024-12-27 10:00:00，CPU 使用率为 75%”。多个连续的数据点便可以分析系统性能的趋势和变化规律。指标是发现问题的起点，例如你收到一条告警：“12 点 22 分，接口请求成功率下降到 10%”，这表明系统出现了问题。接着，你结合链路追踪和日志数据深入分析，找到问题的根本原因并进行修复。
 
-- **日志（logs）**：系统运行过程中，记录离散事件的文本数据，每条日志详细描述事件操作对象、操作结果、操作时间。例如下面的日志，提供了时间戳、日志级别（ERROR）以及事件描述。
+- **日志（logs）**：系统运行过程中，记录离散事件的文本数据。每条日志详细描述了事件操作对象、操作结果、操作时间等信息。例如下面的日志示例，内容包含时间戳、日志级别（ERROR）以及事件描述。
 ```bash
 [2024-12-27 14:35:22] ERROR: Failed to connect to database. Retry attempts exceeded.
 ```
 日志为问题诊断提供了精准的上下文信息，与指标形成互补。当系统故障时，“指标”告诉你应用程序出现了问题，“日志”则解释了问题出现的原因。
 
-- **链路追踪（traces）**：记录单个请求在多个服务之间的传播路径（Trace），包括流经的节点（span）、耗时分布及相关上下文信息。链路追踪以追踪树（Trace Tree）的形式直观呈现请求的调用链路，帮助工程师在复杂的分布式系统中快速定位异常点和性能瓶颈。
+- **链路追踪（traces）**：记录请求在多个服务之间的“调用链路”（Trace），以“追踪树”（Trace Tree）的形式呈现请求的“调用”（span）、耗时分布等信息。
 
 ```bash
 // 追踪树

Observability/tracing.md

@@ -16,25 +16,27 @@
 
 Dapper 论文中提出了一些很重要的核心概念：Trace、Span、Annonation 等，这是理解链路追踪原理的前提。
 
-- **追踪（trace）**：代表一次完整的请求。一次完整的请求是指，从客户端发起请求，记录请求流转的每一个服务，直到客户端收到响应为止。整个过程中，当请求分发到第一层级的服务时，就会生成一个全局唯一的 Trace ID，并且会随着请求分发到每一层级。因此，通过 Trace ID 就可以把一次用户请求在系统中调用的链路串联起来；
-- **跨度（Span）**：代表一次调用，也是链路追踪的基本单元。由于每次 Trace 都可能会调用数量不定、坐标不定的多个服务，为了能够记录具体调用了哪些服务，以及调用的顺序、开始时点、执行时长等信息，每次开始调用服务前都要先埋入一个调用记录，这个记录称为一个 Span。Span 的数据结构应该足够简单，以便于能放在日志或者网络协议的报文头里；也应该足够完备，起码应含有时间戳、起止时间、Trace 的 ID、当前 Span 的 ID、父 Span 的 ID 等能够满足追踪需要的信息。
-- **Annotation**：用于业务自定义埋点数据，如一次请求的用户 ID，某一个支付订单的订单 ID 等。
+- **追踪（trace）**：表示一次完整的请求，从客户端发起到收到响应的全过程。请求流转时，第一层服务会生成一个全局唯一的 Trace ID，随后该 ID 会随请求传递至各层服务。通过 Trace ID，可以串联起请求在系统中所有服务的调用链路。
+- **跨度（Span）**：表示一次调用，是链路追踪的基本单元。每个 Trace 可能涉及多个服务调用，且数量和顺序不固定。为记录具体调用的服务、调用顺序、开始时间和执行时长等信息，每次调用服务前需生成一条记录，称为 Span。Span 的数据结构应简单，便于嵌入日志或网络协议报文头；同时要足够完整，至少包括时间戳、起止时间、Trace ID、当前 Span ID、父 Span ID 等信息，以满足追踪需求。
+- **Annotation**：记录业务自定义数据，如请求用户 ID、支付订单 ID 等。
 
-Dapper 系统为每一个跨度记录了一个可读的 span name、span id、parent id。没有 parent id 的跨度称为根跨度，一次特定的追踪所有的相关的跨度共享一个通用的 trace id。通过 trace id，即可重建出一次分布式追踪过程中不同跨度之间的因果关系。换句话说，追踪（trace）实际上都是由若干个有顺序、有层级关系的跨度（Span）所组成一颗追踪树（Trace Tree），如图 9-1 所示。
+Dapper 系统为每个跨度记录了一个可读的 span name、span id 和 parent id。没有 parent id 的跨度称为根跨度。在一个请求的追踪中，所有相关跨度共享相同的 trace id。通过 trace id，便可重建分布式系统服务间调用的因果关系。换言之，链路追踪（Trace）是由若干具有顺序、层级关系的跨度（Span）组成一棵追踪树（Trace Tree），如图 9-1 所示。
 
 :::center
   ![](../assets/Dapper-trace-span.png)<br/>
   图 9-11 由不同跨度组成的追踪树
 :::
 
-自 Dapper 论文发布后，几乎成了现代链路追踪的理论基石，主流的链路追踪系统都是基于 Dapper 衍生出来的。当前，常见的链路追踪项目包括 Zipkin、Jaeger、Skyworking、Pinppint 等。
+Dapper 论文发布后，几乎成了现代链路追踪的理论基石，主流的链路追踪系统都是基于 Dapper 衍生出来的。当前，常见的链路追踪项目包括 Zipkin、Jaeger、Skyworking、Pinppint 等。
 
  :::center
   ![](../assets/tracing.png)<br/>
   图 9-12 CNCF 下分布式链路追踪产品生态
 :::
 
-上述各个链路追踪系统笔者无法一一介绍，但从链路追踪系统的实现来看，就是在服务调用的阶段收集 trace、span 信息，然后汇总构成追踪树结构。收集数据并不复杂，但再兼顾下面两个目标，就变得不容易了：
+上述各个链路追踪系统笔者无法一一介绍，但从链路追踪系统的实现来看，都是在服务调用阶段收集 trace、span 信息，然后汇总构成追踪树结构。
+
+收集数据并不复杂，但兼顾下面两个目标，就变得不容易了：
 
 - **低消耗**：追踪系统对业务的影响应该足够小。一些对延迟极其敏感的业务，即使一点点延迟损耗也会很容易察觉到，这可能迫使业务团队不得不将追踪系统关停；
 - **对业务透明**：对于业务工程师而言，不需要知道有追踪系统这回事。如果一个追踪系统必须依赖业务工程师的主动配合，那这个追踪系统也未免太脆弱了。

application-centric/PaaS.md

@@ -6,7 +6,7 @@
 
 “复杂”，是任何一个基础设施项目天生的特质而不是缺点。基础设施本身的复杂度，并不意味着基础设施的所有使用者都应该承担所有这些复杂度本身。为了解决这个问题，很多公司落地 Kubernetes 的时候采用了 “PaaS” 化的思路，即在 Kubernetes 之上，开发一个类 PaaS 平台。
 
-但这个设计，跟 Kubernetes “以应用为中心”的设计不一致，Kubernetes 一旦退化成“类IaaS 基础设施”，它的声明式 API、容器设计模式、控制器模式根本无法发挥原本的实力，也很难与广泛的生态对接。这个问题在 PaaS 系统上的体现就是不具备扩展性。假设我们要满足以下诉求：
+但这个设计，跟 Kubernetes “以应用为中心”的设计不一致，Kubernetes 一旦退化成“类IaaS 基础设施”，它的声明式 API、容器设计模式、控制器模式根本无法发挥原本的实力，也很难与广泛的生态对接。在 PaaS 系统上的体现就是不具备扩展性，假设我们要满足以下诉求：
 
 - 能不能帮我运行一个定时任务
 - 能不能帮我运运行一个 MySQL Operator

architecture/devops.md

@@ -54,9 +54,9 @@ DevOps 核心本质是解决软件开发生命周期中的管理问题，我们
 
 ## 3.DevOps
 
-DevOps 运动始于 2007 年左右，当时技术社区对开发与运维之间分开工作的方式以及由此引发的冲突感到担忧。随着越来越多问题的出现，大家逐渐认识到：为了按时交付软件产品和服务，开发和运维必须紧密配合。
+DevOps 运动始于 2007 年左右，当时技术社区对开发/运维分工协作的方式、以及由此引发的冲突感到担忧。随着越来越多问题的出现，大家逐渐认识到：为了保证产品研发的效率、软件交付的质量，开发和运维必须紧密配合。
 
-2009 年，比利时根特市举办了首届 DevOpsDays 大会，这届会议出乎意料的成功，引起人们广泛的讨论，DevOps 理论由此诞生。
+2009 年，比利时根特市举办了首届 DevOpsDays 大会，这届会议出乎意料的成功，引起人们广泛的讨论。DevOps 理论就此诞生！
 
 :::tip DevOps 的定义
 DevOps（Development 和 Operations 的合成词）是一种重视“软件开发人员（Dev）”和“IT 运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。
@@ -67,9 +67,9 @@ DevOps（Development 和 Operations 的合成词）是一种重视“软件开
 —— from 维基百科
 :::
 
-2009 年 DevOps 概念引入之时，基于“Development“和“Operations”合成一个新词“DevOps”，强调开发（指交付前的广义上的研发活动，包括设计、测试等）与运维融合，目的是打破开发和运维之间的隔阂、加快软件交付流程、提高软件质量。
+2009 年，引入 DevOps 概念之时，基于“Development“和“Operations”合成一个新词“DevOps”，强调开发（指交付前的广义上的研发活动，包括设计、测试等）与运维融合，打破开发和运维之间的隔阂、加快软件研发效率、提高软件交付质量。
 
-从存在的意义上说，DevOps 完善了敏捷开发存在的短板，实现了真正的闭环。如图 1-31 所示，开发和运维不再是“孤立”的团队，两者在软件的整个生命周期内相互协作，紧密配合。由此带来的效益，是软件的品质不仅高、交付的速度还快。
+从存在的意义上说，DevOps 完善了敏捷开发存在的短板，实现了研发流程真正的闭环。如图 1-31 所示，开发和运维不再是“孤立”的团队，两者在软件的整个生命周期内相互协作，紧密配合。由此带来的效益，是软件的品质不仅高、交付的速度还快。
 
 :::center
   ![](../assets/devops-2.jpg)<br/>