为什么 eBPF 如此受欢迎？
eBPF 是一个基于寄存器的虚拟机，最初是为过滤网络数据包而设计的，由于最初的论文[1]是在伯克利实验室（Lawrence Berkeley National Laboratory）写的，所以被称为扩展的伯克利数据包过滤器（Extended Berkeley Packet Filter），也就是 eBPF。本文将会用通俗易懂地语言给大家解释 eBPF 为什么这么受欢迎。
eBPF 介绍
通俗地讲，eBPF 是当有事件触发时，在操作系统的内核中运行的自定义程序，你可以把 eBPF 程序看成事件驱动的函数（比如 AWS lamda，👉OpenFunction）。eBPF 程序可以访问内核函数的子集以及内存，当 eBPF 程序被加载到内核中时，会有一个验证器来确保它是安全运行的，如果无法确认，就会被拒绝运行。也就是说，即使是垃圾 eBPF 代码也不会让内核崩溃。
在容器世界里，eBPF 正变得越来越流行，目前最流行的产品是 Cilium[2] 和 Pixie[3]。其中 Cilium 是基于 eBPF 的 CNI 插件，同时还提供了无需 Sidecar 的 Service Mesh[4]。
而 Pixie 则专注于使用 eBPF 来实现可观测性。
更多 eBPF 使用场景：
- 调试与追踪：追踪任意系统调用，内核函数，以及用户空间的任意进程。代表工具：bpftrace[5]。
- 网络：监测、过滤、控制流量。用户空间的程序可以在任意 Socket 上面附加一个过滤器，用来监测经过它的流量，并对其进行各种操作，比如允许通过、拒绝通过、重定向等等。
- 安全监控与隔离：eBPF 程序可以监测并报告内核中发生的系统调用，也可以阻止应用在内核中执行某些系统调用（例如删除文件）。
尽管 Linux 早已支持上述的这些功能，但 eBPF 可以帮助我们更高效地执行这些任务，消耗的 CPU 和内存资源更少。
eBPF 为什么这么高效？
eBPF 程序比传统程序“跑得”更快，因为它的代码是直接在内核空间中执行的。
设想这样一个场景，假设一个程序想要统计其从 Linux 系统上发送出去的字节数，需要经过哪些步骤？
首先，网络活动发生时，内核会生成原始数据，这些原始数据包含了大量的信息，而且大部分信息都与“字节数”这个信息无关。所以，无论生成的原始数据是个啥，只要你想统计发送出去的字节数，就必须反复过滤，并对其进行数学计算。这个过程每分钟要重复数百次（甚至更多）。
传统的监控程序都运行在用户空间，内核生成的所有原始数据都必须从内核空间复制到用户空间，这种数据复制和过滤的操作会对 CPU 造成极大的负担。这就是为什么 ptrace 很“慢”，而 bpftrace[6] 很”快“。
eBPF 无需将数据从内核空间复制到用户空间，你可以直接在内核空间运行监控程序来聚合可观测性数据，并将其发送到用户空间。eBPF 也可以直接在内核空间过滤数据以及创建 Histogram，这比在用户空间和内核空间之间交换大量数据要快得多。
eBPF 映射（eBPF Map）
eBPF 还有一个黑科技，它会使用 eBPF 映射（eBPF Map）来允许用户空间和内核空间之间进行双向数据交换。在 Linux 中，映射（Map）是一种通用的存储类型，用于在用户空间和内核空间之间共享数据，它们是驻留在内核中的键值存储。
对于可观测性这种应用场景，eBPF 程序会直接在内核空间进行计算，并将结果写入用户空间应用程序可以读取/写入的 eBPF 映射中。
现在你应该理解为什么 eBPF 这么高效了吧？主要还是 eBPF 提供了一种直接在内核空间运行自定义程序，并且避免了在内核空间和用户空间之间复制无关数据的方法。
参考资料
- What Is eBPF?[7]
引用链接
[1]
论文: https://www.tcpdump.org/papers/bpf-usenix93.pdf
[2]
Cilium: https://github.com/cilium/cilium
[3]
Pixie: https://github.com/pixie-io/pixie
[4]
无需 Sidecar 的 Service Mesh: https://cilium.io/blog/2021/12/01/cilium-service-mesh-beta
[5]
bpftrace: https://github.com/iovisor/bpftrace
[6]
bpftrace: https://github.com/iovisor/bpftrace
[7]
What Is eBPF?: https://www.oreilly.com/library/view/what-is-ebpf/9781492097266/