diff --git a/architecture/MicroService.md b/architecture/MicroService.md index d8696b43..fa21547f 100644 --- a/architecture/MicroService.md +++ b/architecture/MicroService.md @@ -95,7 +95,7 @@ Adrian Cockcroft 的观点中有两个核心概念： Kubernetes 的崛起标志着微服务时代的新篇章，但它并未能完全解决所有的分布式问题。就功能的灵活性和强大性而言，Kubernetes 还比不上之前的 Spring Cloud 方案，原因在于某些问题位于应用系统与基础设施的交界处，而微观的服务管理并不能完全在基础设施层面得到解决。 -笔者举个例子，如图 1-21 所示，假设微服务 A 调用了微服务 B 的两个服务，即 B1 和 B2。若 B1 正常运行，而 B2 持续出现 500 错误，那么在达到一定阈值后，就应对 B2 进行熔断，以避免引发雪崩效应。如果仅在基础设施层面处理这个问题，那就会陷入两难境地“切断 A 到 B 的网络通路会影响到 B1 的正常运作，不切断则会持续受到 B2 错误的影响”。 +举个例子，如图 1-21 所示，假设微服务 A 调用了微服务 B 的两个服务，即 B1 和 B2。若 B1 正常运行，而 B2 持续出现 500 错误，那么在达到一定阈值后，就应对 B2 进行熔断，以避免引发雪崩效应。如果仅在基础设施层面处理这个问题，那就会陷入两难境地“切断 A 到 B 的网络通路会影响到 B1 的正常运作，不切断则会持续受到 B2 错误的影响”。
diff --git a/architecture/conclusion.md b/architecture/conclusion.md index 91d252f4..41a1bce7 100644 --- a/architecture/conclusion.md +++ b/architecture/conclusion.md @@ -6,7 +6,7 @@ 如果高可用没有最优解，那就换个思路：努力具备深厚的基础和广泛的知识面。此后面临突发故障虽可能无法立即解决，但至少可以准确地看出源头，从而找到解决问题的正确路径。 -受限于笔者的功力，本书内容有诸多不足，但“足够的广度”和“一定范围内的深度”也是本书着重想要表达的内容。 +受限于作者的功力，本书内容有诸多不足，但“足够的广度”和“一定范围内的深度”也是本书着重想要表达的内容。 本章参考： diff --git a/http/bbr.md b/http/bbr.md index d5eb8563..530d7065 100644 --- a/http/bbr.md +++ b/http/bbr.md @@ -33,7 +33,7 @@ $ tc qdisc add dev eth0 root netem loss 1% latency 25ms $ iperf3 -c 10.0.1.188 -p 8080 ``` -笔者的测试结果中，网络环境条件好的情况下两者相差无几，但如果是弱网、有一定丢包率的场景下，BBR 的性能远超 Cubic。 +我的测试结果中，网络环境条件好的情况下两者相差无几，但如果是弱网、有一定丢包率的场景下，BBR 的性能远超 Cubic。 实践结束了，下面聊聊拥塞控制理论。 diff --git a/http/http-dns.md b/http/http-dns.md index d8d6ee84..13f02f0f 100644 --- a/http/http-dns.md +++ b/http/http-dns.md @@ -15,4 +15,4 @@ HTTPDNS 系统跳过系统默认的 DNS 解析的过程，使用 HTTPS 协议绕

图 2-7 HTTPDNS 模式下 DNS 解析流程

-使用 HTTPDNS ，辅以客户端预解析、懒加载等策略，能明改善传统域名带来的各类解析问题。笔者的工作实践中，使用 HTTPDNS 服务，全球各个服务初次请求延迟约下降 25% 左右，之前劫持、页面无法打开、请求失败的故障率也大幅下降。 \ No newline at end of file +使用 HTTPDNS ，辅以客户端预解析、懒加载等策略，能明改善传统域名带来的各类解析问题。我的工作实践中，使用 HTTPDNS 服务，全球各个服务初次请求延迟约下降 25% 左右，之前劫持、页面无法打开、请求失败的故障率也大幅下降。 \ No newline at end of file diff --git a/http/http-performance.md b/http/http-performance.md index 0e0a40a8..f7112374 100644 --- a/http/http-performance.md +++ b/http/http-performance.md @@ -2,7 +2,7 @@ 解决域名解析环节中的问题之后，我们继续看 HTTP 请求过程中有哪些方面的优化。 -根据笔者的实践经验来看，关注以下几个方面的优化，能明显改善服务质量。 +根据我的实践经验来看，关注以下几个方面的优化，能明显改善服务质量。 - 包体积优化：传输数据的包体大小与传输耗时成正相关，**减小包体**是优化最有效的手段之一。 - 传输层优化：升级拥塞控制算法（譬如默认的 Cubic 升级为 BBR 算法）**提升网络吞出率**。 diff --git a/http/https.md b/http/https.md index 3a298f5f..3675c3ba 100644 --- a/http/https.md +++ b/http/https.md @@ -1,6 +1,6 @@ # 2.5.1 设计“绝对”安全的信息传输机制 -本节内容笔者带领读者们尝试从零开始设计一个“绝对”安全的信息传输机制，从设计者的角度体会 HTTPS 为何有这么多环节以及理解证书产生的作用。 +本节内容，我们尝试从零开始设计一个“绝对”安全的信息传输机制，从设计者的角度体会 HTTPS 为何有这么多环节以及理解证书产生的作用。 ## 1. 解决信息传递的安全性 diff --git a/network/netstack-performance.md b/network/netstack-performance.md index b418b1b4..709e7bfa 100644 --- a/network/netstack-performance.md +++ b/network/netstack-performance.md @@ -4,7 +4,7 @@ 调整保守的内核协议栈参数是降低资源消耗、提升网络效率的有效手段之一。 -本节，笔者将介绍内核协议栈中 TCP 握手流程中队列、挥手 TIME_WAIT、Keepalive 保活原理及参数设置。 +本节，我将介绍内核协议栈中 TCP 握手流程中队列、挥手 TIME_WAIT、Keepalive 保活原理及参数设置。 ## 1. TCP 握手流程 @@ -52,7 +52,7 @@ TIME_WAIT 问题在反向代理节点中出现概率较高，例如 client 传 ## 4. 相关配置参考 -笔者部分内核参数配置[^1]，以供读者参考。但注意使用场景不同和机器配置不同，相关的配置起到的作用也不相同，生产环境中的参数配置，得根据实际情况进行调整。 +以下为部分内核参数配置[^1]，以供读者参考。但注意使用场景不同和机器配置不同，配置起到的作用也不相同，生产环境中的参数配置，得根据实际情况进行调整。 ```bash net.ipv4.tcp_tw_reuse = 1 // 是否复用 TIME_WAIT socket