更新最后一章！

isno · Jan 16, 2025 · 4eae6af · 4eae6af
1 parent edc92e6
commit 4eae6af
Show file tree

Hide file tree

Showing 10 changed files with 31 additions and 25 deletions.
diff --git a/application-centric/Helm.md b/application-centric/Helm.md
@@ -1,4 +1,4 @@
-# 10.3.2 Helm
+# 10.3.2 Helm 与 Chart
 
 相信读者朋友们知道 Linux 的包管理工具和封装格式，如 Debian 系的 apt-get 和 dpkg，RHEL 系的 yum 和 rpm。在 Linux 系统中，有了包管理工具，我们只要知道应用名称，就能从仓库中下载、安装、升级或回滚。而且，包管理工具掌握应用的依赖和版本信息，应用依赖的第三方库，在安装时都会一并处理好。
 

diff --git a/application-centric/OAM.md b/application-centric/OAM.md
@@ -1,4 +1,4 @@
-# 10.3.4 OAM
+# 10.3.4 OAM 与 KubeVela
 
 2019 年 10 月，阿里云与微软在上海 QCon 大会上联合发布了全球首个开放应用模型（OAM，Open Application Model）。OAM 的核心理念是通过模块化设计，将应用拆解为多个功能单元，从而实现开发、运维和平台人员之间的关注点分离。开发人员专注于业务逻辑的实现，运维人员关注程序的稳定性，而平台人员则致力于提升基础设施的能力与可靠性。
 
@@ -7,29 +7,32 @@ OAM 规范下的应用模型并非纯粹的抽象概念，是可以被实际使
 - **应用组件（Component）**：无论是前端还是后端，组件化构建应用的思想屡见不鲜。平台架构师将应用分解成成一个个可被复用的模块、每个组件都具有明确的功能和接口，开发人员通过配置文件填写组件参数、与其他服务的关系，就能描绘出一个完整的应用。
 - **运维特征（Trait）**：运维特征是可以随时绑定给待部署组件的模块化、可拔插的运维能力，比如：副本数调整、数据持久化、设置网关策略、自动设置 DNS 解析等。用户可以从社区获取成熟的能力，也可以自行定义。
 - **应用边界（Application Scope）**：描述集群范围内或应用范围内的行为控制，它定义了与运行时状态、资源利用或安全等相关的约束条件。例如，Policy 可以用来控制副本数量、资源限制、访问控制等。
-- **Workflow**：定义组件如何运行，包含了组件的资源配额和相关的配置。这通常会被映射到 Kubernetes 中的资源对象（如 Pod、Deployment、StatefulSet）上。
+- **工作流步骤（Workflow）**：定义组件如何运行，包含了组件的资源配额和相关的配置。这通常会被映射到 Kubernetes 中的资源对象（如 Pod、Deployment、StatefulSet）上。
+
+
+将组件和运维动作组合，就构成描述统一的、与基础设施无关的“部署计划”。
+对于一个应用而言，大家只需要一份 OAM 的这种自包含的应用描述文件，完整地跟踪到一个软件运行所需要的所有资源和依赖。
 
 :::center
-  ![](../assets/OAM-how-it-works.png)<br/>
+  ![](../assets/OAM.jpg)<br/>
   图 4-0 OAM 应用部署计划
 :::
 
-通过组件（Component）和运维特征（Trait）将业务研发人员与运维人员关注的不同特征进行分离，再将不同的运维特征（Trait）与业务组件（Component）进行绑定，最终再由 OAM 可交付物 – Application Configuration 组装为一个统一的应用。对于一个应用而言，大家只需要一份 OAM 的这种自包含的应用描述文件，完整地跟踪到一个软件运行所需要的所有资源和依赖。
-
-把这样的”高级抽象“交给 OAM 规范实现（如 KubeVela），它将其转换为 Kubernetes 底层资源（如 Deployment、Service 等），
+KubeVela 是将 OAM“模型”化虚为实，也是第一个将“以应用为中心”的设计理念落地的项目。KubeVela 起源于 OAM 社区，由阿里巴巴、微软等公司的技术专家共同维护，它于 2021 年加入 CNCF，2023 年 2 月晋升为“孵化”（Incubating，意味着）级别项目，“孵化”意味着项目达到一定的成熟度，具备了可用性、活跃社区和稳定的技术路线。
 
-KubeVela 项目是 OAM 社区的官方项目，它既是一个端到端、面向全量场景的 OAM Kubernetes 完整实现，同时也是阿里云 EDAS 服务和内部多个核心 PaaS/Serverless 生产系统底层的核心组件。
-
-
-KubeVela 的交付模型是可编程的、以声明式的方式驱动。KubeVela 在 OAM 模型层实现中集成了 CUELang 这种简洁强大的模板语言，从而为平台工程师基于 Kubernetes API 对象定义用户侧抽象，提供了一个标准、通用的配置工具！利用整个 Kubernetes 社区作为自己的“插件中心”，并且“故意”把它的每一个内置能力都设计成是独立的、可插拔的插件。
+KubeVela 基于 OAM 模型的关注点分离理念，将平台用户分为平台工程师（Platform Builder）和最终用户（End User）两类：
+- 平台工程师准备应用部署环境、维护稳定可靠的基础设施功能（如 MySQL Operator），并将这些基础设施能力作为 KubeVela 模块注册到集群中；
+- 最终用户聚焦业务实现，对 Kubernetes 的细节并不关心，他们选择部署环境、挑选能力模块并填写业务参数。最后再 KubeVela 进行组装渲染，变成 Kubernetes 的实际资源，即可在不同运行环境上把应用随时运行起来！
 
