定义
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 功能更加丰富、设计上更为强大,社区相对也更加强大一些。