更新 ServiceMesh

ServiceMesh/MicroService-history.md

@@ -1,6 +1,5 @@
 # 8.2 服务间通信的演化
 
-TCP 协议之后分布式系统诞生，分布式系统催生出微服务，服务间的通信需求又催生出 ServiceMesh。理解服务间通信的本质之后，就会得到一个感性的结论 Service Mesh 是微服务时代的 TCP/IP 协议。
 
 本节，笔者借用 Phil Calçado 的博客《Pattern: Service Mesh》的内容脉络，并加以我的理解，讨论 TCP 协议、分布式系统、服务间通信的因果关系，尝试说清楚 Service Mesh 诞生的必然性。本节内容图片来源于 Phil Calçado 的博客，在此统一注明，后面不再单独列出。
 
@@ -87,12 +86,12 @@ Spring Cloud、Dubbo 这类框架以类库的形式存在，但以运行的操
 
 ## 第一代 ServiceMesh 
 
-因此以 Linkerd、Envoy、NginxMesh 为代表的代理模式（边车模式）应运而生，这就是第一代 Service Mesh，它将分布式服务的通信抽象为单独一层，在这一层中实现负载均衡、服务发现、认证授权、监控追踪、流量控制等分布式系统所需要的功能，作为一个和服务对等的代理服务，和服务部署在一起，接管服务的流量，通过代理之间的通信间接完成服务之间的通信请求，这样传统侵入式的三个问题也迎刃而解。
+因此以 Linkerd、Envoy、NginxMesh 为代表的代理模式（边车模式）应运而生，这就是第一代服务网格，它将分布式服务的通信抽象为单独一层，在这一层中实现负载均衡、服务发现、认证授权、监控追踪、流量控制等分布式系统所需要的功能，作为一个和服务对等的代理服务，和服务部署在一起，接管服务的流量，通过代理之间的通信间接完成服务之间的通信请求，这样传统侵入式的三个问题也迎刃而解。
 
 
 ## 第二代 ServiceMesh
 
-第一代Service Mesh由一系列独立运行的单机代理服务构成，为了提供统一的上层运维入口，演化出了集中式的控制面板，所有的单机代理组件通过和控制面板交互进行网络拓扑策略的更新和单机数据的汇报。这就是以Istio为代表的第二代 Service Mesh。
+第一代服务网格由一系列独立运行的单机代理服务构成，为了提供统一的上层运维入口，演化出了集中式的控制面板，所有的单机代理组件通过和控制面板交互进行网络拓扑策略的更新和单机数据的汇报。这就是 以Istio 为代表的第二代服务网格。
 
 <div  align="center">
 	<img src="../assets/6-b.png" width = "350"  align=center />
@@ -106,9 +105,9 @@ Spring Cloud、Dubbo 这类框架以类库的形式存在，但以运行的操
 
 至此，见证了6个时代的变迁，大家一定清楚了 Service Mesh 技术到底是什么，以及是如何一步步演化到今天这样一个形态。
 
-现在，我们回过头重新看 William Morgan 对 Service Mesh 的定义：
+现在，我们回过头重新看 William Morgan 对服务网格的定义：
 
-:::tip ServiceMesh
+:::tip 服务网格（ServiceMesh）
 
 服务网格是一个**基础设施层**，用于处理服务间通信。云原生应用有着复杂的服务拓扑，服务网格保证**请求在这些拓扑中可靠地穿梭**。在实际应用当中，服务网格通常是由一系列轻量级的**网络代理**组成的，它们与应用程序部署在一起，但**对应用程序透明**。
 
@@ -118,4 +117,4 @@ Spring Cloud、Dubbo 这类框架以类库的形式存在，但以运行的操
 
 - **基础设施层+请求在这些拓扑中可靠穿梭**：这两个词加起来描述了 Service Mesh 的定位和功能，是否似曾相识？没错，你一定想到了TCP。
 - **网络代理**：描述了 Service Mesh 的实现形态。
-- **对应用透明**：描述了 Service Mesh 的关键特点，正是由于这个特点，Service Mesh 能够解决以 Spring Cloud 为代表的第二代微服务框架所面临的三个本质问题。
+- **对应用透明**：描述了 Service Mesh 的关键特点，正是由于这个特点，Service Mesh 能够解决以 Spring Cloud 为代表的第二代微服务框架所面临的三个本质问题。

ServiceMesh/What-is-ServiceMesh.md

@@ -1,18 +1,20 @@
 # 8.1 什么是服务网格
 
