diff --git a/balance/balance-topology.md b/balance/balance-topology.md
index a91aa8e2..69d10d0a 100644
--- a/balance/balance-topology.md
+++ b/balance/balance-topology.md
@@ -38,7 +38,7 @@
## 6.3.3 客户端内嵌
-为解决中间代理型拓扑的单点故障问题，出现了更复杂的解决方案，其中之一是将负载均衡器以 SDK 库形式嵌入客户端（如图 4-7 所示）。这些 SDK 库如 Finagle、Eureka、Ribbon 和 Hystrix 等，它们优缺点是：
+为解决中间代理型拓扑的单点故障问题，出现了更复杂的解决方案，其中之一是将负载均衡器以 SDK 库形式嵌入客户端（如图 6-7 所示）。这些 SDK 库如 Finagle、Eureka、Ribbon 和 Hystrix 等，它们优缺点是：
- 优点：将负载均衡器功能“转移”至客户端，避免了单点故障问题；
- 缺点：需要为每种编程语言实现相应的 SDK，且在项目复杂时，处理版本依赖和兼容性问题变得棘手（微服务框架的相关问题将在本书第八章 8.2 节中详细讨论，读者可参考进一步了解）。
diff --git a/balance/balance4.md b/balance/balance4.md
index c722a725..45ae5b11 100644
--- a/balance/balance4.md
+++ b/balance/balance4.md
@@ -101,7 +101,7 @@ $ ip addr add 1.1.1.1/32 dev lo
到目前为止，我们讨论的都是单个负载均衡器的工作模式。那么，如果负载均衡器出现故障呢？这将影响所有经过该负载均衡器的连接。为了避免因负载均衡器故障导致服务中断，负载均衡器通常以高可用模式进行部署。
-图 6-12 展示的是最常见的主备模式，其核心是每台节点上运行 Keepalived 软件。该软件实现了 VRRP（Virtual Router Redundancy Protocol）协议，虚拟出一个对外服务的 IP 地址（VIP）。该 VIP 默认绑定在主节点（Master）上，由主节点处理所有流量请求。备用节点（Backup）则持续监控主节点的状态，并在主节点发生故障时迅速接管 VIP，从而确保服务不中断。
+图 6-12 展示了最常见的主备模式，其核心在于每台节点上运行 Keepalived 软件，该软件实现了 VRRP（Virtual Router Redundancy Protocol）协议，虚拟出一个对外提供服务的 IP 地址（VIP）。默认情况下，VIP 绑定在主节点（Master）上，由主节点处理所有流量请求。备用节点（Backup）则持续监控主节点的状态，当主节点发生故障时，备用节点会迅速接管 VIP，确保服务不中断。
:::center
diff --git a/balance/conclusion.md b/balance/conclusion.md
index 7cb73abf..3f3762d0 100644
--- a/balance/conclusion.md
+++ b/balance/conclusion.md
@@ -1,8 +1,7 @@
# 6.7 小结
-作为分布式系统的入口，负载均衡领域竞争激烈，技术创新层出不穷。但从处理请求的网络层次划分，所有的负载均衡器可分为两类，四层负载均衡和七层负载均衡。
+负载均衡作为分布式系统的入口，直接影响整个系统的行为。因此，这一领域的竞争异常激烈，技术创新不断涌现。
-- 四层负载均衡器处理传输层连接，功能相对简单，主要依赖 IP 地址和端口信息进行流量分发。随着技术的不断演进，传统负载均衡设备（如 F5）逐渐被通用服务器加上专用软件（如 IPVS、DPDK、fd.io）的方案取代。例如，一台普通物理主机，基于 DPDK 开发的流量转发或数据包处理场景下，能轻松达突破百万到数千万的 PPS（Packets Per Second，每秒处理的数据包数量）指标。
-- 七层负载均衡器处理应用层流量，职责更广、功能丰富。如处理 HTTP 请求、SSL 卸载、URL 路由、Cookie 路由等。这几年，源于微服务架构的快速发展，七层负载均衡领域十分活跃，像传统代理软件（如 NGINX、HAProxy），逐渐被更适应动态微服务架构后来者（如 Envoy、Traefik...）替代。
+总体来看，传统的硬件负载均衡设备（如 F5）正逐步被基于通用服务器和专用软件（如 IPVS、DPDK、fd.io）的解决方案所取代。例如，基于 DPDK 的流量转发和数据包处理技术，在普通物理主机上即可轻松突破百万至数千万的每秒数据包处理能力（PPS）。在七层负载均衡领域，随着微服务架构的快速发展，传统代理软件（如 NGINX、HAProxy）逐渐被更适应动态微服务环境的解决方案（如 Envoy、Traefik）所取代。
-总体而言，随着技术架构逐步向云厂商主导的 IaaS、CaaS 和 FaaS 模式演进，未来工程师将很少需要关注物理网络的工作原理，隐藏在 XaaS 模式之下的各类网络技术，正逐渐演变为“黑科技”。
\ No newline at end of file
+随着技术架构逐步向云厂商主导的 IaaS、CaaS 和 FaaS 模式演进，未来工程师将很少需要关注物理网络的工作原理，隐藏在 XaaS 模式之下的各类网络技术，正逐渐演变为“黑科技”。
\ No newline at end of file
diff --git a/balance/global-load-balancer.md b/balance/global-load-balancer.md
index 224c9a8b..25a18387 100644
--- a/balance/global-load-balancer.md
+++ b/balance/global-load-balancer.md
@@ -5,7 +5,7 @@
图 6-14 展示了全局负载均衡系统设计：
- 边车代理（Sidecar Proxy）和位于三个 Zone 的后端通信；
- 边车代理、后端定期向全局负载均衡器（Global Load Balancer）汇报请求延迟、自身的负载等状态，全局负载均衡器根据状态做出最合适的配置策略；
-- 全局负载均衡器向边车代理下发配置策略，可以看到 90% 的流量到了 Zone C，Zone A 和 B 各只有 5%。
+- 全局负载均衡器向边车代理下发转发策略，可以看到 90% 的流量到了 Zone C，Zone A 和 B 各只有 5%。
:::center
