• 152465

    文章

  • 1250

    评论

  • 10

    友链

  • 最近新加了换肤功能,大家多来逛逛吧~~~~
  • 喜欢这个网站的朋友可以加一下QQ群,我们一起交流技术。

我们这群90后,正在字节跳动“死磕”Linux内核

近日,字节跳动STE团队受邀参加 InfoQ-中国卓越技术团队访谈,与大家分享了STE团队在 Linux 内核领域的技术实践经验与开源贡献,以及团队背后的故事与精神文化,让我们一起来看看吧~

随着互联网的快速更迭,许多明星产品在时代的光环下熠熠生辉;但在喧闹的背后,有这样的一个群体,默默的守护着互联网世界的平稳,今天我们就来介绍这样一群幕后守护者。

2012 - 2022,是字节跳动产品线快速延伸的十年,也是基础设施规模快速增长的十年。在这背后,有这样一支团队默默为字节上层业务的稳定保驾护航,他们就是字节系统部 STE 团队。

早在 2015 年,STE 团队就初具雏形,当时主要是问题驱动,为字节内部基础设施及软件系统提供技术支持。随着 2017 年抖音等热门产品用户量级大爆发、成为现象级 APP,字节内部的服务器规模愈发庞大,对系统的维护工作也成为重中之重。

2018 年,团队被正式命名为 STE(全称:System Technologies & Engineering,系统技术与工程)。如今,STE 团队已从最初的 20 人扩大至数百人规模,在英国、美国等多地设有研发中心。技术维度也从操作系统内核扩展到服务器固件、编译器技术、系统虚拟化、主机网络、系统智能运维等基础技术,并将基础软件工程能力赋能业务。

在本期访谈中,InfoQ 有幸采访到了 STE 内核方向的多位核心成员,了解他们在 Linux 内核优化上的技术实践与经验,以及这些工作为业务带来的价值,同时一窥这支专注于底层基础设施建设、在“看不见的地方”用技术构筑城墙的团队的精神和文化。

专注Linux内核的90后团队

据了解,STE 内核团队是字节系统部面向公司内部所有业务提供 Linux 内核服务的团队,主要负责内核管理、进程调度、虚拟化和网络等几个方面的工作。据 STE 内核团队负责人段熊春介绍,在 2015 年 STE 团队初具雏形的时候,就有研发人员负责内核相关的工作。2018 年,STE 团队正式成立,内核方向也作为其下属团队之一,逐步扩建成有专职研发人员负责解决 Linux 内核存在的问题,并增加和维护新特性。

我们注意到,这是一支非常年轻的团队,内核维护者以 90 后居多,这其实并不常见。毕竟 “Linux 之父”Linus Torvalds 曾感慨,“目前的维护者多是 50、60 后,社区面临代际更新问题。”Linus Torvalds 甚至担心,在他们这批 Linux 内核维护者老去之后,很难再找到新的继任者,因为很多年轻开发者认为“Linux 内核项目并不那么有趣”。

STE 团队的负责人张宇深耕于系统技术领域多年,对此他也表示,“现在专注在底层基础软件、操作系统内核上的人才越来越匮乏,甚至出现了两种极端:一种是开发者的计算机基础非常扎实,底子好,但对内核研发并不感兴趣;一种是对内核非常感兴趣,但底子薄,需要补功课。同时具备这两方面优势的人才非常少。对于我们内核团队而言,年轻是我们的优势,正是这种对内核技术的痴迷和热爱,才让我们走到了一起。”

向团队中注入新鲜的血液并不难,难的是如何让这些年轻人在 Linux 内核方向愈战愈勇、愈走愈远。对此,张宇提到了两个字:激发。给年轻人平台,激发其兴趣;给年轻人机会,激发其斗志。“我们也有很多资深的开发者,但他们更倾向于把好的机会留给年轻人。这种‘传帮带’的传统,能够让年轻开发者有机会站到台前,越做越有信心。否则,如果年轻人持续得不到鼓励、不被激发,在这条艰辛的道路上就很难做出成绩、走得长远。”张宇提到。

正是在这种文化氛围的熏陶下,STE 内核团队依托于 Linux 内核,在虚拟化、云原生、eBPF 等技术方向都有非常硬核的输出。比如,2020 年 9 月,团队向 Linux 内核社区贡献了 HVO 方案,该方案能够解决 Linux 内核内存管理冗余这一难题。

