更新服务网格内容

ServiceMesh/MicroService-history.md

@@ -1,22 +1,19 @@
 # 8.2 服务间通信的演化
 
-本节，笔者借用 Phil Calçado 的博客《Pattern: Service Mesh》的内容脉络，并加以我的理解，尝试从服务间通信的本质层面说清楚 Service Mesh 诞生的必然性。本节内容图片来源于 Phil Calçado 的博客，在此统一注明，后面不再单独列出。
+本节，笔者借用 Phil Calçado 的博客《Pattern: Service Mesh》中的内容脉络，并加以我的理解，尝试从服务间通信层面说清楚 Service Mesh 的本质以及诞生的必然性。本节内容图片来源于 Phil Calçado 的博客，在此统一注明，后面不再单独列出。
 
 ## 原始的通信时代
 
-回到远古时代，大约在50年前，初代的开发人员需要在应用层代码里处理各类网络通信的细节问题，比如可靠连接、超时重传、拥塞控制等等。网络的通信逻辑实际上和业务逻辑没有任何关系，却不得不混杂在一起。
+先回到计算机的远古时代。大约在50年前，初代的开发人员如果要编写涉及网络的应用，需要在业务代码里处理各类网络通信的细节问题，例如可靠连接、超时重传、拥塞控制等等。此类的网络通信细节实际和业务逻辑没有任何关系，但不得不混杂在一起。
 
-<div  align="center">
-	<img src="../assets/service-mesh-tcp.png" width = "350"  align=center />
-</div>
-
-为了解决这个问题，TCP/IP 技术出现了，TCP/IP 把通信的流程控制从应用层剥离出来，网络通信变成了基础的、标准的、通用的功能。这个改动大幅降低了应用程序的复杂性，业务逻辑和底层网络通信细节解耦之后，应用程序开发人员才有更多的精力集中在业务逻辑处理上。
+为了避免每个服务都需要自己实现一套相似的网络传输处理逻辑，TCP/IP 协议出现了，它解决了网络传输中通用的流量控制问题，将技术栈下移，从服务的实现中抽离出来，成为操作系统网络层的一部分。
 
 <div  align="center">
-	<img src="../assets/service-mesh-tcp-1.png" width = "350"  align=center />
+	<img src="../assets/service-mesh-tcp.png" width = "100%"  align=center />
 </div>
 
-从 TCP 协议，我们看到基础的、通用的通信逻辑下移，成为一个基础设施层。逻辑解耦、两者透明，这样彻底解放上层应用生产力。
+
+从原始的通信时代，TCP/IP 协议的出现中，我们看到这样的变化：基础的、通用的逻辑开始逐渐下移，成为一个个的基础设施层。业务与非业务的逻辑解耦、两者逐渐透明，应用开发的生产力解放。
 
 ## 第一代微服务
 
@@ -26,15 +23,13 @@ TCP出现之后，机器之间的网络通信不再是一个难题，以 GFS/Big
 	<img src="../assets/service-mesh-2.png" width = "350"  align=center />
 </div>
 
-这个阶段，开发人员要实现业务逻辑之外，还需要根据业务需求来实现一部分所需的通信语义。随着服务规模的扩大，服务寻址逻辑也愈加变的复杂，哪怕是同一种开发语言的另外一个应用，上述的微服务基础能力也要再重新实现一遍。
-
-笔者依稀记得，2011年使用 Python 编写 Zookeeper 调用库解决公司业务数据同步的问题，这期间耗费了大量的时间编写非业务逻辑，保持心跳、监听节点变化、实现负载均衡等。
+这个阶段，开发人员要实现业务逻辑之外，还需要根据业务需求来实现一部分所需的通信语义，随着服务规模的扩大，就算最基础的服务寻址逻辑也愈加变的复杂。其次，哪怕是同一种开发语言的另外一个应用，上述的微服务基础能力也要再重新实现一遍。
 
 此刻，你是否想到了计算机远古时代前辈们处理网络通信的情形。
 
 ## 第二代微服务
 
