本文翻译至 《Exploring Service Mesh through Istio, eBPF, and RSocket Broker: An In-depth Study.》作者：Seifeddine Rajhi

介绍：

在当今快节奏的技术世界和微服务时代，由于更多的业务责任与服务相关联，管理服务的复杂性已经上升。仅仅依靠框架层面的治理是不够的，还需要完善的治理体系。本文从多个角度审视服务治理，并通过探索传统和现代方法提供对服务网格、Istio、eBPF 和 RSocket Broker 的理解。

1. 服务治理

治理是指建立和实施微服务如何协同工作以实现系统设计和构建的业务目标的过程。服务治理可以通过多种方式实现：

• 服务注册与发现：Consul、ZooKeeper

• 服务配置：Spring Cloud Config

• 负载均衡：Ribbon、Feign

• 追踪工具：Sleuth、Zipkin

• 监控：Grafana、普罗米修斯

稍后，我们将讨论其中的一些。

服务注册和发现

如今，单个大型单体应用程序被分解成更小的可单独部署的单元，称为微服务。当一个服务与另一个服务通信时，它需要远程端的 IP 和端口。将此信息保存在配置文件中很简单，但它不允许云可扩展性，因为使用此方法无法根据负载调整服务器实例。服务发现通过允许服务在服务注册表中使用其 IP 和端口注册自己以供客户端访问来解决此问题。健康检查还确保流量只转发到健康的实例。

负载均衡

负载均衡在多个服务器之间分配网络请求以增加处理能力。我们将检查使用 RSocket 在服务器池之间平衡客户端请求。

2.边车模式

Sidecar 模式将应用程序功能划分为同一单元内的单独进程。它通过允许抽象非业务逻辑功能来减少代码重复和复杂性。Sidecar 容器可用于处理 Kubernetes Pod 中的可观察性、监控、日志记录、配置和断路器等问题。

https://apisix.apache.org/blog/2021/12/17/exposure-istio-with-apisix-ingress/在 Sidecar 模式下，代理容器与 Pod 中的应用程序容器共享网络命名空间，提供隔离的网络堆栈。这允许多个 Pod 在端口 80 上运行 Web 应用程序，代理拦截进出应用程序容器的流量。

3. 服务网格之旅

微服务架构使得具有单一职责的多个单元组成一个复杂的应用程序。早期的微服务依赖于内部 SDK 进行服务发现、重试等，导致软件堆栈增加、依赖特定语言、升级/部署成本高以及学习曲线等缺点。业务逻辑和非功能代码的耦合也导致应用程序频繁发布新版本，即使业务逻辑保持不变。

服务网格

Service Mesh 是一个基础设施层，用于通过 Sidecar 模式处理服务之间的通信，以透明代理的形式提供安全、快速、可靠的服务间通信。

https://servicemesh.es借助服务网格，微服务功能从应用程序中移除并存放在边车容器中。这使得微服务只专注于业务逻辑，而基础设施团队管理通用能力，从而实现高效的独立演进。Istio 和 Linkerd 是流行的开源服务网格选项，具有由控制平面和数据平面组成的简单架构。数据平面拦截服务调用，而控制平面管理协调和版本控制。服务通过本地 Sidecar 代理而不是直接通过网络进行通信。

4. Istio 快速浏览

Istio 是一个服务治理的开放平台，以 Service Mesh 的形式面向云原生场景，与 Kubernetes 紧密结合。Istio 提供负载均衡、服务间认证、监控等功能。

Istio 架构

Istio 的架构分为控制平面和数据平面。

• 数据平面：由遍布网格的 Sidecar 代理组成，与应用服务一起以 Sidecar 的形式部署。每个 Sidecar 都会接管服务的进出流量，配合控制平面完成流量控制等功能。

• 控制平面：顾名思义，控制和管理数据平面的 Sidecar 代理，完成配置分发、服务发现、授权认证等功能。核心组件