-2016年，离开 Twiiter 的工程师 William Morgan 和 Oliver Gould 组建了一个小型的技术公司 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 的定义自然是最官方和最权威的。
 
-:::tip William Morgan 对 ServiceMesh 的定义
+那么，什么是服务网格？服务网格的概念最早出自于 William Morgan 的博文《What’s a service mesh？And why do I need one?》，William Morgan作为服务网格的创造者和布道师，引用他的定义自然是最官方和最权威的。
+
+:::tip William Morgan 对服务网格的定义
 
 “A service mesh is a dedicated infrastructure layer for handling service-to-service communication. It’s responsible for the reliable delivery of requests through the complex topology of services that comprise a modern, cloud native application. In practice, the service mesh is typically implemented as an array of lightweight network proxies that are deployed alongside application code, without the application needing to be aware.”
 
-Service Mesh 是一个处理服务通讯的专门的基础设施层。它的职责是在由云原生应用组成服务的复杂拓扑结构下进行可靠的请求传送。在实践中，它是一组和应用服务部署在一起的轻量级的网络代理，对应用服务透明。
+服务网格是一个处理服务通讯的专门的基础设施层。它的职责是在由云原生应用组成服务的复杂拓扑结构下进行可靠的请求传送。在实践中，它是一组和应用服务部署在一起的轻量级的网络代理，对应用服务透明。
 
 :::
 
-Service Mesh 目的是解决系统架构微服务化后的服务间通信和治理问题。Service Mesh 由 Sidecar 节点组成，这个模式的精髓在于实现了数据面（业务逻辑）和控制面的解耦。
+从 Micro-Services 到 Service Mesh 承前启后和顺其自然，光看名字就能很形象地理解它所做的事情：把微服务的各个 Service（服务）节点，用一张 mesh（网格）连接起来。就这样，原本被拆散得七零八落的微服务们，又被 Service Mesh 这张大网紧密得连接到了一起，即使依然天各一方（进程间隔离），但也找回了当年一起挤在单体应用内抱团撒欢的亲密感（通信更容易）。
+
 
 服务之间通过 Sidecar 发现和调用目标服务，从而在服务之间形成一种网络状依赖关系，如果我们把节点和业务逻辑从视图剥离，就会出现一种网络状的架构，如图 1-23 所示，服务网格由此得名。
 
@@ -21,12 +23,13 @@ Service Mesh 目的是解决系统架构微服务化后的服务间通信和治
 	<p>图1-23 服务网格形象示例</p>
 </div>
 
-从 Micro-Services 到 Service Mesh 承前启后和顺其自然，光看名字就能很形象地理解它所做的事情：把微服务的各个 Service（服务）节点，用一张 mesh（网格）连接起来。就这样，原本被拆散得七零八落的微服务们，又被 Service Mesh 这张大网紧密得连接到了一起，即使依然天各一方（进程间隔离），但也找回了当年一起挤在单体应用内抱团撒欢的亲密感（通信更容易）。
-
-最后，概览以下里程碑事件，我们感受 ServiceMesh 从无到有、被社区接受、巨头入局、众人皆捧的历程。
+感受服务网格从无到有、被社区接受、巨头入局、众人皆捧的历程。
 
 - 2016年9 月，在 SF MicroServices 大会上，“ServiceMesh” 这个术语第一次在公开场合使用，这标志着 ServiceMesh 逐渐从 Buoyant 公司走向社区，并开始被广泛接受以及推崇。
 - 2017年1月，Linkerd 加入 CNCF，项目类型被归类到 CNCF 新开辟的 “ServiceMesh” 分类。这代表着 ServiceMesh 理念被 CNCF 社区认同。
 - 2017年4月，Linkerd 发布 1.0 版本。Linkerd 实现了最重要的里程碑：被客户接受并在生产线上被大规模应用，ServiceMesh 从理念走向生产实践。
 - 2017年5月，Google、IBM、Lyft 联合发布 Istio 0.1 版本，以 Istio 为代表的第二代 ServiceMesh 产品开始登场。
-- 2018年7月，CNCF 社区发布的云原生定义中，将服务网格和微服务、容器、不可变基础设施等技术并列。这标志着服务网格已经超越了其原初的角色 —— 仅作为一种实现微服务的新方法，现在已经发展为云原生的又一个关键领域，被放在前所未有的高度。
+- 2018年7月，CNCF 社区发布的云原生定义中，将服务网格和微服务、容器、不可变基础设施等技术并列。这标志着服务网格已经超越了其原初的角色 —— 仅作为一种实现微服务的新方法，现在已经发展为云原生的又一个关键领域，被放在前所未有的高度。
+
+
+