Istio 实践手册 ｜服务网格框架对比

Istio 实践手册 ｜服务网格框架对比

作者：xcbeyond

《Istio 实践手册》，从服务网格概念出发，将逐步从 Istio 具体细节中来，旨在帮助 Istio 学习者、使用者快速掌握相关知识点，可作为 Istio 学习、实践手册，建议收藏！（不断更新中……）

当前，业界主要有以下主要几种 ​​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​​管理接口。

控制平面

是在​​Kubernetes​​特定命名空间中运行的一组服务。这些服务可以完成各种事情：聚集遥测数据，提供面向用户的 API，向数据平面代理提供控制数据等。

由以下部分组成：

​​Controller​​​：由​​public-api​​​容器组成，该容器为​​CLI​​​和​​dashboard​​​提供接口 API。​​​Destination​​​：数据平面中的每个代理都使用此组件来查找将请求发送到哪里。还用于获取服务配置信息，如：路由指标，重试和超时等。​​​Identity​​​：该组件提供了证书的颁发，接受来自代理的 CSRs 并返回正确身份签名的证书。这些证书由代理在启动时获取，并且必须在代理准备就绪之前发出。随后，它们可用于​​Linkerd​​​代理之间的任何连接以实现​​mTLS​​​。​​​Proxy Injector​​​：是一个注入程序，每次创建一个​​pod​​​时，它都会接收一个​​webhook​​​请求。该注入程序检查资源以查找特定于​​Linkerd​​​的注释（​​linkerd.io/inject: enabled​​​）。当存在该注释时，注入器将更改容器的规范，并添加​​initContainer​​​包含代理本身的以及附属工具。​​​Service Profile Validator​​​：用于在保存新服务配置文件之前先对其进行验证。​​​Tap​​​：从​​CLI​​​和​​dashboard​​接收请求，以实时监视请求和响应。

数据平面

由轻量级代理组成，这些代理作为​​sidecar​​​容器与服务代码的每个实例一起部署。为了将服务“添加”到​​Linkerd​​​服务网格，必须重新部署该服务的​​Pod​​，以在每个 Pod 中包含数据平面代理。

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​​：负责各个应用服务之间通信。​​Pilot​​​：管理和配置​​Envoy​​，提供服务发现、负载均衡和智能路由，保证弹性服务（服务超时次数、重试、熔断策略）。​​Mixer​​：信息监控检查。​​Istio-Auth​​：提供服务和服务、用户和服务之间的认证服务，实现访问控制，解决是谁访问的是哪个 API 的问题。

其中，图中的通信代理组件为​​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 框架进行简单的比较汇总，见下表所示：

上述任何一个 ​​Service Mesh​​ 框架都能够满足您的基本需求。

到⽬前为⽌，​​Istio​​ 具有这几个服务⽹格框架中最多的功能和灵活性，灵活性意味着复杂性，因此需要团队更为充⾜的准备。

如果只想使⽤基本的 ​​Service Mesh​​​ 治理功能，​​Linkerd​​​ 可能是最佳选择。如果您想⽀持同时包含 ​​Kubernetes​​​ 和 ​​VM​​​ 的异构环境，并且不需要 ​​Istio​​​ 的复杂性，那么 ​​Conduit​​​ 可能是您的最佳选择，⽬前 ​​Istio​​​ 也提供了同时包含 ​​Kubernetes​​​ 和 ​​VM​​ 的异构环境的⽀持。

下篇预告：将正式踏进 Istio 的征程，从 Istio 的整体架构谈起，一同目睹 Istio 中都有哪些组件及如何实现的。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。