下面简单介绍一下 Istio 架构中几个核心组件的主要功能。

https://ssup2.github.io/theory_analysis/Istio_Architecture/

Envoy

Envoy 是 Istio 服务网格中使用的高性能 C++ 代理，作为 Sidecar 容器拦截所有入站和出站流量，执行负载均衡、熔断和故障注入等功能，并为 Prometheus 和 Jeager 提供指标收集。它是 Istio 中数据平面的一部分。

Istiod

Istiod 是一个控制平面组件，提供服务发现、配置和证书管理功能。Istiod 采用 YAML 编写的高级规则，并将其转换为 Envoy 的可操作配置。然后它将此配置传播到网格中的所有边车。

• Pilot：Pilot 主要作用是将路由规则等配置信息转换为 Sidecar 可以识别的信息，发送给数据面。可以简单理解为配置分发器，辅助 Sidecar 完成流量控制相关功能。

• Citadel：Citadel 是 Istio 中的一个安全组件，它生成证书以允许数据平面中代理之间的安全 mTLS 通信。

• Galley：Galley 是 Istio 1.1 版本新增的组件，旨在解耦 Pilot 和 Kubernetes 等底层平台。它共享了原有 Pilot 的部分功能，主要负责配置的校验、提取和处理功能。

Istio 流量转发

流量路由分为入站和出站流程。

Istio + Envoy 的 Sidecar 是一种流行的服务网格架构，它将 Envoy 代理作为边车容器注入，以拦截所有进出主容器的流量，提供负载均衡、故障注入和指标收集等功能。但是，存在性能下降、架构复杂性和运营成本增加等考虑因素。init 容器用于设置网络规则，但添加代理会增加资源使用，并且需要自动化操作设置，通常使用 Kubernetes。

5. eBPF 技术概述

使用 Sidecar 模式，正如您可能已经观察到的那样，我们需要在每个单元上部署一个具有适当配置的容器。如果仔细观察，每个节点只有一个内核；在一个节点上运行的所有容器共享同一个内核，我们不能利用它来将部署的 Sidecar 代理的数量减少到节点的数量吗？这将我们引向 eBPF。eBPF 是一种内核技术，可以运行自定义程序以响应各种事件，包括网络数据包、函数访问等。该技术允许自定义程序直接在主机上运行，无需 Sidecar，从而减少了服务网格中部署的 Sidecar 代理的数量。eBPF 驱动的解决方案可以提供可观察性、安全性和网络优势，而无需在每个单元上安装 Sidecar 容器。

https://isovalent.com/blog/post/2021-12-08-ebpf-servicemesh2021 年 12 月 2 日，Cilium 项目宣布了Cilium Service Mesh 的 beta 测试计划。基于 eBPF 的 Cilium 项目将这种“无边车”模型引入服务网格的世界，以处理服务网格中的许多边车代理功能，包括 L7 路由、负载均衡、TLS、访问策略、健康检查、日志记录和追踪。

https://thenewstack.io/how-ebpf-streamlines-the-service-mesh/切换到这种新模式我们有什么好处？YAML 缩减在 Sidecar 模型中，必须修改 YAML 为每个 pod 添加一个 Sidecar 容器，但未能正确标记的命名空间或 Pod 可能会导致 Sidecar 无法注入。支持 eBPF 的 Sidecar-free 代理模型可以在不修改的情况下检测 pod，并将它们包含在服务网格中，即使攻击者绕过 Kubernetes 编排，也可以检测恶意活动。此外，支持 eBPF 的网络通过绕过一些内核网络堆栈来提高性能。网络效率在启用 eBPF 的网络中，数据包可以绕过内核的一些网络堆栈，从而提高性能。让我们看看这如何应用于服务网格数据平面。