困扰业内数十年的Linux内核内存管理冗余,有了解法

从 Linus Torvalds 在 1991 年发布第一版开始,Linux 内核迄今已发展了 30 余年。据称,第一版的 Linux 内核只有 10250 行代码,占用 65 KB,而如今,Linux 内核代码行数早已超过 2700 万。

Linux 内核每年新增 / 删除的代码多达百万行,也加入了越来越多优秀的特性。这样一个复杂且臃肿的工程,在不同的业务场景下,势必会面临各式各样的挑战。

支撑字节全量服务器运转的正是 Linux 操作系统。STE 内核团队发现,一些云计算的场景会带来额外的内存管理开销,随着服务器规模越来越大,这种损耗也会成倍放大。

“Linux 内核以页(一般 4 KB)为单位管理物理内存。每个 4 KB 页对应一个 struct page 结构体。使用一个 struct page 管理一个页,这本身没什么问题。但是当使用的页的大小是 2 MB 甚至 1 GB 时,Linux 依然以 4 KB 为单位分配 struct page,这显然是个内存浪费的行为。我的目的就是尽可能减少这部分冗余的内存管理开销。”说这话的是 STE 工程师宋牧春。2019 年 7 月,宋牧春加入字节 STE 内核团队,三年时间,宋牧春随团队一同成长,也完成了从 Linux 内核开发者到 Linux 内核维护者的转变,并成为 Linux 内核社区 HugeTLB 和 Memory Cgroup 两个核心子模块的 maintainer。

实际上,Linux 内核内存管理冗余并不是一个新问题,它在业内已存在十年之久。过去不少公司都做过研究,但始终没有找到解法。即便如此,STE 内核团队依然想做一些尝试。在不断地讨论、验证各种方案的可行性后,团队发现这个问题是有可能被解决的。

“某些场景会使用到大页,每个大页需要 8 个页的 struct page 去管理,即 8X4K 的内存,我们希望最终只占用一个页的物理内存(4KB)。对此,我们想的方案是复用,把后面 7 个虚拟地址映射到唯一的物理页,如果方案能成功落地,则意味着 1T 的服务器,最大能节省接近 16GB 的内存。即使优化 1%,整体给公司带来的收益也会非常大。”宋牧春说道。

这套方案被称作 HVO (HugeTLB Vmemmap Optimization)。方案有了,下一步就是做代码调研。

Linux 内核管理是非常复杂且核心的一个模块,它和各个模块交织在一起,它的稳定性也必然会影响整个 Linux 内核的稳定性。因此,STE 内核团队需要尽可能地减少该方案代码涉及的范围,并确保不会影响系统里的其他功能。为此,从 2020 年 4 月到 2021 年 6 月,团队开始了长达一年时间的代码调研、开发、测试和重构。

用一年的时间,解决一个技术难题,值得吗?段熊春给出了肯定的回答。

“我们会衡量这件事情的价值,显然我们也面临着很多压力,但真正难的事情是需要投入更多时间去看的,我们也需要这样做。基于对技术的狂热,我们周末也经常聚在一起讨论和思考,再把这些想法带到实际场景中,更好的打磨和优化。这是一个长期的过程,而这些突破也能为公司和业界带来巨大的收入,这就是有价值的。”

同时,HVO 也得到了业界的广泛认可:华为、Google、AWS、甲骨文都准备将这个方案投入使用,还有公司向团队发来感谢信。“但这不是终点,我们会持续优化 HVO 方案。”段熊春说道。

Linux内核云原生技术新探索

设备虚拟化技术作为云计算领域最重要的基础技术之一,多年来一直在稳步向前演进。其中,virtio 和 VFIO 在过去一直是最主流的设备虚拟化技术,并分别于 2008 年、2012 年被合入 Linux 内核主线。为了将 virtio 和 VFIO 的优势结合,2020 年,vDPA(Virtio Data Path Acceleration)技术框架被合入 Linux 内核主线。

与此同时,字节内部的云原生化进程也在进行着。

