更新内容

README.md

@@ -1,26 +1,23 @@
 # 深入架构原理与实践
 
+## 这是什么？
+
+这是一本关于架构设计的开源书籍，预计 2024 年 3 月左右出版，目前内容还存在逻辑不清晰、内容组织结构不完整的地方，我将在这期间逐渐完成修正。
+
 ## ⭐️ 为什么要写这个？
 
 这几年互联网基础设施技术出现了很大的更新迭代，比如容器技术（Container、Kubernetes）、服务网格（ServiceMesh）、无服务器（Serverless）、高性能网络（DPDK、XDP） 等等，我对这些技术有一些浅薄的见解和实践，但也远没达到深刻理解的境界，我尝试使用 `费曼学习法` 把这些东西体系化地总结输出。一方面是加深自我的学习认识，另一方面也希望这些输出对其他人有所帮助。
 
 整个系列的内容主要集中在 `网络`、`集群以及服务治理`、`FinOps` 这三个主题，这也代表着基础架构的几个核心：稳定、效率、成本。
 
-
 我会持续更新这个仓库的内容，如果想要关注可以点 `star` 。
 
-
 <div  align="center">
 	<img src="./assets/star-history-2023928.png" width = "460"  align=center />
 	<p><a href="https://github.com/isno/theByteBook">https://github.com/isno/theByteBook</a></p>
 </div>
 
 
-## 关于写作进度
-
-本书预计 2024 年 3 月左右完稿，目前内容还存在用词不规范、逻辑不清晰、内容组织结构不完整的地方，我将在这期间逐渐完成修正。
-
-
 ## 如何阅读
 
 - **在线阅读**：本文档在线阅读地址为：[https://www.thebyte.com.cn](https://www.thebyte.com.cn)  【为防止缓存，阅读前请先强制刷新】

balance/balance.md

@@ -13,11 +13,4 @@
 	<p>图4-2 负载均衡架构</p>
 </div>
 
-在分布式系统中正确地使用负载均衡可以带来这些好处：
-
-- 命名抽象化：客户端无需知道每个后端（服务发现），只要能找到负载均衡器就行了，名称解析委托给负载均衡器。
-- 容错：通过健康检查和各种算法，负载均衡器可以有效地绕开不良或超载的后端。
-- 开销和性能优势：分布式系统的网络很少是同构的，系统很可能跨多个网络 zone 和 region。负载均衡可以最大限度地将请求流量保持在 zone 内部，即提高性能（更低的延迟）又降低整体系统成本（减少跨 zone 带宽）。
-
-
 广义的负载均衡包括操作系统使用负载均衡来跨物理处理器调度任务、容器编排器使用负载均衡来跨集群调度任务、网络负载中跨可用后端调度网络任务等等，本章我们讨论的内容主要为网络负载均衡。网络类型所有解决方案通常分为两类：四层负载均衡和七层负载均衡，这两者分别对应 OSI 模型的 4 层和 7 层。

balance/balance4-conclusion.md

@@ -8,7 +8,5 @@
 2. L4LB 为每个进来（从客户端）的连接建立一个出去的（到后端）的连接，因此有两个进来的连接和两个出去的连接。
 3. 客户端 A 的连接每分钟发送 1 个请求，而客户端 B 的连接每秒发送 50 个请求。
 
-由于四层负载均衡器的同一个 session 的字节永远落到同一后端，选中的处理客户端 A 请求的后端比选中的处理客户端 B 请求的后端，负载要相差很多倍，这就与负载均衡的目的背道而驰。
-
-由于性能考虑（创建 TCP 连接的开销非常大，尤其连接使用 TLS 加密的时候），以及所有现代协议都在演进以支持 multiplexing（多路复用） 和 kept-alive（连接保活），因此 L4LB 的阻抗不匹配问题随时间越来越彰显，不过这个问题在 L7LB 得到解决。
+由于四层负载均衡器的同一个 session 的字节永远落到同一后端，选中的处理客户端 A 请求的后端比选中的处理客户端 B 请求的后端负载要相差很多倍，这就与负载均衡的目的背道而驰。由于性能考虑（创建 TCP 连接的开销非常大，尤其连接使用 TLS 加密的时候），以及所有现代协议都在演进以支持 multiplexing（多路复用） 和 kept-alive（连接保活），因此四层负载均衡器的阻抗不匹配问题随时间越来越彰显，不过这个问题在四层负载均衡器之后再加一级七层负载均衡器就能得到解决。