8.1 Service Mesh 概述
新兴的下一代微服务架构，被称为下一代微服务，同时也是云原生技术栈的代表技术之一。
8.1.1 Service Mesh的由来
从2016年到2018年，service mesh经历了从无到有的过程
8.1.2 Service Mesh的定义
服务网格是一个基础设施层，用于处理服务间通信。现代云原生应用有着复杂的服务拓扑结构，服务网格负责在这些拓扑结构中实现请求的可靠传递。实践中，服务网格通常被实现为一组轻量级网络代理，它们与应用程序部署在一起，对应用程序透明。
8.1.3 Service Mesh详解
- 单个服务调用：应用实例和Service mesh 代理实例是两个独立的进程，它们之间的通信时远程调用，而不是代码层面的方法调用。客户端的请求会先到Service Mesh代理实例，代理实例表现为Sidecar,完成服务发现、负载均衡等基本功能，熔断、限流、重试等容错功能，路由功能，以及认证、授权、加密等，最后将请求发送给应用服务。
- 多个服务调用：Service mesh负责所有服务间请求转发，服务只负责发送和处理请求，不必再负责传递请求的具体逻辑。
- 大量服务调用：当系统存在大量服务时，服务间调用关系表现为网状。Sidecar之间的服务调用关系形成一个网络，这就是Service Mesh(服务网格)名字的由来。
- Service Mesh定义回顾：抽象：Service mesh是一个抽象层，负责王完成服务间通信。并且将这些功能从应用中剥离出来，形成一个单独的通信层，并将其下沉到基础设施层。 功能：请求的可靠传递。 部署：轻量级网络代理，以sidecar的模式和应用程序一对一部署，两者之间的通信时远程调用。 透明：Service mesh对应用程序是透明的。Service Mesh可以独立部署升级、扩展功能、修复缺陷，而不必改动应用程序。
8.2 Service Mesh演进历程
下面讲述Service Mesh技术的起源、发展、以及一步一步的演进历程。
8.2.1 远古时代的案例
在应用代码中处理网络通信细节，比如数据包顺序、流量控制等。后来TCP/IP协议栈负责这些功能。
8.2.2 微服务时代的现状
服务发现、负载均衡、熔断、重试。
8.2.3 侵入式框架的痛点
Spring Cloud和Dubbo这些传统的微服务治理框架都是侵入式的微服务框架。
痛点1：门槛高。
痛点2：功能不全。 Istio的路由功能比Spring Cloud强大。
痛点3： 无法跨语言。微服务有跨语言的优点。
痛点4：升级困难。
8.2.4 解决问题的思路
8.2.5 Proxy模式的探索
8.2.6 Sidecar模式的出现
8.2.7 第一点的service Mesh
8.2.8 第二代的Service Mesh
8.3 Service Mesh市场竞争
8.3.1 Service Mesh的萌芽期
8.3.2 急转直下的Linkerd
8.3.3 波澜不惊的Envoy
8.3.4 背负使命的Istio
8.3.5 背水一战的Buoyant
8.3.6 其他参与者
8.3.7 Service Mesh的国内发展情况
8.4 Istio
8.4.1 Istio概述
8.4.2 架构和核心组件