删除不必要的细节。

isno · Mar 12, 2024 · 3ae285d · 3ae285d
1 parent eac90b0
commit 3ae285d
Show file tree

Hide file tree

Showing 3 changed files with 10 additions and 11 deletions.
diff --git a/architecture/cloud-native-tech.md b/architecture/cloud-native-tech.md
@@ -1,5 +1,5 @@
 # 1.5 云原生代表技术
 
-Docker 刚发布时笔者对其短暂地调研，不过由于认知的局限性导致笔者对于 Docker 的印象长期停留在”大工具“的概念中。没错，彼时的笔者已经”跟不上“了，直至笔者对云计算产生了足够的兴趣研究这个领域时，总算理解了容器技术对 IT 行业的影响。
+Docker 刚发布时笔者对其短暂地调研，不过由于认知的局限性导致笔者对于 Docker 的印象长期停留在”大工具“的概念中，直至笔者对容器编排产生了足够的兴趣研究这个领域时，总算理解了容器技术对 IT 行业的影响。
 
-回归本文的主题，笔者接下来介绍云原生中的一些代表技术，并对其中一部分核心，例如容器，将花费一定篇幅追溯其中出现的背景、发展历史，以期望透过纷繁复杂的表象洞察这些技术演进的本质。
+回归内容主题，接下来几节内容将介绍云原生中的一些代表技术，并对其中一部分核心，例如容器，花费一定篇幅追溯其中出现的背景、发展历史，期望透过纷繁复杂的表象洞察这些技术演进的本质。
diff --git a/architecture/container.md b/architecture/container.md
@@ -47,19 +47,17 @@ chroot 被认为是最早的容器化技术之一，chroot 可以重定向进程
 
 2015 年 6 月，Linux 基金会联合 Docker 带头成立 OCI（Open Container Initiative，开放容器标准），OCI 组织着力解决容器的构建、分发和运行问题，其宗旨是制定并维护容器镜像格式和容器运行时的正式规范（OCI Specifications）。
 
-OCI 其核心产出是：
+OCI 其核心产出是下面三个标准：
 
 - OCI Runtime Spec（容器运行时规范）
 - OCI Image Spec（镜像格式规范）
 - OCI Distribution Spec（镜像分发规范）。
 
-OCI 项目启动后，为了符合 OCI 标准，Docker 推动自身的架构持续向前演进。
+OCI 项目启动后，为了符合 OCI 标准，Docker 推动自身的架构持续向前演进。首先它将 libcontainer 独立出来，封装重构成 runC 项目，并捐赠给 Linux 基金会管理。runC 是 OCI Runtime 的首个参考实现，它提出了“让标准容器无处不在”（Make Standard Containers Available Everywhere）的口号。
 
-首先它将 libcontainer 独立出来，封装重构成 runC 项目，并捐赠给 Linux 基金会管理。runC 是 OCI Runtime 的首个参考实现，它提出了“让标准容器无处不在”（Make Standard Containers Available Everywhere）的口号。
+为了能够兼容所有符合标准的 OCI Runtime 实现，Docker 进一步重构了 Docker Daemon 子系统，把其中与运行时交互的部分抽象为了 containerd 项目。这是一个负责管理容器执行、分发、监控、网络、构建、日志等功能的核心模块，其内部会为每个容器运行时创建一个 containerd-shim 适配进程，默认与 runC 搭配工作，但也可以切换到其他 OCI Runtime 实现上（实际并没做到，containerd 仍是紧密绑定于 runC）。
 
-而为了能够兼容所有符合标准的 OCI Runtime 实现，Docker 进一步重构了 Docker Daemon 子系统，把其中与运行时交互的部分抽象为了 containerd 项目。这是一个负责管理容器执行、分发、监控、网络、构建、日志等功能的核心模块，其内部会为每个容器运行时创建一个 containerd-shim 适配进程，默认与 runC 搭配工作，但也可以切换到其他 OCI Runtime 实现上（然而实际并没做到，最后 containerd 仍是紧密绑定于 runC）。
-
-后来到了 2016 年，Docker 把 containerd 捐献给了 CNCF 管理。此后 Docker 运行就不是简单通过 Docker Daemon 来启动了，现阶段的 Docker 通过集成 containerd、containerd-shim、runC 等多个组件共同完成，架构如图 1-16 所示。
+2016 年，Docker 把 containerd 捐献给了 CNCF 管理。此后 Docker 运行就不是简单通过 Docker Daemon 来启动了，现阶段的 Docker 通过集成 containerd、containerd-shim、runC 等多个组件共同完成，架构如图 1-16 所示。
 
 <div  align="center">
 	<img src="../assets/docker-arc.png" width = "600"  align=center />
@@ -94,7 +92,7 @@ OCI 和 CNCF 这两个围绕容器的基金会对云原生生态的发展发挥
 
 在容器编排大战期间，以 kubernetes 为底层资源调度和应用生命周期管理的 CNCF 生态系统也得以迅猛发展，云原生成为云计算市场的技术新热点。
 
-迄今为止，CNCF 在其公布的云原生全景图中，如图 1-18 所示，显示了目前近 30 个领域、数百个项目的繁荣发展，从数据存储、消息传递，到持续集成、服务编排乃至网络管理无所不包，无所不含，正如稼轩先生有言 “溪边照影行，天在清溪底。天上有行云，人在行云里”。
+迄今为止，CNCF 在其公布的云原生全景图中，如图 1-18 所示，显示了目前近 30 个领域、数百个项目的繁荣发展，从数据存储、消息传递，到持续集成、服务编排乃至网络管理无所不包、无所不含。
 
 <div  align="center">
 	<img src="../assets/landscape.png" width = "100%"  align=center />

diff --git a/architecture/declarative-api.md b/architecture/declarative-api.md
@@ -1,6 +1,8 @@
 # 1.5.5 声明式设计
 
+:::tip 声明式设计
 声明式设计（Declarative）指的是一种软件设计理念和做法：“我们向一个工具描述我们想要让一个事物达到的目标状态，由这个工具自己内部去解决如何令这个事物达到目标状态”。
+:::
 
 和声明式设计相对的则是过程式设计（Imperative 或 Procedural），两者的区别是：在声明式模式中，我们描述的是目标状态（Goal State），而在过程式模式中，我们描述的是一系列的动作，这一系列的动作如果被正确的顺利执行，最终结果是这个事物达到了我们期望的目标状态的。
 
@@ -49,7 +51,6 @@ spec:
 - **简单** 我们不需要关心任何过程细节。过程是由工具自己内部 figure out 的、内部执行的。
 - **自我描述 （self-documentation）** 因为我们描述的就是希望一个事物变成什么样子，而不是“发育”过程。
 
-声明式的方式能够大量地减少使用者的工作量，极大地增加开发的效率，这是因为声明式能够简化需要的代码，减少开发人员的工作，如果我们使用命令式的方式进行开发，虽然在配置上比较灵活，但是带来了更多的工作。
+声明式作为是一种设计理念，透传出来的是“把方便留给别人，把麻烦留给自己”的哲学。如果我们使用命令式的方式进行开发，虽然在配置上比较灵活，但是带来了更多的工作。
 
-声明式作为是一种设计理念，透传出来的是“把方便留给别人，把麻烦留给自己”的哲学。声明式模式的工具，设计和实现的难度是远高于 Imperative 模式的。但作为用的人来说，声明式模式省心省事。