为什么说 eBPF 是神器？

是不是神器，有对比就能看出来。

以前我们使用 APM Agent 来实现可观测性，它对于业务代码的侵扰性使得落地和维护非常困难，它在云原生环境下的盲点使得故障定界非常困难。

首先是侵扰性：

比如说我们把一个 SDK 或者一个 Java Agent 插入到一个应用程序里面来以后，此时应用程序已经变了。现在来发起一个灵魂拷问：我们本来要观测的原始程序 A，在插入 SDK 或 Java Agent 以后已经变成了 B，此时我们到底是实现了 A 的可观测性，还是 B 的可观测性？

被迫插桩后的应用，还是以前那个应用吗？

不仅如此，之后还有一堆随之而来的问题：

代码冲突：多个 Java Agent 运行时冲突，或者 SDK 依赖库版本编译时冲突，怎么办？
维护困难：Agent 多久可发版一次，要维护多少个版本，要适配多少种语言？
边界模糊：预期之外的性能衰减、运行故障，是谁的锅？

我们可以看到，这些障碍使得 APM Agent 这种方式不适合作为一个服务能力来跨团队提供，它只能是开发团队的一个自主行为，而且是开发人员可以百花齐放灵活选择具体方案的行为。而 SkyWalking 等开源社区的火热其实也间接说明了一点，APM 在开发者主导的开源领域获得了成功，但难以（至少尚未）在企业服务领域复制这样的成功。在一些非常核心的领域，例如金融、能源、电信、制造等行业，由于部门分工细致、软件外采普遍等特点，插桩的方案很难落地。

此外是盲点：

在云原生的场景下，两个 APP 之间的通信其实是很复杂的。除了业务代码框架代码以外，还有更复杂的网络传输、系统调用、数据库访问、中间件访问、各种网关和代理转发等等。而除了业务代码和框架代码以外，复杂的云原生基础设施通信路径都难以插桩。这时候出了问题，定界十分困难。

比如说，一个 Pod 访问一个云服务发生了故障，作为一个开发，你的责任边界是这个 Pod 内的应用进程，但是你去提工单的时候，怎么确定要提给哪个部门？一个 Pod 里面有很复杂的通信路径，从业务代码到系统调用，再到网络收发，可能还会有 Sidecar 的流量拦截，出了 Pod 以后还有 IPVS，到 KVM 以后还有 vSwitch/Bridge，可以看到非常复杂，而且基本上每一跳关键节点都无法插桩。此时问题的定界基本靠猜。

我们认为，eBPF 是解决侵扰性和盲点的绝佳方案。eBPF 可以去追踪服务内的行为，也可以去追踪服务间的行为，全程零侵扰，不用改代码，当天部署当天就能用；遇到问题，由于它的全栈覆盖能力，通常 5 分钟就能完成定界。

没有 eBPF，插桩只能靠强推，盲点定界只能靠瞎猜。而有了 eBPF ，这些都不是问题，真正的云原生应用可观测性才能得以实现，你说它是不是神器？