定义
service mesh(服务网格)，作为服务间通信的基础设施层;
背景
应用越来越复杂，由数以千记得服务组成，每个服务又有多个实例，每个实例的状态都在不停的改变。
service mesh 是不是一个网络模型？
service mesh 处在TCP/IP层之上，抽象出可靠性传输，限流等功能。
service mesh不同于TCP/IP之处在于，将服务沟通从不可见的，隐含的基础设施转变为生态系统中第一级别的成员，可以被管理、监控。
servcie mesh 功能
- circuit-breaking
- latency-aware load balancing
- eventually consistent (“advisory”)
- service discovery
- retries deadlines
service mesh来龙去脉
service mesh并不是一夜之间就建立起来的，也是通过集成以前的经验而设计出来。
- 从最原始的主机之间直接使用网线相连
- 网络层的出现
- 集成到应用程序内部的控制流
- 分解到应用程序外部的控制流网络层的出现
- 集成到应用程序内部的控制流
- 分解到应用程序外部的控制流集成到应用程序内部的控制流
- 应用程序的中集成服务发现和断路器
- 出现了专门用于服务发现和断路器的软件包/库，如 Twitter 的 Finagle 和应用程序的中集成服务发现和断路器 出现了专门用于服务发现和断路器的软件包/库，
- 出现了专门用于服务发现和断路器的开源软件，如 Netflix出现了专门用于服务发现和断路器的开源软件，如 Netflix OSS、Airbnb 的 synapse 和 nerve
- 最后作为微服务的中间层 Service Mesh 出现 最后作为微服务的中间层 Service Mesh 出现
系统架构图
service mesh将服务的流量都通过sidecar拦截，然后做service mesh的功能处理，对于服务来说，service mesh是透明的。
图片来自：Pattern: Service Mesh
服务间通信关注点
- 服务发现
- 负载均衡
- 路由
- 流量控制
- 通信可靠性
- 弹性
- 安全
- 监控/日志
选择service mesh
service mesh解决的是其他工具已经解决的问题，但是部署的环境变成了Cloud Native的kubernetes.
现如今，单体应用被分解为众多的微服务，服务之间的依赖和通讯十分复杂，twitter的Finagle与netflix的Hystrix，还有google的stubby都是适用于特定环境的胖客户端库，不能作为平台级的支持。
在 Cloud Native 架构下，容器的使用给予了异构应用程序的更多可行性，kubernetes 增强的应用的横向扩容能力，用户可以快速的编排出复杂环境、复杂依赖关系的应用程序，同时开发者又无须过分关心应用程序的监控、扩展性、服务发现和分布式追踪这些繁琐的事情而专注于程序开发，赋予开发者更多的创造性。
方案
Buoyant 公司推出的 Linkerd
Google、IBM 等厂商牵头的 Istio。
Linkerd 更加成熟稳定些，Istio 功能更加丰富、设计上更为强大，社区相对也更加强大一些。