修改容器内容

Observability/OpenTelemetry.md

@@ -2,19 +2,17 @@
 
 收集应用数据并不是什么新鲜事。但是，从一个应用到另一个应用，收集机制和格式很少是一致的。这种不一致，对于只是试图了解应用健康状况的开发人员和 SRE 来说，可能是一场噩梦。
 
+先是 CNCF 提出了 OpenTracing 分布式追踪的标准协议，定义了一套厂商无关、语言无关的规范，也有 Jaeger 、Zipkin 等项目的实现和支持。随后 Google 和微软提出了 OpenCensus 项目，在定义分布式追踪协议的基础上，规范了应用性能指标，并实现了一套标准的 API ，为可观测性能力统一奠定了基础。
 
-
-2010 年，Google 的一篇 Dapper 论文[1]开启了分布式追踪的序章。CNCF 的 OpenTracing 作为分布式追踪的标准协议，定义了一套厂商无关、语言无关的规范，也有 Jaeger 、Zipkin 等项目的实现和支持。随后 Google 和微软提出了 OpenCensus 项目，在定义分布式追踪协议的基础上，也规范了应用性能指标，并实现了一套标准的 API ，为可观测性能力统一奠定了基础。经过对已有的标准协议不停的打磨和演变，CNCF 提出了 OpenTelemetry，它结合了 OpenTracing 与 OpenCensus 两个项目，成为了一个厂商无关、平台无关的支撑可观测性三大支柱的标准协议和开源实现。
-
-OpenTelemetry（也称为 OTel）是一个开源可观测能力框架，由一系列工具、API 和 SDK 组成
+经过对已有的标准协议不停的打磨和演变，最终 CNCF 提出了可观测性的终极项目 OpenTelemetry，它结合了 OpenTracing 与 OpenCensus 两个项目，成为了一个厂商无关、平台无关的支撑可观测性三大支柱的标准协议和开源实现。
 
 OpenTelemetry 的核心工作主要集中在三部分：
 - 规范的制定和协议的统一，规范包含数据传输、API的规范，协议的统一包含：HTTP W3C的标准支持、gRPC等框架的协议标准。
 - 多语言SDK的实现和集成，用户可以使用SDK进行代码自动注入和手动埋点，同时对其他三方库进行集成支持。
 - 数据收集系统的实现，当前是基于OpenCensus Service的收集系统，包括 Agent 和 Collector。
 
-
 <div  align="center">
 	<img src="../assets/otel-diagram.svg" width = "550"  align=center />
 </div>
+
 OpenTelemetry 定位明确，专注于数据采集和标准规范的统一，对于数据如何去使用、存储、展示、告警，标准本身并不涉及。但就总体来说，可观测的技术方案成以下趋势：对于 Metrics 使用 Prometheus 做存储 Grafana 展示，使用 Jaeger 做分布式跟踪存储和展示，对于日志则使用 Loki 存储 Grafana 展示。

Observability/history.md

@@ -2,7 +2,7 @@
 
 分布式系统的可观测性跟控制论里面的可观测性是一致的，这种在其他领域借用的舶来概念并不稀奇，比如常见的“架构”、“设计模式” 等词汇与都是来自于建筑学的概念。
 
-那么，什么是可观测性？可观测性观测什么？Google Cloud 在 OpenTelemetry 的介绍中提到了这么一个概念[^1]：
+那么，什么是可观测性？观测的是什么？Google Cloud 在 OpenTelemetry 的介绍中提到了这么一个概念[^1]：
 
 :::tip telemetry data（遥测数据）
 
@@ -11,7 +11,7 @@ The information that you will use to determine whether an application is healthy
 遥测数据是指采样和汇总有关软件系统性能和行为的数据，这些数据（响应时间、错误率、资源消耗等）用于监控和了解系统的当前状态。
 :::
 
-遥测数据你不一定陌生，如果你在生活中观察仔细，观看电视台火箭发射的直播时，能注意到发射指挥大厅内回响起一系列这样的口令：“东风光学USB雷达跟踪正常，遥测信号正常”，软件领域的可测性和系统遥测数据本质和火箭一样，主要就是通过收集系统内部各类的遥测数据来了解系统内部正在发生的事情，帮助大家在 DevOps 中遇到的故障定位难、容量评估、链路梳理、性能分析等问题，本质上它就是一门数据收集和分析的科学。
+如果你在生活中观察仔细，观看电视台火箭发射的直播时，能注意到发射指挥大厅内回响起一系列这样的口令：“东风光学USB雷达跟踪正常，遥测信号正常”，软件领域的可测性和系统遥测数据本质和火箭一样，就是通过收集系统内部各类的遥测数据来了解系统内部正在发生的事情，帮助大家在 DevOps 中遇到的故障定位难、容量评估、链路梳理、性能分析等问题，本质上它就是一门数据收集和分析的科学。
 
 
 ## 可观测性与传统监控