-为了避免每个服务都需要自己实现一套分布式系统通信的语义功能，随着技术的发展，一些面向微服务架构的开发框架出现了，如 Twitter 的 Finagle、Facebook 的 Proxygen 以及 Spring Cloud 等等。
+为了避免每个服务都需要自己实现一套分布式系统通信的语义功能，一些面向微服务架构的开发框架出现了，如 Twitter 的 Finagle、Facebook 的 Proxygen 以及 Spring Cloud 等等。
 <div  align="center">
 	<img src="../assets/service-mesh-3.png" width = "350"  align=center />
 </div>
@@ -43,77 +38,68 @@ TCP出现之后，机器之间的网络通信不再是一个难题，以 GFS/Big
 
 ## 微服务的痛点显现
 
-Spring Cloud、Dubbo 这类框架以类库的形式存在，但以运行的操作系统进程来看，类库还是渗透进了打包部署之后的业务程序之中，无论这些框架技术如何迭代，实现本质止步于“侵入性”的方式。
+第二代微服务模式看似完美，但开发人员很快又发现，它也存在一些本质问题。
 
-侵入性代表耦合，这一代的微服务框架无论如何迭代，都无法避免与生俱来的诸多痛点。
-
-- **门槛高**：虽然框架本身屏蔽了分布式系统通信的一些通用功能实现细节，但开发者却要花更多精力去掌握和管理复杂的框架本身，在实际应用中，去追踪和解决框架出现的问题也绝非易事。
-
-以 SpringCloud 和 Netflix OSS 为例说明：
-| SpringCloud | Netflix OSS |
-|:--|:--|
-|||
-
-问题来了，你准备花费多少时间让团队熟练使用这些技能？Netflix OSS 在 2019 开始逐步停止维护，问题又来了，你是否会选择切换到 Dubbo 这类框架，如果 Dubbo 也停止维护呢？付出巨大的精力学习，居然要处于这些软件在未来某一段时间取代、消亡的尴尬境地。
+- **门槛高**：虽然框架本身屏蔽了分布式系统通信的一些通用功能实现细节，但开发者却要花更多精力去掌握和管理复杂的框架本身，在实际应用中，去追踪和解决框架出现的问题也绝非易事。以 SpringCloud 为例，它的官网上有满满一页实现各类通信功能的技术组件，你准备花费多少时间让团队熟练使用这些技能？
+<div  align="center">
+	<img src="../assets/SpringCloud.webp" width = "550"  align=center />
+	<p>SpringCloud 全家桶</p>
+</div>
 
 - **无法跨语言**：开发框架通常只支持一种或几种特定的语言，回过头来看文章最开始对微服务的定义，一个重要的特性就是语言无关，但那些没有框架支持的语言编写的服务，很难融入面向微服务的架构体系，想因地制宜的用多种语言实现架构体系中的不同模块也很难做到
 
 - **升级困难**：框架以lib库的形式和服务联编，复杂项目依赖时的库版本兼容问题非常棘手，同时，框架库的升级也无法对服务透明，服务会因为和业务无关的lib库升级而被迫升级；
 
-站在企业组织的角度思考：技术重要还是业务重要？每个人都是分布式专家固然好，但这种情况现实又不可能存在。当一个业务团队或者非技术驱动的企业，员工每天处理大量的非业务逻辑，时不时还解决粗心、技术理解不到位出现的各类非功能 Bug，第二天隔壁的部门又重新上演，这种情况是否合理？
+站在企业组织的角度思考：技术重要还是业务重要？每个人都是分布式专家固然好，但这种情况现实又不可能存在。因此，你会看到业务团队或者非技术驱动的企业，员工每天处理大量的非业务逻辑，不同的部门反反复复上演同样的问题。
 
+## 思考服务间通信的本质
 
