Service Mesh的起源：为什么会出现Service Mesh技术？
微服务架构的特性
特点 1：围绕业务构建团队
特点 2：去中心化的数据管理
微服务架构面临什么样的问题？
微服务架构的优势
- 团队层面：内聚，独立开发业务，没有依赖
- 产品层面：服务彼此独立，独立部署，没有依赖
- 微服务是软件架构的银弹吗？而银弹理论已经说明了没有任何一种技术和管理上的进步，可以极大的提升生产效率
服务之间的网络通信是微服务架构的一大痛点，当微服务越来越多时，整体的调用链路就呈现一个复杂的图状：
为什么网络通信是微服务架构的痛点？分布式计算的 8 个谬论（Fallacies of Distributed Computing Explained）：
- 网络是可靠的
- 网络延迟是 0
- 带宽是无限的
- 网络是安全的
- 网络拓扑从不改变
- 只有一个管理员
- 传输成本是 0
- 网络是同构的
如何管理和控制服务间的通信？
- 服务注册/发现
- 路由，流量转移
- 弹性能力（熔断、超时、重试）
- 安全
- 可观测性
Service Mesh的发展：Service Mesh技术是如何演进的？
第一阶段：控制逻辑和业务逻辑耦合
- 网络调用、熔断、服务发现等控制逻辑与业务逻辑交杂耦合在一起
第二阶段：公共库
- 这个公共库可以是第三方的，例如Spring Cloud体系中的一些相关框架
- 在这个阶段达到了控制逻辑和业务逻辑解耦、消除重复
- 但需要花人力和时间成本去学习这个库以及维护它，并且通常是语言绑定，且仍有侵入
第三阶段：代理
- 公共库不再和现在的业务逻辑部署在一起，而是单独抽出一个代理模块，由该模块去包含相应的控制逻辑
- 功能简陋，但思路正确
第四阶段：边车模式（Sidecar)
- 在应用旁边部署一个Sidecar，由Sidecar去处理所有的网络请求以及相应的控制逻辑，然后再把请求转发给应用
第五阶段：Service Mesh 的出现
微服务通信的济世良方：什么是Service Mesh？它能帮你做什么？
Service Mesh 的定义
- 所谓 Service Mesh 就是一个用来进行请求转发的基础设施层，它通常是以Sidecar的形式部署，并且对应用透明
Service Mesh 的产品形态
- Service Mesh 是 Sidecar 的网络拓扑模式。整体上分为数据平面和控制平面
Service Mesh 的主要功能
Service Mesh 和 Kubernetes 的关系
Service Mesh 和 API 网关的异同点
- 功能有重叠，但角色不同
- Service Mesh 在应用内，API 网关在应用之上（边界）
Service Mesh 技术标准
列王的纷争：市面上有哪些主流的Service Mesh产品？
Linkerd
- 第一个 Service Mesh 产品
- 2016 年底在 GitHub 上发布 0.x
- 2017 年加入 CNCF，4 月发布 1.0 版本
- Conduit – Linkerd2.0：支持 Kubernetes，轻量化
- Linkerd 的败局？
envoy
- 2016 年 9 月发布
- 定位于 Sidecar 代理
- 第 3 个从 CNCF 毕业的产品
- 稳定可靠，性能出众
- Istio 的默认数据平面
- xDS 协议成为数据平面的事实标准
Istio
- 2017 年 5 月发布 0.1
- 光环加身：Google，IBM，Lyft 背书
- 第二代 Service Mesh，增加了控制平面，奠定目前 Service Mesh 的产品形态
- 收编 Envoy，直接拥有高水准的数据平面
- 受到社区强烈追捧
AWS App Mesh
- 2018 年 re:Invent 公布
- 2019 年 4 月 GA 发布
- 支持自家的多种计算资源的部署