Observability/metrics.md

@@ -1,8 +1,8 @@
 # 9.2 度量
 
-作为传统监控和告警领域的代名词，Metrics 最广为人知，也被各类可观测系统支持的最丰富。
+作为传统监控和告警领域的代名词，Metrics 最广为人知，也被各类可观测系统支持的最丰富。可聚合性即是 Metrics 的特征，它们是一段时间内某个度量（计数器或者直方图）的原子或者是元数据，即是我们的度量元数据，可以进行简单的加法聚合，当持续了一段时间我们又可以建模为直方图。
 
-大部分时候，Metrics 都是以数字化指标出现，例如请求数、成功率。
+大部分时候，Metrics 都是以数字化指标出现，例如请求数、成功率。例如服务 QPS、API 响应延迟、某个接口的失败数等，
 
 在数据的处理上，Metrics 可以是实时的，也可能是区间范围的，既能做常见的监控告警，也可以用来做趋势分析。
 

Observability/summary.md

@@ -4,7 +4,7 @@
 
 :::tip 额外知识
 
-控制理论中的可观察性（observability）是指系统可以由其外部输出推断其内部状态的程度。系统的可观察性和可控制性是数学上对偶的概念。可观察性最早是匈牙利裔工程师鲁 Rudolf E. Kálmán 针对线性动态系统提出的概念，若以信号流图来看，若所有的内部状态都可以输出到输出信号，此系统即有可观察性。
+控制理论中的可观察性（observability）是指系统可以由其外部输出推断其内部状态的程度。可观察性最早是匈牙利裔工程师鲁 Rudolf E. Kálmán 针对线性动态系统提出的概念，若以信号流图来看，若所有的内部状态都可以输出到输出信号，此系统即有可观察性。
 
 <div  align="center">
 	<img src="../assets/State_transition_SFG.svg.png" width = "350"  align=center />

Observability/tracing.md

@@ -26,6 +26,8 @@
 	<p>Skywaling 链路分析</p>
 </div>
 
+## 代表性项目
+
 在没有形成大一统标准的早期，Dapper 的思想和协议影响了大量的开源项目。受到 Dapper 的启发，Twitter 开发了自己的分布式追踪系统 Zipkin，Zipkin 是第一个被广泛采用的开源的分布式链路追踪系统，提供了数据收集、存储和查询的功能以及友好的 UI 界面来展示追踪信息。
 
 2017年 Uber 在基于 Zipkin 思想和经验的基础上开源了 Jaeger，增加了自适应采样、提供了更加强大和灵活的查询能力等，后来 Jaeger 成为 CNCF 的托管项目，并在 2019年 成为 graduated 级别。即使在今天，Zipkin 和 Jaeger 仍然是最流行的分布式追踪工具之一。

architecture/Immutable.md

@@ -1,6 +1,6 @@
 # 1.5.4 不可变基础设施
 
-解决生产环境中的故障场景下，经常会先出现这么几个画面：开发工程师 “我本地跑好好的，怎么到你那就不行？”；运维工程师 “谁又改了配置文件...”。本节，我们聊聊此类问题的本源 -- 基础设施。
+如果你是个开发工程师，你一定这样抱怨过 “我本地跑好好的，怎么到你那就不行？”，又或者你是个运维工程师，我猜测你这样呐喊过 “谁又改了配置文件啊...”。本节，我们聊聊此类问题的本源 -- 基础设施的可变与不可变问题。
 
 2013 年 6 月，Chad Fowler 在自己的博客中撰写一篇 《Trash Your Servers and Burn Your Code: Immutable Infrastructure and Disposable Components》 的文章，提出了 Immutable Infrastructure（不可变基础设施）的概念[^1]。这一前瞻性的构想，伴随着 Docker 容器技术的兴起、微服务架构的流行，得到了事实上的检验。
 
