微服务是一种架构风格，一个复杂系统由一个或者多个微服务组成，系统中微服务被独立部署，各个微服务是松耦合的。每个微服务只需关注完成一件任务并执行。微服务也就是把一个大系统按照业务功能拆分成多个功能业务单一的小系统服务。然后进行相互协作组成一个大系统。

微服务架构优点：

降低系统复杂度

松耦合

跨语言

独立部署

缺点：

(1)强调了服务大小，但无统一标准

(2)当服务多起来，服务间调用链的跟踪变得复杂。

(3)带来分布式事务问题

(4)部署复杂，每个服务可能有自己的配置，实例数量等。

问题：api网关、服务调用、服务发现、服务安全、服务部署

不过spring cloud dubbo等微服务框架已解决这些问题。

微服务架构中我们要保证通信通道需要保持无故障，安全，高可用性和健壮性。而这恰恰是服务网格作为基础结构组件出现的地方，它通过实现多个服务代理来确保受控的服务到服务通信。服务网格负责不同服务之间的通信，而不是添加新功能。

但是当服务多起来，我们希望能将分布式服务所需要额度一些特性放入底层的公共平台中。工程师只需要关注业务逻辑上，不需要浪费时间去编写服务基础设施代码或管理系统用到的软件框架。比如sso认证、服务治理（限流、熔断、异常重试/超时、监控和服务发现）等,也就是TCP/IP这一层。

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

Service Mesh 有如下几个特点：

应用程序间通讯的中间层

轻量级网络代理

应用程序无感知

解耦应用程序的重试/超时、监控、追踪和服务发现

架构图例：

那么用户请求流程为

user---->api gateway--->sidecar---->具体微服务service

在服务网格中，与单个服务一起部署的代理可以实现服务之间的通信，这被广泛称为Sidecar模式。Sidecar（代理）被设计为处理服务间通信的任何功能，例如负载均衡，断路器，服务发现等。

目前流行的 Service Mesh 基于k8s容器的有istio。

个人理解，服务网格模式使得服务的治理和通信变的更加容易。