fix typo

.vuepress/config.js

@@ -277,7 +277,6 @@ export default defineUserConfig({
                     '/ServiceMesh/data-plane.md',
                     '/ServiceMesh/control-plane.md',
                     '/ServiceMesh/overview.md',
-                    '/ServiceMesh/ServiceMesh-and-Kubernetes.md',
                     '/ServiceMesh/The-future-of-ServiceMesh.md',
                     '/ServiceMesh/conclusion.md',
                 ]
@@ -311,18 +310,18 @@ export default defineUserConfig({
                 collapsable: false,
                 sidebarDepth: 1,
                 children: [
+                    '/application-centric/PaaS.md',
                     '/application-centric/Controller.md',
-                    '/application-centric/IaD.md',
                     {
                         text: "10.3 从“构建抽象”到“应用模型”",
                         link: '/application-centric/app-model.md',
                         children: [
                             '/application-centric/Kustomize.md',
                             '/application-centric/Helm.md',
                             '/application-centric/Operator.md',
+                            '/application-centric/OAM.md',
                         ]
                     },
-                    '/application-centric/GitOps.md',
                     '/application-centric/conclusion.md',
                 ]
             }

application-centric/Controller.md

@@ -1,4 +1,4 @@
-# 10.1 声明式应用管理
+# 10.2 声明式应用管理的本质
 
 Kubernetes 与其他技术项目最大的不同是“声明式应用管理”。
 
@@ -21,9 +21,9 @@ Kubernetes 中有多种类型的控制器，例如 Deployment Controller、Repli
 
 ## 10.1.2 基础设施即数据思想
 
-上述操作体系的理论基础，是一种叫做 IaD（Infrastructure as Data，基础设施即数据）的思想。这种思想认为，基础设施的管理不应该耦合于某种编程语言或者配置方式，而应该是纯粹的、格式化的、系统可读的数据，并且这些数据能够完整的表征使用者所期望的系统状态。
+“控制器模式”体系的理论基础，是一种叫做 IaD（Infrastructure as Data，基础设施即数据）的思想。
 
-这种思想的优势在于，对基础设施实施的任何操作，本质上都等同于对数据执行 “增、删、改、查” 操作。更为关键的是，这些数据 “增、删、改、查” 的实现方式，与基础设施本身毫无关系。这意味着，操作方式不会受限于特定的编程语言、远程调用协议或软件开发工具包（SDK）。只要能够生成符合对应格式的 “数据”，便可以 “随心所欲” 地采用任何你偏好的方式来完成对基础设施的操作 。
+IaD 思想主张，基础设施的管理应脱离特定的编程语言或配置方式，而采用纯粹、格式化、系统可读的数据形式。这些数据能够完整地描述用户期望的系统状态。这种思想的优势在于，对基础设施的所有操作本质上等同于对数据的“增、删、改、查”。更重要的是，这些操作的实现方式与基础设施本身无关，不受限于特定的编程语言、远程调用协议或 SDK。只要生成符合格式要求的“数据”，便可以“随心所欲”地采用任何你偏好的方式管理基础设施。
 
 IaD 思想在 Kubernetes 上的体现，就是执行任何操作，只需要提交一个 YAML 文件，然后对 YAML 文件增、删、查、改即可，而不是必须使用 Kubernetes SDK 或者 Restful API。这个 YAML 文件其实就对应了 IaD 中的 Data。 
 
@@ -53,16 +53,15 @@ spec:
 |COLUMN|property|表里面的列，有 string、boolean 等多种类型|
 |rows|resources|表中的一个具体记录|
 
-Kubernetes 在 v1.7 版本开始支持 CRD（Custom Resource Definitions，自定义资源定义），实质上是允许用户定义自己的资源类型，扩展 Kubernetes API，将复杂的业务需求抽象为 Kubernetes 的原生对象。
+
+所以说，Kubernetes v1.7 版本支持 CRD（Custom Resource Definitions，自定义资源定义），实质上是允许用户定义自己的资源类型，，扩展 Kubernetes API，将复杂的业务需求抽象为 Kubernetes 的原生对象。
+
+有了 CRD，用户便不再受制于 Kubernetes 内置资源的表达能力，自定义出数据库、Task Runner、消息总线、数字证书...。加上自定义的“控制器”，便可把“能力”移植到 Kubernetes 中，并以 Kubernetes 统一的方式暴漏给上层用户。
 
 :::center
   ![](../assets/CRD.webp)<br/>
   图 10-10 CRD
 :::
 
-CRD 加上自定义的“控制器”，便不在受制于 Kubernetes 内置资源的表达能力。例如、持续集成 CRD（Tekton）、持续部署 CRD（ArgoCD）、管理应用伸缩 CRD（Keda）、微服务通信治理（Istio）、监控（Prometheus）“能力”移植到 Kubernetes 中。
-
-
-至此，相信读者已经理解了：IaD 思想中的 Data 具体表现其实就是声明式的 Kubernetes API 对象，而 Kubernetes 中的控制循环确保系统状态始终跟这些 Data 所描述的状态保持一致。从这一点讲，Kubernetes 的本质是一个以“数据”（Data）表达系统的设定值，通过“控制器”（Controller）的动作来让系统维持在设定值的调谐系统。
+至此，相信读者已经理解了：IaD 思想中的 Data 具体表现其实就是声明式的 Kubernetes API 对象，而 Kubernetes 中的控制循环确保系统状态始终跟这些 Data 所描述的状态保持一致。从这一点讲，Kubernetes 的本质是一个以“数据”（Data）表达系统的设定值，通过“控制器”（Controller）的动作来让系统维持在设定值的“调谐”系统。
 
-今天我们在使用 Kubernetes 的时候之所以要写那么多 YAML 文件，其实是因为我们需要通过一种方式把 Data 提交给 Kubernetes 这个控制系统。而在这个过程中，YAML 只是一种为了让人类能够格式化的编写 Data 的一个载体。

application-centric/OAM.md

@@ -1,30 +1,34 @@
 # 10.3.5 OAM
 
-前面介绍的 Helm、Kustomize、CRD + Operator 在各自领域很好的承载一个“组件”的概念，但它们都没有解决一个完整的、面向业务场景的“应用”问题。
+前面介绍的 Helm、Kustomize、CRD + Operator 在各自领域很好的承载一个“组件”的概念。但对于一个完整的“应用”，即面向具体业务场景的定义、部署和运行需求，仍旧缺乏系统化的解决方案。
 
-OAM 的全称为开放应用模型（Open Application Model），由阿里巴巴联合微软共同推出。
+OAM 的全称为开放应用模型（Open Application Model），由阿里巴巴联合微软共同推出，提供了一种大家都可以遵循的、标准化的方式来定义更高层级的应用层抽象，并且把“关注点分离”（Separation of Concerns）作为这个应用模型的核心思想。
 
-- Open，开放与云服务供应商无关。定义的开放标准应该是一套更高级别的抽象，可以跨越本地集群、异构平台、云服务提供商，不会被锁定到任何一个厂商的底座。
-- Application，应用为先。一个应用的交付与部署应该是自包含的，其中的各类操作行为应该作为应用定义的一部分，这些内容与实际的基础设施无关。
-- Model，标准的开放模型。模块化整个应用交付流程，根据个人的需要将这些模块自由组装，达成自己想要的结果。
+OAM 有两个部分：OAM 规范、OAM 规范的 Kubernetes 实现。
 
+详细的说，OAM 规范是基于自定义资源讲原先 All-in-One 的复杂配置做了一定层次的解耦，它强调一个现代应用是多个“组件”（Component）的集合，而非一个简单的工作负载或者 K8s Operator。更进一步的，OAM 把这个应用所需的“运维策略”（Trait）也认为是一个应用的一部分，在 OAM 中，一个应用程序包含三个核心理念：
+- 第一个核心理念是组成应用程序的组件（Component），它可能包含微服务集合、数据库和云负载均衡器；
+- 第二个核心理念是描述应用程序运维特征（Trait）的集合，例如，弹性伸缩和 Ingress 等功能。它们对应用程序的运行至关重要，但在不同环境中其实现方式各不相同；
+- 最后，为了将这些描述转化为具体的应用程序，运维人员使用应用配置（Application Configuration）来组合组件和相应的特征，以构建应部署的应用程序的具体实例。
 
-在 OAM 体系中大致分了三个角色，分别为：
+不同角色分工协作，整体上简化单个角色关注的内容，使得不同角色可以更聚焦更专业的做好本角色的工作。
 
-基础设施运维人员
-负责开发、安装和维护各种 Kubernetes 级别的功能。具体工作包括但不限于维护大规模的 K8s 集群、实现控制器/Operator，以及开发各种 K8s 插件。在公司内部，我们通常被称为“平台团队（Platform Builder）
-业务研发人员
-以代码形式传递业务价值。大多数业务研发都对基础设施或 K8s 不甚了解，他们与 PaaS 和 CI 流水线交互以管理其应用程序。业务研发人员的生产效率对公司而言价值巨大。
-应用运维人员
-为业务研发人员提供有关集群容量、稳定性和性能的专业知识，帮助业务研发人员大规模配置、部署和运行应用程序（例如，更新、扩展、恢复）。请注意，尽管应用运维人员对 K8s 的 API 和功能具有一定了解，但他们并不直接在 K8s 上工作。在大多数情况下，他们利用 PaaS 系统为业务研发人员提供基础 K8s 功能。在这种情况下，许多应用运维人员实际上也是 PaaS 工程人员。
+:::center
+  ![](../assets/OAM-app.png)<br/>
+  图 4-0 OAM
+:::
 
+OAM 在社区的众多用户呼声下诞生。KubeVela 在“关注点分离”的核心思想之上，把平台的用户分成两种角色：
+- **平台构建者**：准备应用部署环境，维护稳定可靠的基础设施功能（如 MySQL Operator），并将基础设施能力作为“KubeVela 模块定义“注册到集群中。
+- **最终用户**：即业务应用的开发者，他们选择部署环境、挑选能力模块、填写业务参数组装成 KubeVela 应用。使用平台的过程中，无需关心基础设施细节。
 
-OAM 使用自定义资源将原先 All-in-One 的复杂配置做了一定层次的解耦，开发工程师管理 Component、运维工程师将 Component 组合并绑定 Trait 变成 AppConfig；平台工程师提供 OAM 的解释能力，将上述自定义资源映射到实际的基础设施；不同角色分工协作，整体上简化单个角色关注的内容，使得不同角色可以更聚焦更专业的做好本角色的工作。
+整个工作流程如下图。
 
 :::center
-  ![](../assets/OAM-how-it-works.png)<br/>
+  ![](../assets/kubevela.jpg)<br/>
   图 4-0 OAM
 :::
 
-- 组件（Component）：
-- 运维特征（运维特征）：运维特征是可以随时绑定给待部署组件的模块化、可拔插的运维能力，比如：副本数调整、数据持久化、设置网关策略、自动设置 DNS 解析等。用户可以从社区获取成熟的能力，也可以自行定义。
+相比于传统的 “PaaS” 项目，KubeVela 这种基于 OAM 和 Kubernetes 构建的云原生应用平台，本质是“应用为中心的” Kubernetes，保证端到端接入整个云原生生态能力。同时，还为最终用户降低心智负担，带来媲美 PaaS 应用管理与交付体验。
+
+[^1]: https://zh.wikipedia.org/wiki/%E4%BF%A1%E6%81%AF%E7%83%9F%E5%9B%B1

application-centric/Operator.md

@@ -36,7 +36,6 @@ Operator 本身在实现上，其实是在 Kubernetes 声明式 API 基础上的
 
 就是把运维的经验沉淀为代码，实现运维的代码化、自动化、智能化。以往的高可用、扩展收缩，以及故障恢复等等运维操作，都通过 Operator 进行沉淀下来。
 
-
 Red Hat 今天与 AWS、Google Cloud 和 Microsoft 合作推出了 OperatorHub.io。
 
 :::center

application-centric/PaaS.md

@@ -0,0 +1,24 @@
+# 10.1 “以应用为中心”的设计
+
+究其原因，其实在于 Kubernetes 中的核心概念与体系，如：Pod、sidecar、Service、资源管理、调度算法和 CRD 等等，主要是面向平台团队而非最终用户设计（如：应用开发人员）。
+
+为了解决这个问题，很多公司落地 Kubernetes 的时候采用了 “PaaS” 化的思路，即在 Kubernetes 之上，开发一个类 PaaS 平台。
+
+但这个设计，跟 Kubernetes “以应用为中心”的设计不一致，Kubernetes 一旦退化成“类IaaS 基础设施”，它的声明式 API、容器设计模式、控制器模式根本无法发挥原本的实力，也很难接入更广泛的生态。
+
+这个问题在 PaaS 系统上的体现就是不具备扩展性。假设我们要满足以下诉求：
+
+- 能不能帮我运行一个定时任务
+- 能不能帮我运运行一个 MySQL Operator
+- 能不能根据自定义 metrics 定义水平扩容策略
+- 能不能基于 Istio 来帮我做渐进式灰度发布
+- 能不能...
+
+这里的关键点在于，上述能力在 Kubernetes 生态中都是非常常见的的能力，有的甚至是 Kubernetes 内置就可以支持。但是到了 PaaS 这里，要支持上述任何一个能力，都必须对 PaaS 进行一轮开发。而且由于先前的一些假设和设计，甚至很可能需要大规模的重构。
+
+具体来说，以“应用为中心”的基础设施：
+
+只有让研发通过他自己的视角来定义应用，而不是定义 Kubernetes API 对象，才能从根本上解决 Kubernetes 使用者“错位”带来的各种问题。
+
+
+符合以“应用为中心”的软件，从研发而不是基础设施的视角自描绘

application-centric/conclusion.md

@@ -1,11 +1,8 @@
-# 10.7 小结
+# 10.4 小结
 
 本章，通过介绍 GitOps 理念，并扩展讨论如何在 Pod 内构建镜像、如何使用 Pod 组织 CI 流水线、如何通过 Argo CD 实施持续交付。相信，你已理解如何构建基于 Kubernetes 为底座的 CI/CD 系统。
 
 至于产生落地中，你或许想要 Argo CD 换成 Flux CD、Tekton 换成 Jenkins X，还有那些代码质量检测、渐进式交付的集成等等，这对你而言，肯定也不再是什么困难的事情。
 
-参考文档：
-- https://www.gitops.tech/
-- 《利用 Tekton + ArgoCD 打造云原生 GitSecOps》 https://majinghe.github.io/devsecops/gitops/
-- 《Enhance your Docker image build pipeline with Kaniko》https://medium.com/01001101/enhance-your-docker-image-build-pipeline-with-kaniko-567afb6cf97c
-- 《Creating CI Pipelines with Tekton》https://www.arthurkoziel.com/creating-ci-pipelines-with-tekton-part-1/
+一个应用要在世界上任何一个地方运行起来，唯一要做的，就是声明“我是什么”、“我要什么”。在那个时候，所有基础设施的概念，包括 Kubernetes、Istio、Knative 统统消失不见。
+

balance/summary.md

@@ -10,7 +10,7 @@
 
 或者出于扩展服务能力的考虑，又或者出于提高容错性的考虑，大多数系统通常以集群形式对外提供服务。
 
-以集群形式对外提供服务时，外界的请求无论由哪台服务器处理，都应获得一致的结果；另一方面，集群还需对外界保持足够的透明。也就是说，外界与集群交互时仿佛面对一台高性能、高可用的服务器。外界不会察觉到集群内部任何变动，比如增加或删除服务器、某个服务器故障等，也无需对应修改任何配置。
+以集群形式对外提供服务时，外界的请求无论由哪台服务器处理，都应获得一致的结果；另一方面，集群需要对外界保持足够的透明度。也就是说，外界与集群交互时仿佛面对一台高性能、高可用的服务器。外界不会察觉到集群内部任何变动，比如增加或删除服务器、某个服务器故障等，也无需对应修改任何配置。
 
 为集群提供访问入口并实现上述职责的组件称为“负载均衡器”（或称代理）。负载均衡器是业内最活跃的领域之一，产品层出不穷（如专用网络设备、基于通用服务器的各类软件等）、部署拓扑多样（如中间代理型、边缘代理、客户端内嵌等）。无论其形式如何，所有负载均衡器的核心职责无外乎 “选择处理外界请求的目标”（即负载均衡算法）和“将外界请求转发至目标”（即负载均衡的工作模式），本章我们围绕这两个核心职责，深入理解负载均衡的工作原理。
 :::center

consensus/Basic-Paxos.md

@@ -36,11 +36,12 @@ SET balance = balance + ?,
 WHERE id = ? AND version = ?;
 ```
 
-我们延续“乐观锁”的思路，思考图 6-7 所示并发冲突如何解决。
+我们借鉴“乐观锁”的思路，思考如何解决图 6-5 中的并发冲突问题。
 
-首先，S~1~ 发起提案，S~3~ 收到 S~1~ 提案时，应该意识到 S~5~ 发起的提案（blue）的 Quorum 已经达成，S~1~ 提案（red）太老。基于先来先得原则，S~1~ 应该更新自己的提案值（red 替换为 blue），这个操作相当于对提案编号（乐观锁中的 version）“锁定”，防止在之后出现多个冲突的提案编号。
+首先，S~1~ 发起提案，S~3~ 收到 S~1~ 提案时，应该意识到 S~5~ 发起的提案（blue）的 Quorum 已经达成，S~1~ 提案（red）已经失效。根据先到先得原则，S~1~ 应该更新自己的提案值（red 替换为 blue），这个操作相当于对提案编号（乐观锁中的 version）“锁定”，防止在之后出现多个冲突的提案编号。
+
+了解哪些编号被接受后，接下来的处理就变得简单了。现在，我们可以直面 Paxos 算法的细节了。
 
-知道哪些编号被接受，后面的处理就简单了。现在，我们可以直面 Paxos 算法的细节了。
 
 ## 2. Paxos 算法描述
 

distributed-transaction/idempotent.md

@@ -19,7 +19,7 @@
 	- 如果 ID 已存在：说明该请求已经被处理过，服务器直接返回之前的响应结果，避免重复处理。
 	- 如果 ID 不存在：执行请求的操作，并将操作结果和该 ID 存储在数据存储中（如数据库、缓存等），以供后续请求检查。
 
-值得一提的是，唯一ID 生成算法 snowflake，取自世界上没有两片相同的雪花之意。使用分布式部署的情况下每秒可生成百万个不重复、递增 id，已经广泛应用于需要分生成唯一标识符的场景。
+值得一提的是，唯一ID 生成算法 snowflake，取自世界上没有两片相同的雪花之意。使用分布式部署的 Snowflake 每秒可生成数百万个唯一且递增的 ID，已被广泛应用于需要生成唯一标识符的各种场景。
 
 ## 5.4.2 乐观锁方案