@@ -31,7 +31,7 @@
 	<p>图1-30 基础设施可变与不可变对比</p>
 </div>
 
-此刻，读者是否灵光一现想起前面介绍的容器技术“构建镜像运行容器之后，如果出现问题，我们不会在容器内修改解决，而是在容器构建阶段去解决”。从容器的角度看，镜像就是一个不可变基础设施，正是容器技术的出现使不同环境的标准化配置成为可能，我们可以快速拉起成千上万一模一样的服务，服务的版本升级、回滚也成为常态，进而不可变基础设施也逐步变成可能。
+此刻，读者是否灵光一现想起前面介绍的容器技术“构建镜像运行容器之后，如果出现问题，我们不会在容器内修改解决，而是在容器构建阶段去解决”。从容器的角度看，镜像就是一个不可变基础设施，开发工程师交付的产物从一个有着各种依赖条件的安装包变成一个不依赖任何环境的镜像文件，那么本地与测试环境不一致、测试环境与正式环境不一致问题从此消失殆尽。正是容器技术的出现使不同环境的标准化配置成为可能，从此我们可以快速拉起成千上万一模一样的服务，服务的版本升级、回滚也成为常态。
 
 对比可变基础设施，不可变基础设施的最大的优势是**一致性**，在不可变基础设施下，所有的配置都通过标准化描述文件（例如 yaml、dockerfile 等）进行统一定义，不同的 Pod、Service 都按照同样的定义创建，不同实例配置不一致的情况不会再出现。在一致性的前提下，当线上突发故障或者遇到异常流量时，不可变基础设施才可以快速进行弹性扩缩容、升级、回滚等操作，应对问题时也更加快速和自动化。
 

architecture/container.md

@@ -1,8 +1,8 @@
 # 1.5.1 容器技术
 
-时间回到 2013 年，当一条简单的 docker run postgre 命令就能运行起 postgre 这样复杂的传统服务时，开发者在震惊之余犹如受到天启。
+时间回到 2013 年，当一条简单的 docker run postgre 命令就能运行起 postgre 这样复杂的传统服务时，开发者在震惊之余犹如受到天启。以 docker 为代表的实用容器技术横空出世，一扇通往敏捷基础设施的大门即将打开。
 
-以 docker 为代表的实用容器技术的横空出世，也预示着一扇通往敏捷基础设施的大门即将打开。越来越多的开发者开始采用容器作为一种标准构建和运行方式，同时业界也意识到，很容易将这种封装方式引入计算集群，通过 Kubernetes 或 Mesos 这样的编排器来调度计算任务 —— 自此，容器便成为这些调度器最重要的 workload 类型。
+容器开始作为一种标准构建和运行方式，同时业界也意识到，很容易将这种封装方式引入计算集群，通过 Kubernetes 或 Mesos 这样的编排器来调度计算任务 —— 自此，容器便成为这些调度器最重要的 workload 类型。
 
 本节内容我们概览容器技术演进历程以及各个阶段所试图解决的问题，以便更全面地了解容器技术。
 

container/dragonfly.md

@@ -1,21 +1,9 @@
 # 7.6.2 镜像分发加速
 
-容器云平台达到一定规模之后，镜像分发就可能成为整个平台的性能瓶颈。举例说明：在生产实践中，较大尺寸的容器镜像有多方面的问题，其一影响容器启动效率，其二在应对瞬时高峰启动几百、几千 Pod 时，受带宽、镜像仓库服务瓶颈等影响，会存在较长的耗时，有时候甚至流量高峰已过，集群还没有扩展完毕。
+容器云平台达到一定规模之后，镜像分发就可能成为整个平台的性能瓶颈。举例说明：在生产实践中，较大尺寸的容器镜像有多方面的问题（见过 12G 的镜像文件），其一影响容器启动效率，其二在应对瞬时高峰启动几百、几千 Pod 时，受带宽、镜像仓库服务瓶颈等影响，会存在较长的耗时。笔者见过多次所有的环节准备完毕，唯独遗漏了镜像下载服务，有时候甚至流量高峰已过，集群还没有扩展完毕。
 
-Dragonfly 则是解决此类容器镜像资源管理和分发瓶颈的方案。
+如果你也有过此类的困扰，那么可以看看 Dragonfly。Dragonfly 是阿里巴巴开源的容器镜像分发系统，目标是解决容器镜像分发效率低下和镜像共享依赖公共镜像仓库等问题。它的核心思想是基于 P2P 的镜像分发模型，以提高镜像传输速度和并发性，减少公共镜像仓库的依赖。
 
