Service Mesh 作为下一代微服务技术的代名词，初出茅庐却深得人心一鸣惊人，在国内外大厂中广泛实践。这里聊一聊微服务和 Service Mesh 的关联与区别，有了微服务为什么还需要服务网格。

应用架构的演变

单体架构 -> SOA 架构 -> 微服务架构 -> Service Mesh。

第一代：单体架构

典型的单体架构就将所有的业务场景的表现层，业务逻辑层，数据访问层放在一个工程中最终经过编译，打包，部署在一台服务器上。

第二代：SOA 架构

将各个系统的不同功能单元抽象为服务，服务间彼此通过标准的接口协议连接起来，并以此完成特定功能的实现。当出现新的业务需求时，不需要从零开始实现，只需将已有的服务进行编排装配来实现新业务。

第三代：微服务

微服务是 SOA 思想的一种提炼，它强调业务系统彻底的组件化和服务化，通过有效的拆分系统，实现敏捷开发和部署。原有的单个业务系统被拆分为多个可以独立开发，设计，运行和运维的小应用，这些小应用之间通过服务完成交互和集成。

常见的技术栈基于 SpringCloud 或者 dubbo 框架进行开发，仅使用服务注册与发现与服务网关等策略。使用熔断、限流、降级等服务治理策略，并配备完整服务工具和平台。

第四代：ServiceMesh

ServiceMesh 将服务治理作为通用组件并下沉到平台层实现，使得应用层仅仅关注业务逻辑。将业务所有的流量都转发到 ServiceMesh 的代理服务中，由服务网格帮助应用程序在海量服务、复杂的架构和网络中建立稳定的通信机制。
此外，ServiceMesh 还承担了微服务框架所有的功能，包括服务注册发现、负载均衡、熔断限流、认证鉴权、缓存加速等，不同的是，Service Mesh 强调的是通过独立的进程代理的方式。

微服务 VS ServiceMesh

微服务更像是一个服务之间的生态，专注于服务治理等方面，而 Service Mesh 更专注于服务之间的通信。Service Mesh 作为服务间通信的基础设施层，可以将它比作是应用程序或者说微服务间的 TCP/IP，负责服务之间的网络调用、限流、熔断和监控。对于编写应用程序来说一般无须关心 TCP/IP 这一层（比如通过 HTTP 协议的 RESTful 应用），同样使用 Service Mesh 也就无须关系服务之间的那些原来是通过应用程序或者其他框架实现的事情，比如 Spring Cloud、OSS，现在只要交给 Service Mesh 就可以了。

微服务

为了避免每个服务都需要自己实现一套分布式系统通信的语义功能，随着技术的发展，一些面向微服务架构的开发框架出现了，如 Twitter 的 Finagle、Facebook 的 Proxygen 以及Spring Cloud等等，这些框架实现了分布式系统通信需要的各种通用语义功能：如负载均衡和服务发现等，因此一定程度上屏蔽了这些通信细节，使得开发人员使用较少的框架代码就能开发出健壮的分布式系统。

Service Mesh 1.0

微服务模式看似完美，但开发人员很快又发现，它也存在一些本质问题：

• 其一，虽然框架本身屏蔽了分布式系统通信的一些通用功能实现细节，但开发者却要花更多精力去掌握和管理复杂的框架本身，在实际应用中，去追踪和解决框架出现的问题也绝非易事；

• 其二，开发框架通常只支持一种或几种特定的语言，回过头来看文章最开始对微服务的定义，一个重要的特性就是语言无关，但那些没有框架支持的语言编写的服务，很难融入面向微服务的架构体系，想因地制宜的用多种语言实现架构体系中的不同模块也很难做到；

• 其三，框架以 lib 库的形式和服务联编，复杂项目依赖时的库版本兼容问题非常棘手，同时，框架库的升级也无法对服务透明，服务会因为和业务无关的 lib 库升级而被迫升级；
  因此以 Linkerd，Envoy，NginxMesh 为代表的代理模式（边车模式）应运而生，这就是第一代 Service Mesh，它将分布式服务的通信抽象为单独一层，在这一层中实现负载均衡、服务发现、认证授权、监控追踪、流量控制等分布式系统所需要的功能，作为一个和服务对等的代理服务，和服务部署在一起，接管服务的流量，通过代理之间的通信间接完成服务之间的通信请求，这样上边所说的三个问题也迎刃而解。

  

如果我们从一个全局视角来看，就会得到如下部署图：

Service Mesh 2.0

第一代 Service Mesh 由一系列独立运行的单机代理服务构成，为了提供统一的上层运维入口，演化出了集中式的控制面板，所有的单机代理组件通过和控制面板交互进行网络拓扑策略的更新和单机数据的汇报。这就是以 Istio 为代表的 Service Mesh。

只看单机代理组件(数据面板)和控制面板的 Service Mesh 全局部署视图如下：

Service Mesh 的优缺点

优点

• 屏蔽分布式系统通信的复杂性（负载均衡、服务发现、认证授权、监控追踪、流量控制等等），服务只用关注业务逻辑；

• 真正的语言无关，服务可以用任何语言编写，只需和 Service Mesh 通信即可；

• 对应用透明，Service Mesh 组件可以单独升级。

缺点

• Service Mesh 组件以代理模式计算并转发请求，一定程度上会降低通信系统性能，并增加系统资源开销；

• Service Mesh 组件接管了网络流量，因此服务的整体稳定性依赖于 Service Mesh，同时额外引入的大量 Service Mesh 服务实例的运维和管理也是一个挑战；

参考资料

什么是 Service Mesh
有了微服务为什么还需要服务网格
一文读懂微服务和 ServiceMesh 的区别
顺丰科技 Service Mesh 落地半年：最初目标已经实现，将继续探索