转向模式驱动——用buf管理云原生系统的API
前言 最近在对既有系统向云原生改造,为了平衡服务间的独立性、互通性,在参考了Medium和OREILLY的资料后,decoupling服务时决定仅允许服务间通过gRPC调用、不暴露中间件和数据库,因此,需要一个仓库来存放、管理所有的gRPC API,也就是一堆的protobuf文件。 ...
前言 最近在对既有系统向云原生改造,为了平衡服务间的独立性、互通性,在参考了Medium和OREILLY的资料后,decoupling服务时决定仅允许服务间通过gRPC调用、不暴露中间件和数据库,因此,需要一个仓库来存放、管理所有的gRPC API,也就是一堆的protobuf文件。 ...
上一篇文章讲了eBPF Tracepoint和Kprobe,这一篇文章我们来看一下如何应对无BTF的老版本内核,以及如何只使用fd寻找关联的socket结构。 这篇文章的大背景,是需要关联fd、socket结构体指针,以便能够在hook系统调用时,通过fd找到对应的五元组信息。但是问题就在于,尝试了众多方法来关联上述的数据,甚至hook了十几个内核函数,希望包围socket的全生命周期,但是最终都出现了意料之外的结果,非常棘手。 ...
简介 eBPF老生常谈了,这里就不多介绍了,我们直接来看看Tracepoint和Kprobe。 Kprobe是Linux内核中的一个功能,可以实现无感知、动态切入任何内核活动中,并且收集调试和性能信息,一个很典型的使用案例就是切入内核的某个函数中并且获取传入参数和返回值。Kprobe共有两个类型,一个是Kprobe,一个是Kretprobe,他们都被统称为probes,前者用于切入内核函数并且获取传入参数,后者用于切入内核函数并且获取返回值。早期的Kprobe是以内核模块的形式开发,错误的操作会直接导致模块panic,并且可能会影响内核运行的稳定性,而如今,这些代码可以简化成eBPF代码,经过内核的检查才会装入BPF虚拟机中运行,也会限制能够访问的内存、内核函数,这虽然造成了一定的使用不便,但是大幅提高了安全性,也降低了使用难度。 ...
我有一台小主机,来自Lenovo的M73t,CPU型号为i3-4130T,内存为DDR3仅有8GB。这篇文章,我们就一起来看看,如何用这一台已经过时的、仅有两个物理核心的机器,做一台高性能的白盒交换机。 ...
众所周知,Google的gRPC体系可谓是相当好用,在有protoc这样的工具加持下,原本要维护调用侧和服务侧两部分代码,现在写完proto文件直接交给protoc编译一下即可,可谓是减少了不少工作量。但是,如果我就是要兼容HTTP API,那么这又怎么处理呢? ...
好久没写文章了,最近忙于各种事情,再加上过年放假学习,计划文章队列排的老长了。在此,新年第一篇文章,就先祝一下大家新年快乐哈~ eBPF香是香,但是竟然还有内核不支持?博主最近遇到了这么个情况,eBPF程序死活无法加载,始终报出Invalid argument的错误,为了解决这个问题,博主我花了好多天时间排查,跟踪了Linux内核的调用链,最后发现,问题竟然是…(实在想不到好的开头了) ...
众所周知,Go语言里没有原生的RCU一致性原语,这在一些特定场景下,会造成蛮大的性能问题。为了解决这个问题,我们来贴贴地气,在符合适用场景需要的条件下,使用简单粗暴的手段解决问题。 前言 之所以需要RCU,其实是来自于Bridge中FDB(Forwarding Database)场景的一个需要。 ...
上一篇文章我们一块来看了eBPF XDP的性能之路和场景,文中对于Ring也进行了简单的描述,但是真正当我重构起来那个包时,这么多的Ring究竟在内存中的哪个位置?哪些数据之间又是重叠的?本篇文章,我们就来顺腾摸瓜,看看这玩意更低层级是什么样子的。 ...
相信使用过Linux的AF_PACKET类型socket的朋友都知道,性能不是特别好,而且似乎引入了一个新的问题——用户态程序要处理所有来的报文(可能也能绑定socket,博主我没有尝试过),这应该是相当拉胯了。使用eBPF XDP处理完美解决所有问题,还附带了UMEM共享内存,省掉了不少CPU时钟,不仅能解决云原生场景下的一些性能和潜在问题,还能顺带做个SD-WAN,能不香吗?(手动狗头 ...
既可以拥有GoLand代码补全的能力,又可以在Windows上体验到原生的Linux编程调试过程,当开发环境和终端设备能够解耦开的时候,工程随行就成为了可能,开发效率再度+++++到底是什么东西能有这么香?我们来看看~ ...