更新 ServiceMesh

ServiceMesh/overview.md

@@ -1,15 +1,21 @@
 # 8.3 服务网格的产品与生态
 
-初代的服务网格理念美好，但以 Sidecar 为核心还是存在不少缺陷：明显的资源消耗、额外的请求转发带来的性能影响，其次功能仅限于数据层面的代理时，当大量部署 Sidecar 后也没有充分考虑如何管理和控制这些 Sidecar。于是，第一代的服务网格产品（Linkerd、Envoy）刚开始被市场接受，第二代服务网格产品就已迫不及待入场。
+初代的服务网格理念美好，但以 Sidecar 为核心还是存在不少缺陷：明显的资源消耗、额外的请求转发带来的性能影响，其次功能仅限于数据层面的代理时，当大量部署 Sidecar 后也没有充分考虑如何管理和控制这些 Sidecar。于是，第一代的服务网格产品（Linkerd、Envoy）刚开始被市场接受，第二代服务网格产品匆忙入局。
 
 ## Istio 入局
 
-2017年5月，Google、IBM、Lyft 宣布新一代的服务网格 Istio 开源，有巨头背书以及**新增控制平面的设计理念**让 Istio 得到极大关注和发展，并迅速成为 ServiceMesh 的代表产品。Istio 最大的创新在于它为 ServiceMesh 带来前所未有的控制力：
+2017年5月，Google、IBM、Lyft 宣布新一代的服务网格 Istio 开源，有巨头背书以及**新增控制平面的设计理念**让 Istio 得到极大关注和发展，并迅速成为第二代服务网格的代表产品。
 
-- 以 Sidercar 方式部署的 ServiceMesh 控制服务间所有的流量
-- Istio 增加控制面板来控制系统中所有的 Sidecar。
+Istio 最大的创新在于它为服务网格带来前所未有的控制力。
 
-以此，Istio 便控制了系统中所有请求的发送，也即控制了所有的流量。
+- 以 Linkerd 代表的第一代服务网格用 Sidercar 方式部署，控制服务间所有的流量
+- 以 Istio 为代表的第二代服务网格增加控制面板，控制系统中所有的 Sidecar。
+
+至此，Istio 便控制了系统中所有请求的发送，也即控制了所有的流量。
+
+Istio 的架构如下图所示，对于一个仅提供服务与服务之间连接通信的基础设施来说，Istio 的架构算不上简单，但其中各个组件的理念得承认的确非常先进和超前。
+
+- Pilot：负责部署在 ServiceMesh 中的 Envoy 实例的生命周期管理。主要职责是负责流量管理和控制，向 Envoy 发送服务发现信息和各种流量管理以及路由规则。Pilot 让运维人员通过 pilot 指定它们希望流量遵循什么规则，而不是哪些特定的 Pod/VM 应该接收什么流量。有了 Pilot 这个组件，就可以轻松实现 A/B 测试以及金丝雀 Canary 测试。
 
 <div  align="center">
 	<img src="../assets/service-mesh-arc.svg" width = "500"  align=center />
@@ -47,9 +53,7 @@ Istio 的数据面支持的特性如下：
 Outbound 特性是指服务请求侧的 Sidecar 提供的功能特性。而 Inbound 特性是指服务提供侧 Sidecar 提供的功能特性。类似遥测、分布式追踪需要两侧的 Sidecar 都提供支持。而另一些特性只要一侧提供支持即可，例如鉴权只需要在服务提供侧支持，重试只需要在请求侧支持。
 :::
 
-对于一个仅提供服务与服务之间连接通信的基础设施来说，Istio 的架构算不上简单，但其中各个组件的理念得承认的确非常先进和超前。
 
-- Pilot：负责部署在 ServiceMesh 中的 Envoy 实例的生命周期管理。主要职责是负责流量管理和控制，向 Envoy 发送服务发现信息和各种流量管理以及路由规则。Pilot 让运维人员通过 pilot 指定它们希望流量遵循什么规则，而不是哪些特定的 Pod/VM 应该接收什么流量。有了 Pilot 这个组件，就可以轻松实现 A/B 测试以及金丝雀 Canary 测试。
 
 ## Linkerd 2.0 
 

architecture/arc.md

@@ -1,8 +1,6 @@
-# 1.6 以解决问题为目的推进架构演进
+# 1.6 传统架构向云原生架构的演进
 
-理解云原生的代表技术之后，这一节，我们继续讨论如何把这些技术融入到到架构设计中，享受技术红利并解决现实问题。
-
-首先，没有完美应对所有变化的架构，技术架构很多时候是依据当时的技术条件来设计的，当制约因素改变的时候，技术架构也要相应变化。所以说好的架构是演进而来的，不是设计出来的，架构演进的目的一定是解决某一类问题，我们不妨从“解决问题”的角度出发，来聊一下云原生架构如何设计，如图 1-38 所示，传统架构向云原生架构的演进。
+好的架构不是设计出来的，是根据业务落地生根长期演化来。架构演进的目的一定是解决某一类问题，我们就从“解决问题”的角度出发，如图 1-38 所示，讨论传统架构向云原生架构的演进。
 
 <div  align="center">
 	<img src="../assets/arc-1.svg" width = "700"  align=center />
@@ -13,9 +11,11 @@
 - 为了解决微服务间 “通讯异常问题”，使用治理框架 + 监控。
 - 为了解决微服务架构下大量应用 “部署问题”，使用容器。
 - 为了解决容器的 “编排和调度问题”，使用 Kubernetes。
-- 为了解决微服务框架的 “侵入性问题”，使用 Service Mesh。
-- 为了让 Service Mesh 有 “更好的底层支撑”，将 Service Mesh 运行在 Kubernetes 上。
+- 为了解决微服务框架的 “侵入性问题”，使用服务网格。
+- 为了让服务网格有 “更好的底层支撑”，将服务网格运行在 Kubernetes 上。
 
 从单个微服务应用的角度看，自身的复杂度降低了，在“强大底层系统”支撑的情况下监控、治理、部署、调度功能齐全，已经符合云原生架构。但站在整个系统的角度看，复杂度并没有减少和消失，要实现“强大底层系统”付出的成本是非常昂贵（很强的架构和运维能力）。
 
-为了解决项目整体复杂度，选择上云托管，将底层系统的复杂度交给云基础设施，让云提供保姆式服务，最终演变为无基础架构设计，通过 YAML 声明式代码、编排底层基础设施、中间件等资源，即应用要什么，云给我什么，企业最终走向开放、标准的“云”技术体系。
+为了解决项目整体复杂度，选择上云托管，将底层系统的复杂度交给云基础设施，让云提供保姆式服务，最终演变为无基础架构设计。
+
+最后，通过 yaml 声明式代码、编排底层基础设施、中间件等资源，即应用要什么，云给我什么，企业最终走向开放、标准的“云”技术体系。