现今有了 Kubernetes 这类微服务编排工具后,微服务这项架构引得越来越多的企业使用. 虽然微服务之间都是相互独立,可以做到互不影响,但是随着量级的增加,微服务的管理将会越加趋于复杂,于此之下衍生微服务的治理问题是亟待解决的.
关注 Kubernetes 的人可能发现在一些 Kubernetes 交流社区已经悄然兴起了一些微服务治理的手段和工具,而其中最常见的一个词应该是Service Mesh.
这个词的流行是来自 Linkerd 公司的工具 Linkerd ,这是 Service Mesh 技术的具体实现,当然也有其他的工具实现 Service Mesh,比如最近火热的 Istio.
它们都是基于服务网格的设计实现,核心是一个透明代理,用以提供底层服务间的通信.因为处于通信底层,所以可以供上层实现:
- 服务发现
- 负载均衡
- 路由
- 限流
- 熔断
- 错误应答规则
- 超时重试
既可以实现功能而无需入侵服务内部,这无疑大大降低了微服务治理的门槛.
以 Kubernetes 下的 Istio 为例,其在部署后,会在创建的 Pod 中添加一个代理容器,称之为 Sidecar.这种称呼非常的形象,这个附加的类似边斗车,它的功能只有一个就是负责底层的链路通讯,接管整个网络,把所有的请求在服务间转发.因此,网络也被抽象剥离了出来,从而有了可控性.
这就是 Service Mesh.