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 发布
• 支持自家的多种计算资源的部署

国内发展情况

• 蚂蚁金服：SOFA Mesh，MOSN 数据平面
• 几大云厂商（腾讯、阿里、百度）
• 华为、微博
• 其他