2021 年 12 月 2 日，Cilium 项目宣布了 Cilium Service Mesh 的 beta 测试计划。基于 Google Cloud 基于 eBPF 的 Google Kubernetes Service (GKS) Dataplane V2 开创的概念，Cilium Service Mesh 于一年前于 2020 年 8 月宣布，推广了“无边服务网格”的理念。它扩展了 Cilium eBPF 产品以处理服务网格中的大部分 Sidecar 代理功能，包括 L7 路由和负载平衡、TLS 终止、访问策略、健康检查、日志记录和跟踪以及内置的 Kubernetes 入口。
Cillium 的创建者 Isovalent 在题为“eBPF 如何解决服务网格 - 再见 Sidecars”的文章中解释了使用 eBPF 作为 sidecar 代理的替代方案的基本原理。
它将我们从 sidecar 模型中解放出来，并允许我们将现有的代理技术集成到现有的内核命名空间概念中，从而使它们成为我们每天都在使用的美丽容器抽象的一部分。
简而言之，eBPF 承诺解决服务网格中的一个主要痛点——当有许多细粒度的微服务时缺乏性能。然而，使用 eBPF 代替 sidecar 代理是一个新颖的想法，并非没有争议。
(source: How eBPF will solve Service Mesh - Goodbye Sidecars)
服务网格中的数据平面是指管理数据流量如何路由和传递到微服务应用程序的基础设施服务。目前，这是通过使用服务代理来实现的。这种设计模式通常也被称为边车模式。Sidecar 允许其附加的微服务透明地向服务网格中的其他组件发出和接收请求。
Sidecar 通常包含一个 L7 网络代理，例如 Envoy、Linkerd 或 MOSN。代理处理流量路由、负载平衡、健康检查、身份验证、授权、加密、日志记录、跟踪和统计信息收集。Sidecar 还可以包含基于 SDK 的应用程序框架，例如 Dapr，以提供网络代理之外的应用程序服务。此类应用服务的示例包括服务注册、服务发现、资源绑定、基于名称的服务调用、状态管理、参与者框架和秘密存储。
Sidecar 代理和服务通常在 Kubernetes pod 或容器中运行。微服务应用程序也在容器内运行，它们通过网络接口连接到 sidecar。但是，这些容器化应用程序的一个重要问题是资源消耗。Sidecar 服务随着微服务的数量呈几何级数增长。当应用程序具有数百个相互关联且负载平衡的微服务时，开销可能会变得不堪重负。服务网格代理供应者在性能上展开竞争。正如 InfoQ 之前报道的那样，Linkerd 将其代理从 Go 重写为 Rust，并取得了显着的性能提升。
不出所料，现有的服务网格提供者并不认为 eBPF 是解决我们所有问题的圣杯。伊迪特莱文等人。来自基于 Envoy Proxy 和 Istio 的领先服务网格提供者 Solo.io 写了一篇文章来回应 Cilium 的公告。这篇文章的标题是“eBPF for Service Mesh？是的，但是 Envoy Proxy 将继续存在”。
在 Solo.io，我们将 eBPF 视为优化服务网格的强大方法，并将 Envoy 代理视为数据平面的基石。
Solo.io 作者提出的关键点是，sidecar 代理现在所做的不仅仅是简单的网络流量管理。当今的服务网格部署有复杂的需求，远远超出了 eBPF 支持的有限编程模型，这是图灵不完整的，并且对内核的安全性有许多限制。Cilium eBPF 产品可以处理由 sidecar 代理执行的许多但不是全部的各种任务。此外，Solo.io 的作者指出，与传统代理的每个 pod 一个代理设置相比，eBPF 的每个节点一个代理设置提供的灵活性要小得多，因此增加了总体开销。这些 eBPF 缺点对于开发人员必须编写和部署到服务网格代理中的流量路由、负载平衡和授权的应用程序特定逻辑尤其明显。
Terate.io 的开发人员在对 Cilium 公告“社区中关于 Istio 和 Service Mesh 的辩论”的回应中提出了类似的论点。他们指出，今天的 sidecar 代理的性能是合理的，开源社区已经想出了进一步提高性能的方法。同时，开发人员很难在像 eBPF 这样新颖且图灵不完备的技术中构建特定于应用程序的数据平面逻辑。
Istio 架构稳定且可用于生产，生态系统正在萌芽。
eBPF 的许多问题都与它是一种内核技术有关，因此必须有安全限制。有没有一种方法可以将复杂的特定于应用程序的代理逻辑合并到数据平面中，而不会使用使用空间技术降低性能？事实证明，WebAssembly (Wasm) 可能就是这样的选择。Wasm 运行时可以以接近本机的性能安全地隔离和执行用户空间代码。
Envoy Proxy 开创了使用 Wasm 作为扩展机制来对数据平面进行编程的方法。开发人员可以使用 C、C++、Rust、AssemblyScript、Swift 和 TinyGo 等语言编写特定于应用程序的代理逻辑，并将模块编译成 Wasm。通过 proxy-Wasm 标准，代理可以在 Wasmtime 和 WasmEdge 等高性能运行时执行那些 Wasm 插件。目前，Envoy Proxy、Istio Proxy、MOSN 和 OpenResty 都支持 proxy-Wasm。
(Wasm in the container ecosystem. Source: WasmEdge Book)
此外，Wasm 可以充当通用应用程序容器。它在服务网格数据平面上的应用不仅限于 sidecar 代理。附加到 sidecar 的微服务可以在其自己的轻量级 Wasm 运行时中运行。WasmEdge WebAssembly Runtime 是一个安全、轻量级、快速、可移植和多语言的运行时，可以由 Kubernetes 作为容器直接管理。到 2021 年 12 月，WasmEdge 贡献者社区证明，基于 WasmEdge 的微服务可以与 Dapr 和 Linkerd 边车一起使用，作为具有来宾操作系统和完整软件堆栈的重量级成熟 Linux 容器的替代方案。与 Linux 容器应用程序相比，WebAssembly 微服务消耗 1% 的资源，冷启动时间为 1%。
eBPF 和 Wasm 是服务网格应用程序在数据平面中实现高性能的新手。它们仍然是新兴技术，但有可能成为微服务生态系统中当今 Linux 容器的替代品或补充品。
