有了微服务为什么还需要服务网格(service mesh)？

一、什么是微服务

微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。

微服务的概念源于2014年3月Martin Fowler所写的一篇文章：(http://martinfowler.com/articles/microservices.html)

image.png

二、什么是服务网格

根据Linkerd CEO William Morgan定义，Service Mesh是用于处理服务间通信的基础设施层，用于在云原生应用复杂的服务拓扑中实现可靠的请求传递。在实践中，Service Mesh通常是一组与应用一起部署，但对应用透明的轻量级网络代理。
Service Mesh与传统基础设施层不同之处在于，它形成了一个分布式的互连代理网络，以sidecar形式部署在服务两侧，服务对于代理无感知，且服务间所有通信都由代理进行路由。

image.png

三、微服务 VS 服务网格

微服务架构的优点很多，比如它解耦业务，提供更高的灵活性，允许在服务频繁发版的同时保持系统其它部分的可用性与稳定性;解耦编程语言，针对不同业务可以使用更加合适的语言进行开发;解耦开发团队，不同团队各自负责一个微服务，互不影响，加速交付。

以spring cloud微服务核心组件包括以下几个组件：

• Config：配置中心
• Eureka：服务治理组件，包含服务注册与发现
• Hystrix：容错管理组件，实现了熔断器
• Ribbon：客户端负载均衡的服务调用组件
• Feign：基于Ribbon和Hystrix的声明式服务调用组件
• Zuul：网关组件，提供智能路由、访问过滤等功能

Service Mesh 有如下几个特点：

• 应用程序间通讯的中间层
• 轻量级网络代理
• 应用程序无感知

• 解耦应用程序的重试/超时、监控、追踪和服务发现
  以Istio为例：

  
  
  image.png

关于微服务和服务网格的区别:

微服务更像是一个服务之间的生态，专注于服务治理等方面，而服务网格更专注于服务之间的通信，以及和 DevOps 更好的结合。

四、为什么需要服务网格

从微服务和服务网格的对比和区别来看，其实很明确了，为什么有了微服务还需要服务网格。

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