+KubeVela 工作流程如下图。
 :::center
-  ![](../assets/definition-cap.png)<br/>
-  图 4-0 OAM 应用部署计划
+  ![](../assets/kubevela.jpg)<br/>
+  图 4-0 KubeVela 工作流程
 :::
 
-有了 KubeVela，平台工程师终于拥有了一个可以方便快捷地将任何一个 Kubernetes 社区能力封装抽象成一个面向用户的上层平台特性的强大工具。而作为这个平台的最终用户，应用开发者们只需要学习这些上层抽象，在一个配置文件中描述应用，就可以快速、在不同运行环境上把应用随时运行起来！
+KubeVela 的价值在于，将云原生丰富的技术快速落地。做一个类比，KubeVela 有点像云原生生态的 “Spring 框架”。在 Java 生态中，Spring 框架帮助开发者快速构建业务应用，通过统一的编程模型，避免深入了解各类技术细节，从而大大降低了技术门槛。相对应的，KubeVela 通过将云原生技术组件与企业应用连接起来，建立统一的管理与运维交付标准，使开发者将关注点从底层的 “Pod”、“Statefulset”、“deployment”转向更高层次“代码”、“应用”。
 
+让研发专注于代码，让技术无缝落地，正是 KubeVela 项目核心价值所在！
 
 
 [^1]: https://zh.wikipedia.org/wiki/%E4%BF%A1%E6%81%AF%E7%83%9F%E5%9B%B1
diff --git a/application-centric/PaaS.md b/application-centric/PaaS.md
@@ -1,5 +1,7 @@
 # 10.1 “以应用为中心”的设计
 
+很多用户开始学习 Kubernetes，太多的用户也在抱怨 Kubernetes “太复杂了”！
+
 ## 10.1.1 下沉基础设施能力
 
 <!--

diff --git a/application-centric/conclusion.md b/application-centric/conclusion.md
@@ -1,8 +1,10 @@
 # 10.4 小结
 
-本章，通过介绍 GitOps 理念，并扩展讨论如何在 Pod 内构建镜像、如何使用 Pod 组织 CI 流水线、如何通过 Argo CD 实施持续交付。相信，你已理解如何构建基于 Kubernetes 为底座的 CI/CD 系统。
+云原生技术与理念发展至今，在推动现代应用架构演进方面取得了空前的成就！
 
-至于产生落地中，你或许想要 Argo CD 换成 Flux CD、Tekton 换成 Jenkins X，还有那些代码质量检测、渐进式交付的集成等等，这对你而言，肯定也不再是什么困难的事情。
+以 Kubernetes 为代表的基础设施，将传统的中间件功能，如服务发现、负载均衡、自动化伸缩，从应用层剥离，下沉至基础设施层！而 Service Mesh 更进一步将传统中间件中至关重要的“服务间流量治理”也下沉至基础设施层面。
 
-一个应用要在世界上任何一个地方运行起来，唯一要做的，就是声明“我是什么”、“我要什么”。在那个时候，所有基础设施的概念，包括 Kubernetes、Istio、Knative 统统消失不见。
+当然，光有基础设施能力远远不够。云原生的最终目标是给业务用户带来价值，借助云原生所独具的弹性、敏捷性，帮助用户更快、更好、更有信心地开发和交付应用！而至于 Kubernetes 也好，ServiceMesh 也罢，都是实现这个目标的手段而不是目的。而今出现的 Helm、Operator、OAM、KubeVela，则是在所有这些能力之上，解决“最后一公里”的问题，如何把这些能力高效、敏捷、通过”以应用为中心“的方式交付给业务用户？
+
+随着底层基础设施能力的日趋完善，相信不久的未来，一个应用要在世界上任何一个地方运行起来，唯一要做的，就是声明“我是什么”、“我要什么”。在那个时候，所有基础设施的概念，包括 Kubernetes、Istio、Knative 统统消失不见。
 
diff --git a/assets/OAM-app.png b/assets/OAM-app.png
diff --git a/assets/OAM.webp b/assets/OAM.webp
diff --git a/assets/oam-principle.jpg b/assets/oam-principle.jpg
diff --git a/container/orchestration.md b/container/orchestration.md
@@ -53,7 +53,7 @@ chroot 最初的目的是为了实现文件系统的隔离，并非专门为容
 
 后来 Linux 吸收了 chroot 的设计理念，先是在 2.4.19 引入了 Mount 命名空间，这样就可以隔离挂载文件系统。又想到进程间通信也需要隔离，就有了 IPC（Process ID）命名空间。同时，容器还需要一个独立的主机名以便在网络中标识自己，于是有了 UTS（UNIX Time-Sharing）命名空间。有了独立的主机名，自然要有配套的 IP、端口、路由等，于是 Network 命名空间应用而生。
 
