eBPF_9_汽车软件性能提升方法的工程化落地

哔哩哔哩学习视频网址

会议名称：第二届中国eBPF开发者大会

演讲主题：汽车软件性能提升方法的工程化落地

主讲人：张旭海（Thoughtworks 的 架构师及专家咨询顾问）

举办地点：中国·西安

相关网站：WWW.ebpftravel.com

https://www.bilibili.com/video/BV1z1421R7S8?spm_id_from=333.788.player.switch&vd_source=c6eb01f477318fe011791628a835c734

除了哔哩哔哩有视频可以学习之外，还有原文《车企软件性能提升的工程化破解之道》可以学习

作者张旭海

https://www.thoughtworks.com/zh-cn/insights/blog/platforms/software-improvement-in-sdv

一、软件的本质复杂度

    本质复杂度是指待解决问题本身固有复杂度，与如何解决方法无关。

两大表现：

依赖性：系统各模块耦合度高，形成复杂的依赖关系，导致维护困难（“牵一发而动全身”）。

晦涩性：系统的内部运作机制难以被直观理解，导致知识传递困难或理解偏差。

二、软件定义汽车的领域复杂性

    现代汽车软件不仅是单一的控制程序，而是一个涉及异构硬件、多种操作系统内核、复杂的通信中间件、庞大的功能模型库以及丰富的云端应用生态的综合系统。同时，整个架构还必须贯穿安全（功能、数据、信息）和完善的工具体系，体现了软件定义汽车在架构设计上的深度与广度。

    “软件定义汽车”时代汽车电子电气架构的分层复杂性。它将汽车软件体系划分为从底层的硬件到上层的云端应用的多个层次，我们还需要建立一些中间的功能软件层。这一层包含了支撑上层应用的核心能力，如数据抽象、通用框架（服务与计算引擎）、通用模型（覆盖驾驶、车载、底盘、动力、车身五大域）以及管理平面。

三、持续性能提升的跨领域挑战

    一个高精地图实时导航与自动驾驶联动的例子：一辆正在行驶的新能源汽车，驾驶员在车机屏幕上查看实时导航路线，同时车辆开启了L2+级别的辅助驾驶（ADAS）。导航系统不仅提供路径指引，还需要将前方复杂的路况信息（如连续弯道、限速变化）实时传递给车辆的底盘控制系统（控制转向、制动）和动力系统（调整扭矩输出），以确保行驶平稳且安全。

四、持续性能提升的工程化方法

    如何将性能提升从一个临时的、局部的优化活动，转变为一套可持续的、系统化的工程方法。其核心在于构建一个多维度的工程体系，具体包括：

1.团队协作：整合领域、性能和工程专家的力量。

2.流程规范：建立标准化的工作流程。

3.技术支撑：利用成熟的工程技术。

4.全周期视角：覆盖从设计到运维的整个生命周期。

5.闭环反馈：结合监控与 DevOps 理念，实现持续改进。

    DevOps 循环图：包含 Code（代码）、Build（构建）、Release（发布）、Monitor（监控）、Operate（运营）等环节。强调通过研发与运维的闭环协作，结合监控反馈，来实现性能和稳定性的持续提升。

五、构建研发团队自主驱动的性能工程反馈闭环

    核心思想是将性能管理融入到软件研发的每一个环节，并通过平台化的手段赋能团队，实现自我驱动的性能优化。

    设计期：通过“性能关注点地图”等工具，让架构师和设计师提前识别性能瓶颈。

    开发期：强调“代码级”的优化，如静态扫描和微基准测试，在代码提交前就解决潜在问题。

    测试期：不仅仅是跑测试，而是通过“仿真”和“数据分析”，提供更深层次的洞察。

    运营期：建立“基线”和“对比”机制，使性能变化可量化、可追溯，并通过“根因分析”快速解决问题。

    平台化赋能：“平台能力支撑”是整个体系落地的关键。它提供了统一的工具链和基础设施：

    插件市场：允许团队根据需要扩展工具。

    测试平台 & 观测系统：提供自动化测试和实时监控能力。

    分析服务 & 知识库：将数据转化为知识，让团队能从历史经验中学习。

    性能工程不应是某个专家或某个阶段的“救火队”，而应是嵌入到研发全流程的、由平台支撑的、团队共同参与的“常态化工程实践”。通过这种闭环机制，才能实现性能的持续、自主优化。