据了解,字节最早于 2016 年开始在内部推进云原生化进程,对业务进行大规模容器化改造。到 2021 年年末,字节已经有超过 95% 的应用实现了云原生化。在这个过程中,STE 内核团队发现,容器在一些 I/O 相关的解决方案中,与传统的虚拟化方案相比比较受限。“我们当时希望能够在 Linux 内核中提供一套框架,开发者可以基于这个框架去模拟各种各样的设备,并且能够直接供容器接入使用。这样,就进一步弥补了基于容器的云原生方案在 I/O 方面的短板,甚至还能够和相对成熟的虚拟化方案实现一定程度上的技术复用。”STE 工程师谢永吉对 InfoQ 说道。

于是,VDUSE 框架应运而生。通过 VDUSE,开发者可以在一个用户进程中实现一个软件定义的 vDPA 设备,并可以通过 vDPA 框架接入 virtio 或者 vhost 子系统,供容器或者虚机使用。

图片

根据介绍,具体的实现原理上,VDUSE 设备是由 /dev/vduse/control 的 ioctl(VDUSE_CREATE_DEV) 创建的,通过这个 ioctl,用户空间可以为这个模拟设备指定一些基本配置,如设备名称(唯一标识 VDUSE 设备)、virtio 特性、virtio 配置空间、virtqueues 数量等等。然后,一个字符设备接口(/dev/vduse/$NAME)会被导出到用户空间用于设备模拟。用户空间可以在 /dev/vduse/$NAME 上使用 VDUSE_VQ_SETUP ioctl 来初始化每个 virtqueue 的配置,如 virtqueue 的最大长度等。

在初始化之后,VDUSE 设备可以通过 VDPA_CMD_DEV_NEW 这条 netlink 消息绑定到 vDPA 总线。之后,用户空间可以在 /dev/vduse/$NAME 上通过 read()/write() 来接收并回复来自 VDUSE 内核模块的一些控制请求,同时还可以通过 mmap() 映射一段共享内存,与内核相应的 virtio 驱动进行数据通信。

2020 年 10 月,STE 内核团队向 Linux 内核社区正式开源 VDUSE。经过一年时间,VDUSE 在 Linux 5.15 版本被正式合入。

“在计算存储分离的架构下,我们可以在计算节点通过 VDUSE 框架模拟各类存储设备供容器或虚机使用,这类存储设备的后端往往是远端的存储节点。现在,这套解决方案在字节的云原生场景已经开始大规模部署。后续,我们也将继续探索在云原生高性能网络场景上的应用可行性。”谢永吉说道。

Linux 内核始终在向前演进,在 STE 工程师邓良看来,“随着云原生应用场景不断扩大、硬件朝着高密度应用异构的机型上发展,对 Linux 内核提出了新的要求。内核是连接底层硬件和上层云原生应用的一个桥梁,我们也在思考,当前这种单一的宏内核是否合适,并且我们也在做一些探索。”

拥抱社区,让技术产出更大效益和价值

如果说攻克技术难关靠的是技术硬实力,那么向社区推广并使其合入我们的代码,则要依靠足够多的耐心去沟通和布道。

在与社区沟通上,STE 内核团队也积累了自己的经验。

2020 年 9 月,当 HVO 第一个版本发到社区后,团队收到很多质疑的声音。“社区起初对我们的方案产生怀疑,我们需要先向社区证明这个方案没有问题。同时,社区也会提出一些针对性的问题,甚至有很多都是我们之前没有考虑过的场景。根据这些问题,我们再对方案进行迭代和维护。像 HVO,我们迭代了 20 多个版本,需要不断地向社区证明这个方案在不同场景的有效性,这个过程持续了很长的时间。”回忆 HVO 的社区之路,宋牧春觉得特别漫长。在他看来,社区需要考虑维护成本是否大于收益,这无可厚非,作为开发者和社区贡献者,要做的就是解释清楚技术方案能够产生的价值,让社区看到它带来的收益,并证明这个方案的可行性和稳定性。

在企业内部,一套技术方案从开发到应用,这个链路并不复杂。但面向社区,开发人员需要考虑的问题就会更多。“很多时候,我们要突破自有场景,去看社区里的其他场景和痛点,而这些很可能是我们从来没有遇到过的。”显然,拥抱社区的沟通成本会很高,但在段熊春看来,为社区贡献代码能够实现双赢,这都是值得的。

“现在我们的工作环境基本是模拟社区环境,工作模式也跟社区保持一致。这种标准化的作业模式能有效降低代码的维护成本,同时社区思维的开阔性,也为我们思考问题提供了更多的思路,进而为技术创造价值提供了更多的可能性。”