https://thenewstack.io/how-ebpf-streamlines-the-service-mesh/在 eBPF 加速和无 Sidecar 的服务网格模型中，网络数据包传递的路径要短得多。在服务网格中，到应用程序的数据包路径很长，导致延迟增加。Cilium 是一个基于 eBPF 的 Kubernetes CNI，可以使用 eBPF 将数据包重定向到更直接的路由并最大限度地减少延迟。服务网格通常用于通过双向 TLS (mTLS) 或使用 IPSec 或 WireGuard 的网络层加密对应用程序流量进行身份验证和加密。网络层加密是一种更简单、更通用的加密选项，因为它适用于节点上的所有流量，而不仅仅是启用了 Sidecar 的工作负载。

6. RSocket 代理

RSocket 路由代理是使用 RSocket 协议在广泛的应用程序之间进行通信的系统。

https://rsocketbyexample.info/java/RSocket Broker 的工作原理是：服务调用者（Requester）向 broker 发起服务调用请求，broker 将请求转发给服务提供者（Responder），broker 最终将响应者的处理结果返回给请求者。

在基于服务的体系结构中，服务提供者和消费者之间的通信由称为 Broker 的中央实体促进。当服务提供者启动时，它会与 Broker 建立持久连接并通知它它可以提供的服务。另一方面，当服务消费者启动时，它也会连接到 Broker。当消费者需要访问远程服务时，它会向充当中介的 Broker 发送消息。Broker 接收消息并使用元信息来解析所需的服务。然后它会查询其路由表以找到合适的服务提供商。选定的服务提供者处理请求并将消息连同结果发送回 Broker。Broker 然后将消息转发给原始服务消费者。消费者接收响应并执行适当的业务逻辑。这种基于 Broker 的消息通信方式具有以下优点：

• 不需要第三方健康检查，因为我们知道连接何时启动

• 无端口监听：服务提供者不再监听端口，与 HTTP REST API 和 gRPC 完全不同，更加安全

• 通信透明：请求者和服务提供者无需感知对方的存在

• 服务注册与发现：无需 Eureka、Consul、ZooKeeper 等第三方注册中心，降低基础设施依赖成本

• 安全性：Broker 会验证服务提供者和服务消费者的访问权限，只需要在 Broker 上部署 TLS 支持即可保证通信通道的安全

没有容易的收获

使用 Broker 也有一些缺点。一个问题是性能可能会受到轻微影响，因为各方之间无法进行直接通信。另一个是所有通信流量都通过 Broker，从而在网络中造成潜在的瓶颈。但是，可以通过拥有高度可靠的集群和 Broker 来减少这种情况。

7.通过 RSocket Broker 进行服务治理

Istio 作为 Service Mesh 解决方案，很难在数据中心外应用。物联网设备呢？每个手机都安装 Sidecar？这就是 RSocket 代理发挥作用的地方。RSocket 路由代理可用于实现服务网格。在下面的方案中，没有运行 Sidecar，也没有重复进程。

https://rsocketbyexample.info/下面是两种架构方案的典型特征对比：

• 基础设施层：一方面是 Sidecar Proxy + Control Plane，另一方面是集成 Control Plane 功能的中心化 Broker。

• 集中管理：集中化会让管理更加全面，比如 Logging、Metrics 等。

• 通信协议：RSocket 方案的一个缺点是应用程序之间必须使用 RSocket 通信协议。

• 效率：RSocket 协议性能比 HTTP 高 10 倍。

• 安全性：RSocket 安全性更简单，依赖于 TLS + JWT，减少攻击面并提供更容易的细粒度权限控制。

• 网络和基础设施依赖：RSocket Broker 比 Istio 有一个优势，因为它不依赖 Kubernetes，而 Istio 仍然需要在 Kubernetes 内部或外部部署和管理 Sidecar 代理，这并不简单。RSocket Broker 可以部署在任何地方，而不依赖于网络或基础设施。

结论

服务治理是微服务时代一个非常重要的成长话题。我们研究了通过 Istio、eBPF 和 RSocket 路由器实现它的不同方法。