六、工程实践 1：持续性能观测

    性能工程不能只看结果（业务指标），必须建立从硬件资源到系统调用再到用户体验的完整观测链路，才能有效保障系统的稳定性与高性能。

1.业务指标

这是面向最终用户、衡量应用“好不好用”的直观指标。

应用启动速度：App 打开的快慢。

帧率：画面每秒刷新的次数，直接影响流畅度。

丢帧数：卡顿的具体表现。

崩溃：应用闪退情况。

运行时卡顿：操作响应延迟的主观感受。

开机时间：设备启动耗时。

内存泄漏：内存占用异常增长，长期运行导致变慢。

2.系统指标

这是面向技术实现、衡量软件底层运作效率的指标。

负载特征：系统当前的繁忙程度特征。

调度延迟：CPU 等资源分配任务的时间差。

IO 队列：输入输出操作的排队情况。

缓存命中率：数据读取的效率。

Swap 率：内存交换频率，反映内存压力。

函数热点：代码中消耗资源最多的部分。

内核时间：操作系统内核态消耗的时间。

3.资源指标

这是面向硬件基础、衡量物理或虚拟资源利用状况的指标。

利用率：CPU、内存等资源的占用百分比。

饱和度：资源被占满的程度（如网卡带宽跑满）。

错误：资源请求失败的次数。

吞吐量：单位时间内处理的请求量。

大小核：涉及异构 CPU 架构（如 ARM big.LITTLE）的调度观测。

延迟：资源响应的绝对时间。

失效率：系统或组件出错的几率。

七、性能观察工具

    性能工程是一个跨学科、全周期、闭环驱动的体系，通过标准化的方法、分层的技术指标和强大的观测工具，将性能管理深度融入研发流程，最终实现系统的持续自我优化。

八、科学地评估性能变化与调优效果

1.性能趋势的定性监控

图表类型：折线图（横轴为版本/时间，纵轴为 TPS 或吞吐量）。

性能基线：图中虚线代表系统正常运行的性能水平。

性能劣化：实线波动下降，穿过基线，明确标示出在某个版本出现了性能衰退（Performance Degradation）。

调优效果：绿色区域显示，在经过干预（调优）后，性能指标回升并超过了之前的劣化状态。

2.统计学视角的定量验证

在进行性能调优时，不能只看监控图上的线条是否向上走，而应该通过统计学方法（如 t 检验和计算效应量）来科学地证明：性能变化是真实存在的，不是随机波动和调优带来的提升具有显著的工程价值（效应量大）。一句话：不要相信直觉，要相信数据。

第一步：数据预处理（正态性检验 + 数据矫正）

    原始数据（直方图）通常是杂乱的。首先要检验数据是否符合正态分布（钟形曲线）。

    只有符合特定分布的数据，才能使用标准的参数检验方法。如果不符合，需要进行矫正。

第二步：假设检验（t 检验）

    在确认数据分布后，使用 t 检验 来比较两组数据（例如：调优前 vs 调优后）的均值是否存在显著差异。

    红色阴影部分 t 检验的示意图显示了置信区，用来界定“偶然误差”的范围。

第三步：效应量（Effect Size）

    两个重叠的正态分布曲线（通常蓝色代表对照组/调优前，红色代表实验组/调优后）。其中d1和 d2代表效应量的边界。

    效应量：衡量的是“调优带来的变化幅度有多大”。

    如果两条曲线重叠很多，说明调优效果不明显（只是噪音）。

    如果两条曲线分得很开（效应量大），说明调优措施产生了实质性的、巨大的性能提升。

