更新微服务

ServiceMesh/MicroService-history.md

@@ -4,7 +4,7 @@
 
 ## 原始的通信时代
 
-先回到计算机的远古时代。大约在50年前，初代的开发人员如果要编写涉及网络的应用，需要在业务代码里处理各类网络通信的细节问题，例如可靠连接、超时重传、拥塞控制等等。此类的网络通信细节实际和业务逻辑没有任何关系，但不得不混杂在一起。
+先回到计算机的远古时代。大约在50年前，初代的开发人员如果要编写涉及网络的应用，需要在业务代码里处理各类网络通信的细节问题，例如可靠连接、超时重传以及拥塞控制等。此类的网络通信细节实际和业务逻辑没有任何关系，但不得不混杂在一起。
 
 为了避免每个服务都需要自己实现一套相似的网络传输处理逻辑，TCP/IP 协议出现了，它解决了网络传输中通用的流量控制问题，将技术栈下移，从服务的实现中抽离出来，成为操作系统网络层的一部分。
 
@@ -17,7 +17,7 @@
 
 ## 第一代微服务
 
-TCP出现之后，机器之间的网络通信不再是一个难题，以 GFS/BigTable/MapReduce 为代表的分布式系统得以蓬勃发展。此时，分布式系统特有的通信语义又出现了，例如熔断策略、负载均衡、服务发现、认证和授权、quota限制、链路追踪和监控等等。
+TCP出现之后，机器之间的网络通信不再是一个难题，以 GFS/BigTable/MapReduce 为代表的分布式系统得以蓬勃发展。此时，分布式系统特有的通信语义又出现了，例如熔断策略、负载均衡、服务发现、认证和授权、灰度发布、蓝绿部署以及版本控制等等。
 
 <div  align="center">
 	<img src="../assets/service-mesh-2.png" width = "350"  align=center />
@@ -54,19 +54,21 @@ TCP出现之后，机器之间的网络通信不再是一个难题，以 GFS/Big
 
 ## 思考服务间通信的本质
 
-微服务架构中，**那些需要解决的诸如：服务注册、服务发现、负载均衡、弹性等等问题，本质是实现请求的可靠传递**。在整个服务间通信的处理流程上，无论上述功能如何复杂，请求本身的业务语义与业务内容不会发生任何变化。微服务架构的技术挑战和业务应用或者服务本身也没有任何关系。
+微服务架构中，**那些需要解决的诸如：服务注册、服务发现、负载均衡、弹性等等问题，本质是实现请求的可靠传递**。在整个服务间通信的处理流程上，**无论上述功能如何复杂，请求本身的业务语义与业务内容不会发生任何变化**。微服务架构的技术挑战和业务应用或者服务本身也没有任何关系。
 
 回顾开篇提到的 TCP/IP 案例，我们思考是否服务间的通信也能像 TCP 协议栈那样，人们基于 HTTP 协议开发复杂的应用，无需关心底层 TCP 如何控制包。如果能把服务间通信剥离并下沉到微服务基础层，工程师也将不再浪费时间编写服务基础设施代码或者管理系统用到的软件库和框架，而是聚焦在业务逻辑处理上。
 
 <div  align="center">
 	<img src="../assets/service-mesh-4.png" width = "350"  align=center />
 </div>
 
-## Proxy 模式的探索
-
 ## 第一代服务网格
 
-因此以 Linkerd、Envoy、NginxMesh 为代表的代理模式（边车模式）应运而生，这就是第一代服务网格，它将分布式服务的通信抽象为单独一层，在这一层中实现负载均衡、服务发现、认证授权、监控追踪、流量控制等分布式系统所需要的功能。为一个和服务对等的代理服务（Sidecar）和服务部署在一起，接管服务的流量。
+最开始，先驱者尝试过使用代理的方案，常见的 Nginx、Haproxy、Apache 等代理。这种方式和微服务关系不大，功能也简陋，例如 Nginx，配置上游、负载均衡还得手动更新。但是它们提供了一个思路：在服务器端和客户端之间插入了一个东西完成功能，避免两者直接通讯。
+
+因此以 Linkerd、Envoy、NginxMesh 为代表的代理模式（Sidecar）应运而生。Sidecar 扮演的角色和代理很像，但功能齐全，完全对照微服务框架的功能开发。
+
+第一代服务网格将分布式服务的通信抽象为单独一层，在这一层中实现负载均衡、服务发现、认证授权、监控追踪、流量控制等分布式系统所需要的功能。为一个和服务对等的代理服务（Sidecar）和服务部署在一起，接管服务的流量。
 
 <div  align="center">
 	<img src="../assets/servicemesh-sidecar.png" width = "350"  align=center />
