update 数据格式

Observability/OpenTelemetry.md

@@ -16,7 +16,7 @@ OpenCensus 最初是 Google 内部监控工具，开源的目地并不是抢 Ope
 
 2019 年，OpenTracing 和 OpenCensus 的维护者决定将两个项目整合在一起，提供各类遥测数据统一采集解决方案 —— OpenTelemetry。
 
-OpenTelemetry 覆盖了各类遥测数据规范定义、API 定义、规范实现以及数据的获取与传输。目标是解决的是遥测数据统一的第一步：通过 API 和 SDK 来标准化遥测数据采集和传输。之后，遥测数据如何使用、存储、展示和告警，OpenTelemetry 本身并不涉及。这使得 OpenTelemetry 既不会因动了“数据的蛋糕”，引起生态抵制，也极大保存了精力，得以专注实现兼容“所有的语言、所有的系统”的遥测数据采集器（OpenTelemetry Collector）。
+OpenTelemetry 做的事情是，标准化遥测数据的定义、采集。至于采集后如何使用、存储、展示、告警，OpenTelemetry 本身并不涉及。这使得 OpenTelemetry 既不会因动了“数据的蛋糕”，引起生态抵制，也极大保存了精力，得以专注实现兼容“所有的语言、所有的系统”的“遥测数据采集器”（OpenTelemetry Collector）。
 
 如图 9-17 所示，集成了 OpenTelemetry 的可观测系统：
 - 应用程序只需要一种 SDK 就可以实现所有类型遥测数据的统一产生；
@@ -30,4 +30,4 @@ OpenTelemetry 覆盖了各类遥测数据规范定义、API 定义、规范实
 :::
 
 
-自 2019 年发布，OpenTelemetry 便得到了广泛的社区支持。现如今，多数的云服务提供商和容器平台，如 AWS、Google Cloud、Azure、阿里云等均已开始支持和推广 OpenTelemetry。在复杂的微服务架构和云原生环境中，OpenTelemetry 已成为可观测领域遥测数据生成和收集的事实标准。
+自 2019 年发布，OpenTelemetry 便得到了社区的广泛支持。现如今，多数的云服务提供商和容器平台，如 AWS、Google Cloud、Azure、阿里云等均已开始支持和推广 OpenTelemetry。在复杂的微服务架构和云原生环境中，OpenTelemetry 已成为可观测领域遥测数据生成和收集的事实标准。

application-centric/Operator.md

