当前,业界主要有以下主要几种Service Mesh框架,下面进行详细的说明及对比。
1、Linkerd
Linkerd是Buoyant公司2016年率先开源的高性能网络代理,是业界的第一款Service Mesh框架。其主要用于解决分布式环境中服务之间通信面临的一些问题,如网络不可靠、不安全、延迟丢包等问题。
Linkerd使用Scala语言编写,运行于JVM,底层基于Twitter的Finagle库,并对其做了相应的扩展。最主要的是Linkerd具有快速、轻量级、高性能等特点,每秒以最小的延迟及负载处理万级请求,易于水平扩展。除此之外,还有以下功能:
- 支持多平台:可运行于多种平台,比如
Kubernetes、DC/OS、Docker,甚至虚拟机或物理机。
- 无缝集成多种服务发现工具。
- 支持多协议,如
gRPC、HTTP/1.x、HTTP/2,甚至可通过linkerd-tcp支持TCP协议。
- 支持与第三方分布式追踪系统
Zipkin集成。
- 灵活性、扩展性高,可通过其提供的接口开发自定义插件。
目前,Linkerd和Linkerd2并行开发,其情况如下:
Linkerd:Linkerd使用**Scala语言编写**,运行于JVM,底层基于Twitter的Finagle库,并对其做了相应的扩展。
Linkerd2:使用Go语言和Rust语言完全重写了Linkerd,专门用于Kubernetes。
Linkerd本身是数据平面,负责将数据路由到目标服务,同时保证数据在分布式环境中传输是安全、可靠、快速的。另外,Linkerd还包括控制平面组件Namerd,通过控制平面Namerd实现中心化管理和存储路由规则、中心化管理服务发现配置、支持运行时动态路由以及暴露Namerd API管理接口。
![在这里插入图片描述]()
2、Envoy
同Linkerd一样,Envoy也是一款高性能的网络代理,于2016年10月份有Lyft公司开源,为云原生应用而设计,可作为边界入口,处理外部流量,此外,也作为内部服务间通信代理,实现服务间可靠通信。Envoy的实现借鉴现有生产级代理及负载均衡器,如Nginx、HAProxy、硬件负载均衡器及云负载均衡器的实践经验,同时基于C++编写及Lyft公司生产实践证明,Envoy性能非常优秀、稳定。
Envoy既可用作独立代理层运行,也可作为Service Mesh架构中数据平面层,因此通常Envoy跟服务运行在一起,将应用的网络功能抽象化,Envoy提供通用网络功能,实现平台及语言无法性。除此之外,还有以下功能:
- 优先支持
HTTP/2和gRPC,同时支持Websocket和TCP代理。
- API驱动的配置管理方式,支持动态管理、更新配置以及无连接和请求丢失的热重启功能。
L3/L4层过滤器形成Envoy核心的连接管理功能。
- 通过与多种指标收集工具及分布式追踪系统集成,实现运行时指标收集、分布式追踪,提供整个系统及服务的运行时可见性。
- 内存资源使用率低,
sidecar是Envoy最常用的部署模式。
3、Istio
Istio是由Google、IBM和Lyft发起的开源的Service Mesh框架。该项目在2017年推出,并在2018年7月发布了1.0版本。
Istio是Service Mesh目前的实现的典型代表,如果Sidecar是整个Service Mesh的数据面,那么Istio主要在控制面上做了更多的改进,Istio使用Envoy作为Sidecar,控制面相关全部使用Golang编写,性能上有了很大的提升。
Istio 首先是一个服务网格,但是Istio又不仅仅是服务网格:在 Linkerd,Envoy 这样的典型服务网格之上,Istio提供了一个完整的解决方案,为整个服务网格提供行为洞察和操作控制,以满足微服务应用程序的多样化需求。
Istio在服务网络中统一提供了许多关键功能:
-
流量管理:控制服务之间的流量和API调用的流向,使得调用更可靠,并使网络在恶劣情况下更加健壮。
-
可观察性:了解服务之间的依赖关系,以及它们之间流量的本质和流向,从而提供快速识别问题的能力。
-
策略执行:将组织策略应用于服务之间的互动,确保访问策略得以执行,资源在消费者之间良好分配。策略的更改是通过配置网格而不是修改应用程序代码。
-
服务身份和安全:为网格中的服务提供可验证身份,并提供保护服务流量的能力,使其可以在不同可信度的网络上流转。
-
除此之外,Istio针对可扩展性进行了设计,以满足不同的部署需要。
-
平台支持:Istio旨在在各种环境中运行,包括跨云, 预置,Kubernetes,Mesos等。最初专注于Kubernetes,但很快将支持其他环境。
-
集成和定制:策略执行组件可以扩展和定制,以便与现有的ACL,日志,监控,配额,审核等解决方案集成。
这些功能极大的减少了应用程序代码,底层平台和策略之间的耦合,使微服务更容易实现。 ![在这里插入图片描述]()
Istio架构图中各个子模块功能如下:
其中,图中的通信代理组件为Envoy,这是Istio原生引入的,但Linkerd也能够集成对接Istio。
4、Conduit
Conduit于2017年12月发布,作为由Buoyant继Linkerd后赞助的另外一个开源项目,作为Linkerd面向Kubernetes的独立版本。Conduit旨在彻底简化用户在Kubernetes使用服务网格的复杂度,提高用户体验,而不是像Linkerd一样针对各种平台进行优化。
Conduit的主要目标是轻量级、高性能、安全并且非常容易理解和使用。同Linkerd和Istio,Conduit也包含数据平面和控制平面,其中数据平面由Rust语言开发,使得Conduit使用极少的内存资源,而控制平面由Go语言开发。Conduit依然支持Service Mesh要求的功能,而且还包括以下功能:
- 超级轻量级和极快的性能。
- 专注于支持
Kubernetes平台,提高运行在Kubernetes平台上服务的可靠性、可见性及安全性。
- 支持
gRPC、HTTP/2和HTTP/1.x请求及所有TCP流量。
Conduit以极简主义架构,以零配置理念为中心,旨在减少用户与Conduit的交互,实现开箱即用。
5、对比总结
下面对上述各种Service Mesh框架进行简单的比较汇总,见下表所示:
| 功能 |
Linkerd |
Envoy |
Istio |
Conduit |
| 代理 |
Finagle + Jetty |
Envoy |
Envoy |
Conduit |
| 熔断 |
支持。基于连接的熔断器Fast Fail和基于请求的熔断器Failure Accrual。 |
支持。通过特定准则,如最大连接数、 最大请求数、最大挂起请求数或者最大重试数的设定。 |
支持。通过特定准则,如最大连接数和最大请求数等的设定。 |
暂不支持。 |
| 动态路由 |
支持。通过设置Linkerd的dtab规则实现不同版本服务请求的动态路由。 |
支持。通过服务的版本或环境信息实现。 |
支持。通过服务的版本或环境信息实现。 |
暂不支持。 |
| 流量分流 |
支持。以增量和受控的方式实现分流。 |
支持。以增量和受控的方式实现分流。 |
支持。以增量和受控的方式实现分流。 |
暂不支持。 |
| 服务发现 |
支持。支持多种服务发现机制,如基于文件的服务发现、Consul、Zookeeper、Kubernetes等。 |
支持。通过提供平台无关的服务发现接口实现与不同服务发现工具集成。 |
支持。通过提供平台无关的服务发现接口实现与不同服务发现工具集成。 |
只支持Kubernetes。 |
| 负载均衡 |
支持。提供多种负载均衡算法。 |
支持。提供多种负载均衡算法,如Round Robin、加权最小请求、哈希环、Maglev等。 |
支持。提供多种负载均衡算法,如Round Robin、加权最小请求、哈希环、Maglev等。 |
支持。当前只有HTTP请求支持基于P2C + least-loaded的负载均衡算法。 |
| 安全通信 |
支持TLS。 |
支持TLS。 |
支持TLS。 |
支持TLS。 |
| 访问控制 |
不支持。 |
不支持。 |
支持。基于RBAC的访问控制。 |
暂不支持。 |
| 可见性 |
分布式追踪(Zipkin)、运行时指标(InfluxDB、Prometheus、statsd) |
分布式追踪(Zipkin)、运行时指标(statsd) |
分布式追踪(Zipkin)、运行时指标(Prometheus、statsd)、监控(NewRepic、Stackdriver) |
运行时指标(Prometheus) |
| 部署模式 |
sidecar或者per-host模式 |
sidecar模式 |
sidecar模式 |
sidecar模式 |
| 控制平面 |
Namerd |
没有,但可通过API实现。 |
Pilot、Mixer、Citadel |
Conduit |
| 协议支持 |
HTTP/1.x、HTTP/2、gRPC |
HTTP/1.x、HTTP/2、gRPC、TCP |
HTTP/1.x、HTTP/2、gRPC、TCP |
HTTP/1.x、HTTP/2、gRPC、TCP |
| 运行平台 |
平台无关 |
平台无关 |
目前支持Kubernetes,平台无关是最终实现目标。 |
只支持Kubernetes。 |
综上对比,推荐选择生态比较完善的Istio。