@@ -76,9 +78,7 @@ TCP出现之后，机器之间的网络通信不再是一个难题，以 GFS/Big
 
 ## 第二代服务网格
 
-第一代服务网格由一系列独立运行的单机代理服务构成，但并没有思考如何管理这些代理服务。
-
-为了提供统一的上层运维入口，演化出了集中式的控制面板，所有的单机代理组件通过和控制面板交互进行网络拓扑策略的更新和单机数据的汇报。这就是以 Istio 为代表的第二代服务网格。
+第一代服务网格由一系列独立运行的单机代理服务构成，但并没有思考如何管理这些代理服务。为了提供统一的上层运维入口，服务网格继续演化出了集中式的控制面板，所有的单机代理组件通过和控制面板交互进行网络拓扑策略的更新和单机数据的汇报。这就是以 Istio 为代表的第二代服务网格。
 
 <div  align="center">
 	<img src="../assets/6-b.png" width = "350"  align=center />
@@ -90,7 +90,7 @@ TCP出现之后，机器之间的网络通信不再是一个难题，以 GFS/Big
 	<img src="../assets/mesh3.png" width = "350"  align=center />
 </div>
 
-至此，见证了6个时代的变迁，大家一定清楚了服务网格技术到底是什么，以及是如何一步步演化到今天这样一个形态。
+至此，见证了五个时代的变迁，大家一定清楚了服务网格技术到底是什么，以及是如何一步步演化到今天这样一个形态。
 
 现在，我们回过头重新看 William Morgan 对服务网格的定义：
 

container/linux-vnet.md

@@ -104,7 +104,6 @@ Linux Bridge 是 Linux Kernel 2.2 版本开始提供的二层转发工具，与
     <p>图 2-24 conntrack 示例</p>
 </div>
 
-
 ## 网络 - VXLAN
 
 有了各类虚拟设备之后，下一步就是要使用这些设备组成网络。传统的物理拓扑结构相对固定，很难支持云原生时代下逻辑拓扑结构频繁变动的需求，例如灾难恢复、业务迁移等敏捷需求，跨集群甚至跨多个计算中心的可迁移性。SDN（Software Definded Network，软件定义网络）在云计算和分布式时代下应运而生。
@@ -134,5 +133,4 @@ VXLAN 你可能没有听说过，但 VLAN（Virtual Local Area Network，虚拟
 	<p>图 2-28 VXLAN 通信概览</p>
 </div>
 
-VXLAN 对网络基础设施的要求很低，不需要专门的硬件只要三层可达的网络就可以部署 VXLAN。从 Linux Kernel 3.2 起，一台 Linux 主机经过简单配置之后，就可以把 Linux Bridge 作为 VETP 设备使用。VXLAN 带来了很高的灵活性、扩展性和可管理性，已经成为当前构建数据中心的主流技术，绝大多数的公有云（阿里云、华为云、AWS等）的 VPC 都是用 VXLAN 来作为数据转发层面。
-
+VXLAN 对网络基础设施的要求很低，不需要专门的硬件只要三层可达的网络就可以部署 VXLAN。从 Linux Kernel 3.2 起，一台 Linux 主机经过简单配置之后，就可以把 Linux Bridge 作为 VETP 设备使用。VXLAN 带来了很高的灵活性、扩展性和可管理性，已经成为当前构建数据中心的主流技术，绝大多数的公有云（阿里云、华为云、AWS等）的 VPC 都是用 VXLAN 来作为数据转发层面。