九、Linux 内核中基于 eBPF 的动态调度微调系统架构

    按场景划分：行车/休闲/哨兵。不同场景对性能的要求不同。例如“行车”模式下要求极致的响应速度，而“休闲”模式下可能更看重功耗。

按业务划分：关键服务分组。将系统服务按重要性分组，确保关键业务（如刹车系统、导航）永远优先获得 CPU 资源。

    按前后台划分：前台应用优先。在移动端或嵌入式系统中，确保用户正在交互的前台应用流畅，而后台下载、日志同步等任务可以被适当抑制或降级。

    利用 eBPF 的零侵入特性（无需修改内核源码即可运行代码），实现了内核调度器与外部策略控制的解耦。它允许开发者针对特定的业务场景（如车载 OS 的特定工况）定制极其细致的 CPU 调度策略，在保证系统稳定性的同时优化用户体验。

十、AI 驱动的代码性能优化

    基于大语言模型（LLM）的自动化代码性能优化工程流水线，通过流水线自动化处理代码提交，利用专门微调的 LLM 提供精准的优化建议，并通过反馈机制不断迭代改进，最终实现高效、自动化的代码性能提升。

整体流程：

  1.触发：开发者提交 Pull request。

  2.分析：Pipeline 接收代码，分析其性能瓶颈。

  3.优化：调用右侧的 LLM（优先使用微调模型，必要时结合预训练模型）进行优化。

  4.输出：生成优化建议。

  5.反馈闭环：将优化结果（如是否通过测试、性能提升多少）作为反馈输入，持续优化模型。

预训练 LLM：基础的通用大模型，拥有广泛的知识，但可能缺乏特定领域的优化经验。

微调 LLM：经过特定数据集（如性能优化数据集）专门训练过的模型，更擅长解决具体的代码优化问题。

性能数据集：包含了大量代码性能数据、优化前后对比、基准测试结果等的专用数据库，用于训练和校准模型。

优化模式：一种特定的指令或上下文设置，指导模型如何进行优化（例如追求极致速度、节省内存等）。

十一、性能工程团队拓扑

    旨在避免“每个人都在重复造轮子”或“只有少数人懂性能导致瓶颈难以突破”的问题。

平台团队: 在下层搭好“舞台”（工具链），提供基础设施。

复杂子系统团队: 在上层攻克“堡垒”（底层难题），制定标准。

赋能团队: 在中间做“军师”（方法论指导），连接上下，提升整体认知。

流对齐团队: 在前线冲锋陷阵（业务开发），利用平台和专家的能力，确保自己的业务又快又稳。

十二、性能工程体系平台

    “性能工程体系平台”全景架构是一个集建模、数据、仿真、观测、分析、看护于一体的闭环生态系统。

整个平台通过5大核心能力单元构建，并通过底层闭环支撑上层开放能力：

1.基础能力层（上半部分）：事前与事中

这一层主要解决“如何模拟环境”和“如何获取数据基线”的问题。

建模 (Modeling)：提供排队模型、分发模型等理论模型，用于性能容量规划和预测。

数据 (Data)：建立性能知识图谱，包含基线设定、劣化识别、分析和推荐，实现数据驱动的决策。

仿真 (Simulation)：支持 ARM、x86、Qemu、Docker 等多种环境的仿真管理，用于在不真实部署的情况下进行性能预估和压力测试。

2.端到端流程层（中部）：流程保障

流程端到端：强调通过“看护”和“定界”驱动问题发现，落实责任。利用知识图谱将建模、分析、优化串联成一套标准的性能工程流程，避免流程断裂。

3.执行与落地层（下半部分）：事后与验证

这一层是工程师日常接触最多的实操工具集。

