定义
根据Linkerd CEO William Morgan定义，Service Mesh是用于处理服务间通信的基础设施层，用于在云原生应用复杂的服务拓扑中实现可靠的请求传递。在实践中，Service Mesh通常是一组与应用一起部署，但对应用透明的轻量级网络代理。
架构难题
我司采用的微服务架构基于Thrift通信，为了提供一个全局通用的通信协议，把这些与协议、路由等相关的操作封装在内部基础库上，像Netflix、Twitter等SOA/微服务的早期采用者，他们通过建立内部库的方式处理这些问题，然后提供给所有服务使用一样。
这种方法的问题在于，把库扩展到成百上千个微服务中难度极高，而且这些库相对来说是比较”脆弱“的，每次需要升级基础内部库，对众多微服务来说，虽然有容器支撑，也是一种小灾难~~
而Service Mesh提供了一种解决困境的思路和统一方案。
Service Mesh与传统基础设施层不同之处在于，它形成了一个分布式的互连代理网络，以sidecar形式部署在服务两侧，服务对于代理无感知，且服务间所有通信都由代理进行路由。
全局视角
仔细观察上面几张图，应该很清晰的阐述了解决问题的观点。
Service Mesh由data plane构成，其中所有服务通过sidecar代理进行服务通信。（所有代理相互连接形成一个Mesh，Service Mesh由此得名）网格同时包含一个control plane——可以将所有独立的sidecar代理连接到一个分布式网络中，并设置网格还包括一个控制平面——它将所有独立的sidecar代理连接到一个分布式网络中，并设置由data plane指定的策略。
Control plane定义服务发现、路由、流量控制等策略。这些策略可以是全局的，也可以是限定的。Data plane负责在通信时应用和执行这些策略。
微软阵营的Service Fabric
完美解决服务发现、负载均衡、路由、流量控制、通信可靠性、弹性、安全、监控/日志等问题。
目前已经开源。
github： Service Fabric
google 的ISTIO
两者对比
