原文：https://www.solo.io/blog/ebpf-for-service-mesh/
我们在 Solo.io 的目标是围绕应用程序网络和服务连接为我们的客户带来有价值的解决方案。早在 10 月，我们就宣布了使用 eBPF 增强我们的企业服务网格产品 (Gloo Mesh Enterprise) 的计划，以优化围绕网络、可观察性和安全性的功能。eBPF 在多大程度上可以在服务网格中发挥作用？ 服务代理的角色如何变化？ 在这篇博客中，我们将深入探讨 eBPF 在服务网格数据平面中的作用，以及各种数据平面架构的一些权衡。
对服务代理说再见？
服务网格（ServiceMesh）为服务提供复杂的应用程序网络行为，例如服务发现、流量路由、弹性（超时/重试/熔断）认证，鉴权，可观测性（日志/监控/追踪）。我们可以使用 eBPF 将所有这些功能重写到内核中吗？
简短的回答：这将是相当困难的，而且可能不是正确的方法。eBPF 是一个事件处理模型，对它的运行方式有一些限制。你可以将 eBPF 模式视为内核的“功能即服务（faas）”。例如，在内核中安全执行之前，必须完全了解和验证 eBPF 执行路径。eBPF 程序不能有任意循环，其中的验证者不知道程序何时停止执行。简而言之，eBPF 是图灵不完整的。
七层协议（如各种协议编码器、重试、数据头操作等）单独在 eBPF 中实现可能非常复杂，并且没有更好的内核原生支持。也许这种支持会有，但这可能需要数年时间，并且不会在旧版本上提供。在许多方面，eBPF 是 O(1) 复杂度的理想选择（例如检查数据包、操作一些数据位并在途中发送它）。实现像 HTTP/2 和 gRPC 这样的复杂协议可能是O(n)复杂度并且非常难以调试。那么这些7层功能可以驻留在哪里呢？
Envoy 代理已成为服务网格实现的标准，并且对我们大多数客户所需的第七层功能有很好的支持。尽管 eBPF 和内核可用于改进网络的执行（短路最佳路径、卸载 TLS/mTLS、可监测性收集等），但复杂的协议协商、解析和用户扩展仍可以保留在用户空间中。对于第七层的复杂性，Envoy 仍然是服务网格的数据平面。