• 什么是eBPF？
• 为什么需要eBPF？
• 如何使用eBPF？
• 使用eBPF时应该注意？
• eBPF的应用领域？
• eBPF的优缺点？
  • 优点
  • 缺点
• 推荐阅读

按照惯例，第一篇先来个概览，做一些基础知识的铺垫。

目前这个技术领域还相对较“新”，本人也刚刚开始摸索学习，有错误的地方还请大佬们多多指正。

什么是eBPF？

eBPF由BPF(Berkeley Packet Filter)扩展而来，提供了一种在内核事件和用户程序事件发生时安全注入代码的机制，使得非内核开发人员也可以对内核进行控制，无需修改内核源码和重新编译内核就可以扩展内核的功能。（简单类比的话，就类似未成年人可以在有限的范围内安全的做一些成年人才能做的事了）

之前想对内核做点什么，需要编写内核模块后编译进去，一个不小心就把内核搞崩了。而eBPF则通过即时编译器(JIT)，保证只有经过验证的、安全的eBFP指令才会被内核执行。

为什么需要eBPF？

从业界的角度看，最主要的因素还是对性能的追求。比如，小规模的k8s使用iptables就可以搞定容器网络通信，但随着规模的增大iptables性能问题越发明显，然后就有了IPVS模式。虽然IPVS和iptables都是基于Netfilter，但由于IPVS使用哈希表而iptables使用规则链表，导致前者的性能高于后者。然后随着集群规模的再次扩大，对性能有了更高的要求，于是乎eBPF就成了目前进一步提高性能的技术方案：

The aforementioned KubeCon Talk performed specific measurements on iptables as a bottleneck for Kubernetes service forwarding and noted that throughput degraded by ~30% with 5,000 services deployed, and by 80% with 10,000 services (a 6X performance difference). Likewise, rule updates at 5,000 services took 11 minutes, ages in a world of continuous delivery.

Thanks to the flexibility of BPF, Cilium performs this same operation with O(1) average runtime behavior using a simple BPF map based hash table, meaning the lookup latency at 10,000 or even 20,000 services is constant. Likewise, updates to these BPF maps from userspace are highly-efficient, meaning that even with 20,000+ services, the time to update a forwarding rule is microseconds, not hours.

For these reasons, Facebook has recently presented their use of BPF and XDP for load-balancing in a public talk to replace IPVS after measuring an almost 10x performance increase.

最近看ebpf相关技术，找到一篇2015年的老文，现在看依然不过时——原文。

当你为了性能问题而登录到Linux系统时，首先要检查哪些东西呢？

在奈飞有大量的Linux机器，并且有众多的工具去监控和分析性能。既包括负责整个云范围的监控工具Atlas，也包括单个实例分析的Vector。尽管这些工具帮助我们解决了很多问题，但是有些时候我们还是需要登录到实例上去执行一些标准Linux指令。

原文地址：这里，省略了一些非重点片段。

Open/Closed Principle（OCP，开闭原则）也不过多介绍了，一句话“对扩展开放，对修改封闭”。策略模式就是这一原则的一种实现。

原文地址：这里，省略了一些非重点片段。

The Single Responsibility Principle (SRP，单一职责原则)的文字定义这里我就不再次说明了，直接开始重点。

原文地址：这里，省略了一些非重点片段。

先定义一个结构体Pubsub，客户端可以使用它来订阅、发布主题：

type Pubsub struct {
  mu   sync.RWMutex
  subs map[string][]chan string
}

断断续续写博客居然有8年时间了啊……

5年前，博客从wordpress迁移到了hexo+github静态页面，用着不错之后就一直懒得折腾。但五一假期想写博客发现安装nodejs和hexo3版本怎么也搞不定，看报错提示似乎是某些依赖库已经不支持老版本了，干脆一不做二不休整体替换成hugo+Mainroad主题。要不电脑里又得装python又得装golang还得装nodejs，也是麻烦。