fix 内容

architecture/Immutable.md

@@ -6,11 +6,9 @@
 
 ## 1.可变的基础设施
 
-从管理基础设施的层面看，“可变”的基础设施与传统运维操作相关。例如，有一台服务器部署的是 Apache，现在想换成 Nginx。传统运维手段是先卸载掉 Apache，重新安装一个 Nginx，再重启系统让这次变更生效。
+从管理基础设施的层面看：“可变”的基础设施与传统运维操作相关。例如，有一台服务器部署的是 Apache，现在想换成 Nginx。传统手段是先卸载掉 Apache，重新安装一个 Nginx，再重启系统让这次变更生效。
 
-上述的过程中，装有 Apache 的 Linux 系统为了满足业务需求，进行了一次或多次变更，该 Linux 系统就是一个可变的基础设施。
-
-可变的基础设施通常会导致以下问题：
+上述的过程中，装有 Apache 的 Linux 操作系统为了满足业务需求，进行了一次或多次变更，该 Linux 操作系统就是一个可变的基础设施。可变的基础设施会导致以下问题：
 
 - **重大故障时，难以快速重新构建服务**：持续过多的手动操作并且缺乏记录，会导致很难由标准初始化的服务器来重新构建起等效的服务；
 - **不一致风险**：类似于程序变量因并发修改而带来的状态不一致风险。服务运行过程中，频繁的修改基础设施配置，同样会引入中间状态，导致出现无法预知的问题。
@@ -23,7 +21,7 @@
 
 2013 年 6 月，Chad Fowler 撰写了一篇名为 《Trash Your Servers and Burn Your Code: Immutable Infrastructure and Disposable Components》的文章，提出了 Immutable Infrastructure（不可变基础设施）的概念[^1]。这一前瞻性的构想，伴随着 Docker 容器技术的兴起、微服务架构的流行，得到了事实上的检验。
 
-不可变基础设施的**核心思想是任何基础设施的运行实例一旦创建之后就变成只读状态**。如需修改或升级，应该先修改基础设施的配置模版（例如 yaml、Dockerfile 配置），之后再使用新的运行实例替换。例如上面提到的 Nginx 升级案例，应该准备一个新的装有 Nginx 的操作系统，而不是在原有的基础上原地更新。
+不可变基础设施的核心思想是**任何基础设施的运行实例一旦创建之后就变成只读状态**。如需修改或升级，应该先修改基础设施的配置模版（例如 yaml、Dockerfile 配置），之后再使用新的运行实例替换。例如上面提到的 Nginx 升级案例，应该准备一个新的装有 Nginx 的 Linux 操作系统，而不是在 Linux 操作系统上原地更新。
 
 :::center
   ![](../assets/Immutable.png)<br/>
@@ -34,9 +32,7 @@
 
 从容器的角度看，**镜像就是一个不可变基础设施**。工程师交付的产物从有着各种依赖条件的安装包变成一个不依赖任何环境的镜像文件，当软件需要升级或者修改配置时，我们修改镜像文件，新起一个容器实例替换，而不是在运行容器内修改。有了镜像之后，本地与测试环境不一致、测试环境与正式环境不一致问题消失殆尽了。
 
-相比可变基础设施，**不可变基础设施的最大的优势是一致性**。所有的基础设施通过标准化描述文件（如 yaml、dockerfile 等）统一定义，同样的配置拉起的服务，绝对不可能出现不一致的情况。
-
-从此，我们可以快速拉起成千上万一模一样的服务，服务的版本升级、回滚也成为常态。
+相比可变基础设施，不可变基础设施通过标准化描述文件（如 yaml、dockerfile 等）统一定义，同样的配置拉起的服务，绝对不可能出现不一致的情况。从此，我们可以快速拉起成千上万一模一样的服务，服务的版本升级、回滚也成为常态。
 
 
 [^1]: 参见 http://chadfowler.com/2013/06/23/immutable-deployments.html

architecture/define-cloud-native.md

@@ -66,10 +66,10 @@ CNCF 是 Linux 基金会旗下的基金会，可以理解为一个非盈利组
 :::
 
 图 1-11 描述了新定义中的代表技术：不可变基础设施、容器、服务网格、微服务、声明式 API。
-- 容器和微服务两项在不同时期的不同定义中都有出现；
+- 容器和微服务在不同时期、不同定义中都有出现；
 - 而服务网格这个在 2017 年才被社区接纳的新技术被醒目的列出来。
 
-服务网格的概念和微服务并列，这表明服务网格已经超越了其原初的角色 —— 仅作为一种实现微服务的新方法，已经发展为云原生的又一个关键领域。
+服务网格和微服务并列，这表明服务网格已经超越了其原初的角色 —— 仅作为实现微服务的新方法，已经发展为云原生的又一个关键领域。
 
 :::center
   ![](../assets/cncf-cloud-native.svg)<br/>

consensus/raft-ConfChange.md

@@ -1,9 +1,9 @@
 # 6.4.3 成员变更
 
-前面的讨论中，我们假设的都是集群的成员是固定的，也就是集群的 Quorum 是固定的。但生产环境中，有很多集群节点变更的情况，如服务器故障需要移除、集群扩容增加节点等等。那如何在集群运行过程中，对成员动态变更呢？
+前面的讨论中，我们假设的都是集群的成员是固定的，也就是集群的 Quorum 是固定的。但生产环境中，有很多集群节点变更的情况，如服务器故障需要移除、集群扩容增加节点等等。
 
 
-先假设有这么个 “配置”（configuration）管理所有的成员信息。
+讨论如何实现成员动态变更之前，先理解 Raft 中“配置”（configuration）的概念。
 
 :::tip 配置
 配置说明集群由哪些节点组成。例如，一个集群有三个节点（Server 1、Server 2、Server 3），该集群的配置就是 [Server1、Server2、Server3]。

distributed-transaction/CAP.md

@@ -2,9 +2,7 @@
 
 CAP 是分布式系统中关于一致性与可用性权衡的理论，是理解分布式系统的起点。
 
-1999 年，美国工程院院士 Eric A.Brewer 发表的论文《Harvest, Yield, and Scalable Tolerant Systems》[^1] 中，首次提出了 CAP 原理（CAP Principle）。不过彼时的 CAP 仅是一种猜想，尚未得到理论上的证明。2002 年，麻省理工学院的 Seth Gilbert 和 Nancy Lynch 用严谨的数学推理证明了 CAP 的正确性。
-
-此后，CAP 从原理转变成定理，在分布式系统领域产生了深远的影响。
+1999 年，美国工程院院士 Eric A.Brewer 发表的论文《Harvest, Yield, and Scalable Tolerant Systems》[^1] 中，首次提出了 CAP 原理（CAP Principle）。不过彼时的 CAP 仅是一种猜想，尚未得到理论上的证明。2002 年，麻省理工学院的 Seth Gilbert 和 Nancy Lynch 用严谨的数学推理证明了 CAP 的正确性。此后，CAP 从原理转变成定理，在分布式系统领域产生了深远的影响。
 
 :::center
   ![](../assets/cap-theorem.png) <br/>