【一】Service Mesh介绍
1. 基本概念
Service Mesh（服务网格）是 CNCF（Cloud Native Computing Foundation，云原生计算基金会）目前主力推动的新一代的微服务架构。第一篇关于Service Mesh的文章What’s a service mesh? And why do I need one?，这篇文章对Service Mesh理念的知识源头，干货还是比较多的。
A service mesh is a dedicated infrastructure layer for handling service-to-service communication. It’s responsible for the reliable delivery of requests through the complex topology of services that comprise a modern, cloud native application. In practice, the service mesh is typically implemented as an array of lightweight network proxies that are deployed alongside application code, without the application needing to be aware.
这里归纳出如下几个要点：
定位：基础设施层
解决的问题域：服务间通信
目标：请求可靠传递
部署方式：轻量级网络代理
核心功能：连接，保护，控制，观测
2.Trade-Off
这部分列举Service Mesh的优劣势，Trade部分它的优势，如果其中恰好有我们目前遇到问题的解决方案，那么这个就是我们选择它的理由，Off则是我们选择它之后，要承担的风险或者需要改进的方面。
-
Trade
对应用透明
扫描二维码关注公众号，回复： 9077241 查看本文章
业务无侵入，微服务基础设施下沉
语言无关
标准化，降低升级成本
-
Off
稳定性要求高：因为调度了流量，如果有 bug或是 Sidecar 的组件不可用，就会导致整个架构出现问题
性能问题：一直被诟病的问题，Service Mesh组件代理请求转发，会在一定程度上降低系统通信性能
3. 核心模式
SideCar：
- 基于iptables的网络拦截
- 采用协议转换的方式
Control Plane：
服务之间的所有流量都可以通过SideCar来转发，这样的话所有的SideCar就组成了一个服务网格，再通过Control Plane与各个SideCar交互，控制网格中流量的运转。
【二】开源项目
1.Linkerd
Linkerd是第一代Service Mesh产品的代表，在2016年出现，核心理念SideCar模式，也就是在服务实例之上添加一个抽象层。提供自动化负载均衡，服务发现和运行时恢复等能力。核心是路由机制。
2.Istio
简介：
第二代Service Mesh产品的代表，由Google，IBM和Lyft联合开发，
定位：完整的Service Mesh解决方案
核心理念：数据和控制分分离，模块化设计
核心能力：
- 对业务流量进行透明转发和治理
- 数据平面聚集流量转发
- 链路监控治理
- 控制平面
组成： Proxy和Control Plane
-
Proxy，就是前面提到的SideCar，与应用程序部署在同一个主机上，应用程序之间的调用都通过Proxy来转发，目前支持HTTP/1.1、HTTP/2、gRPC以及TCP请求。采用的是Envoy。
Envoy：
定位：微服务架构的通信总线
核心理念：网络对应用透明
功能：Envoy是Istio中最基础的组件，所有其他组件的功能都是通过调用Envoy提供的API，在请求经过Envoy转发时，由Envoy执行相关的控制逻辑来实现的
-
Control Plane，与Proxy通信，来实现各种服务治理功能，包括三个基本组件：Pilot、Mixer以及Citadel。Pilot专注于流量控制，Mixer专注于策略控制以及监控日志功能，而Citadel专注于安全。
Istio各组件功能总结：
| Proxy | Pilot | Mixer | Citadel | |
|---|---|---|---|---|
| 功能总述 | 代理组件（Envoy） | 流量控制 | 策略控制和监控日志收集 | 保证服务访问的安全 |
| 服务发现、服务注册、负载均衡、限流降级、超时熔断、动态路由、监控上报和日志推送 | 服务发现和负载均衡,请求路由，超时重试 | 策略控制，监控和日志收集 |
3.Sofa Mesh（蚂蚁金服）
简述： 数据平面采用自研MOSN，控制平面采用Istio
改进点：
- 使用Golang语言开发全新的Sidecar，替代Envoy
- 为了避免Mixer带来的性能瓶颈，合并Mixer部分功能进入Sidecar
- Pilot和Citadel模块进行了大幅的扩展和增强
4.Weibo Mesh（微博）
2017年开始实践Service Mesh的，从自身的业务特征和既有技术体系出发，与当前云原生和Istio的实践方案存在一定差别，总结来说具有一定的业务特性。控制平面和数据平面分别为自研的SGCenter和Motan-go Agent
- SideCar：Istio使用Envoy，Weibo Mesh采用Motan-go Agent。基于iptables技术则业务无需变更，更适合Cloud Native场景。
- 服务治理：Istio采用Control Plane来控制Proxy，Weibo Mesh是通过统一的服务治理中心。
【三】商业产品
1. Google
- Google Cloud Service Mesh - Istio的完全托管版本，减少开发者在Istio部署，管理上的开销。
- Traffic Director - 流量管理产品，支持容器，虚拟机多种环境，提供多平台，多容器之间进行全局流量调度的能力。
2. APP Mesh（AWS）
2018年12月发布，支持Kubernetes，AWS ECS等多个平台。
数据平面基于Envoy，控制平面自研，通过XDS API对Envoy进行配置和管理。
3. Azure Service Fabirc Mesh
Service Fabirc是一个开源跨平台分布式应用平台。而Service Fabirc Mesh是Service Fabirc的云托管版本。
2018年7月发布，基于Envoy构建，提供流量调度和路由管理能力。
4.TSF（腾讯）
采用基于开源Istio和Envoy技术栈的方案，进行扩展和定制
通过一定程度的定制及扩展，可以使得Istio与Kubernetes成功解耦
5.CSE Mesher（华为）
- 控制面：使用CSE组件的服务中心与配置中心等服务作为控制面
- 数据面：Mesher与业务代码部署在一起运行在数据面
- 监控：华为公有云APM
- 不绑定任何基础设施层
特色：通过Channel与Go协程机制主动上报metric数据，以此获得更高的性能
##【五】参考文献
《Service Mesh微服务架构设计》