-## 理解服务间通信的本质
+微服务架构中，**那些需要解决的诸如：服务注册、服务发现、负载均衡、弹性等等问题，本质是实现请求的可靠传递**。在整个服务间通信的处理流程上，无论上述功能如何复杂，请求本身的业务语义与业务内容不会发生任何变化。微服务架构的技术挑战和业务应用或者服务本身也没有任何关系。
 
-
-微服务架构中，一次请求往往经历多个服务节点，从这个角度看，服务间的通信是多个节点访问多个节点的关系。
-
-在处理分布式微服务架构中“多个节点”的通信上，**那些需要解决的诸如：服务注册、服务发现、负载均衡、弹性等等，本质是解决请求的可靠传递**。在整个服务间通信的处理流程上，无论上述功能如何复杂，请求本身的业务语义与业务内容不会发生任何变化。分布式的技术挑战和业务应用，或者服务本身有关系么？没有任何关系。这些都属于服务通信的范畴，和应用本身的实现逻辑没有任何关系。
-
-此外，以上还具有高度的普适性，只要是微服务架构，那这些问题适用于所有的语言框架、组织。
-
-回顾开篇提到的 TCP 案例，你是否发现似曾相识？是否服务间的通信也能像TCP 协议栈那样，人们基于 HTTP 协议开发复杂的应用，无需关心底层 TCP 如何控制包。
-
-借鉴当年 TCP/IP ，对于服务间通信，除了传统的侵入式框架，又有了一个新的思路：既然能把网络功能剥离并下沉到 TCP，那么服务间通信是否也能剥离，下沉到微服务基础层。如此，工程师不再浪费时间编写服务基础设施代码或者管理系统用到的软件库和框架，而是聚焦在业务逻辑处理上。
+回顾开篇提到的 TCP/IP 案例，我们思考是否服务间的通信也能像 TCP 协议栈那样，人们基于 HTTP 协议开发复杂的应用，无需关心底层 TCP 如何控制包。如果能把服务间通信剥离并下沉到微服务基础层，工程师也将不再浪费时间编写服务基础设施代码或者管理系统用到的软件库和框架，而是聚焦在业务逻辑处理上。
 
 <div  align="center">
 	<img src="../assets/service-mesh-4.png" width = "350"  align=center />
 </div>
 
-
 ## Proxy 模式的探索
 
-## 第一代 ServiceMesh 
+## 第一代服务网格
+
+因此以 Linkerd、Envoy、NginxMesh 为代表的代理模式（边车模式）应运而生，这就是第一代服务网格，它将分布式服务的通信抽象为单独一层，在这一层中实现负载均衡、服务发现、认证授权、监控追踪、流量控制等分布式系统所需要的功能。为一个和服务对等的代理服务（sidecar）和服务部署在一起，接管服务的流量。
 
-因此以 Linkerd、Envoy、NginxMesh 为代表的代理模式（边车模式）应运而生，这就是第一代服务网格，它将分布式服务的通信抽象为单独一层，在这一层中实现负载均衡、服务发现、认证授权、监控追踪、流量控制等分布式系统所需要的功能，作为一个和服务对等的代理服务，和服务部署在一起，接管服务的流量，通过代理之间的通信间接完成服务之间的通信请求，这样传统侵入式的三个问题也迎刃而解。
+第一代的服务网格通过代理的方式间接完成服务之间的通信治理，这样传统侵入式的三个问题也迎刃而解。
 
+<div  align="center">
+	<img src="../assets/servicemesh-sidecar.png" width = "350"  align=center />
+</div>
 
-## 第二代 ServiceMesh
+## 第二代服务网格
 
