更新 ServiceMesh

isno · Feb 17, 2024 · a8542ae · a8542ae
1 parent acd918e
commit a8542ae
Show file tree

Hide file tree

Showing 7 changed files with 24 additions and 21 deletions.
diff --git a/.vuepress/config.js b/.vuepress/config.js
@@ -279,7 +279,7 @@ export default defineUserConfig({
                 ]
             },
             {
-                text: '第八章：服务治理变革 ServiceMesh',
+                text: '第八章：后微服务时代',
                 collapsable: false,
                 sidebarDepth: 1,
                 link: '/ServiceMesh/summary.md',

diff --git a/ServiceMesh/MicroService-history.md b/ServiceMesh/MicroService-history.md
@@ -1,4 +1,4 @@
-# 8.2 服务治理形式的演进
+# 8.2 演化出 ServiceMesh 的驱动力
 
 TCP 协议之后分布式系统诞生，分布式系统催生出微服务，服务间的通信需求又催生出 ServiceMesh。理解服务间通信的本质之后，就会得到一个感性的结论 Service Mesh 是微服务时代的 TCP/IP 协议。
 

diff --git a/ServiceMesh/The-future-of-ServiceMesh.md b/ServiceMesh/The-future-of-ServiceMesh.md
@@ -1,4 +1,4 @@
-# 8.4 服务网格的未来
+# 8.4 ServiceMesh 的未来
 
 基于 Istio 的 ServiceMesh 架构在互联网公司进行大规模线上部署的时候逐渐遇到以下问题：
 
@@ -26,7 +26,7 @@ ServiceMesh 中所有的流量出入都要经过 Sidecar。Sidecar 的加入增
 - iptables 的规则匹配是线性的，匹配的时间复杂度是 O(N)，当规则较多时候，性能会严重下滑。
 - 每个请求的处理都要经过内核态到用户态再到内核态的过程。当网络中有大量数据包到达内核时，会产生频繁的硬件中断、上下文切换以及数据在内核态和用户态来回拷贝的性能损耗。
 
-针对以上的两点性能瓶颈，Linux社区以及 Envoy 社区通过以下方式进行优化：
+针对以上的两点性能瓶颈，Linux 社区以及 Envoy 社区通过以下方式进行优化：
 
 Linux 社区发布了 bpfilter，这是一个使用 Linux BPF 提供的高性能网络过滤内核模块，计划用来替换 netfilter 作为 iptables 的内核底层实现，实现 Linux 网络包过滤框架从 netfilter 向 BPF 过渡的演进。
 
@@ -37,7 +37,6 @@ Linux 社区发布了 bpfilter，这是一个使用 Linux BPF 提供的高性能
 ## QUIC
 
 
-
 ## 高效通信
 
 ## xDS 全量下发的问题

diff --git a/ServiceMesh/What-is-ServiceMesh.md b/ServiceMesh/What-is-ServiceMesh.md
@@ -1,6 +1,6 @@
 # 8.1 什么是 ServiceMesh
 
-2016年，离开 Twiiter 的工程师 William Morgan 和 Oliver Gould 组建了一个小型的技术公司 Buoyant，不久之后 Buoyant 在 github 上发布了它们的创业项目 Linkerd，业界第一款 ServiceMesh 项目诞生。
+2016年，离开 Twiiter 的工程师 William Morgan 和 Oliver Gould 组建了一个小型的技术公司 Buoyant，不久之后他们在 Github 上发布了创业项目 Linkerd，业界第一款 ServiceMesh（服务网格）项目诞生。
 
 那么，什么是 ServiceMesh？ServiceMesh 最早出自于 William Morgan 的博文《What’s a service mesh？And why do I need one?》，作为 ServiceMesh 的创造者和布道师，引用 William Morgan 的定义自然是最官方和最权威的。
 

diff --git a/ServiceMesh/overview.md b/ServiceMesh/overview.md
@@ -1,4 +1,4 @@
-# 8.3 服务网格的产品与生态
+# 8.3 ServiceMesh 的产品与生态
 
 2016年1月，Buoyant 公司发布了第一代 ServiceMesh 产品 Linkerd。初次发布的 Linkerd 以 Scala 编写，绝大部分关注点都是如何做好 proxy（代理） 并完成一些通用控制面的功能。同期专注于 proxy 领域的还有一个重量级选手 Envoy，Envoy 由 Lyft 公司基于 C++ 开发，特点为性能出色、功能丰富、生态成熟，是 CNCF 内继 Kubernetes、Prometheus 第三个孵化成熟的项目。
 

diff --git a/ServiceMesh/summary.md b/ServiceMesh/summary.md
@@ -1,5 +1,13 @@
-# 第九章：ServiceMesh
+# 第九章：后微服务时代
 
-在过去几年，微服务技术迅速普及，和容器技术一起成为最吸引眼球的热点技术之一。微服务虽好但也存在明显弊端，人们也一直在寻找治理分布式系统中的理想方案。虽然近几年一批又一批技术框架不断涌现，但微服务治理的技术理念却止步于 Dubbo、SpringCloud 为代表的传统侵入性方案。直到 2017年底，当非侵入性的 ServiceMesh 技术从萌芽走向成熟，当 Istio 横空出世，人们才惊觉：原来微服务并非只有侵入性一种玩法。
+承载我们应用工作负载的形式已经从”物理机“过渡到”容器“，容器意味着创建（包括初始化）和销毁高度自动化，具备极强弹性。此时，基础设施的功能（服务发现、负载均衡、熔断限流、路由等）与业务代码的集成需要在低成本前提下保证相同的生命周期。物理机时代，基础设施功能添加到业务代码的最佳方式无疑是 SDK，而容器时代，基础设施的功能添加到业务代码的最佳方式变成了 Sidecar。Sidecar 模式解耦了基础设施和核心业务。
 
-Kubernetes 的崛起标志着微服务时代的新篇章，通过基础设施层解决分布式架构问题，实现了业务与非功能性终极解耦，微服务服务治理开启了全新的进化。2018年，Bilgin lbryam 在 InfoQ 发了一篇名为 《MicroService in a Post-Kubernetes Era 》的文章，文章虽然没有明确“ 后 Kubernetes 时代的微服务” 是什么，但从文章也能看出作者的观点是：在后 Kubernetes 时代，服务网格技术已经完全取代了通过使用软件库来实现网络运维的方式。
+Kubernetes 的崛起标志着微服务时代的新篇章，通过基础设施层解决分布式架构问题，微服务服务治理也开启了全新的进化，并衍生服务间通信的基础设施层 ServiceMesh。当非侵入性的 ServiceMesh 技术从萌芽走向成熟，当 Istio 横空出世，人们才惊觉：原来微服务也并非只有侵入性一种“玩法”。
+
+2018年，Bilgin lbryam 在 InfoQ 发了一篇名为 《MicroService in a Post-Kubernetes Era 》的文章，文章虽然没有明确“ 后 Kubernetes 时代的微服务” 是什么，但从文章也能看出作者的观点是：在后 Kubernetes 时代，服务网格技术已经完全取代了通过使用软件库来实现网络运维的方式。
+
+:::tip 后微服务时代
+
+从软件层面独力应对微服务架构问题，发展到软、硬一体，合力应对架构问题的时代，此即为“后微服务时代”。
+
+:::
diff --git a/intro.md b/intro.md
@@ -1,13 +1,10 @@
 # 前言
 
-既然翻开这本书，我猜测你大概率是个互联网从业者，我还能猜出这几年你大概率被层出不穷的概念、技术、方法论折磨过：SOA、SRE、容器、容器编排、ServiceMesh、Serverless、可观测、大数据，当然不能遗漏了各种 Ops，DevOps、GitOps、AIOps、MLOps...
+既然翻开这本书，我猜测你大概率是个互联网从业者，我还能猜出这几年你大概率被这些层出不穷的概念包围：SOA、SRE、容器、容器编排、ServiceMesh、Serverless、可观测、大数据，当然不能遗漏了各种 Ops，DevOps、GitOps、AIOps、MLOps...
 
-或者你完全不关心这些抽象的概念，什么云计算、什么云原生，不听不听，统统王八念经。那就再更具体一点，你是否权衡过 Dubbo 和 SpringCloud 选型，那我要武断下个结论，无论是核算技术成本还是人力成本，怎么着都预示 ServiceMesh 的理念将是微服务治理的未来主流。不过没有结束，不能缺席多运行时架构。
+这些概念全部围绕着构建大规模分布式架构的几个核心要素：稳定（不出任何问题）、效率（快速响应市场需求）、成本（充分有效的利用资源）。
 
-我得解释：列举上面案例并不是要追随潮流。再先进的技术方案也有利有弊，但这些技术背后的组织/公司可不会告诉你它们的劣势或者缺陷，软件行业乱象丛生，更有“xx已死”
-“回归单体”、“下云”各类标题党的推波助澜，引导你到错误的方向，做出错误的判断，付出巨大的精力学习之后，再无端承受这些软件在未来某一段时间取代、消亡的尴尬境地。也难怪，后浪推前浪，老程序员们被拍死在沙滩上。
-
-言归正传，让我们暂且放下技术，透过表象发散思维，从宏观再宏观的角度思考驱使技术演进的核心动力是什么!
+分析这些激动人心的技术变革之前，暂且放下技术，透过表象发散思维，从宏观的角度思考驱使技术演进的驱动力是什么!
 
 ## 软件在吞噬世界
 
@@ -23,7 +20,7 @@
 
 文中列出了被重塑的产业，具体有：最大的书店 Amazon、最多人订阅的 Video service Netflix、最大的音乐公司 iTunes、Spotify and Pandora 等、成长最快的娱乐领域 videogame、最好的电影制片厂 Pixar、最大的行销平台 Google、Groupon、Facebook 等、成长最快的电信公司 Skype 、成长最快招聘公司 LinkedIn。
 
-文章发表于 2011 年，2023 年再来回顾，互联网冲击已经无所不在，感触更加深刻。互联网已经成为国民经济的高速公路，部分软件成为像水、电、媒一样的基础设施。
+文章发表于 2011 年，2023 年再来回顾，互联网冲击已经无所不在，感触更加深刻。互联网俨然已成为国民经济的高速公路，部分软件成为像水、电、媒一样的基础设施。
 
 ## 移动互联网在加剧变化
 
@@ -36,15 +33,14 @@
 - 技术的形态持续在演进
 
 
-## 思考架构迭代的本质
 
 ## 沉淀底层的原理和方法论
 
-不管技术发展如何日新月异，其根本性变化并没有那么快，很多“老”技术、“老”方法在过去多年一直很有效，预计未来相当长时间仍然会保持有效。举个例子，你看 Kubernetes 的网络方案，Cilium、Calico、Flannel、weave 表面五花八门，但它们的基本技术和底层原理总结下来基本没什么变化，只是把这些不同的计算机基本原理、方法重新组合起来，换种形式去解决因为业务变化带来的新问题。
+笔者也未曾花费精力去介绍某一种技术的 feature，看官方的手册比任何资料都详细、权威。所以，本书的宗旨是希望能说清楚这些问题的本质，解释清楚整个服务架构的发展历程, 走过了哪些弯路，以至于今天使用了哪些技术的缘由，讨论它们背后遵循的不变的原则、知晓这些技术做的取舍、探索它们的设计选择。
+
 
-真正有长久生命力并能做到历久弥新的技术是少数，如果尝试理清它们脉络，总能找到若干贯穿其中的一些颠扑不破的底层原理、方法论，比如分布式系统演进方向是 CAP 定理的权衡选择，局限于时间与空间的法则。
+不管技术发展如何日新月异，其根本性变化并没有那么快，如果尝试理清它们脉络，总能找到若干贯穿其中的一些颠扑不破的底层原理、方法论，比如分布式系统演进方向是 CAP 定理的权衡选择，局限于时间与空间的法则。举个例子，Kubernetes 的网络方案，Cilium、Calico、Flannel、weave 表面五花八门，但它们的基本技术和底层原理总结下来基本没什么变化，只是把这些不同的计算机基本原理、方法重新组合起来，换种形式去解决因为业务变化带来的新问题。
 
-笔者也未曾花费精力去介绍某一种技术的 feature，看官方的手册比任何资料都详细、权威。所以，本书的宗旨是希望能说清楚这些问题的本质，解释清楚整个服务架构的发展历程, 走过了哪些弯路，以至于今天使用了哪些技术的缘由，讨论它们背后遵循的不变的原则、知晓这些技术做的取舍、探索它们的设计选择。
 
 善于思考总结的人总会从历史的进程中得到相关的规律，所以，**过时的不是基础的技术原理和方法，而是人的思考能力以及没有跟上节奏的对技术的认知**。面对层出不穷的技术、唯有掌握底层的核心原理时，方能肚子里有货，从容不迫。