-从 Linux 内核 2.6.19 开始，陆续引入了 UTS、IPC、PID、Network 和 User 等命名空间。到 Linux 内核 3.8 版本时，Linux 已经实现了容器所需的六项基本资源隔离。
+自 Linux 内核 2.6.19 起，逐步引入了 UTS、IPC、PID、Network 和 User 等命名空间功能。到 3.8 版本，Linux 实现了容器所需的六项核心资源隔离机制。
 
 :::center
 表 7-1 Linux 系统目前支持的八类命名空间（Linux 4.6 版本起，新增了 Cgroup 和 Time 命名空间）
@@ -70,7 +70,6 @@ chroot 最初的目的是为了实现文件系统的隔离，并非专门为容
 | Cgroup| 使进程拥有一个独立的 cgroup 控制组。cgroup 非常重要，稍后笔者详细介绍。 | 4.6 |
 | Time| 隔离系统时间，Linux 5.6 内核版本起支持进程独立设置系统时间 | 5.6 |
 
-
 在 Linux 中，为进程设置各种命名空间非常简单，只需通过系统调用函数 clone 并指定相应的 flags 参数即可。
 
 ```c

diff --git a/distributed-transaction/CAP.md b/distributed-transaction/CAP.md
@@ -31,7 +31,7 @@ CAP 定理描述的是**一个分布式系统中，涉及共享数据问题时
 为此，工程师们又重新给一致性下了定义，**将 CAP、ACID 中讨论的一致性（C）称为“强一致性”，而把牺牲了 C 的 AP 系统但又要尽可能获得正确结果的行为称为追求“弱一致性”**。不过，若只是单纯地谈论“弱一致性”，通常意味着不保证一致性。在弱一致性中，工程师们进一步总结出了一种较强的特例，称为“最终一致性”（Eventual Consistency），它由 eBay 的系统架构师 Dan Pritchett 在 BASE 理论中提出。
 
 :::tip 额外知识
-ACID 在英文中有的“酸”的含义，强调强一致性。BASE 在英文中有“碱”的含义，强调放弃强一致性实现可用性。酸 vs 碱衍生出 CAP 中的 AP 型可用性架构和 CP 型强一致性架构，所以 CAP 理论又戏称度量分布式系统的“Ph试纸”。
+ACID 在英文中有的“酸”的含义，强调强一致性。BASE 在英文中有“碱”的含义，强调放弃强一致性保证可用性。酸 vs 碱衍生出 CAP 中的 AP 型可用性架构和 CP 型强一致性架构，所以 CAP 理论又戏称度量分布式系统的“Ph试纸”。
 :::
 
 

diff --git a/http/Edge-Acceleration.md b/http/Edge-Acceleration.md
@@ -1,15 +1,15 @@
 # 2.7 对请求进行“动态加速”
 
-CDN 技术依赖“边缘节点”缓存静态文件实现就近访问，“动态加速”技术则是通过“边缘节点”，优化 IP 路由和传输层，对动态请求进行加速。
+CDN 技术依赖“边缘节点”缓存静态文件实现就近访问，“动态加速”技术则是利用“边缘节点”，优化 IP 路由、传输协议算法，对请求进行动态加速。
 
-目前，主流的技术服务商，如 Akamai、Fastly、Amazon CloudFront 和 Microsoft Azure 等在全球多个地区部署了数量庞大的边缘服务器，构建了一个庞大的全球性加速网络。使用上述服务商提供的“动态加速”操作简单，将域名的解析记录 CNAME 到服务商提供的域名后，整个加速过程就能自动实现。
+主流技术服务商（如 Akamai、Fastly、Amazon CloudFront 和 Microsoft Azure）在全球各地部署了大量边缘服务器，构建了覆盖广泛的全球加速网络。使用这些服务商的“动态加速”服务非常简单，只需将域名 CNAME 到服务商提供的地址，即可自动实现加速。
 
 操作流程大致如下：
 
-1. 源站（Origin）将域名 CNAME 到 CDN 服务商提供的域名。例如，将 www.thebyte.com.cn CNAME  到 thebyte.akamai.com。
+1. “源站”（Origin）将域名 CNAME 到 CDN 服务商提供的域名。例如，将 www.thebyte.com.cn CNAME  到 thebyte.akamai.com。
 2. 源站提供一个约 20KB 的文件资源，用于探测网络质量。
-3. CDN 服务商在源站附近选择一批转发节点（Relay Nodes）。
-4. 转发节点对测试资源执行下载测试，根据丢包率、RTT、路由的 hops 数等，选定客户端（End Users）到源站的最佳路径。
+3. CDN 服务商在源站附近选择一批“转发节点”（Relay Nodes）。
+4. 转发节点对测试资源执行下载测试，根据丢包率、RTT、路由的 hops 数等，选定“客户端”（End Users）到源站的最佳路径。
 
 :::center
   ![](../assets/dsa.png)<br/>