@@ -125,10 +125,9 @@ spec:
             storage: 8Gi
 ```
 
-Operator 本身在实现上，其实是在 Kubernetes 声明式 API 基础上的一种“微创新”。它合理的利用了 Kubernetes API 可以添加自定义 API 类型的能力，然后又巧妙的通过 Kubernetes 原生的“控制器模式”，完成了一个面向分布式应用终态的调谐过程。
+Operator 本身在实现上，其实是在 Kubernetes 声明式 API 基础上的一种“微创新”。它利用了 CRD 构建“高层抽象”，又通过 Kubernetes 原生的“控制器模式”，完成了一个面向分布式应用终态的“调谐”过程。
 
-
-使用 CRD 构建“高层抽象”，带来的好处远不止使用简单。
+带来的好处远不止使用简单。
 
 就是把运维的经验沉淀为代码，实现运维的代码化、自动化、智能化。以往的高可用、扩展收缩，以及故障恢复等等运维操作，都通过 Operator 进行沉淀下来。
 

container/kube-scheduler.md

@@ -1,8 +1,8 @@
 # 7.7.3 调度器与扩展设计
 
-如果集群中节点的数量只有几十个，为新创建的 Pod 找到最合适的节点并不困难。但当节点的数量扩大到几千台甚至更多时，问题就变得复杂了：
-- 首先，Pod 的创建、更新还有节点资源无时无刻不在变化，如果每次调度都需要数千次远程请求获取信息，势必因耗时过长，增加调度失败的风险。
-- 其次，调度器频繁发起网络请求，极容易成为集群性能的关键瓶颈，影响整个集群的运行效率。
+如果集群中节点的数量只有几十个，为新建的 Pod 找到合适的节点并不困难。但当节点的数量扩大到几千台甚至更多时，情况就复杂了：
+- 首先，Pod 的创建、更新、节点资源无时无刻不在变化，如果每次调度都需要数千次远程请求获取信息，势必因耗时过长，增加调度失败的风险。
+- 其次，调度器频繁发起网络请求，极容易成为性能瓶颈，影响整个集群的运行效率。
 
 :::tip <a/>
 为了充分利用硬件资源，通常会将各种类型(CPU 密集、IO 密集、批量处理、低延迟作业)的 workloads 运行在同一台机器上，这种方式减少了硬件上的投入，但也使调度问题更加复杂。
@@ -150,12 +150,12 @@ profiles:
 
 经过优选阶段之后，调度器根据预定的打分策略为每个节点分配一个分数，最终选择出分数最高的节点来运行 Pod。如果存在多个节点分数相同，调度器则随机选择其中一个。
 
-经过预选筛选，优选的打分之后，调度器已选择出调度的最终目标节点。最后一步是通知目标节点中的 Kubelet 创建 Pod 了。
+经过预选阶段筛选，优选阶段的打分之后，调度器选择最终目标节点，最后阶段是通知目标节点内的 Kubelet 创建 Pod 了。
 
-这一阶段，调度器并不会直接与 Kubelet 通信，而是将 Pod 对象的 nodeName 字段的值，修改为上述选中 Node 的名字即可。Kubelet 会持续监控 Etcd 中 Pod 信息的变化，然后执行一个称为“Admin”的本地操作，确认资源是否可用、端口是否冲突，实际上就是通用过滤策略再执行一遍，再次确认 Pod 是否能在该节点运行。
+这一阶段中，调度器并不会直接与 Kubelet 通信，而是将 Pod 对象的 nodeName 字段的值，修改为上述选中 Node 的名字即可。Kubelet 会持续监控 Etcd 中 Pod 信息的变化，然后执行一个称为“Admin”的本地操作，确认资源是否可用、端口是否冲突，实际上就是通用过滤策略再执行一遍，二次确认 Pod 是否能在该节点运行。
 
 不过，从调度器更新 Etcd 中的 nodeName，到 Kueblet 检测到变化，再到二次确认是否可调度。这一系列的过程，会持续一段不等的时间。如果等到一切工作都完成，才宣告调度结束，那势必影响整体调度的效率。
 
-调度器采用了乐观绑定（Optimistic Binding）的策略来解决上述问题。首先，调度器同步更新 Scheduler Cache 里的 Pod 的 nodeName 的信息，并发起异步请求 Etcd 更新 Pod 的 nodeName 信息，该步骤在调度生命周期中称 Bind 步骤。如果调度成功了，那 Scheduler Cache 和 Etcd 中的信息势必一致。如果调度失败了（也就是异步更新失败），也没有太大关系，Informer 会持续监控 Pod 的变化，将调度成功却没有创建成功的 Pod 清空 nodeName 字段，并重新同步至调度队列。
+调度器采用了“乐观绑定”（Optimistic Binding）策略来解决上述问题。首先，调度器同步更新 Scheduler Cache 里的 Pod 的 nodeName 的信息，并发起异步请求 Etcd 更新 Pod 的 nodeName 信息，该步骤在调度生命周期中称 Bind 步骤。如果调度成功了，Scheduler Cache 和 Etcd 中的信息势必一致。如果调度失败了（也就是异步更新失败），也没有太大关系，Informer 会持续监控 Pod 的变化，将调度成功却没有创建成功的 Pod 清空 nodeName 字段，并重新同步至调度队列。
 
 至此，整个 Pod 调度生命周期宣告结束。

network/DPDK.md

@@ -14,7 +14,7 @@
  图 3-6 DPDK 与传统内核网络对比
 :::
 
-图 3-7 展示了 DPVS（基于 DPDK 实现的四层负载均衡器）与 LVS（Linux 内核内置的四层负载均衡器）的性能对比。根据每秒转发数据包数量（Packet Per Second，PPS）指标来看，DPVS 的性能表现比 LVS 高出 300%。
+爱奇艺开源的 DPVS 是 DPDK 技术在负载均衡领域的成功应用。图 3-7 展示了 DPVS 与标准 LVS 的性能对比，从每秒转发数据包数量（Packet Per Second，PPS）指标来看，DPVS 的性能表现比 LVS 高出 300%。
 
 :::center
   ![](../assets/dpvs-performance.png)<br/>
@@ -23,4 +23,4 @@
 
 对于海量用户规模的互联网应用来说，动辄需要部署数千、甚至数万台服务器，如果能将单机性能提升十倍甚至百倍，无论是从硬件投入还是运营成本上来看，都能带来非常可观的成本削减。这样的技术变革带来的潜在效益，无疑非常诱人。
 
-DPDK 属于硬件厂商主导的“内核旁路”技术。接下来，笔者再介绍由社区开发者主导的另一类“内核旁路”技术。
+DPDK 是由硬件厂商主导的“内核旁路”技术。在下一节，笔者将介绍由社区开发者主导的另一类“内核旁路”技术。

network/latency.md

@@ -12,7 +12,7 @@
 CPU 从一级缓存中读取数据| 1 ns
 CPU 分支预测错误（Branch mispredict）| 3 ns
 CPU 从二级缓存中读取数据 | 4 ns
-线性间互斥锁/解锁 | 17 ns
+线程间，共享资源加锁/解锁 | 17 ns
 在 1Gbps 的网络上发送 2KB 数据 | 44 ns
 访问一次主存 | 100 ns
 使用 Zippy 压缩 1KB 数据 | 2,000 ns ≈ 2 μs

network/linux-vritual-net.md

@@ -2,4 +2,4 @@
 
 Linux 网络虚拟化的核心技术主要是网络命名空间和各种虚拟网络设备，如稍后介绍的 Veth、Linux Bridge、TUN/TAP 等。这些虚拟设备由代码实现，完全模拟物理设备的功能。
 
-近年来流行的**容器技术基于这些虚拟网络设备，模拟物理设备之间协作方式，将各个独立的网络命名空间连接起来，构建出不受物理环境限制的网络架构**，实现容器之间、容器与宿主机之间，甚至跨数据中心的动态网络拓扑。
+近年来流行颇广的容器技术，正是基于这些虚拟网络设备，模拟物理设备之间协作方式，将各个独立的网络命名空间连接起来，构建出不受物理环境限制的网络架构，实现容器之间、容器与宿主机之间，甚至跨数据中心的动态网络拓扑。