作者 | Vivian Hu
译者 | 张卫滨
策划 | 辛晓亮
随着 eBPF 和 WebAssembly（WASM）等轻量级运行时的发展，我们现在看到了新一代的服务网状数据平面解决方案，它们更轻便、更安全、更快速。
2021 年 12 月 2 日，Cilium 项目宣布了 Cilium 服务网格的 beta 测试计划。在谷歌云基于 eBPF 的谷歌 Kubernetes 服务（GKS）Dataplane V2（于 2020 年 8 月发布）所开创的概念基础上，Cilium 服务网格倡导“无 sidecar 服务网格”的理念。它扩展了 Cilium eBPF 产品，以处理服务网格中大部分 sidecar 代理的功能，包括 L7 路由和负载均衡、TLS 终止、访问策略、健康检查、日志与跟踪，以及内置的 Kubernetes ingress。
Cillium 的创建者 Isovalent 在一篇题为“eBPF 将如何解决服务网格的问题 -- 再见 Sidecar”的文章中阐述了使用 eBPF 代替 sidecar 代理的理由。
它能够将我们从 sidecar 模型中解放出来，允许我们将现有的代理技术集成到现有的内核命名空间概念中，从而使它们成为我们每天都在使用的容器抽象的一部分。
简而言之，eBPF 承诺会解决服务网格中的一个主要痛点，那就是当存在数量众多的微服务时，会导致较差的性能。但是，使用 eBPF 来取代 sidecar 是一个新的想法，并非没有争议。
（来源：eBPF 将如何解决服务网格的问题 -- 再见 Sidecar）
在服务网格中，数据平面指的是基础设施服务，它会管理数据流量如何路由和投递给微服务应用。目前，这主要是通过使用服务代理实现的。这种设计模式通常被称为 sidecar 模式。sidecar 能够允许其关联的微服务以透明的方式向服务网格中的其他组件发送和接收请求。
sidecar 一般会包含一个 L7 的网络代理，比如 Envoy、Linkerd 或 MOSN。代理要处理流量路由、负载平衡、健康检查、认证、授权、加密、日志、跟踪和统计数据收集。sidecar 还可以包含一个基于 SDK 的应用框架，比如 Dapr，以提供网络代理之外的应用服务。举例来讲，这种应用服务包括服务注册、服务发现、资源绑定、基于名字的服务调用、状态管理、actor 框架和 secret 存储。
sidecar 代理和服务通常会在 Kubernetes pod 或容器中运行。微服务应用也会在容器中运行，它们通过网络接口关联到 sidecar 上。但是，这种容器化应用的方式有一个明显的问题那就是资源的消耗。sidecar 服务会随着微服务的数量呈几何级数增加。当一个应用有数百个相关连接和负载均衡的微服务时，所带来的开销就会变得难以承受。服务网格代理供应商在性能方面展开了竞争。正如 InfoQ 最近所报道的，Linkerd 使用 Rust 重写了原本基于 Go 实现的代理，并取得了明显的性能提升。
不出意料的是，现有的服务网格供应商并不相信 eBPF 会是解决我们所有问题的灵丹妙药。来自 Solo.io（一个基于 Envoy Proxy 和 Istio 的领先的服务网格供应商）的 Idit Levine 等人撰写了一篇文章来回应 Cilium 的公告。该文章的标题就是“用于服务网格的 eBPF？是的，但 Envoy 代理将会继续存在”。
在 Solo.io，我们认为 eBPF 是一个优化服务网格的强大方式，同时，我们也认为 Envoy 代理是数据平面的基石。
Solo.io 作者提出的关键点是，sidecar 代理现在的作用远远超过了简单的网络流量管理。如今的服务网格部署有复杂的要求，远远超过了 eBPF 所支持的有限的编程模型，eBPF 是图灵不完备的，对内核的安全有许多限制。Cilium eBPF 的产品可以解决许多 sidecar 代理所能处理的各种任务，但不是全部。此外，Solo.io 的作者指出，eBPF 的每个节点一个代理（one-proxy-per-node）的设置提供了更少的灵活性，因此与传统代理的每个 pod 一个代理（one-proxy-per-pod）的设置相比，会增加整体的开销。如果开发者必须编写应用程序特定的流量路由、负载平衡和授权等逻辑并将其部署到服务网格中的话，那么 eBPF 的这些缺点会更加明显。
Terate.io 的开发人员在对 Cilium 公告的回应中提出了类似的论点，他们撰写了一篇名为“社区中关于 Istio 和服务网格的争论”的博客文章。他们指出，如今的 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。来源：WasmEdge Book）
此外，Wasm 可以作为一个通用的应用容器。在服务网格的数据平面方面，它的应用并不局限于 sidecar 代理。关联到 sidecar 的微服务可以在它自己的轻量级 Wasm 运行时中运行。WasmEdge WebAssembly 运行时是一个安全、轻量级、快速、可移植和支持多语言的运行时，可以直接由 Kubernetes 作为容器管理。截止 2021 年 12 月，WasmEdge 社区的贡献者证明了基于 WasmEdge 的微服务可以与 Dapr 和 Linkerd 的 sidecar 一起工作，能够替代重量级的完整 Linux 容器，而这种完整的容器通常都需要 guest OS 和完备的软件栈。与 Linux 容器应用相比，WebAssembly 微服务仅消耗 1% 的资源，冷启动时间为 1%。
eBPF 和 Wasm 是服务网格应用在数据平面上实现高性能的新生力量。它们仍然是新生的技术，但有可能成为今天微服务生态系统中 Linux 容器的替代品或补充。
关于作者
Vivian HuVivian 是来自亚洲的一个开源爱好者和开发者倡导者。她是 Second State 的产品经理。她非常关注如何通过更好的工具、文档和教程来改善开发者的体验和生产力。Vivian 在 WebAssembly.today 上为 WebAssembly、Rust 和无服务器技术撰写了一份每周新闻通讯。
查看英文原文：
https://www.infoq.com/news/2022/01/ebpf-wasm-service-mesh/
