共计 2530 个字符，预计需要花费 7 分钟才能阅读完成。
本文翻译自 Vivian Hu 的《eBPF and Wasm: Exploring the Future of the Service Mesh Data Plane》。
在 2021 年 12 月 2 日，Cilium 我的项目发表了 Cilium Service Mesh 我的项目的测试版。在 2020 年 8 月 Google Cloud 发表基于 eBPF 的 Google Kubernetes 服务（GKS）的数据立体 V2 的一年后，Cilium Service Mesh 带来了“无际车服务网格”（sidecarless service mesh）的想法。它扩大了 Cilium eBPF 产品来解决服务网格中的大部分边车代理性能，包含 7 层路由和负载平衡、TLS 终止、拜访策略、健康检查、日志和跟踪，以及内置的 Kubernetes Ingress。
Cilium 的创始人 Isovalent 在一篇名为“How eBPF will solve Service Mesh – Goodbye Sidecars”的文章中解释了 eBPF 如何代替边车代理。
它将咱们从边车模型中解放解决，并容许咱们将现有的代理技术集成到现有的内核命名空间概念中，使其成为日常应用的优雅容器形象的一部分。
简而言之，eBPF 承诺会解决服务网格中的重要痛点 — 当有许多细粒度微服务时的性能损耗。然而，应用 eBPF 替换边车代理这种新鲜的想法，也存在着争议。
服务网格中的数据立体是指治理数据流量如何路由和服务之间的流转的基础设施服务。目前，这是通过应用服务代理实现的。这种设计模式也通常被称为边车模式。边车容许其附加的微服务通明地向服务网格中的其余组件发送和接管申请。
边车通常蕴含了 7 层代理，比方 Envoy、Linkerd 或者 MOSN。该代理解决流量的路由、负载平衡、健康检查、身份验证、受权、加密、日志、跟踪和统计数据收集。边车还能够蕴含一个基于 SDK 的应用程序框架（比方 Dapr）以提供网络代理以外的应用程序服务。此类服务的示例还蕴含了服务注册、服务发现、资源绑定、基于名称的服务调用、状态治理、actor 框架 和密钥存储。
边车代理通常在 Kubernetes Pod 或者容器中运行。微服务利用也同样运行在容器内，并通过网络接口连贯到边车。然而，这些容器化应用程序的一个重要问题就是资源耗费。边车服务随着微服务的数量几何级增长。当应用程序有数百个互联和负载平衡的微服务时，开销变得难以承受。服务网格代理商开始了性能上的竞争。正如 Infoq 之前报道的那样，Linkerd 将其 Go 写的代理用 Rust 重写了，并取得了显著的性能晋升。
并不奇怪，现有的服务网格提供商不置信 eBPF 是解决所有问题的圣杯。Solo.io 的 Idit Levine 等人针对 Cilium 的这篇布告撰写了一篇文章“eBPF for Service Mesh? Yes, But Envoy Proxy is Here to Stay”。
在 Solo.io，咱们认为 eBPF 是优化服务网格的很好的形式，并将 Envoy 代理视为数据立体的基石。
Solo.io 作者提出的观点是：边车代理当初所做的不仅仅是简略的网络流量治理。当今的服务网格部署中有着简单的需要，远超过 eBPF 反对的无限编程模型，其不合乎图灵齐备性且受到内核平安的诸多限度。Cilium eBPF 产品能够解决边车代理许多但并不是全副的工作。此外，Solo.io 的作者还指出，eBPF 的节点级代理与传统的 Pod 级边车代理相比不足灵活性，反而减少了整体开销。eBPF 缺点在开发人员必须编写并部署到服务网格代理中的流量路由、负载平衡和受权的特定利用程序逻辑中体现得尤为显著。
Terate.io 的开发人员在回应名为 [The Debate in the Community about Istio and Service Mesh]() 的 Cilium 布告中也提出了相似的观点。他们指出，以后边车代理的性能是正当的，开源社区也曾经有了进一步提高性能的办法。与此同时，开发人员很难在 eBPF 等新鲜但图灵不残缺的技术中构建应用程序特定的数据立体逻辑。
Istio 架构稳固且生产就绪，生态系统正在发展期。
eBPF 的许多问题与其是一种内核技术分不开，必然收到平安限度。有没有一种办法能够在不应用空间技术升高性能的状况下将简单的应用程序特定的代理逻辑集成到数据立体中？事实证明，WebAssembly（Wasm）可能会是个抉择。Wasm 运行时能够以近似原生性能平安地隔离和执行用户空间代码。
Envoy Proxy 率先应用 Wasm 作为扩大机制对数据立体的编程。开发人员能够用 C、C++、Rust、AssemblyScript、Swift 和 TinyGO 等语言编写应用程序特定的代理逻辑，并将模块编译为 Wasm。通过 proxy-Wasm 规范，代理能够在例如 Wasmtime 和 WasmEdge 的高性能运行时执行这些 Wasm 插件。目前，Envoy 代理、Istio 代理、MOSN 和 OpenResty 反对 proxy-Wasm。
此外，Wasm 能够充当通用应用程序容器。它在服务网格数据立体上的利用不仅限于边车代理。附加到边车的微服务也能够运行在轻量级 Wasm 运行时中。WasmEdge WebAssembly 运行时是一个平安、轻量级、疾速、便携式和多语言运行时，Kubernetes 能够间接将其作为容器进行治理。到 2012 年 12 月，WasmEdge 贡献者社区验证了基于 WasEdge 的微服务能够与 Dapr 和 Linkerd 边车一起工作，作为带有 guest 操作系统和残缺软件对战的重量级 Linux 容器的替代品。与 Linux 容器应用程序相比，WebAssembly 微服务耗费了 1% 的资源，冷启动工夫也只用了 1%。
eBPF 和 Wasm 是服务网格利用的新方向，以便在数据立体上实现高性能。他们依然是新兴技术，但可能会成为微服务生态系统 Linux 容器的替代品或者补充。
对于作者：
Vivian Hu：Vivian 是亚洲的开源爱好者和开发人员倡导者，Second State 的产品经理。她十分关怀通过更好的工具、文档和教程来改善开发人员体验和生产力。Vivian 在 WebAssembly.today 上为 WebAssembly、Rust 和无服务器编写每周时事通信。
文章对立公布在公众号
云原生指北
