根据Service Mesh的发展历程和使用方式，我们可以把Service Mesh划分为两个模式。
一、Sidecar模式
在Service Mesh发展早期，Service Mesh以Sidecar的形态存在。Sidecar模式可以看作是第一代Service Mesh，代表有早期的Linkerd和Envoy。Sidecar模式下，网络代理服务在微服务旁边，为微服务提供通信和链路治理功能。因此，数据平面代理服务也经常被简称为Sidecar。
此时，只有数据平面的网络代理服务没有控制平面，和外部基础设施服务的交互直接在网络代理服务中进行。第一代Service Mesh通过采用Sidecar模式，将通信和通信链路治理功能从微服务中剥离出来，实现了通信基础设施的下沉和服务化，这里也体现了架构解耦的思想，通过解耦减少了微服务的负担。
二、第二代Service Mesh模式
Sidecar模式的Service Mesh有一个突出的问题，将通信和通信链路治理的所有功能都放到这个代理服务中，导致数据平面代理很重，并且由于承载了太多的特性和功能，使得数据平面代理的更新和修改特别频繁，频繁的更新和升级会导致代理服务出问题的概率增大，影响代理服务的稳定性。
同时，Service Mesh模式下，数据平面代理承载了微服务通信的全部流量，对稳定性要求极高，这个服务的任何故障都会对整个系统的稳定性产生很大的影响。为了解决上述频繁升级和稳定性之间的矛盾，将策略和配置决策逻辑从代理服务中脱离出来，形成了独立的控制平面，这就是第二代Service Mesh。
第二代Service Mesh最重要的标志就是控制平面和数据平面分离。数据平面和控制平面并不是新的概念，路由器/交换机等数据通信产品架构上，就有运行于专门处理器上的控制平面和多个独立运行、用于路由或交换功能的数据平面。SDN（Software Defined Network，软件定义网络）将数据平面和控制平面分离，控制平面具有可编程性，使得网络更加智能、灵活和易扩展，激发了网络技术的又一次革命。
第二代Service Mesh借鉴了SDN的思路，基于控制平面和数据平面分离思想，有了完善的控制平面：①所有的代理服务都由控制平面掌控，因为控制平面可以控制整个系统，所以提供了强大的控制能力和策略能力；②将具体的控制逻辑从数据平面移除，简化了数据平面的设计，数据平面不需要和外部系统进行交互，数据平面完全聚焦在变更频率很低的流量路由和转发逻辑上，提升了数据平面的稳定性。
三、Service Mesh架构
第二代Service Mesh的基本架构上分为数据平面和控制平面两个部分。
- 数据平面
数据平面负责代理微服务之间的通信，具体包含RPC通信、服务发现、负载均衡、降级熔断、限流容错等，数据平面可以认为是将Spring Cloud、Dubbo等语言相关的微服务框架中通信和服务治理能力独立出来的一个语言无关的进程，并且更注重通用性和扩展性。在Service Mesh中，不再将数据平面代理视为一个个孤立的组件，而是将这些代理连接在一起形成一个全局的分布式网络。
- 控制平面
控制平面负责对数据平面进行管理，定义服务发现、路由、流量控制、遥测统计等策略，这些策略可以是全局的，也可以通过配置某个数据平面节点单独指定。控制平面通过一定的机制将策略下发到各个数据平面节点，数据平面节点在通信时会使用这些策略。
