sevice mesh 简介

定义

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并不是一夜之间就建立起来的，也是通过集成以前的经验而设计出来。

1. 从最原始的主机之间直接使用网线相连
2. 网络层的出现
3. 集成到应用程序内部的控制流
4. 分解到应用程序外部的控制流网络层的出现
5. 集成到应用程序内部的控制流
6. 分解到应用程序外部的控制流集成到应用程序内部的控制流
7. 应用程序的中集成服务发现和断路器
8. 出现了专门用于服务发现和断路器的软件包/库，如 Twitter 的 Finagle 和应用程序的中集成服务发现和断路器 出现了专门用于服务发现和断路器的软件包/库，
9. 出现了专门用于服务发现和断路器的开源软件，如 Netflix出现了专门用于服务发现和断路器的开源软件，如 Netflix OSS、Airbnb 的 synapse 和 nerve
10. 最后作为微服务的中间层 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 功能更加丰富、设计上更为强大，社区相对也更加强大一些。