关于微服务架构service mesh，它比起传统的微服务架构有那些优势的地方?

Service mesh被用来处理服务间通讯的专用基础设施层，通过复杂的拓扑结构让请求传递的过程变得更可靠。

Service mesh通常作为一组轻量级高性能网络代理，这些代理和程序代码部署在一起，但是应用程序不需要对代理有任何动作。

Service mesh是一个网络模型，它是位于TCP/IP之上的抽象层。它假定底层的L3/L4网络是真实存在的，并且能够点对点地传递字节。

但与TCP不同的是，Service mesh具有更高的性能。

Service mesh最终并不是引入一项新功能，而是功能定位的转变。Web应用程序总是必须管理服务间通信的复杂性。

比如2000年的中型web应用程序的典型架构: 三层应用程序。 在这个模型中，应用程序逻辑、web服务逻辑和存储逻辑都是单独的一层。层之间的通信虽然复杂，但这种复杂性是限定在一定范围内，因为毕竟只有两个跳转。这里没有“网格”，但是在每个层的代码中处理的跳转之间有通信逻辑。

当这种架构方式在面对应用程序内部逻辑越来越复杂化的情形时，它就开始崩溃了。 像Google、Netflix和Twitter这样的公司无时无刻都面临着巨大的流量需求，它们实现了云原生方案的前身: 应用层被分解成许多服务(有时称为“微服务”)，层级间则形成了一个拓扑结构。 在这些系统中，广义的通讯层突然变得相关起来， 但通常以“胖客户端”的库集（library）形式出现， 比如twitter的Finagle，Netflix的Hystrix，以及Google的Stubby就是这样的例子。

从很多方面上来讲，像Finagle, Stubby和Hystrix这些库集其实是Service mesh的雏形。虽然它们受其周围环境的细节影响，并且需要使用特定的语言和框架，但是它们是用于管理服务到服务间通信的专用基础设施，并且(在开源Finagle和 Hystrix库集的情形下)可以在其公司之外使用。

到了云原生应用时期， 云原生模型本身结合了许多小型服务的微服务方法和两个额外的因素:容器(例如Docker)，它提供了资源隔离和依赖关系管理，以及一个编排层(例如Kubernetes)，它将底层硬件抽象出了一个同质池。

这三个组件支持应用程序在负载下可弹性伸缩的自然机制， 并能够处理云平台环境中存在的部分故障。

但面对数百个服务或数千个实例，和随时在重新安排实例的编排层，单个请求经由服务拓扑的路径可能非常复杂， 而由于容器使每个服务用不同的语言写入处理变得更容易了，库集方法也就不再可行了。

这种复杂性和关键性的结合，激发了对服务到服务间通信的专用基础层的需求，这个专用层与应用程序代码分离出来，并能够捕捉底层环境的高度动态特性。就是这一专用层我们称之为Service mesh。