-第一代服务网格由一系列独立运行的单机代理服务构成，为了提供统一的上层运维入口，演化出了集中式的控制面板，所有的单机代理组件通过和控制面板交互进行网络拓扑策略的更新和单机数据的汇报。这就是 以Istio 为代表的第二代服务网格。
+第一代服务网格由一系列独立运行的单机代理服务构成，为了提供统一的上层运维入口，演化出了集中式的控制面板，所有的单机代理组件通过和控制面板交互进行网络拓扑策略的更新和单机数据的汇报。这就是以 Istio 为代表的第二代服务网格。
 
 <div  align="center">
 	<img src="../assets/6-b.png" width = "350"  align=center />
 </div>
 
-只看单机代理组件(数据面板)和控制面板的Service Mesh全局部署视图如下：
+只看单机代理组件(数据面板)和控制面板的服务网格全局部署视图如下：
 
 <div  align="center">
 	<img src="../assets/mesh3.png" width = "350"  align=center />
 </div>
 
-至此，见证了6个时代的变迁，大家一定清楚了 Service Mesh 技术到底是什么，以及是如何一步步演化到今天这样一个形态。
+至此，见证了6个时代的变迁，大家一定清楚了服务网格技术到底是什么，以及是如何一步步演化到今天这样一个形态。
 
 现在，我们回过头重新看 William Morgan 对服务网格的定义：
 
-:::tip 服务网格（ServiceMesh）
+:::tip 服务网格的定义
 
-服务网格是一个**基础设施层**，用于处理服务间通信。云原生应用有着复杂的服务拓扑，服务网格保证**请求在这些拓扑中可靠地穿梭**。在实际应用当中，服务网格通常是由一系列轻量级的**网络代理**组成的，它们与应用程序部署在一起，但**对应用程序透明**。
+服务网格（ServiceMesh）是一个**基础设施层**，用于处理服务间通信。云原生应用有着复杂的服务拓扑，服务网格保证**请求在这些拓扑中可靠地穿梭**。在实际应用当中，服务网格通常是由一系列轻量级的**网络代理**组成的，它们与应用程序部署在一起，但**对应用程序透明**。
 
 :::
 
 再来理解定义中的4个关键词：
 
-- **基础设施层+请求在这些拓扑中可靠穿梭**：这两个词加起来描述了 Service Mesh 的定位和功能，是否似曾相识？没错，你一定想到了TCP。
-- **网络代理**：描述了 Service Mesh 的实现形态。
-- **对应用透明**：描述了 Service Mesh 的关键特点，正是由于这个特点，Service Mesh 能够解决以 Spring Cloud 为代表的第二代微服务框架所面临的三个本质问题。
+- **基础设施层+请求在这些拓扑中可靠穿梭**：这两个词加起来描述了服务网格的定位和功能，是否似曾相识？没错，你一定想到了 TCP。
+- **网络代理**：描述了服务网格的实现形态。
+- **对应用透明**：描述了服务网格的关键特点，正是由于这个特点，服务网格能够解决以 Spring Cloud 为代表的第二代微服务框架所面临的三个本质问题。

intro.md

@@ -69,9 +69,9 @@
 
 本书主要针对软件工程师、软件架构师以及技术负责人等，特别是那些需要对系统架构做权衡的人，譬如需要选择一些工具去解决某个领域的特定问题。退一步，如果你不需要做这些决定，本书也可以帮助你更好地理解这些技术的优缺点。
 
-阅读本书，最好了解一些请求/响应型（Web）系统原理，有一些后端开发经验，熟悉一些常见的网络协议（譬如 TCP、HTTP ），这将会对阅读有很大帮助，至于你熟悉何种编程语言倒没有太大关系。
+阅读本书，最好了解一些请求/响应型（Web）系统原理，熟悉一些常见的网络协议（譬如 TCP、HTTP 等）。如再有一些后端开发经验，这将会对阅读有很大帮助，至于你熟悉何种编程语言倒没有太大关系。
 
-若以下条件适用你，可能会从本书收益：
+总体上讲，若以下条件适用你，可能会从本书收益：
 
 - 对系统如何运行有着天然的兴趣和探索精神