-## 1. Dragonfly 介绍
-
-Dragonfly 是阿里巴巴开源的容器镜像分发系统，旨在解决容器镜像分发效率低下和镜像共享依赖公共镜像仓库等问题。Dragonfly 的核心思想是基于 P2P 的镜像分发模型，以提高镜像传输速度和并发性，减少公共镜像仓库的依赖。
-
-Dragonfly 的主要特点和优势如下：
-
-- 快速分发：利用 P2P 技术进行镜像分发，提高传输速度和并发性，支持自动发现、下载和缓存镜像。
-- 高效存储：支持镜像存储中心的横向扩展和透明级联，提供高可用和高扩展性的镜像存储方案。
-- 安全性：支持私有部署和访问权限管理，保证镜像传输和存储的安全性。
-- 易于部署：支持多种部署方式，如二进制包、容器和 Kubernetes Operator 等，方便快速部署和集成。
-
-## 2. Dragonfly 运作流程
 
 Dragonfly 是一种无侵入的解决方案，并不需要修改 Docker 等源码，下图为 Dragonfly 的架构图，在每一个节点上会启动一个 dfdaemon 和 dfget, dfdaemon 是一个代理程序，他会截获 dockerd 上传或者下载镜像的请求，dfget 是一个下载客户端工具。每个 dfget 启动后 将自己注册到 supernode 上。supernode 超级节点以被动 CDN 的方式产生种子数据块，并调度数据块分布。
 

container/k8s-deploy-prepare.md

@@ -21,7 +21,7 @@ sudo sysctl --system
 ```
 2. **关闭 swap 内存**
 
-在 Linux 系统，swap 类似于虚拟内存，初衷是为了缓解物理内存用尽而选择直接粗暴 OOM 进程的尴尬。但实际的运维观察情况是内存不足，swap 场景下进程就是僵而不死，资源被占用不放，与其服务一直不可用，不如关闭 swap 直接 OOM。此外，对于一个分布式系统来说，并不担心节点宕机，而恰恰最担心某个节点夯住，宕机自有副本机制保障可用性，但节点夯住会将所有分布式请求都夯住，导致整个集群请求阻塞。从这两个角度考虑，都应该关掉 swap。
+在 Linux 系统，swap 类似于虚拟内存，初衷是为了缓解物理内存用尽而选择直接粗暴 OOM 进程的尴尬。但实际开启了 swap 更尴尬，内存不足进程僵而不死、资源占用不放。与其服务一直不可用，不如关闭 swap 直接 OOM。此外，对于一个分布式系统来说，并不担心节点宕机，而是担心某个节点夯住，宕机自有副本机制保障可用性，但节点夯住会将所有分布式请求夯住，导致整个集群请求阻塞。从这两个角度考虑，都应该关掉 swap。
 
 ```
 # 使用命令直接关闭swap内存

container/linux-vnet.md

@@ -1,8 +1,10 @@
 # Linux 网络虚拟化
 
-虚拟化容器是以 Linux 名称空间的隔离性为基础来实现的，那解决隔离的容器之间、容器与宿主机之间、乃至跨物理网络的不同容器间通信问题的责任，很自然也落在了 Linux 网络虚拟化技术的肩上。
+本节，走入 Linux 网络的底层世界，先去学习一些与设备、协议、通信相关的基础网络知识。有着这些基础的技术储备之后，方能更好理解容器网络。
+
+Linux 网络虚拟化的主要技术是网络命名空间以及各类虚拟设备，例如 veth、Linux Bridge、tap/tun 等。虚拟化的本质是现实世界的映射，容器网络正是基于这些虚拟设备模拟现实世界中的物理设备彼此协作，将各个独立的网络命名空间连接起来，构建出不受物理环境约束的容器之间、容器与宿主机之间、乃至跨物理网络各类动态网络拓扑架构。
+
 
-Linux 网络虚拟化的主要技术是网络命名空间以及各类虚拟设备，例如 veth、Linux Bridge、tap/tun 等。虚拟化的本质是现实世界的映射，这些虚拟设备像现实世界中的物理设备一样彼此协作，将各个独立的网络命名空间连接起来，构建出不受物理环境约束的各类动态网络拓扑架构。
 
 ## 网络命名空间