采集/观测：底层数据入口，包含 perf、valgrind、bcc、ftrace、sar等主流 Linux 性能剖析工具。

分析优化：核心剖析大脑，包含火焰图、调用图、Top-Down 分析、访存分析、指令分析、系统/组件/算法/函数/符号定界等深度分析手段。

看护：质量保障体系，通过测试用例、流水线集成、监控指标和自动提单，确保性能不退化。

4.开放与定制层（右侧）：赋能产品线

开放 API/UI：平台的核心价值输出口。将底层的“原子能力”通过 API 或 UI 插件开放。

产品线 A/B (Product Line A/B)：展示平台的灵活性。不同产品线（如 A 产品线侧重网络，B 产品线侧重 I/O 和存储）可以基于统一的平台底座，编排定制出符合自身业务特性的性能工程能力（如 A 线用 ftrace 和函数调用图，B 线用 perf 和缓存模型）。

5.核心纽带：研发流水线反馈闭环

底部贯穿的箭头强调了CI/CD 流水线的重要性。所有的性能测试、分析、优化、看护都必须嵌入到研发流程中，形成“提交 -> 测试 -> 分析 -> 反馈”的闭环，才能真正落地。

十三、性能工程成熟度模型

    按照软件研发生命周期（SDLC）的五个阶段（需求/建模、开发/编码、测试/看护、监控/发现、分析/优化）来评估企业在每个阶段的成熟度表现。递进的等级：L1 无（初始）、L2 量化（中级）、L3 高效（高级）。

图源网址：

https://www.thoughtworks.com/zh-cn/insights/blog/platforms/performance-engineering-maturity-model

L1 无（初始阶段）—— 被动与经验驱动

核心特征：缺乏系统性的性能意识，性能问题通常在事后暴露，严重依赖个人经验。

表现：

需求阶段：没有明确的性能指标，设计存在大量缺陷，需求阶段未投入资源规划性能。

开发阶段：开发者对性能问题无感知，编码反模式多（如大量IO、阻塞），缺乏提升性能的案例和知识库。

测试阶段：没有针对不同产品的基线测试，缺乏CI/CD集成和测试环境管理。

监控阶段：完全没有量化监控，缺乏预警机制，缺乏全链路监控手段。

解决阶段：缺乏优化思路（依赖个人），缺乏团队共识，没有业务模型到系统架构的梳理。

L2 量化（中级阶段）—— 体系化与标准化

核心特征：建立了基本的量化指标和基线，开始形成标准化流程，但自动化程度不足。

表现：

需求阶段：有明确的性能基线和设计考量，能提前设计量化指标和用例约束。

开发阶段：开发者有一定知识并能做出相应设计，能通过特定测试用例获取反馈，有零散文档。

测试阶段：有针对不同产品的基线测试，有准备好的数据和环境，但无法自动化，结果归档不统一。

监控阶段：有针对系统指标的监控和可视化，能进行跨组件问题定界，但不够动态和全链路。

解决阶段：积累了优化案例和知识图谱，能基于图谱找方案，团队内有共识，完成了业务到架构的梳理（但不够细粒度）。

L3 高效（高级阶段）—— 自动化与智能化

核心特征：性能工程完全融入研发流程，具备预测能力、自动化执行能力和全链路洞察力。

表现：

需求阶段：预先建模，能预测需求变更带来的性能影响，有专门的架构设计和文档跟进。

开发阶段：开发者有工具可自主化识别性能问题，有可参考的高性能编码实践，有体系化的知识库。

测试阶段：可针对各版本做持续看护，能自动化执行性能测试，工具集成度高，有问题自动告警并归因给责任人。

监控阶段：动态下发指标收集任务，及时发现潜在降级，能获取异常信息及运行时上下文，有缓解策略。

解决阶段：积累成功案例持续赋能，通过数据统计挖掘优化模式，形成领域内性能反思和方法论。