走进“无人区”

对于 STE 内核团队的愿景和目标,张宇用了三个“贴近”来描述:贴近业务,去了解业务的痛点;贴近社区,去了解社区的方向;贴近新硬件技术,在软硬协同设计上发挥内核更大价值。内核本身无法直接创造价值,更多是通过服务业务来创造价值。所以团队在做研发时,一定要想清楚对业务的收益是什么,它能否真正的解决业务痛点,进而创造业务价值。

STE 内核团队多年来一直深入社区。基于开源 Linux 操作系统,团队做了一些优化以满足企业内部的需求,反之,团队也会把这些好的特性回馈给社区,像前文提到的 HVO 和 VDUSE 都已被合入 Linux 内核主线。在张宇看来,STE 内核团队并不是要做一个标新立异的操作系统,更多的是源自技术初心,希望能够把自身的力量贡献给社区,交给 Linux,再不断引进。

张宇表示,STE 团队非常重视“务实”,这也是字节的核心价值观之一。“我们在做的事情都是围绕基础设施展开的,提高它的稳定性、优化性能等等,与公司内其他能直接创造收益的明星产品相比,我们是一个做减法的部门,通过技术手段降低基础设施成本,在业务链路里属于非常靠后的位置,就像足球场上的后卫一样,要能守住系统稳定性 / 可靠性的基本盘不出问题,又要能够往前场助攻进球。回到团队的愿景来看,我的想法比较简单务实,希望团队先满足业务的需求,再高于业务需求、先于业务需求,做一些引领业界的技术。就像一开始,我们是跟着社区,跟着业界领先者的路径去走,但随着我们技术能力不断提升以满足业务场景多样性的需求,再往前走,必将进入‘无人区’。”

进入“无人区”后,没有方向的指引,也没有参照物,这才是最考验团队能力和韧性的时候。“我希望团队有开拓精神,辨识出合理的方向并坚定的走下去,也许在过程中会有微调,但最后顶多画出来的路线是波浪线,而不是一条完全没有目标的曲线。”张宇说道。

写在最后

直到今天,团队对 HVO 的优化还在继续。2022 年 3 月,团队优化了 HVO 在 2 MB HugeTLB 的表现,与此前相比,它进一步将 2 MB HugeTLB 的 struct page 开销减少了 12.5%;2022 年 4 月,HVO 支持 ARM 64 架构;2022 年 5 月,HVO 支持运行时开关,不再束缚于 cmdline 的方式使能。

依托 Linux 内核,团队在虚拟化、云原生、eBPF 等技术方向上也在继续探索着。

“现在我们关注的比较多的场景,一个是云原生,这也是大家都在关注的方向,但当前并没有一个特别好的解决方案,甚至在云游戏的一些基础设施场景下,业界还没有形成一个标准;另一个就是软硬协同,用软件的方式定义硬件,用硬件的方式来定义软件。目前我们也围绕这些方向在做一些研究。”张宇认为,“如果团队一直在做一些重复的事情,是没有激情与战斗力的,对团队的期待还是要在满足业务需求之上,去做一些引领业界的事情。”

在张宇看来,做操作系统这类基础软件不是一时热情,是需要长期投入的。大浪淘沙沙去尽,沙尽之时见真金。“目前国内外大厂也都在围绕自己的业务场景做软硬一体的事情,涉及基础系统软件、芯片板卡服务器之类的硬件研发。在做的同时也要上升到社会责任感的层面上来看,能贡献多少力量。这些都是需要持续思考的。”

嘉宾介绍

张宇,字节跳动 STE 团队负责人

段熊春,字节跳动 STE 内核团队负责人

宋牧春,字节跳动 STE 工程师、Linux 内核社区 HugeTLB 和 Memory Cgroup 两个核心子模块的 maintainer

谢永吉,字节跳动 STE 工程师

邓良,字节跳动 STE 工程师

欢迎扫码关注【字节跳动       SYS       Tech】公众号

695856371Web网页设计师②群 | 喜欢本站的朋友可以收藏本站,或者加入我们大家一起来交流技术!

自定义皮肤 主体内容背景
打开支付宝扫码付款购买视频教程
遇到问题联系客服QQ:419400980
注册梁钟霖个人博客