1、封面页（此页面将由下图全覆盖，此为编辑稿中的示意，将在终稿 PDF 版中做更新）卷首语 我们相信操作系统将成为数字产业支柱算力来源，龙蜥社区是近两年业界发展最为强劲的一大操作系统开源社区，因为做对了这两件事：一、“开放算力”，龙蜥社区短期目标是开发龙蜥操作系统作为 CentOS 替代，助力广大用户无缝迁移。基于阿里云、统信软件等社区多年来的技术沉淀，面向广大用户进一步释放底层算力。二、“云启未来”，龙蜥社区的长期使命是与生态合作伙伴联手，共同打造一个面向云时代的操作系统，协同产业上下游能力和诉求，建立统一的开源操作系统生态。2022 年是龙蜥社区在产业落地的一年，为让大家看到龙蜥社区每一年扎扎

2、实实的突破，我们在 2022 云栖大会上举办了阵容强大的龙蜥峰会。本次峰会在浙江省软件协会指导下，由龙蜥社区主办，阿里云、统信软件、Arm 等 21 家企业单位共同协办，围绕“开放算力 云启未来”的主题，打造了操作系统产业主论坛、eBPF&Linux 稳定性专场、RISC-V 专场、云原生专场共 4 个会场，聚焦社区演进、技术实践、生态发展和开发者培养四大维度，呈现一个繁荣的开源社区全貌。奋进谋发展，笃行创新业。截至目前，龙蜥操作系统下载量已经达到 230 万，装机量超过 300 万。龙蜥社区当前有 21 家理事单位和超 250 家生态合作伙伴，近50 个 SIG 组，上百位 Maintain

3、er，上千名开发者。龙蜥社区在短时间内实现的跨越式发展，与社区坚持的平等、开放、协作、创新的准则息息相关。基于此，龙蜥将贯彻建设面向云时代的操作系统的长期使命，打造“集产业之大成”的下一代操作系统 Anolis OS 23。Anolis OS 23 是通过分层分类理论指导来打造的。操作系统如何在云场景下做好多样化支持的同时，还能向上给应用开发者一个一致性的体验，这是龙蜥操作系统未来 3-5 年奋斗的目标。在未来技术趋势方面，社区主要是围绕着下一代数据中心的技术趋势、下一代的云原生软件栈的需求、以及软硬协同的技术发展趋势展开。我们坚信，未来十年，操作系统的大发展一定势不可挡。欢迎所有有志于参与操

4、作系统研发的同仁一起加入龙蜥社区，打造面向未来的下一代操作系统。目录 eBPF 技术&Linux 稳定性专场.6 SYSOM 在系统可靠性与安全上实践.6 手机内核稳定性的治理与实践.17 系统运维利器，百万服务器运维实战总结！一文了解最新版 SysAK.26 eBPF 技术发展及挑战.33 Coolbpf 的应用实践.41 eBPF 安全特性解析.49 基于 eBPF 的程序摄像头构想.54 eunomia-bpf eBPF 轻量级开发框架.61 RISC-V 专场.66 平头哥在 RISC-V 软件生态的探索和实践.67 开源高性能 RISC-V 处理器敏捷开发实践.74 RISC-V 边

5、缘 AI 芯片的开源生态和应用落地.83 快速发展的 RISC-V 软件生态.92 蜥峰会 RISC-V 专场圆桌对话.102 云原生专场.108 龙蜥云原生社区发展思考&Kata Containers 社区共建.109 中国移动算力网络云原生虚拟化技术.113 基于 kata 的 Serverless 产品体系建设.118 基于龙蜥与 Koordinator 的在离线混部的实践.122 ContainerOS 在云原生中的应用.130 如何在云原生时代下管理微服务应用.136 Serverless Computing 技术架构.144 机密容器崛起和发展.152 龙蜥云原生社区未来展望.15

6、8 eBPF技术&Linux稳定性专场eBPF技术和Linux稳定性在龙蜥社区的实践 SYSOM 在系统可靠性与安全上实践 6 SYSOM 在系统可靠性与安全上实践 作者：魏东，统信软件高级系统研发工程师 1.系统可靠性 SRE 是判断系统是否可靠、可用、有效重要标准，它包括：服务水平指标 SLI：衡量服务使用情况量化指标。比如 IO 读写速率、网络延迟。通常量化指标会转换为比率、平均值或百分 比。服务水平目标 SLO：一段时间、区间内的目标。SLO 的表达式通常为：SLI=target 或 lowerboundSLIupper bound。比如 SLO 可以为每个请求的平均延迟rodata

7、变量。_load()：初始化，加载和校验 BPF 应用部分。Coolbpf 的应用实践 43 _attach()：附加所有可以自动附加的 BPF 程序。有事件和网络运行报文到达时，会触发运行 bpf 程序。_destroy()：分离所有的 BPF 程序并使用其使用的所有资源。eBPF 的主要开发方式有三种，各有优缺点。原生 Libbpf 无 CORE：该方式没有任何基于第三方的开源项目，而是直接调用Libbpf 里的代码，资源占用量低。但缺点为需要自己完全重新搭建工程，效率较低，且版本兼容性较差。BPF CORE：该方式不依赖在环境中部署 Clang/LLVM，资源占用少。但是需要搭建编译工程

8、，部分代码相对固定，无法动态配置。BCC：该方式是应用最广的开源项目，开发效率较高。但是每一次运行都要执行 Clang/LLVM 编译，存在内存、CPU 等资源的争抢。目标环境依赖头文件，需要单独下载头文件。2.Coolbpf 的功能和架构 Coolbpf 提供了远程编译（云编译）。其中远程编译指运行程序的目标机器与编译程序不在同一个机器上，能够解决资源占用问题；提供了本地编译和基础库封装，方便用户的理解与适用；提供了低版本内核的支持；提供了 BTF 的自动生成和发布，用 户 无 需 手 动 适 配，下 载 即 可 直 接 使 用；提 供 了 自 动 化 测 试 以 及 支 持python/g

9、o/rust 等高级语言进行应用开发。Coolbpf 的应用实践 44 Coolbpf 天然支持 BPF 的 CORE 能力，它解决了编译和资源消耗的问题，同时，前面介绍的复杂的 libbpf 开发步骤完全被简化了。用户只需要专注自己的功能开发，不用关注环境搭建和冗余代码开发。Coolbpf 提供了标准化的 bbf 编译服务。将 bpf.c 提交到远程编译服务器时，会根据的内核版本针对不同的语言返回点 bpf.so 或 bpf.o 为高级的应用程序提供服务。因此高级语言中，只需加载 bpf.so 即可运行程序，无需再手动触发 Libbpf 的加载、open、attach 等函数，而是由高级语言

10、程序的 initial 操作自动完成，可以快速搭建和部署工程，用户只需专注于数据输出之后的处理。Coolbpf 的应用实践 45 Coolbpf 提供了标准化的 bpf 编译服务。首先将 bpf.c 提交到远程编译服务器时，服务器会根据的内核版本针对不同的语言返回点bpf.so或bpf.o为高级的应用程序提供服务。因此在你的高级语言代码中，只需加载 bpf.so 即可运行程序，无需再手动触发 Libbpf 的 open()、load()、attach()等函数，而是由高级语言程序的 init()自动完成，这样用户可以快速搭建和部署工程，只需专注于数据输出之后的处理。Coolbpf 还支持在没有

11、 eBPF 特性的低内核版本上，通过我们提供的 eBPF 驱动，帮助它安全的在低版本上运行。我们将高版本上 eBPFverifier 校验部分实现在一个驱动里，它会进行各种安全校验，保证 eBPF 对比于内核模块的安全性。另外，我们把原来基于 libbpf 的调用都转换为 IOCTL 的系统调用。原先支持的 helper 函数、创建 map、加载 program 都会转化成低版本上的 kprobe或 tracepoint 的实现，另外还支持 perfevent 和 jit。这样就使得同一个用户程序，加载这样一个驱动，就能不修改 eBPF 程序代码而安全的运行在低版本内核上。Coolbpf 的应

12、用实践 46 3.Coolbpf 的网络应用实践 Raptor 是基于 Coolbpf 的系统可观测工具，能够运行在低版本内核如 alios、centos3.10 等。它可以作为一个 SDK，提供给第三方使用，进行数据采集。在这个网络应用观测中，通过监控系统调用中的数据交互、请求和回复等信息，来确定交互的数据内容和五元组等信息，通过 map 的交互方式发送给用户态，做到了无侵入的方式做观测，最终呈现比如流量统计、请求时延等观测结果。Coolbpf 的应用实践 47 我们来看一个具体的问题，了解 Coolbpf 是如何发现收包阶段的网络抖动问题，我们知道网络收包分为两个阶段：阶段 1：OS 通过

13、软中断将数据包送到应用的收包队列并通知进程，完成协议栈的收包工作。阶段 2：应用得到通知后从收包队列取数据。我们在 Coolbpf 里写一段 BPF 程序，只需监控两个 tracepoint：tcp_probe，tcp_rcv_space_adjust 就能查询到阶段 2 的延迟问题。在这个案例中，某业务应用收包慢，发现内核侧已经收到了 tcp 包，但是应用侧将近 1s 后才收到。Coolbpf 的应用实践 48 观测方法：部署 eBPFagent，发现阶段 2“收包延迟时间”将近 1 秒。确定原因：每次发生延迟时间都在某时刻的大致 42 秒处，怀疑跟业务某定时任务相关造成应用自身延时，最终排

14、查到业务有某个任务会定时收集 jvm 的参数，对该业务有 stop 的操作。解决方法：停掉该任务后，消除了抖动问题。eBPF 安全特性解析 49 eBPF 安全特性解析 作者：许庆伟，深信服创新研究院 安全是 eBPF 应用中较为重要的一个特性。比如操作系统、软件安、网络、容器等场景都会应用到 eBPF 的安全特性。可观测性存在冰山现象，安全也是。普通开发者或用户，平时接触的多为主机安全、PC 端的安全等。PC 端或大型集群服务器的业务场景非常广泛，包括异常的攻击行为、异常漏洞等，其对应的检测范围也较大。主机端实现安全防护或检测，一般通过构建病毒库，然后不断地根据受到的攻击将新的病毒更新到病毒

15、库，达到一定的阻断和防御目的。但该手段无法应对近年出现的新型病毒，因此我们需要利用 eBPF 的能力，比如用 eBPF 做一个容器或云原生场景的白名单，该白名单之外的所有异常行为都会被阻断。eBPF 安全特性解析 50 安全是指一种状态，在这种状态下，某种对象或对象的某种属性不受威胁。eBPF 具有以下几个安全特性：程序沙箱化：内核源代码受到保护并保持不变，eBPF 程序的验证步骤会确保资源不会程序阻塞。侵入性低：无需修改内核代码，也无需停下现有程序来验证效果。透明化：数据都从内核中透明地收集，应用无需检测监控的状态，符合安全用例。eBPF 安全特性解析 51 可配置：自定义乃至自动化配置策略

16、，修改检测、阻断规则文件更快速，更新灵活性高、过滤条件丰富（进程、网络、文件等）。一般而言，检测到异常后，如果直接阻断，可能会对业务产生影响。因此，会先进行告警，然后根据严重程度决定是否阻断。快速检测：在内核直接处理各种事件，使得检测异常情况更方便和快速，从性能和开销上也能获得更大的收益。eBPF 程序会被 LLVM 编译为 eBPF 字节码，eBPF 字节码需要通过 eBPF Verifier 的（静态）验证，再通过比如 JIT 解析成符合要求的机器码，方能真正地运行。因此，边界检查是 eBPF Verifier 的重点工作，经过验证步骤后，能够确保 eBPF 程序可以安全运行。内核的稳定性

17、大多与内存相关，因此 eBPF 验证器的主要工作也与其有一定的关联，也就需要确保以下几点：第一，需要拥有加载 eBPF 流程所需的特权，对指令集、指令数等都有一定要求。从安全角度来说，即使赋予程序一定的非 root 权限，部分功能可能也并没有效果。第二，不要出现 crash 或其他异常导致系统异常或内核崩溃的情况。因为 eBPF 本身的工作内容即沙箱化、无侵入、不对内核造成大的影响。第三，程序可以正常结束，无死循环。从静态分析的角度将程序完全地运行一遍，确保无死循环。eBPF 安全特性解析 52 第四，检查内存越界。如果存在内存越界，则可能导致验证不通过，流程无法往下进行。第五，检查寄存器溢出

18、。如果存在寄存器溢出，则会导致验证流程中断。随着云网边端的急速发展，人们的目光越发聚焦在目前最火热的云原生场景上。Falco、Tracee、Tetragon、Datadog-agent、KubeArmor 是现阶段云原生场景下比较流行的几款运行时防护方案。这些方案主要基于 eBPF 挂载内核函数并编写过滤策略，在内核层出现异常攻击时触发预置的策略，在内核层对异常攻击进行记录并发出告警，无需再返回用户层，可以直接发出告警甚至阻断。以上方案多为应用层的运行时防御方案，以进程为粒度，而阻断进程会导致业务运行受到影响。因此，我们正在推进内核侧的 eBPF 与 LSM 结合的方案，期望能够解决上述问题。

19、该方案能够从函数调用的粒度进行阻断，在白名单内记录正常的调用路径，一旦发现白名单之外的调用行为，即可阻断此次函数调用，而不会影响正常的业务运行。但此类方案目前尚存在较多的限制，比如需要较高的内核版本。此前，人们对安全的关注点大多集中于应用层规则的编写或安全策略的实施。而伴随着云原生的发展，我们会越来越注重于内核端，结合内核和 eBPF 的安全特性，进行防御和阻断。安全策略可以通过 Kubernetes（CRD）、JSON API 或 Open Policy Agent（OPA）等系统注入。eBPF 安全特性解析 53 以 CNCF 为例，上层收集到的数据后，通过 agent 到达内核端，进行一

20、系列的收集、检测。每一个 POD 会制定规则，触发了规则之后会给予相应的措施，比如告警或阻断。基于 eBPF 的程序摄像头构想 54 基于 eBPF 的程序摄像头构想 作者：苌程，开源 eBPF 可观测项目 kindling 创始人 1.云原生可观测性挑战 云原生可观测性的核心价值在于快速排障。在日常工作中，很多时候即使使用了 Log、Trace 和 Metrics 三种手段，依然无法标准化定位问题的根因，极度依赖排障人员的个人经验，所以说当前可观测领域面临的最大挑战在于节点异常根因的定位。基于 eBPF 的程序摄像头构想 55 程序执行过程对于开发者而言是个比较复杂的黑盒子。开发者所写的代码

21、，是运行在常用的一些依赖库之上的，而这些依赖库有运行在 JVM 或者 Go 虚拟机之上，虚拟机又运行在 glibc 之上，最后调用到内核提供的系统调用接口。每一层都可能有bug。日志与 Trace 能够部分发现用户代码层面的问题，metric 可以覆盖从用户代码到系统调用库的问题，但都不具有针对性，是一种统计结果。在黑盒情况下，我们通过技术看到的只是程序执行过程的留痕，查找问题根因时需要人为想象还原程序的执行过程，推演出可能存在的问题，再去验证。当前也有一些白盒化的方式，比如类 jstack 的线程剖析能够部分发现用户代码与类库代码现场。如果发现的是排障人员熟悉的代码，则可以在一定程度上解决问

22、题，但是很多时候恰巧发现的是依赖库或者不熟悉的代码，则需要完整理解代码执行过程，才能进行排障。另外，如果只能看到代码层面的堆栈，当面对生产环境突发问题，某个程序正常运行后突然执行变慢或者出错，特别是多实例场景，同样的代码理应执行过程一直，那又如何解释某一个实例有问题，而其他实例没有问题。2.老刑侦的破案经验与光学摄像头 从刑侦学的知识和运用中我们可以总结出一个道理：从学会知识到到会用知识，需要经过不断练习。因此，程序员能够通过问题的表征想象出程序的运行方式也需要积累非常多的经验。基于 eBPF 的程序摄像头构想 56 几年前中国推广光学摄像头之后，全国各地的破案率达到历史最高水平。这正是因为光

23、学摄像头极大降低了破案门槛，即便没有受过刑侦训练的普通人都可以通过生活常识结合光学摄像头就能够理解罪犯犯罪过程。3.基于 eBPF 的光学摄像头构想 我们从光学摄像头上收到了启发，开发了程序摄像头。程序摄像头将应用层的代码首先转换成内核的Tracingpoint和kprobe等基础信息，再转换成操作系统的资源消耗情况，方便用户直观地理解。我们希望开发者能够通过程序摄像头，理解程序每一秒甚至每一个毫秒的执行情况。基于 eBPF 的程序摄像头构想 57 上图左侧为 CPU 的火焰图，代表程序进程在 CPU 上消耗的时间。但在对于常规在线业务，我们认为更重要的是 OffCPU 的火焰图，它体现了程序

24、由于何种调用堆栈引发程序暂停执行。另外，不管是 OnCPU 与 OffCPU，仅查看进程级别的数据，尚无法很好地解决可观测性问题，因为一个进程节点对外提供多个业务接口服务，我们更希望能够按照业务接口粒度去排查问题，这就需要到达线程级别的 OnCPU 与OffCPU 数据。我们需要按照程序执行过程对齐 OnCPU 和 OffCPU 到线程粒度。比如线程执行程序时在 CPU 上执行了什么代码，比如由于什么原因导致其离开了 CPU 最后恢复到 CPU上继续执行。基于 eBPF 的程序摄像头构想 58 然后在线程粒度上将 OnCPU/OffCPU 与主流的 Trace 技术按照时间轴做对齐，加上线程输

25、出的日志，即可将执行过程完整地还原。上图为通过程序摄像头观察 ES 执行 Bulk 插入的执行情况。图中紫色段为 Bulk 从开始执行到结束的过程。可以发现其执行了三个并发进程：epoll 线程做网络的读写，显示多为空闲状态；而另外两个线程几乎将全部的时间用于 IO 读写，且被读写的文件一秒钟的增长量仅 3M/s。因此可以得出结论：机器的IO 达到了瓶颈，瓶颈为 3M/s。使用程序摄像头之前，我们一直无法确认问题根因，因为我们认为 3M/s 并不是瓶颈，它属于正常范围。基于 eBPF 的程序摄像头构想 59 通常来说，tracing 与 loging 天然地能够进行关联，因其均为代码维度。而

26、tracing与 metrics 难以关联，因为 metrics 是资源维度，代表程序执行完后的结论，而且metrics 维度的数据量非常庞大，一一排查太消耗时间。而 Kindling 的解法为：通过 eBPF 将线程代码过程转换为资源消耗的过程，然后每个环节在该时间段内关联相关 metric，如果是 CPU 的时间段则关联 CPU 的指标，如果是网络则关联网络的指标，能够极大地减少无关指标的干扰。我们参考 Continuous Profiling，实现了 Trace Profiling。Continuous Profiling 大多针对进程，但我们认为，用户在排障时更需要针对业务请求来进行，

27、大多情况下只 基于 eBPF 的程序摄像头构想 60 是其中的某些业务请求出现问题；当进程出现问题时，通过 metrics 很容易识别这类问题。Trace Profiling 能够将所有线程执行的情况进行记录并重放，可以将执行的某 trace线程标记为高亮，帮助用户理解请求时每一毫秒的具体执行内容，以便确认程序根因。并且能够有针对性地关联指标，比如 CPU 密集型则关联 CPU 相关指标。4.程序摄像头构想的预期效果 总结来看，我们期望未来程序摄像头能够解决可观测领域越来越多的问题，包括但不限于以下几种场景：程序执行过程中锁占比时间较长。并发过高，线程池不够用：程序摄像头能够发现请求线程池满，

28、请求过多导致线程池不够用，进程卡住。程序由于 Java GC 导致执行时间较长：程序摄像头可以很明确地坐实两个不同的线程之间的相互影响。程序自身执行了 CPU 开销非常大的代码。程序自身文件 IO 的读写时间较长。网络执行慢。eunomia-bpf eBPF 轻量级开发框架 61 eunomia-bpf eBPF 轻量级开发框架 作者：郑昱笙，浙江大学 1.概要 当前，eunomia-bpf 想要解决的问题或 eBPF 程序当前的开发和分发过程中存的痛点主要有以下两个：第一，对于新手而言，搭建和开发 eBPF 程序的门槛较高，必须同时关注内核态和用户态两方面的交互和信息处理，还需要编写复杂或者

29、重复性较高的用户态加载代码。第二，在不同架构的不同内核版本上无法方便快捷地打包、分发、发布各种 eBPF 程序。eBPF 很多小工具由不同的语言开发，存在不同的接口，无法轻易集成到大型的可观测系统。当前也没有很好的插件方案，对于一个大型的 eBPF 应用，很多时候必须重新编译整个可观测的框架，再重新部署上线，才能更新 eBPF 探针或数据处理模块。另外，如果引入未经审查和测试的第三方的用户态数据处理代码，代码崩溃也可能导致整个程序崩溃。因此，我们提出了三种解决思路：eunomia-bpf eBPF 轻量级开发框架 62 第一，针对初学者，只需要编写内核态代码即可自动采样、自动获取内核态导出的数

30、据，编译后即可进行分发、加载和运行，极大地降低了 eBPF 的学习成本，提高了开发效率。第二，基于 libbpf 一次编译处处运行的特性，将用户态和内核态的编译和运行的完全分离，通过标准 JSON 或 WASM 模块的方式进行分发，无需进行重新编译，应用启动占用资源少，时间短，甚至容器启动更短。WebAssembly（缩写 Wasm）是一种基于堆栈虚拟机的二进制格式，Wasm 是为了可移植的目标而设计。可作为 C/C+/RUST 等高级语言的编译目标，使客户端和服务器应用程序能够在 Web 上部署。到现在为止，WASM 已经发展成为一个轻量级、高性能、跨平台和多语种的软件沙盒环境，被运用于云原

31、生软件组件，可以在非浏览器环境下运行。WASM 的设计思路和 eBPF 也有不少相似之处。第三，只编写内核态代码的时候，使用 JSON 即可完成分发、加载、打包的过程，对于完整的、需要用户态和内核态进行交互的 eBPF 应用或工具，可以在 WASM 中编写复杂的用户态处理程序进行控制和处理，并且将编译好的 eBPF 字节码嵌入在WASM 模块中一同分发，在目标机器上动态加载运行。和 WASM 生态项结合可以给 eBPF 程序带来许多特性，同时和 eBPF 程序原本的设计思路也不谋而合，比如可移植、隔离性、安全性，它也是一个跨语言、轻量级的运行环境等等；同时也可以借助 WASM 的相关工具完成

32、eBPF 程序的 OCI镜像的存储和分发，最近 docker 官方也推出了一个基于 WASM 的分发和运行工具。以上三部分就是 eunomia-bpf 的核心特性。接着我们和大家一起来看一些示例。2.示例 Eunomia 并不是一个完整的系统，而是类似于开发库和开发框架，可以很轻松地嵌入 coolbpf 这样的大型工具链里，或作为运行时库嵌入到任何需要使用 eBPF 作为插件的的地方。eunomia-bpf eBPF 轻量级开发框架 63 可以通过一行命令从网页端直接下载预编译好的 eBPF 程序运行。使用WebAssembly 模块或 JSON 配置文件的方式进行分发，部署时无需重新编译，启

33、动速度相比 BCC 能提升一到二个数量级。图中使用 URL 启动 eBPF 程序的形式，也可以换成 OCI 镜像或 Docker 镜像，可以存储在 Docker 仓库或 Github Package 中，使用方式与 Docker 基本一致，只需简单地执行 pull、run 即可运行，也可以将编译好的程序包 push 下去直接使用。相比于传统的 Docker 镜像，使用 WASM 作为轻量级容器的启动速度更快，同时也保留了 eBPF 很重要的特性，可以轻松嵌入到其他程序作为子模块或插件使用，并且和具体内核版本、架构完全无关。eunomia-bpf eBPF 轻量级开发框架 64 通过 eunom

34、ia-bpf，只需编写内核态代码即可正确运行，能够最大程度减少新手的上手障碍，不需要编写 libbpf 的用户态的加载框架编写，就能够自动导出内核态perf event 或 ring buffer 事件。另外，它与和原生 libbpf 完全兼容，可以获取 libbpf tools 的内核态代码，无需修改任何代码，可直接运行。可以额外添加 tracepoint，也可以通过注释的形式添加其他内容。使用容器打包编译工具链，无需担心环境配置问题，一行命令生成项目模板、一行命令编译。这里演示的是一个简单的 wasm 模块，它可以获取当前系统的进程间的 signal 信号传递的事件。它可以接受一些命令行参

35、数，并且对上报的信息进行处理。目前来看，我们已经可以基本上不用进行代码修改，就可以直接把 BCC/libbpf-tools里面的程序编译为 wasm 模块。对开发体验来说，也可以做到和使用 C 语言开发libbpf 的 eBPF 程序完全相同，之后也可以引入其他的语言开发 SDK。把 wasm 和 ebpf 结合起来主要的困难在于，WASM 的内存布局和 eBPF 程序并不一样，C 语言的结构体并不能直接映射，所以传递结构体必须要经过序列化操作；同时，WASM 对于访问系统资源，例如文件、网络等等，也有不少限制，很多标准库是缺失的，所以我们需要在 wasm 模块中进行一些特殊的处理和移植。3.

36、系统架构 架构底层依赖的是内核态和用户态的基础设施，比如 libbpf 库和 Kernel 中的 eBPF虚拟机。在内核的基础设施这之上，我们会提供相关的编译工具链，和对应的运行 eunomia-bpf eBPF 轻量级开发框架 65 时加载器，帮助生成 JSON 或打包成 WASM 的模块，工具链本身使用了比如Clang/LLVM、bpftool 等工具。动态加载库可以独立使用，与 WASM 无关，也可以借助动态加载 JSON 配置信息即可热插拔、热更新 eBPF 程序的形式，通过 API 接口轻松实现 kernel function as a service（内核函数即服务）。我们还实现了

37、 WASM 抽象层，包含 API 规范，比如用于扩展 WASM 的虚拟机 WSAI系统占用的访问形式或与eBPF交互的访问形式。还有基于WASM定制的libbpf库、移植的辅助态程序以及序列化库等，用于在 WASM 模块加载基于 libbpf 的 eBPF 程序。运行时库可以轻松进行替换，比如替换成 WSI 的 WASM 运行时。除此之外，上层还实现了 LMP、命令行工具、可观测性工具等。目前，eunomia-bpf 项目已在龙蜥社区开源，欢迎各位开发者体验，也欢迎大家提出建议和反馈，一起来做大做强。eunomia-bpf 项目龙蜥社区开源仓库：https:/ RISC-V专场龙蜥社区共建RI

38、SC-V软硬件全栈生态 平头哥在 RISC-V 软件生态的探索和实践 67 平头哥在 RISC-V 软件生态的探索和实践 作者：熊健，平头哥资深技术专家 平头哥 RISC-V 软件生态 在 RISC-V 专场，来自平头哥 IoT 研发 OS 平台团队的负责人，资深技术专家熊健介绍了平头哥在 RISC-V 软件生态的探索。从底层软件的适配，语音、视频、安全等子系统的构建，各个操作系统的应用框架的搭建和支持，到上层应用方案设计，平头哥不断深耕 RISC-V 技术和生态，端云一体的丰富生态正在形成。平头哥团队过去一年在开源社区的贡献 平头哥在 RISC-V 软件生态的探索和实践 68 平头哥持续在开

39、源社区贡献代码，在 Linux-5.19 中发布的 106 个 RISC-V patch 中，有 43 个与玄铁 CPU 相关，并贡献了 RV32 COMPAT 和 Svpbmt 两个重要功能。通过上图看到，其中 Compat 模式能够支持 32 位应用程序在 64 位 RISC-V 的 Linux上运行，一方面可以保证 32 位应用程序的兼容性，同时也能有效降低系统内存和应用内存的占用。Svpbmt 是 MMU 页面管理的重要属性，能进一步加强 RISC-V 对于 Linux 内存管理机制的支持。Crash 是非常强大的调试工具，用于调试内核问题，长期以来 Crash 社区一直未能支持 RI

40、SC-V 架构，严重影响了 RISC-V 平台的内核调试。平头哥为 Crash社区贡献了 RV64 架构的支持方案，解决了多年来离线调试的短板，为 RISC-V 的开发带来重要意义。我们坚信，安全是未来云端一体的重要基础技术。平头哥从硬件安全到软件安全提供了全套安全体系方案，研发了全球首个支持兼容 GP 标准的 RISC-V 芯片/平台，并因此获得了全球首个基于 RISC-V 架构的 GP TEE 安全评估认证。安全的重要特点是从处理器硬件到软件具备完整、全套的安全体系，我们实现了OPTEE 全栈的技术能力，可以帮助 RISC-V 架构实现对现有安全软件生态的兼容。该安全系统能够支持 RTOS

41、、Linux 和 Android 等多个主流操作系统，可以弹性地支持各种不同领域的安全终端产品，提供了标准的用户开发界面，保证安全应用的快 平头哥在 RISC-V 软件生态的探索和实践 69 速迁移。该安全框架已经实现了部分阿里的安全应用，可以无缝快速接入阿里巴巴生态，最大化有效复用现有的安全认证资源，减少安全认证的周期，加速产品上市速度。YOC（Yun on Chip）是一个 RISC-V 软硬融合多元体的开源 AIoT 软件平台。通过高效的芯片对接、丰富的系统组件、简洁的应用框架，能够助力芯片到终端产品的快速落地。针对不同的应用场景，YOC 可以提供接入语音、图形、视频视觉等各种系统的能力

42、，帮助开发者在各个领域快速构建自己的应用解决方案。YOC 的最新版本 v7.6 已于近期同时在 github 和 gitee 上做了开源发布。通过支持更多 RISC-V 芯片，提供了更多通用示例，进一步提高了开发者的开发效率。YOC 的视频视觉子系统为需要低成本、高实时的 camera 场景提供了竞争力。它通过几个重要组件比如 Media Entity、内存子系统、bind 子系统、profiling 子系统提供多媒体场景需要的功能。同时能够提供硬件加速和软件处理的能力，支持 Linux和 RTOS 两个系统，可以实现跨系统的平滑迁移。未来平头哥会持续在 YoC 上深耕，进一步提高开发者的开发

43、效率，为市场带来更多有竞争力的产品。平头哥在 RISC-V 软件生态的探索和实践 70 在端侧，平头哥引领 RISC-V 架构首次进入安卓开源生态体系，推动 RISC-V 正式与全球主流移动操作系统生态接轨。2021 年 10 月，平头哥首次在玄铁处理器上成功运行了 Android 系统，并且运行了Chrome 浏览器等大型应用，实现了业内首次 RISC-V 芯片上对 Android 的支持。今年 4 月份，我们进一步在 Android 系统上成功运行 Tensorflow Light，首次实现了RISC-V 架构对 Android AI 场景的支持。平头哥持续推进 RISC-V 在 Andr

44、oid 系统的工作。截止到目前，平头哥已经在 Android 相关代码仓库做了 100 多处改动，修改或提交了 2000 多个文件，改动代码超过 12 万行。为 RISC-V 支持 Android 的生态作出了重要贡献，同时也为未来 RISC-V 支撑高性能软件栈的应用打下了基础。近期，阿里巴巴平头哥提供的 RISC-V 兼容 Android 的代码补丁正式被谷歌 Android的 AOSP 社区收录进系统源代码，这是全球首批 RISC-V 兼容 Android 的正式补丁。意味着谷歌 Android 正式开启了对 RISC-V 架构官方原生的支持，也意味着 RISC-V和 Android 两

45、大阵营的融合驶入了快车道。平头哥在 RISC-V 软件生态的探索和实践 71 Linux 系统平台也可以为开发者提供产品开发、验证以及构建产品的系统能力。Linux系统平台的软件栈自底向上分为五个软件层面，分别是 Linux 内核、设备驱动、基础系统、核心组件和系统软件。Linux 内核层，平头哥开源了平头哥各款玄铁处理器的 ARK 支持，能够为开发者提供最基础的系统支持。设备驱动层面，提供了无剑 600 平台的成熟设备驱动方案，并且提供了一套自动化验证平台。基础系统层提供了 Buildroot 和 Yocto 两种系统构建方式。Buildroot 比较简单，容易上手；Yocto 能够更有效地

46、帮助开发者构建更为复杂的系统，并支持安装包的管理，可以帮助开发者快速构建所需 Linux 发行版。核心组件层提供了可以体现产品核心竞争力的系统组件，包括诊断、图形、视频视觉、语音、安全等各种系统组件。在系统软件层，为了提高终端用户的使用体验，我们支持了涉及到 UI 交互的大型应用，比如 Gnome、多媒体的 Gstreamere、Libra office、Firefox。Linux 的系统平台已开源发布到 Gitee，我们也会通过详尽的软件技术文档以及官网自动化 AI 机器人和客户线上支持来帮助客户和开发者快速上手 Linux 系统平台。平头哥在 RISC-V 软件生态的探索和实践 72 龙蜥

47、 Anolis OS 是龙蜥社区的开源 Linux 发行版，已经较为成熟，支持多种 CPU 架构，但在此之前尚不支持 RISC-V 架构。平头哥在近日的 RISC-V 峰会上发布了无剑600 的高性能 RISC-V 芯片设计平台，并且基于平台提供了 SoC 原型曳影 1520。无剑 600 原生提供了 Buildroot 和 Yocto 等系统构建方式，我们也在探索寻求支持更多优秀的 Linux 发行版。龙蜥社区本次推出了桌面版的开源系统，为 RISC-V 芯片未来在桌面生态的进展奠定了良好的基础。本次平头哥与开源操作系统龙蜥 OS 的合作既是平头哥对于进入桌面领域的重要举措，也是为 RISC

48、-V 提供真正全面从硬件到基础软件到应用层软件的全面开放性能力的体现。无剑 600 是一个软硬一体的全栈平台，不仅有硬件、有平台，也有软件包。基于无剑 600 的第一颗原型样片曳影 1520 与龙蜥社区、中科院软件所的 PLCT 实验室联 平头哥在 RISC-V 软件生态的探索和实践 73 合打造了从底层的RISC-V芯片平台到龙蜥OS再到上层基础应用和桌面应用的全栈能力。中科院 PLCT 实验室有着非常强的应用开发能力，为系统提供了 Libra office、firefox 等大型软件的支持。平头哥提供了无剑 600 的硬件平台，并且协助龙蜥社区做好了系统 bring up。过程中，平头哥向

49、龙蜥的内核提交了 120 多个关于 RISC-V 的 ARK 以及无剑 600 相关驱动的 patch 贡献。同时密切配合龙蜥社区和 PLCT 实验室适配相关软件，也搭建了曳影 1520 云上实验室，并开放了用户体验，用户可以通过远程访问实现真实的体验。通过与龙蜥社区和 PLCT 实验室联合的技术攻关，我们已经成功在曳影 1520 上运行了龙蜥的桌面级操作系统。上图为相关实拍照片以及系统截图。这是 RISC-V 架构第一次运行 Libra office 等大型应用软件，对 RISC-V 进入未来桌面级领域运行大型复杂应用具有重要意义。此外，我们也成功运行了基于 nodeJS 和Java 的应用

50、。未来，我们希望与龙蜥社区一起为 RISC-V 架构运行更多不同种类的软件，也非常期望可以与龙蜥社区保持密切合作，一起取得更好的成绩。开源高性能 RISC-V 处理器敏捷开发实践 74 开源高性能 RISC-V 处理器敏捷开发实践 作者：徐易难，中国科学院计算技术研究所 过去二十年，开源软件对中国产业的发展发挥了革命性作用。很多产业比如云计算、移动互联网、大数据、人工智能、区块链都基于开源软件构建了产业核心技术，使得中国移动互联网产业处于世界领先水平。开源软件成功降低了 App 的开发门槛，吸引和培养了大批人才，帮助企业建立了强大的自主研发能力。开源高性能 RISC-V 处理器敏捷开发实践 7

51、5 开源软件的成功得益于它降低了互联网创新门槛，使得更多人能够参与到创新业务中。比如，现在开发手机 App 可能只需要 3-5 位开发人员花费几个月时间，其中大量甚至 90%的工作基于开源代码实现，仅需在此基础上定制 10%代码即可实现需要的功能。另外，开源软件成功提高了互联网企业的自主能力。当年，阿里巴巴正是在“去 IOE”的背景下打造了 OceanBase 数据库，目前 OceanBase 已是国际领先的数据库。借鉴开源软件的成功经验，我们希望能够构建开源芯片生态，同时借助于硬件的敏捷开发，降低芯片设计的人力、EDA 和 IP 等成本。我们希望 90%资源来自于开源社区，用户只需付出 10

52、%的精力完成自定义代码，即可打造一款属于自己的芯片。基于以上发展愿景，RISC-V 行业和生态得到了极大的关注。开源高性能 RISC-V 处理器敏捷开发实践 76 软件方面，目前国际开源社区积极投入 RISC-V 生态建设，比如 Debian 软件包对RISC-V 的支持已经超过 95%。在硬件领域，高性能 RISC-V 处理器已经越来越多地进入国际竞赛阶段，RISC-V 与顶尖处理器的性能差距在快速缩小。由阿里平头哥、北京开源芯片研究院等组成的RISC-V 基金会数据中心工作组也已成立。香山正是在此背景下诞生的开源项目，目标是做开源高性能的 RISC-V 处理器，以下是各版本介绍：第一版名为

53、雁栖湖架构，于 2020 年 6 月建立代码仓库，开始 RTL 实现工作；于 2021年 7 月完成 28nm 流片，频率 1.3GHz，实测 SPEC CPU2006 性能超过 7 分/GHz。第二版名为南湖架构，于 2021 年 5 月开始 RTL 实现工作，持续进行设计讨论。预计将于 22 年底投片，预估 SPEC CPU2006 20 分，2GHz14nm。第三版名为昆明湖架构，已经开始设计规划，新增支持 RISC-V 向量（Vector，V）扩展指令集。目前，香山在 github、gitee 等平台均已开源，采用 Mulan 协议宽松版。主仓库在开源项目托管平台 github 已获得

54、 3000+star，形成超过 370 个 fork。开源高性能 RISC-V 处理器敏捷开发实践 77 香山处理器在开发过程中非常重视敏捷开发的基础流程和工具。处理器的开发流程可以分为以下几步：第一步，新特性提出，针对特性完成设计和实现文档。第二步，RTL 实现，我们采用了 Chisel 开发语言加速 RTL 实现过程。第三步，功能验证，也就是需要确认实现在功能上是否正确。第四步，性能分析和性能验证。第五步，物理设计验证。香山开发过程中搭建了大量工具用于加速处理器设计迭代，其中有十几个工具用于辅助加速验证流程。开源高性能 RISC-V 处理器敏捷开发实践 78 我们将两年的敏捷开发经验和工具

55、沉淀为论文，文章发表在今年的计算机体系结构领域顶级会议 MICRO 上，向国际学术界和工业界介绍我们针对处理器敏捷开发的观察与技术创新。下面我介绍一部分我们创新提出的敏捷开发工具。RISC-V 体系结构的 checkpoint 能够对程序在某一时刻的状态进行全局快照。有了快照之后，可支撑上层丰富的应用场景，支持用户像使用模拟器一样使用精确 RTL模型。比如，我们可以在模拟器上完成 OS 启动，将 OS 启动后整个程序镜像进行checkpoint 并在 RTL 上实现快速恢复。即使 RTL 仿真很慢，也能够实现快速 OS 启动。其次，Checkpoint 支持生成程序无关负载，因此，只要有足够多

56、的程序，我们即可生成足够多的程序片段，并且在仿真环境下复现，快速助力处理器功能验证。另外，可以还可以从所挑选片段中进行采样，选取具有特征的片段，实现敏捷性能评估。RISC-V Checkpoint 技术已经成为支撑香山处理器体系结构和微结构优化的基础性工作。开源高性能 RISC-V 处理器敏捷开发实践 79 在 checkpoint 基础之上，我们搭建了 DiffTest 处理器系统级验证方案，基本流程为：处理器仿真产生指定提交和其他状态更新，让模拟器执行相同指令，并且在执行完成之后比较两者状态以进行报错或继续。在 MICRO 的论文中，我们提出了敏捷验证方案 DRAV，能够支持更多的处理器、

57、更复杂的场景和更快速的迭代。我们提出了 Diff-rule 机制，能够描述设计规范所允许的行为。同时，DiffTest 基于 prob 完成了微结构信息的自动传递，加速 Chisel 到系统级验证的流程。有了系统级验证之后，还需要单元级验证的支持。我们针对处理器验证中的核心难点 L2cache 和 L3 cache，完成了 TL-Test，一个支持 TileLink 总线的缓存验证框架。香山南湖架构是双核 SoC，其设计复杂度相比于雁栖湖有了巨大提高。而 TL-Test 通过单元级验证、子系统级验证和SoC级验证共同支撑了南湖架构的缓存一致性验证。开源高性能 RISC-V 处理器敏捷开发实践

58、80 有了处理器验证框架之后，我们还需要在仿真出现 BUG 后进行调试。我们提出了LightSSS 轻量级仿真调试技术，其原理为基于快照完成对仿真现场的快速重建，以支持后续调试。核心技术为通过 fork 系统调用，能够帮助通过差分快照、高可移植性、高效率等角度共同实现了低开销的进程级快照。我们实验中实测发现，LightSSS 仅带来了小于 1%的性能损失，这大幅提高了波形获取效率。现在，即使在仿真一周之后报错，我们也能够在两分钟之内完成报错现场的重现来辅助调试。最后，面向香山的性能分析和性能验证问题，我们提出了 Top-Down 模型，它能够支持性能建模、数据处理、结果分析、优化建模等完整的性

59、能分析工作流程。基于公开的论文，我们做了几点创新。开源高性能 RISC-V 处理器敏捷开发实践 81 首先，原有工作均基于 x86，不兼容 RISC-V 结构，因此我们针对 RISC-V 指令集完成了大量针对性的优化适配。其次，由于现有 Top-Down 工作主要针对另一微结构，而香山的微结构与原始论文中已经存在很大差异。因此，我们针对香山微结构的设计完成了大量优化。最后，香山处理器微结构复杂度相比于原有设计已经高出几个量级。因此我们进一步细化了 Top-Down 模型分层设计，从而支持更准确的性能分析。刚才我介绍了一些香山开发过程中同步产出的基础开发工具。从这些内容中我们能看出，香山项目的整

60、体不仅包括香山芯片，更重要的部分是底层支撑香山开发的敏捷基础设施和基础工具。在香山处理器设计开源的同时，我们还希望将开发香山的基础能力开源，赋能企业加速处理器的研发节奏，最终能够实现像软件生态一样，少量开发人员即可完成一款自定义芯片的开发，能够支持按需快速定制芯片。开源高性能 RISC-V 处理器敏捷开发实践 82 在 2021 年底，在北京市和中科院的支持下，18 家企业联合发起了北京开源芯片研究院，将参与后续的“香山”处理器产品化改造和架构研发。面向未来，我们希望通过快速迭代和流片验证，探索芯片开放、开源的开发模式和敏捷开发的基础设施，搭建一套敏捷开发的基础流程，像使用开源软件一样，快速实

61、现从 idea 到实际芯片产品的落地。我们希望建立规范的开源社区，并且基于北京开源芯片研究院的稳定资金源推动香山快速在工业界完成落地。同时，香山将继续成为学术界的创新平台，赋能更多学术界的研究者和工业界的开发人员。RISC-V 边缘 AI 芯片的开源生态和应用落地 83 RISC-V 边缘 AI 芯片的开源生态和应用落地 作者：何含，嘉楠科技 上图为当前市面上较为典型的边缘 AISoC 芯片基本框架。加入了 AI 的 NPU 加速器单元后，AI 算法的处理以及前后的数据加速，使其相较于传统的 SoC 芯片具备了更高的设计复杂度，各个模块之间需要相互协同，生态推广和开发难度也越来越高。RISC-

62、V 边缘 AI 芯片的开源生态和应用落地 84 当前，芯片开发者最常面临的困境：比如无法通过便捷的渠道购买到芯片，如何选择合适的芯片平台，如何从原厂获得完整的数据文件包括竞争力手册、文档等。另外，使用过程中发现的问题也难以向芯片原厂反馈，工作成果无法沉淀共享。因此，开发者们都希望能有一个对开发者长期友好的芯片厂商，能有一个特别乐意开源开放的芯片厂商。而嘉楠科技在过去三年里，一直在此方面积极地努力。嘉楠科技公司的定位是数字新基建算力提供商。2016年开始启动AI业务线的研发，2018 年作为业内首家交付了基于 RISC-V 架构的第一颗 AI 产品 K210，第一代 AI 芯片的神经网络加速器达

63、到 1tops/w 的出色能效比。RISC-V 边缘 AI 芯片的开源生态和应用落地 85 上图为嘉楠勘智 AI 业务线的整体 roadmap。在 2018 年推出 k210 后，2021 年 7月推出了面向专业 AIoT 领域的 k510，最高具备 2.45T 的 kpu 算力，RISC-V 核心也提升至双核 800M，配有 800M 的 P 扩展，支持 2 路 1080p 的摄像头输入。明年即将推出 K230，相对于前两代产品，其在整体计算性能上会有 3-5 倍提升。蓝色部分为未来我们将针对消费 IOT、专业 IOT 和边缘计算三个领域的 IOT 分支。K210 是全球首款 RISC-V

64、架构的商用边缘 AI 芯片，目前已经完成了对主流嵌入式OS 的应用，包括 Linux、RTT-RTOS、FREE-RTOS 等。对主流的深度学习框架也通过不断迭代实现了较为完整的支持。2020 年 4 月，Linux 通过了 k210 加入 Linux 内核的申请。RISC-V 边缘 AI 芯片的开源生态和应用落地 86 K510 是目前在市面上比较少见的高精度端侧 AI 推理芯片，主要面向中高阶 IOT 的智能硬件应用领域，具备双核 64 位 RISC-V CPU 以及 800Mhz 的 DSP 扩展，也支持FPU 扩展。K510 也是市面上面非常少见的、带有 AI 算力且同时能够支持完整

65、Linux应用的 AI 推理芯片。我们应该从多维度协同推进 AIOT 生态。RISC-V 全系列 CPU 的核心处理器的应用以及 AI 算力的长期延展和长期开源是需要坚持的核心点。只有坚持核心算力的扩展，开发者才能在芯片原厂长期推出的产品上更好地利用继承性，更好地做迭代。整体来看，可以分为以下几点：第一，SoC 算力能力的持续发展，包括由低到高的产品布局。当前 AI 领域在端侧变得非常泛化，面临丰富的应用场景，不同等级的智能硬件应用走进了千家万户。第二，系统软硬件和编译工具链路的开放演进。第三，与生态的上下游伙伴形成长期稳定的合作关系。基于稳定的产品和可迭代的软件，才能构建出稳定的生态环境。第

66、四，降低 AI 芯片开发者的使用门槛，加快成果的产出速度，加快商业方案导入的速度，形成正向的反馈和循环。RISC-V 边缘 AI 芯片的开源生态和应用落地 87 上图左侧为 RISC-V 处理器核心的性能演进，右图为 KPU 处理器核心的性能演进。在过去的 5 年，嘉楠科技基于 RISC-V 和资源 KPU 生态的演进，提供了三代产品、10 倍以上的算力性能迭代和演进，可以满足 IoT 大量生态用户不断提升的算力需要，能够开发更多样、更复杂的 AI 场景示例。当前，所有 AI 芯片的开发都需要对应专门针对 AI 的算法模型，包括不同的机器学习框架等编译工具，才能将比较常见的 AI 模型 dep

67、loy 到 AI 芯片上。RISC-V 边缘 AI 芯片的开源生态和应用落地 88 在过去的三代的产品上，我们保证了工具链前后的继承性，在保证继承性的同时也实现了对框架 TF、PyTorch、ONNX 等算法框架的支持。系统软件方面，嘉楠科技在不同芯片平台上建立了开源工程，两代芯片产品都已在github 上进行了完整开源，包括所有软件的 SDK 公共分支和开发分支，可以实时看到所有 SDK 的迭代过程，轻松获取全部开发代码以及所有 AI 开发示例和特殊方案的开发组件。另外，我们也在淘宝上面向一线开发者开放了低门槛的芯片采购和开发板采购渠道。RISC-V 边缘 AI 芯片的开源生态和应用落地 8

68、9 通过和龙蜥社区以及其他上下游伙伴的长期合作，我们基于 k210 和 k510 孵化出了大量第三方开发者硬件形态。嘉楠科技构建了软硬件全栈的开源开放的生态系统，从硬件参考设计的芯片级、板级到模组级，到系统工具链、AI 算法 demo 以及最上层的商业化 Turnkey 方案，均已实现了面向用户且非常完整的软硬件协同的开源能力。在 github 上孵化了 650+开源项目，全球开发者数量超 1 万名。庞大的开发者和爱好者基础也同样为嘉楠科技带来了商业回报。目前，我们的 210和 510 芯片累计已出货超 200 万颗，销往 20+国家。嘉楠科技将会在更大范围的产品线上坚持开源，与开发者和所有

69、RISC-V 爱好者实现生态的共赢。RISC-V 边缘 AI 芯片的开源生态和应用落地 90 CanMVK210 是由 01Studio 设计研发，基于嘉楠科技边缘计算芯片 K210（RSIC-V架构，64 位双核）和 CanMV 开源项目的一款开发板，硬件采用一体化设计（K210核心板、摄像头、LCD 集成在一个 PCB 上），即拿即用。该产品在上架当天即达到近 1000 台的销量。K510 CRB为基于K510 CORE核心板扩展的嵌入式参考开发板（Customer Reference Board），该平台能够加速客户产品开发和导入速度，产品已于今年 5 月在淘宝店 RISC-V 边缘 A

70、I 芯片的开源生态和应用落地 91 铺上线。截至目前，市场上已有五六百名开发者依托于该硬件平台实现生态的 demo以及产品方案的开发。K510 CRB 也是目前市面上不多见的、能够在端侧支持高精度的 FP16 算力的 AI 芯片，在做 AI demo 的开发时，可以实现训练模型到实际部署模型的低精度损失，简化开发者在开发过程中的复杂度。快速发展的 RISC-V 软件生态 92 快速发展的 RISC-V 软件生态 作者：吴伟，PLCT 实验室项目总监 TARSIER 团队的愿景是让 RISC-V 成为所有主流开源软件的 Tier-1 平台。我们希望确保所有流行的 Linux 发行版在 RISC-

71、V 平台上平稳流畅运行，软件生态丰富性、可用性以及使用体验达到并超过 X86 及 Arm64 平台。期望 2025 年，我们能够促成主流 Linux 发行版将 RISC-V 提升为默认支持架构，RISC-V 笔记本上的软件能够满足日常办公需求，支撑 RISC-V 进入超算领域所需的所有开源软件栈。上图中最底层为基础设施层，软件所购买了几乎市面上所有能买到的 RISC-V 设备，为全球所有开源社区提供开源的 CI Farm，同时也通过阿里云构建了大量交叉编译环境，拥有超过 2000 个节点的硬件环境（包括 x86 计算节点）。第二层为面向开发者和操作系统的基础服务层，目前为全球超过 50 个社区

72、提供 CI Farm 服务，可直接通过 SSH 的方式远程登录访问所有 RISC-V 设备。第三层为语言和执行环境层。所有编译器、虚拟机、模拟器均已能够在解释器模式上被执行。另外，我们也正在做 SpiderMonkey 等 JIT 方面的工作。快速发展的 RISC-V 软件生态 93 最上层为 Linux 发行版层，几乎所有发行版包括龙蜥操作系统在内的都已支持 RISC-V 架构。摩尔定律在 2003 年已经停滞，但算力地发展以及数据规模的增大是无限的。这其中存在内生的矛盾，硬件领域的革命已经推行了十几年，顶端优势逐步消除，随着芯片设计成本、制造的成本的降低，工艺的门槛也逐步降低，越来越多的厂

73、商开始尝试在特定领域做特定的芯片。软件系统的复杂度超线性增长（可能是平方级或指数级增长），比如手机内的一个软件可能有几百万行代码在运行，每一次更新都或许会新增几十万行代码，这样的规模已经超过任何公司或国家能够维护的水平。快速发展的 RISC-V 软件生态 94 因此，2022 年的开源相比于 1980 年代的开源已经具备了不一样的意义。所有公司不得不利用开源，否则产品成本将非常高。开源软件已经成为人类知识尤其是信息产业知识的共同体。全球范围内来看，有能力驾驭软件复杂度的开发者也非常有限。如果没有意识到这一点，则在产品的推广和竞争上将面临巨大的困境。当前，一个细分领域只有 1-2个开源社区最终活

74、跃，不被上游维护的代码就像活在 ICU 中，费用昂贵且死亡率高。综上，我们可以得出两个推论：第一，开源软件将吞噬一切：市场或细分技术领域出现了开源软件的活跃社区后，它大概率会成为最终的顶部赢家，会压制其他非开源或新兴的产品。第二，必然会出现自由开放的指令集。指令集对于软件开发者而言是开放的，但对于硬件制造商来说是封闭的。开放的指令集能够使领域专用架构的硬件设计成员设计自己的指令、设计自己的芯片。另外，我们认为，最终能够存活的自由开放的指令集也仅有 1-2 个。快速发展的 RISC-V 软件生态 95 所有技术领域都会有开源的标准。从狭义上来说，RISC-V 仅包含规范，而规范是开放的。对于硬件

75、开发者而言，只要符合标准，则在开发完后可以立刻通过编译器编译软件并运行，这是一种巨大的转变。快速发展的 RISC-V 软件生态 96 RISC-V 是成功的。它在合适的时间（摩尔定律已经失效、需要 DSA 时）被提出，采用了模块化指令，最小的指令集仅 47 条指令，可以直接在小的芯片控制和 IoT MCU中进行使用，也可以加浮点计算指令、DSP 指令成为手表芯片，加 64 位之后可以成为手机或笔记本电脑的芯片。RISC-V 在提出时即采用了开放的标准，硬件商可以直接使用，无需考虑专利等问题。RISC-V 于 2020 年决定从体系架构导向转为软件导向。软件导向的最大特点在于对开源软件和开发者有

76、着充分的尊重，能够采用协同的方式产生统一完整的社区。而这也引发了新的商业模式，即先选择 RISC-V 架构，再选择制造商。快速发展的 RISC-V 软件生态 97 上图为 RISC-V 在 2020 年发生转向。我们也期待国内厂商能够更多地从软件视角进行思考。上图为 2021 年 RISC-V 基金会的统计。而实际上，目前已有 100 亿颗 RISC-V 芯片出货，2025 年将有可能超过 800 亿颗。以 debian 为例，RISC-V 开源软件生态对操作系统基础性的支持已经全部完成，包括浏览网页、办公软件、图形编辑等，还有大约不到 5%尚未完成的主要为 JIT 编译器等，目前正在陆续解决

77、。快速发展的 RISC-V 软件生态 98 中国是 RISC-V 发展非常迅速的区域，第二届 RISC-V 中国峰会是全球范围内除了北美之外唯一 summit 级别的峰会。所有演讲视频均已上线：https:/ RISC-V 当前主要的应用涵盖了编译器领域、虚拟机领域、模拟器领域、应用领域以及 RISC-V 发行版。快速发展的 RISC-V 软件生态 99 面向 RISC-V 开源软件的生态存在大量崭新的机会，是基础软件领域的狂欢，我们希望有更多人参与到 RISC-V 的生态建设，尤其是软件的生态建设。RISC-V 为安全领域开放了新的可能性，可以通过 FPGA、通过开源的 RISC-V 探索更

78、多的可能。我们相信，五年后市面上可能会大量涌现 RISC-V 相关的安全产品。我们正在实施采用 RISC-V 搭建超过 1000 个核的集群，希望能够借此验证开源软件在 HPC 领域对 RISC-V 的支持。PLCT 实验室的实习生团队将会充分挖掘包括 Vector 快速发展的 RISC-V 软件生态 100 v0.7.1 扩展在内的 D1 算力潜能，将形成一套面向 RISC-V 超算领域的 Linux 发行版：RobinOS，且基于龙蜥 RISC-V 实现。对 此，我 们 计 划 于 2022 年 12 月 31 日 前 公 开 该 项 目。大 家 可 登 录https:/ github 的

79、 pull request 直接进行提交，甚至可以拆掉机器，按照自己的拓扑方式重建。另外，PLCT 实验室开始准备用廉价交换机搭建个1024 节点的 RISC-V 集群。快速发展的 RISC-V 软件生态 101 PLCT 许愿池计划是 PLCT 实验室（及 TARSIER 团队）极具特色的社区合作模式。我们向全球开发者收集关于在 RISC-V 软件生态中希望看到、使用哪些软件，或具备哪些特性，并从中选择一部分列入新一年的路线图。蜥峰会 RISC-V 专场圆桌对话 102 蜥峰会 RISC-V 专场圆桌对话 主持人：当前，RISC-V 更多的是在端侧的应用，如果要向数据中心层面演进，还需在哪些

80、方面进行完善？笨叔：RISC-V 从诞生至今一直在高速发展，短短几年时间的出货量已经达到 100 亿颗。要走进数据中心，个人认为需要在以下几个方面不断完善：第一，硬件生态。目前能够做高性能 RISC-V 处理器 IP 的龙头企业，国外有 SiFive公司，国内有平头哥和香山。SiFive 目前为止官宣性能最高的 CPU 的 IP 为 p650，相当于 ARM 的 Cotex-A77，其公开资料显示，最多支持 16 个核心，然而用作数据中心还远远不够。RISC-V SoC 的总线生态目前尚无建树，大多被 ARM 牵着鼻子走，因此我希望 RISC-V 的厂商可以联合起来，构建自己的 SoC 总线生

81、态。同时，内存访问、网络性能、存储性能、数据库性能、虚拟化性能以及数据安全等也需要持续推进。主流的数据中心服务器厂商最近几年在虚拟化、数据安全、加解密、AI 加速、网络加速、存储加速等方面做了很多优化和尝试，而 RISC-V 在以上方面仍处于起步阶段，离芯片部署和应用还很远。到目前为止，尚没有厂商真正做出一款基于 RISC-V 的服务器，任重而道远。第二，软件生态。软件生态和硬件生态的发展相辅相成，软件生态需要完善的内容甚至更多，比如常见的 Linux 内核、GCC 编译器。除此之外，可能还需要优化虚拟化和语音相关的开源软件比如 docker、kubernetes，网络加速方面的软件栈、AI

82、软件数据库等也都需要做特殊的优化和性能调优，需要投入巨大的人力和物力。总体来说，我认为 RISC-V 进入数据中心的前景充满光明。占俊：数据中心或高性能计算需要有背后创新的动力，每个领域都有自己独特的需求，而 RISC-V 的模块化设计和可定制指令能够满足新产品的要求。因此，RISC-V 想要进入数据中心领域，并不一定要在 ARM 的基础上进行革新，而是可以针对更新的场景发力，比如新算法的硬件知识或新的扩展能力。仇瑞：从现有的实践经验来看，从 ARM v8 走向 ARM v9，我们才真正看到了 ARM走向数据中心的曙光。ARM v8 时代有很多厂商经历了失败，而 RISC-V 走到现在，迭代速

83、度依旧很快。ARM 在发展过程中遇到的障碍，在 RISC-V 走向数据中心时，是选择规避还是走向更新的架构调整，是我们需要思考的。只有真正走向商用、大 蜥峰会 RISC-V 专场圆桌对话 103 规模推广，很多问题才会被从业者发现。开源是 RISC-V 的活力所在，但是由开源转向商业的过程，也是 RISC-V 从开源社区走向真正的商业数据中心过程需要考虑的问题。吴伟：通常情况下，我们默认讨论的都是中间最大的一颗 CPU，但数据中心可能有数百万个节点，RISC-V 正在通过“农村包围城市”的方式，先慢慢渗透小的节点，再逐步占领更大的市场。从传统 CPU 的角度来看，大多厂商不可能在短时间内决定选

84、用 RISC-V。但是如果ARM 能够成功替换 x86 的 CPU，则意味着 ARM 能够被 RISC-V 替换。这也表示，ARM 的成功会导致自身市场的丢失，这是新的商业模态，会导致 ARM 等传统 CPU的护城河将不再存在。技术方面，数据中心现在大多被托管。而托管中存在的关键技术点在 2022 年已经实现，即 Java 的执行环境，它已于 2022 年被 Oracle Open JDK 社区接收，意味着所有社区可以自然而然地获得 RISC-V 的支持，这是一种潜移默化的影响。预计 1-2年后，最上层的应用（前提为用 Java 语言编写）能够从 x86 无缝切换到 RISC-V，使得尝试新产

85、品的成本接近于零。云计算方面必须有虚拟化的支持，而 RISC-V 当前存在的不足在于 hypervisor 的扩展目前只是草案，导致硬件厂商不敢流片。我们预计该问题将于 2023 年解决，2024年可实现芯片的完全铺货。另外，RISC-V 也拥有无限的优势。它定义了自定义指令的空间，具有无限的可能性。x86 和 ARM 的指令编码点有限，但是基于 RISC-V 做打底，服务器底层甚至可以不是 RISC-V，可以通过自由指令增加大量差异化的与数据中心相关的指令，可以无限“套娃”。同时，ARM 和 x86 也好在上层模拟用户态的 RISC-V 时，运行时的二进制转换开销非常小，使得用户的迁移成本接

86、近于零。主持人：RISC-V 是否能成为未来中国自研芯片的主流？笨叔：目前，国内大部分 985 高校和部分 211 高校计算机相关专业的核心课程已经逐步从原来的 Linux 和 x86 转向 RISC-V，高校对 RISC-V 的热情能够为产业界输出大量人才，对国内自研芯片的发展起到推动作用。蜥峰会 RISC-V 专场圆桌对话 104 另一方面，目前国内的芯片厂商大多都采用 ARM 的 IP，但已经有不少厂商开始慢慢尝试采用 RISC-V。比较一致的观点为，虽然 RISC-V 软硬件生态还不够完善，但它在未来几年一定会高速发展，因此越早布局 RISC-V 能够在未来得到越多的市场。今年，英特尔

87、也在布局 RISC-V，加入到 RISC-V 基金会，年底将发布一款 RISC-V 的开发版。我相信会有越来越多的芯片厂商以及上下游厂商逐渐加入 RISC-V 的布局。在不久的将来，RISC-V 一定会成为国产芯片的中流砥柱。占俊：目前，国内存在多种 CPU 架构，而过多的架构可能在未来会造成资源的分散，导致若干年后中国依然缺乏在全球市场上与 ARM 和 x86 竞争的能力，CPU 仍然受制于人。因此，大力发展 RISC-V 的产业生态，加大对 RISC-V 的开源设施的建设，可能是一条出路。我也相信，未来 RISC-V 会成为一种主流芯片的架构。仇瑞：伴随着国产软硬件自主化的过程，RISC-

88、V 的出现确实掀起了一定的热潮，但国内相关领域的人才从某种角度上来说依然较为匮乏。软硬件技术越接近底层，人才的培养周期越长。厂商过多加上人才分散，前期可能会展现一片宏伟的景象，但是持续发展几年时间后，最终可能会聚焦为几个主流的 RISC-V IP 厂商，再衍生出很多 SoC 厂商，形成最终的生态。吴伟：在 2025 年之前，RISC-V 一定会在全球范围内成为继 x86 和 ARM 之后的三大架构之一。而中国是世界的一部分，中国新的 CPU 一定是 RISC-V 占绝对主导。有能力开发核心软件或库软件的开发者非常稀有，不仅是在中国，在全世界亦如此。RISC-V 成功的关键并不在于设计上有多么优

89、秀，而是在合适的时间找到了合适的商业模式，用指令集完全开放的授权、模块化的设计吸引了很多足够优秀的开发者来持续贡献。因此，RISC-V 真正有了蓬勃发展的趋势后，很难被再次替换或被超越。我相信 RISC-V 一定会成为国内的主流。主持人：RISC-V 软硬结合是否有优势？具有哪些优势？笨叔：RISC-V 架构的优势在于开源开放、免费的指令集和架构的授权，这是其他商业指令集无法具备的优势。近年，RISC-V 的软硬件生态虽然已经取得了很大进步，Linux 内核、GCC 编译器、Android 系统等主流开源软件已经开始逐步接受 RISC-V补丁，但依然不能与 ARM 的生态相提并论。RISC-V

90、 开放开源的特质一定会吸引很多上下游厂商主动贡献力量，发展前景不可估量。蜥峰会 RISC-V 专场圆桌对话 105 占俊：AIoT 时代已经来临，智能化的应用场景和万物互联的生态对芯片市场有着巨大的需求，特别是中国在智能化和物联网方面具备先发优势。但中国芯片的核心技术一直受制于人，RISC-V 将成为国产芯片自主发展的良好契机。RISC-V 是模块化的设计，可定制指令在轻量级的应用场景上能够更好地发挥软硬结合的优势。特别是在物联网时代，芯片的架构需要轻量化发展，要满足各种不同的应用场景，RISC-V更具优势。仇瑞：RISC-V 的优势在于开源和灵活性。开源和灵活性能够促成软硬结合，单纯的硬件不

91、会面向客户，而是必须搭载软件才能最终面向客户，而通过软件来作用于硬件，紧接着再进行模块化设计的调整，从而实现产品更多的能力，这确实是 RISC-V的优势。吴伟：RISC-V、ARM 和 x86 中，只有 RISC-V 能实现软硬结合。这是 RISC-V 与另外两者本质上的无法相提并论，并不是“优势”二字所能概括的。Q：自己在硬件上增加指令，自己优化编译器，会不会造成上层软件的分裂？比如想用某款硬件，则必须要使用它的交叉编译列。吴伟：RISC-V 留了很大一部分的编码区域用于自定义指令。如果在遵守 RISC-V 规范的基础上进行指令集的扩展，则公版编译器编译出来的程序可以在芯片上直接运行，只是没

92、有使用用户的特定指令。比如龙蜥的所有程序能够在哪吒 D1 上运行，D1 的自定义扩展 vector0.7.1 遵循了 RISC-V 的设计标准，保证了最基本、最通用的兼容性。另外，如果自己设计的指令集没有遵循 RISC-V 规范，占用为未来指令扩展预留的空间，则可能会出现不兼容的情况。Q：RISC-V 的模块化在硬件、编译器以及各种软件上，能否做到像内核模块一样，在运行时进行 patch 加载，而不是提前将整个 SDK 先将模块进行加载、编译？吴伟：编译器在编译时，一份代码可能会生成很多份二进制，这多份二进制是针对不同的 CPU 配置生成不同的二进制序列。即使是 x86 的计算库，也会做运行时

93、的判断，启动时加载库，加载时会判断 CPU 的 flags 是否存在 SSE 指令集。蜥峰会 RISC-V 专场圆桌对话 106 如果存在，则加载时即会加载支持 SSE 的二进制函数实现。更高端的比如 avx512指令的扩展，在加载时会将带有 avx 二进制的实现加载进功能里。这已经非常成熟的编译器技术，是函数级的，在二进制有多个版本，根据 CPU 的属性加载。主持人：从以前做主板或 CPU 的架构演进到现在的 DPU 架构，很多计算的能力被分散到不同的硬件里，不同的硬件承载不同的能力。RISC-V 是否能在此基础上做得更加模块化、更加灵活，值得期待。从 x86、ARM 转向 RISC-V，在

94、软件移植方面我们需要进行哪些工作？笨叔：IoT 场景下，软件比较碎片化而且相对封闭，每个设备厂商都有自己的软件实现。国内外有不少的 IoT OS 厂商会提供 RISC-V 版本的微内核 IoT OS；手机场景下，主要为 Android 和苹果。苹果相对封闭，传闻苹果正在考虑和评估 RISC-V，Android最近也在逐步接收 RISC-V 的相关补丁，从 demo 到量产，还有很长的道路要走；PC 场景下，主要为 Linux 的各种发行版，目前各大 Linux 发行版都在紧锣密鼓地支持 RISC-V。最近国内有厂商正在做一款基于 RISC-V 的笔记本 ROMA，相信它的出现会对 PC 软硬件

95、的生态发展起到强有力的推动作用；服务器场景下，同样需要芯片厂商、服务器厂商、OS 厂商一起努力做软硬件生态方面的优化，需要有几家规模较大的公司持续在软硬件方面不断进行投入。占俊：做好生态的确是一件非常有难度的事情，需要上百家生态厂商的参与，但是生产厂商们会从各自利益来决定在软件研究方面的投入，这对 RISC-V 软件架构的兼容性和扩展性提出了很高要求。另外，在软件方面要提供足够多的底层工具，比如跨平台的编译器、统一的框架平台，生态软件承接商也需要大量的产业投入。在RISC-V 的推广过程中，可能需要通过模拟器或底层转码器来支持业务软件，并在性能上做一定的优化。需要积累足够多的用户，才能撬动足够

96、多的厂商来投入。仇瑞：软件的移植由开发者完成。目前多线程编译依然存在问题。ARM、x86 走向RISC-V 的第一步一定是跨架构编译链的成熟。逐步走向商业的过程中，不同厂商对于同一领域的诉求不一样，希望衍生出其他架构来辅助应用实现，而架构的实现又是很庞大的工作。实现架构后，再到应用，再优化、落地，整体移植过程十分漫长。因此我认为，开发者先投入到编译链工具，可能对于后续的发展更有推动价值。吴伟：本人一直带领两个团队在做软件移植方面的工作，我们将开源软件和商业软件区分开，商业软件又再分为体系结构相关和无关两个部分。与体系结构无关的商 蜥峰会 RISC-V 专场圆桌对话 107 业软件只需要用 re

97、start 工具链重新编译即可。体系结构相关的软件，如果不是用户态，而是涉及到特权态的情况下需要根据架构做专门的条件判断；如果要使用专门的体系结构相关的加速，需要像 OpenBLAS 软件一样，针对英特尔的 avx 扩展指令实现子过程。大多公司可以较为轻松地在 RISC-V 上实现同样的功能，但是如果想要达到同样的商业竞争力，还需要有专家针对 CPU 上的 vector 扩展或 DSP 扩展写一个库。而开源软件是人类知识产权的共同体，PLCT 实验室作为中科院的一部分，必然责无旁贷。云原生专场云原生在龙蜥社区应用与实践 龙蜥云原生社区发展思考&Kata Containers 社区共建 109

98、龙蜥云原生社区发展思考&Kata Containers 社区共建 作者：刘奖，阿里云资深技术专家 彭涛，蚂蚁集团高级技术专家 云原生从提出至今，经历了 7-8 年的发展壮大，目前已经能够投入实际生产活动中，进入了相对健康稳态的环节。云原生系统由四个部分组成。最底层是云计算基础设施及服务，云原生代表长在云上的一套体系架构，因此其底层一定依托于云计算的基础设施以及服务。在此之上是云原生管控系统和云原生节点系统（龙蜥云原生 OS）。管控系统更关注的是应用定义、各种服务框架以及业务编排，更关注集群级的行为，将很多机器或资源进行整合，关注系统整体如何对上服务于业务；而云原生节点系统的关注点在于，在一个具

99、体的节点上，如何高效利用本地的资源、服务并最终服务于业务。管控系统和节点系统一起服务云原生的典型应用场景，包括无状态应用、数据库、大数据智能应用、创新平台等。龙蜥云原生社区发展思考&Kata Containers 社区共建 110 我们想要通过龙蜥云原生构建云原生操作系统。如何构建操作系统？最终希望构建成什么样的操作系统？这是半年以来我们一直在思考的问题。我们曾考虑过两个模型。第一种思路是以 K8S 的发行版为核心立意点，为整个云原生提供开箱即用的发行版，再对发行版下需要的基础软件或操作系统的核心组件和能力进行整合。另外一种思路的核心是立足于操作系统，做云原生时代所需要的操作系统，支持云原生服

100、务平台，比如可以有阿里的 ACK-D 也可以有 OKD 等不同的跨层平台方案。经过综合考虑，我们认为后者更符合当前的定位和需求。龙蜥云原生发行版本质上是针对云原生的技术潮流和业务背景下新型的操作系统发行版，最直白的解读是龙蜥针对云原生场景的特定发行版。容器最开始出现时，操作系统已经将 Docker 等组件包含进来，可以在操作系统里运行容器的组件或服务，也称为包含容器组件的经典 OS。15 年左右，业界提出了新的技术思路在有容器的环境下，可以为容器形态定制专门优化的操作系统，称为 congtainer 或容器系统。然而，我们认为仅仅支持容器还不够，因为云原生还需要更多服务、更多基础能力。在云原生

101、下，应当构建支持云原生业务场景的云原生操作系统，这意味着从容器 OS往前继续演进了一步，演进成为容器云原生 OS。龙蜥云原生社区发展思考&Kata Containers 社区共建 111 最终，我们希望云原生 OS 里的核心技术能够反哺经典 OS，比如包管理、任务资源分配、软件发布等也可以使用容器技术。龙蜥云原生操作系统正在实现从容器 OS 到云原生 OS 的跨越。立足于龙蜥基础的OS 发行版，针对云原生场景进行特殊的优化以及定制，再加上云原生所需要的组件，为用户打造出一套开箱即用的云原生发行版。理想状态下，用户购买几台物理机或在云上购买资源之后，即可快速部署一套系统，运行业务。今年上半年，我

102、们协同 Intel、蚂蚁、阿里内部各团队共同探讨，设计出了龙蜥云原生 OS 的雏形。最底层基于 LifseaOS 容器操作系统，在此之上集成了 Dragonfly 和 SIG，解决的核心问题是系统如何快速部署、快速拉起。往上是运行时、存储、网络几个组件，最上层是容器管控系统。运行时方面，在 Docker 基础之上，针对特殊的业务场景包括不同的任务之间的隔离能力等，构建了 Kata 容器；再结合最新的硬件能力的发展，创新地协同整个国际社区，整体推进了机密容器的技术路线发展。云原生存储方面也构建了一套非常强大的系统，包括镜像管理、针对 AI 大数据场景下的数据加速、数据分发。以上能力初步构成了 A

103、CNS 系统，但系统安全、运维的构建尚未完善。龙蜥云原生社区发展思考&Kata Containers 社区共建 112 龙蜥云原生发行版基于各种各样的开源项目，且开源项目均有自己的上游开发社区，他们与龙蜥云原生社区之间达成互相配合的关系，而 katacontainer 就是他们之间合作非常好的范例。我们实现了 katacontainer3.0 的关键特性，将宿主机上的 runtime 从 go 版本改为rust 版本，内置 Dragonball 虚拟机的安全沙箱，简化整体的部署架构，也成为了开箱可用的方案。同时基于此架构增加了 IntelTDX、AMD SEV 机密容器的支持以及Cgroup

104、v2 和 GPU 的支持。整个开发流程是典型的社区开发迭代流程。我们在去年年底的 Kata VPG 会议上通过社区公开讨论的形式，将 Kata3.0 的关键特性引入到上游社区。龙蜥云原生社区贡献关键特性到 kata 社区，kata 社区通过发行 3.0 版本在龙蜥云原生发行版里打包 katacontainers，形成了两个社区之间良好的互动流程，两个社区协同合作才能在未来有更好的发展。我们希望龙蜥云原生社区能与其他开源社区一起，以相同的形式继续开展合作，实现从上游社区到龙蜥原生发行版之间的良好互动，推动整个社区的发展。中国移动算力网络云原生虚拟化技术 113 中国移动算力网络云原生虚拟化技术

105、作者：魏宝辉，中国移动信息技术技术中心 PaaS 架构师 从算力网络的建设背景上来说，我们国家在 2020、2021 以及 2022 年密集出台多项了相关政策规划规划，比如数据中心、东数西算以及工信部的数据中心发展规划等。建设算力网络既是国家总体规划，它也是产业发展的需要，当下各当前企业都在进行面临产业数字化转型加速，对信息基础设施的实时供给提出了更高需求。建设算力网络也符合中国移动战略转型的需要要求。中国移动算力网络云原生虚拟化技术 114 算力网络的总体规划主要是面向国家产业数字化的升级，构建新型的基础设施。算力网络是以算为中心，以网为根基，网、云、数、智、安、边、端、链（ABCDNETS

106、）深度融合的新型信息基础设施。实现“算力泛在、算网共生、智能编排、一体服务”的目标。算网共生强调从网随算动、算网融合，到算网一体。网络从支持灵活、随需、敏捷的算力连接，到感知算力、承载算力，实现网在算中、算在网中。算力泛在指构建云边端多层次、立体泛在的分布式算力，实现三融通。空间上，融通东西，实现 4+3+X 数据中心布局；逻辑上，实现融通云（C）、边（E）、端（T）；内核实现融通异构，实现 ARM/x86/ASIC 等多样性算力。智能编排指融数注智，构建算网大脑，实现算网统一编排、调度、管理、运维，打造算网资源智能规划、灵活调度、高效优化的核心能力。想要实现以上要求，需要逐步推动算力成为与水

107、电一样，可“一点接入、即取即用”的社会级服务，达成“算力无处不在、网络无所不达、智能无所不及”的愿景。还要实现多要素算力的融合供给、社会算力的并网融合以及数智服务的融合供给，让用户感觉到算力无处不在，网络无所不达，提供智简的使用模式。算力的开发过程中会面临很多问题。比如有各种各样异构的资源、在不同地域部署了不同服务。在算力网络的开发过程中会调用到不同的能力，而能力又分散在各个不同的地方，使用方式也不尽相同，尤其是在云原生时代，微服务开发模式下，往往需要多人协作，甚至多团队协作，那么对开发环境提出了较高的要求，不同的模 中国移动算力网络云原生虚拟化技术 115 块都需要有开发测试准生产等多套环境

108、，那么如何在相对有限的算力上更高效的供给 k8s 环境成为一个难题。开发人员使用本地笔记本电脑开发时，笔记本承载 k8s 环境相对较重，有一定的负载，会影响开发效率。服务器算力更强性能更好，但是却难以提供每人一套 k8s 环境。为解决这个问题，我们利用云原生、基于算力虚拟化技术打造了磐基磐舟一体化开发环境。提供云原生的虚拟化集群，在物理硬件上提供多套虚拟化 k8s 集群，有了开发集群才能做基于云原生的算力网络改造以及应用。在传统集群模式下，比如 9 个节点一般能创建 2-3 个集群，只能满足 2-3 个小的团队使用，而实际的开发团队数量会更多。在云原生虚拟化模式下，能够实现 9 个节点 170

109、 个集群左右的供给。集群均为虚拟化的集群，互相之间独立且隔离，不同的开发团队可以使用不同的集群，甚至每一个开发都可以申请多个集群，有效解决云原生算力开发过程中碰到的开发环境、测试环境不够用问题。技术上，我们使用了 gitops 等云原生的技术，结合 kubevirt、kind 等技术栈，融合了 k8s 的 ClusterAPI 实现了集群资源的自动化供给，同时兼容 ARM 和 X86 两种异构的硬件资源。为了解决本地调试、云原生调试、微服务调试之间的联调需求，我们将集群环境与云IDE做了关联，将云IDE设置为类似于小的开发笔记本，用户可以拥有多个云IDE，中国移动算力网络云原生虚拟化技术 11

110、6 而且云IDE可以部署到多个集群之中，也可以多个用户的云IDE部署到同一个集群，云 IDE 之间能够连成小的局域网，用户可以方便地进行联调，另外用户可以根据自己的使用习惯保存配置。用户也可以从本地直接连到远端的开发集群，云 IDE 可以与远端、本地做联调，解决了用户在联调中本地无法连接远端集群内的中间件、应用的问题。在安全上使用了多层的安全防护，虚拟化的集群相当于在 POD 内设置了虚拟化，虚拟化上又进行了集群的安装，实现了 k8s in pod。那么我们可以基于 K8S 做 POD 级的出入双向白名单控制。采用了云原生虚拟化以后本质上内核已经做了隔离，集群之间与物理机之间也都得到了较好的隔

111、离。在用户开发调试的访问上可以采用统一的开发网关，实现统一的访问控制。云 IDE 会按用户隔离，一个用户可以有多个云 IDE，多个云 IDE 可以多个部署到多个集群，实例之间互相隔离且为容器化。通过集群级、访问级、底层物理机级几层的访问控制以后，隔离上的安全能够得到比较充分的保障。中国移动算力网络云原生虚拟化技术 117 本产品支撑了 2022 年中国移动云原生开发大赛，使用了 9 台服务器，为 130 支参赛队伍，累计交付集群 990+个，同时活跃集群高达 175 个。提供云 IDE 小电脑 397个，用户自助操作内置开发套件服务 1799 次，用户自助部署并暴露 980+服务，开发调试访问

112、超过 1.5 亿次。但是在平台支撑仅投入 3 个开发，1 个兼职运营，无专职运维人员。得益于技术演进，基本实现了平台自助化操作、无人值守自动化运行，用户随用随申请，完全自服务，用完自动回收。本次提供云原生虚拟化服务的资源池分布在两个不同的地域，平台可以做两个地域之间的用户负载。因此，通过该模式能够实现算力的分布式布局，帮助用户解决了算力使用、开发问题，也为后续算力网络的推广应用打下了良好的技术基础。基于 kata 的 Serverless 产品体系建设 118 基于 kata 的 Serverless 产品体系建设 作者：王琦，联通云云原生架构师 1.建设背景 2017 年到 2021 年，国

113、家及地方发布了有关数字化转型以上云的相关政策，其中国家层面 14 项，省市层面 57 项。此类政策也持续引导着国内云计算产业的发展，意味着云计算需求端即将迎来爆发式增长。因此，联通内部也制定了相应的计划和策略。面对如此爆发式的需求增长，能力端是否能够满足需求端的要求？需求端，从联通各省份以及子公司的角度来看，他们更关注零门槛、开箱即用、低改造成本以及平滑迁移的能力。而以上需求正好与 Serverless 无服务器的概念相契合。因此，我们选择进行 Serverless 产品体系的建设，以满足未来爆发式增长对云能力的需求。基于 kata 的 Serverless 产品体系建设 119 在 Serv

114、erless 产品体系建设过程中，要解决以下几个问题。首先，通过安全容器解决弹性容器实例在多租户体系下的安全问题。其次，在裸金属服务器上构建相应的弹性容器实例 ECI，减少虚机上启动容器时一系列资源和性能的损耗，同时借用云平台多租的存储和网络进行租户间的隔离。最后，解决成本问题。构建 Serverless、K8s 或无服器应用引擎时，需要多款产品共用底层基础设施 K8s 的算力，但是又不能互相干扰。因此，我们采用社区虚拟集群的解决方案，从 host 底层提供对应的逻辑虚拟集群，将逻辑的虚拟集群提供给平台产品层使用。2.Serverless 产品体系建设 基于 kata 的 Serverless

115、 产品体系建设 120 联通的产品建设思路为在联通云统一的存储和网络基础设施之上，一体化地构建裸金属服务和资源 K8s 的管理体系。联通将基础设施的 K8s 作为整体调度层，统一调度 OpenStack 虚拟化组件以及云原生相关算力，称为双引擎。完成资源和基础设施的构建后，在其之上可以构建出三种云原生的负载能力，runc、kubevirt 的敏捷虚机以及基于 Kata 的 ECI 弹性容器实例。Serverless 体系的产品主要基于弹性容器实例 ECI 进行构建，包括注重服务器无感知概念的无服务 K8s 函数计算产品、面向用户应用快速上云层面的 Serverless 应用引擎、Cloud I

116、DE 以及托管 K8s 和 vk 的组合产品扩展能力。右下角为逻辑视图。我们在 host K8s 之上复用了 IaaS 的网络以及存储能力，通过 ECI 构建对应的租户K8s 的 master 负载，包含调度器、vk 插件等。租户 K8s 通过 vk 插件构建虚拟 node，并通过 vk 连接 ECI 相关的实例提供算力，使得租户集群拥有多个资源池的算力规模。通过以上方式整合已有的 IaaS 服务，包括已有的网络和存储能力，即可与 ECS 拥有同样的性能规格以及异构计算的能力，可以快速启动、快速部署。基于 kata 的 Serverless 产品体系建设 121 左上半部分是同步与启动机制展开

117、后的流程示意图，通过各自租户集群的同步器，将对应的资源进行 guest 和 host 之间的双向同步，将多种必要资源同步到 host K8s集群中，无需修改任何 K8s API。由于 guest 的 master 节点是完整的，因此其具有与上游 K8s 百分百兼容的能力。同时，租户集群也需通过一致性认证测试。其中核心的业务逻辑即上图中复杂的同步器同步规则。当大部分 guest 资源都有对应的同步器或不同步的处理逻辑，意味着整个 Serverless 集群的能力已经完善，可以投入使用。3.Kata 安全容器 进行 Serverless 产品体系建设时，我们参考了社区的方案，对 Kata 的能力进

118、行了考量，并且针对 CPU、内存的损耗、网络性能等问题进行了优化，满足了当前联通Serverless 场景的使用需求。而由于国产硬件厂商繁多，用户在选择、使用时，时常遇到困难。无服务器的能力对于用户无感知底层硬件，是否可以提供帮助？Serverless 结合国产化服务器和芯片，通过无服务器技术屏蔽底层硬件的差异，同时增强底层的调度机制和算法，是否可以达到在同等算力基础之上异构芯片之间的服务故障和自动迁移的能力？这非常值得期待。基于龙蜥与 Koordinator 的在离线混部的实践 122 基于龙蜥与 Koordinator 的在离线混部的实践 作者：赵蔚，爱奇艺基础架构研究员 1.爱奇艺离线业

119、务混部背景 与众多互联网公司一样，爱奇艺常见的负载类型包括业务应用、数据库&中间件以及离线任务。其中业务应用包括有状态应用和无状态应用，无状态应用可以借助运维平台在业务团队和运维团队之间做比较清晰的职责划分，适合混部；而有状态应用较为复杂，混部时的运行质量难以保证。数据库和缓存目前并没有运行在混部集群中。离线任务中的非实时性任务，比如夜间转码、数据处理等只关注吞吐量而不关注时效的任务也是混部的对象。基于龙蜥与 Koordinator 的在离线混部的实践 123 爱奇艺在混部上经历了长时间的探索。2013 年，爱奇艺初次进行了计算存储混部。进入容器时代后，爱奇艺在 Mesos 上花费了大量精力，

120、最早把在线任务内容生产、Spark、Storm 等所有工作负载混部在一个集群里，没有进行任何特殊的隔离性处理。在 Docker 上经历了困境后，爱奇艺将业务按节点、集群进行了拆分；这又导致离线任务集群资源常年不够用，在线业务集群利用率非常低，尤其是夜间利用率甚至只有个位数。因此，爱奇艺考虑将夜间线任务的资源提供给离线任务。2016 年，通过 Mesos Oversubscription 功能引入根据真实资源做额外计数器的机制，将任务分为了延迟敏感和尽力而为两类进行混部。但由于细粒度的隔离性问题，这条道路也无疾而终。到了 K8s 阶段，由于在线业务的伸缩能力的增强和普及，第二套计数器不再是强需求

121、，爱奇艺直接在 K8s 上进行了混部，通过引入 Kata 保证服务质量。2022 年，龙蜥+Koordinator 一并被引入，用于构建下一步的混部架构。从多年的混部经验里，爱奇艺总结出了影响混部的关键因素：第一，服务质量，尤其是在线业务的质量，脱离了服务质量则混部无意义。第二，获取额外资源。第三，任务适配。基于龙蜥与 Koordinator 的在离线混部的实践 124 获取额外资源存在有两个思路：其一为使用一套计数器，按固定比例超卖资源，直接混用，或者按经验比例分配给各个类型的负载。其二为多套资源计数器，一种方式是利用经验数据判断集群的空闲时间和空闲资源，另一种方式是通过类似 Mesos O

122、versubscription 的方式做空闲资源的实时探测。服务质量的策略分为静态和动态。动态指在离线业务或具体的进程之间动态进行调整，静态则是一旦下发即固定，即便有影响也不变动。基于龙蜥与 Koordinator 的在离线混部的实践 125 2.龙蜥和 Koordinator 在离线业务混部探索 Koordinator 没有对分布架构做本质上的变动，而是在云原生的规范性方面，比如业务类型的抽象上做了更多工作，使 K8s 和 Koordinator 有了做通用分布式架构的可能性，而不像之前只能针对特定的业务定向做定制。Koordinator可以简单理解为给K8s增加插件或做了增强，首先会增加一

123、个调度器，引入一套资源技术，在节点上有一个 Koordlet，分别负责收集资源和保证任务的隔离性。基于龙蜥与 Koordinator 的在离线混部的实践 126 其工作机制为利用计数器在真实利用率基础上进行二次分配。整机的真实使用使用率取决于离线任务的使用率，保证在线业务的质量的前提下，水位线可以根据实践随时调整。Koordinator 在任务分配方面分为五种类型（图中只列举了常用的四种），通过不同层级的分类，对在线业务和离线业务进行了不同层级的保障。基于龙蜥与 Koordinator 的在离线混部的实践 127 为进一步保证服务质量，爱奇艺引入了龙蜥操作系统（Anolis OS）。Group

124、 Identity功能和 CPU Burst 功能对当前的混部效果起到了很大的提升作用。Anolis OS 通过配置不同的 Group Identity 启用两套进程调度，一套作为在线业务的调度器，另一套作为离线任务的调度器，在线业务优先级整体高于离线任务。此前，在公平调度的机制下，在线业务、离线业务之间在细粒度上存在互抢资源；而引入两套调度器后，这个问题可以被合理规避。CPU Burst 的作用是使公平调度进程之间的切换更平滑，避免出现毛刺。基于龙蜥与 Koordinator 的在离线混部的实践 128 第一个试点业务为某类型内容实时生产，已经全量运行在混部资源上。从某种意义上它是零成本的，

125、因为全部复用了其他服务器节省出来的资源。目前运行非常稳定，也没有对在线业务造成无法接受的干扰。每天对热点视频进行二次或更多次编码也是爱奇艺一项较重的非实时离线计算任务，目的在于通过再生产降低码率或提高质量。该任务目前正在灰度验证阶段，期待接入 Anolis OS 和 Koordinator 之后能带来足够大的惊喜。大数据离线计算方面，出于综合考虑，爱奇艺目前依然选择 Kata 作为运行时，因此也正在积极和龙蜥社区进行探索，尝试 Kata 和 Koordinator 的合作。上图为试点前后的效果对比，在验证环境设计比较保守的情况下，利用率整体提升50%以上。图中任务高峰期 CPU 使用率低于水位

126、线的主要原因是 BE 任务申请的资源量没有被充分利用导致，涉及到离线任务的运营。当然，如何通过技术手段将真实的资源进行三次、四次甚至无限次的分配，也是爱奇艺期望尽快解决的。3.未来工作展望 未来，爱奇艺将与社区携手同行。首先，争取将 CPU 利用率提升到 50%甚至更高。其次，因为涉及多租户，需要进行资源分配，尤其是离线任务资源总量不稳定，离线池内资源分配不合理和资源抢占问题时有发生，期望能够在未来规避此类问题。最后，爱奇艺将会在离线任务质量保障方面继续探索。基于龙蜥与 Koordinator 的在离线混部的实践 129 ContainerOS 在云原生中的应用 130 ContainerOS

127、 在云原生中的应用 作者：王磊，龙蜥社区云原生 SIG 成员、统信软件服务器与云计算产线研发主管 云计算的发展可以分为三个阶段。第一阶段：单机式的部署，以设备为中心。比如部署 Java 网站类的应用，通常只使用一台设备，在此台设备上安装 OS 系统，在 OS 系统上再部署 Java JDK、Tomcat等。第二阶段：随着设备和硬件的发展，由原先的以设备为中心发展为以资源为中心，云化概念出现。一般会先部署公有云或私有云，在私有云/公有云上部署虚机的资源，在此之上再部署传统业务比如 Java 类的应用。第三阶段：随着信息的发展，逐渐演变至以应用为中心。比如 Java 类的应用不会再使用传统的服务，

128、而是用容器化或 DevOps 工作流的方式实现应用。云原生成为了当前主要的发展趋势。ContainerOS 在云原生中的应用 131 云原生的发展趋势下，OS 会有哪些变化？首先，传统的 OS 可能在部署过程中安装了 sshd 或 Apache 软件组件包。在云原生场景下，所有应用均以容器为前提，比如 Python 的应用更多的是使用 Python 的容器镜像，对于底层的 sshd 或 Apache 包不再有需求，可以将其裁掉，系统也会变得更薄。其次，云原生环境下，在 K8s 集群下可能会有上千台或上百台 OS 节点。运维十分麻烦，升级等操作需要每台依次进行。另外，传统的 Linux 的环境一

129、切皆文件环境，可以任意更改关键路径或数据。而在云原生环境下，系统需要尽量固化，稳定性或安全性会变得更高。ContainerOS 在云原生中的应用 132 传统的 OS 软件以 RPM 形式进行交付，以 update 的方式进行升级。而 ContainerOS的应用是以容器化镜像的方式来使用。OS 的升级不再提供单独的一台 update 的方式升级，而是将 OS 集群变为一个整体。一次 cve 升级只需推送一次仓库，系统会自动根据仓库里的包进行统一升级。原有的 K8s 部署是通过 K8s 官方提供的部署脚本或部署工具实现，部署完 K8s 集群之后，再将 NGINX 或 Java 等应用部署于 K

130、8s 上。而现在，可以通过 Sealer 技术，将应用打包成一体部署，这意味着部署完 K8s 后，交付的并不是一个纯 K8s 的集群，而是 K8s+NGINX 应用。框架底层的 ContainerOS 是基于龙蜥或统信的 OS 进行轻量化裁剪，将系统固化，变成不可变的 OS。上层提供了容器 runtime 相关的组件包，再上层默认继承了 K8s集群组件。如果想要将传统的 OS 变成 ContainerOS，只需三个步骤：将现有 POD 进行迁移，将现有 OS 替换成 ContainerOS，将现有容器应用镜像的数据迁移到 ContainerOS上的数据上同，即可实现业务的平滑过渡。上图为迁移前

131、后的架构对比。迁移后即可通过 K8s 集群 push 原先的容器镜像，也可以用社区或统信提供的镜像提供服务。ContainerOS 在云原生中的应用 133 ContainerOS 在云原生下具有以下几大优势：第一，更高效的资源。通过裁剪没有必要的组件包，让资源更合理地释放。第二，更便捷的应用。应用不再以传统 RPM 包的形式提供，而是以容器镜像的方式交付，解决了依赖的问题。比如想用 Python2，又想用 Python3，传统的 OS 难以解决；而在 ContainerOS 下，只需要两个容器镜像，一个 Python2 和一个 Python3即可解决。第三，更便捷的运维服务。我们提倡零运维，

132、集群内所有的 OS 版本、软件包、组件、内核全部一致，没有额外的配置。每一次升级就都是一台新的系统，避免了雪花服务器或单独配置的产生，相当于新装了 OS，变得更简单。ContainerOS 在云原生中的应用 134 在云原生场景下，ContainerOS 有了更多的应用场景。可以做迁移替换，将原有的比如部署在传统 OS 或 K8s 集群的环境，直接迁移成 ContainerOS+K8s 场景。提供了私有化仓库的容器镜像，进行容器化镜像的制作时，可以进行 cve 的修复、安全检测，提升容器的安全性。云底座的改造。云原生场景下更多的是基于 K8s 进行开发，而在容器云的场景下，可以将 K8s 做成

133、容器云的组件，提供 API 接口，升级、系统 POD 的监控、K8s 的监控等都可以通过提供的 API 接口对接到容器云平台上，提供更整体化的交付。私有化定制。可以使用 ContainerOS 做自己的 PaaS 平台的定制。比如 OA 软件，可以直接通过容器云+OA 软件这样整体的 PaaS 平台对外提供。上图为云原生下操作系统的性能测试结果。并发、延迟等均有明显提升。主要得益于对于系统、内核的裁剪，释放了更多资源。ContainerOS 在云原生中的应用 135 云原生时代下的 ContainerOS 整体思想在于使运维变得更简单。以动物管理员为例，如果动物园中有不同类型的动物，饲养员需要

134、了解每一种动物的习性，管理难度较大；而如果动物园中如果只有一种动物，则管理员的工作会变得非常简单。操作系统也同理，如果将所有的 OS 底层统一化，变成一种动物，则运维、升级会变得更轻松。综上，ContainerOS 在云原生的场景重点着力于解放运维，让管理变得更轻松。如何在云原生时代下管理微服务应用 136 如何在云原生时代下管理微服务应用 作者：杨轲，Rainbond Maintainer 1.在 Kubernetes 中管理微服务应用 在 K8s 应用中，管理微服务应用首先面临的问题是多套环境搭建。环境搭建流程非常繁琐，尤其是对于处于快速迭代中的产品，至少需要开发环境、测试环境、生产环境三

135、套环境。实际的部署中，开发环境可以通过制定流水线实现代码的不同分支，构建出不同 tag的镜像，最后将其推送到镜像仓库中。但是真正部署在集群中时又会面临多个微服务之间依赖关系的定义，快速复制出一套测试环境需要大量人工操作或脚本类的编写。如何在云原生时代下管理微服务应用 137 另一方面，微服务模块很多，如何编排也是 K8s 中管理微服务的痛点之一。比如微服务模块之间的依赖关系可能会是业务 A 依赖中间件或依赖其他通用的业务模块。在集群中部署后，均以 workload 的形式存在，这会导致无法然一目了然地了解模块之间的依赖关系，也无法合理编排微服务组件。而且在 K8s 中部署微服务应用时往往会先部

136、署 deployment，再为其指定 service，两者之间通过 label 进行选择和绑定。如果部署的微服务过多，YAML 文件的定义会很复杂，后续在同一集群中部署多套也较为复杂。也许 helm 能解决一部分问题，但是 Chart 的编写也是一大门槛。如何在云原生时代下管理微服务应用 138 另外，K8s 集群中微服务组件之间的复用也是一个痛点，比如使用中间件或在项目中开发定制较为通用的模块。我们希望将模块进行沉淀，在新项目开发中能够复用这些模块。而实际情况往往是代码已经沉淀，但部署中要真正使用的用户模块依然需要调整许多配置，比如 YAML 之间的配置或服务之间的依赖关系，这也是影响组件复

137、用的难题。解决了以上问题后，我们如何将开发好的业务交付到客户环境中，也是一个亟待解决的痛点。如何在云原生时代下管理微服务应用 139 目前，K8s 中最常用的解决方案是通过 Helm 进行交付，需要运维人员编写 Helm chart、定义 values 文件以实现在客户环境的交付，对交付人员提出了较高要求。而且后期维护也比较复杂，因为 Helm 本身没有合理的状态回流机制，将资源部署到集群以后，仍然需要手动查看 POD 是否已正常启动。2.RainBond 中管理微服务 Rainbond 是开源的云原生应用管理平台，基于 K8s 构建，做了一层应用级的抽象，将复杂的 K8s workload

138、资源抽象成 Rainbond 的应用模型。在模型之上支撑了应用的全生命周期管理。Rainbond 的应用模版作为应用模型的载体，可以将应用的能力沉淀下来，形成组件库。最终实现拼积木式的编排体验。开发阶段，可以对接 git 仓库，将源码一键部署。完成部署后，在微服务架构这一方面，会有拓扑图的实时显示，可以一目了然的观测到应用下各个服务的状态和依赖关系。同时支持微服务框架的一键切换，以及依赖关系的编排。完成应用的编排后，进入交付阶段，通过应用模版将业务沉淀，发布到应用市场，最后实现基于应用模版的一键升级和交付。到了运维阶段，可以监控每一个服务的日志和状态，同时还可以利用插件扩展单个服务的能力。基于

139、以上流程我们就可以实现应用整体能力的复用和共享，包括组件的发布、安装、升级、交付全流程。如何在云原生时代下管理微服务应用 140 针对多套环境搭建问题，解决方案如下：将应用部署在平台以后，可以通过快速复制，一键复制出所有依赖关系、环境配置等。就像 Fork 一份代码一样简单。而且可以针对不同的镜像版本或代码分支修改组件的构建源，最终实现开发环境、测试环境到预发布环境到生产环境的一键复制和使用。针对微服务编排，解决方案如下：应用模型定义了所有组件之间的业务依赖关系。在依赖关系之上实现了应用与架构的解耦，微服务应用可以一键切换不同的治理类型，比如 Istio、K8s 原生 service 模式和内

140、置的 Service Mesh 框架。如何在云原生时代下管理微服务应用 141 针对用户的单个业务，利用了 K8s 中的 POD Sidecar 机制，提供了组件级的插件，包括日志管理、性能分析、监控等一系列工具。无需更改业务容器代码，即可提升业务的能力边界。上图为平台上部署好的完整的微服务应用。组件的运行状态和依赖关系一目了然，绿色代表组件运行正常，如果出现异常则会变成其他颜色。业务出现问题时，可以快速定位到问题所在。而在编排模式下，则可以通过直接连线的方式将组件和组件连接在一起，建立两者之间的依赖关系，使组件具有直接访问到其依赖组件的能力。如何在云原生时代下管理微服务应用 142 针对微服

141、务组件复用，解决方案如下：用户可以根据粒度大小定义需要复用的组件或模块，然后将拼装好的模块发布到应用市场作为应用模板，供其他用户一键部署和使用。应用开始运行以后，无需学习应用模版的制作，便可以通过页面一键发布到应用市场，实现了业务定义应用模版的效果。让业务运行起来的过程就是定义模版的过程。也省去了再次验证模版的繁琐。最终发布到应用市场中的模版作为载体，就能实现各类公有云、私有云场景下的交付。如何在云原生时代下管理微服务应用 143 上图就是微服务交付的完整流程，开始用户通过源码、镜像等拼装出整体应用，最后基于应用模型导出完整的应用模板，沉淀到应用市场，实现了像安装手机 App 一样的安装体验。

142、上图为发布到应用市场的模板。在离线场景下可以导出应用模版包，其包含了应用的元数据定义以及所有的镜像，用户在其他环境下一键导入，即可实现和原应用模版一致的安装体验。Serverless Computing 技术架构 144 Serverless Computing 技术架构 作者：陈全，上海交通大学教授 1.Serverless Computing 技术特点 Serverless Computing 是介于基础云计算平台和上层用户应用之间的新层次，通过函数计算提供通用计算能力。这种新型计算模式具有以下几个典型特点：无需进行底层运维管理，所有运维交由云提供商进行，上层业务人员仅需关注业务本身逻辑。

143、采用 Pay-as-you-go 计费模式，无需长时间租用服务器。按需资源扩展，需要多少资源则使用多少资源。事件驱动，可以提供更加灵活函数和容器调度。Serverless Computing 技术架构 145 想要实现以上目标，将会面临以下挑战：底层运维时，云提供商需要考虑如何能够实现多个租户不同函数之间高效隔离，保证其安全性。因为事件驱动内在调用方式，需要保在新型函数调用方式下实现快速响应。如何实现高效的任务调度，提高云计算平台资源利用率。针对以上挑战，我们需要解决以下几个问题：如何将底层各式各样的硬件进行高效抽象？基于抽象即可设计高效的隔离策略。如何权衡性能和资源问题，分配给函数多少资源能

144、够恰好满足性能需求？需要在整个云层面、集群层面进行高效的负载均衡，提高其资源利用率。2.Serverless Computing 的分层架构 在分层结构上，我们调研了大量学术界和工业界采用 Serverless Computing 的平台，发现他们大多将平台分为三个层面，从下至上分别为虚拟化层、封装层和系统层。系统层又可以进一步分为协调层和编排层。Serverless Computing 技术架构 146 上层系统层主要负责协调和调度工作。其中协调指提供很多后台软件支持，比如数据库支持、内存数据库支持。通过后台软件，函数计算才能正确地运行。调度功能主要解决单个函数的资源扩展问题，函数调用多次，

145、需要为其分配多少副本、多少容器才能满足性能需求，这是调度层需要解决的事情，另外，海量容器同时存在一个节点上，如何进行负载均衡也是调度层需要解决的问题。容器封装层将用户函数调用封装在低开销的容器中运行，要避免容器本身的启动开销导致函数响应时间过长，因此涉及到预热，需要预先为函数启动好容器。虚拟化层提供了更基础的支持，比如函数的具体实现、容器的具体实现以及资源隔离机制、计算资源、存储资源等，具体的隔离机制在虚拟化层实现。Serverless Computing 技术架构 147 虚拟化层有多种实现方式，可以基于容器实现资源的分配和隔离，也可以基于传统虚拟机实现资源分配和隔离。现有的虚拟化层隔离技术

146、基本可以分为四类，各具优缺点。第一类：基于虚拟机的虚拟化方法。它具有更高的安全性，因为虚拟机实现了资源的完全隔离。第二类：基于传统 runc 容器。runc 容器资源开销较小，运行快，但是隔离性和安全性较差。第三类：基于安全容器。安全容器将虚拟机技术和传统容器技术做了一定权衡，运行资源开销较小，同时隔离性和启动速度比虚拟机更好。现有的发展趋势大多为使用安全容器技术。第四类：基于 unikernel。兼容性较差，需要针对特定函数以及特定应用提前编译镜像，且一旦编译好之后则无法修改。Serverless Computing 技术架构 148 封装层需要解决容器冷启动的开销问题，我们不希望容器的启动

147、开销造成函数运行时间急速增长。最为广泛的解决方法为容器预热技术。容器预热技术分为两种。独立容器预热池：该方法会为每个函数构建独立的预热容器池。但缺点在于会占用过多系统资源，因为每个容器都有自己的池，池中都需要预热一批容器为函数服务。Serverless Computing 技术架构 149 模板容器池：该方案会为所有函数预热同一套模板容器，里面可以运行所有函数。当函数需要容器时，会从模板池中取出容器出，对其进行特异化。特异化是指为其安装函数本身需要的各种依赖、数据。其优点在于资源占用较少，但特异化本身也存在开销，甚至可能比冷启动容器的开销更大。系统层主要负责协调和编排工作。目前学术界对系统层进

148、行研究的关键问题包括：Serverless Computing 技术架构 150 复杂拓扑逻辑支持：单个函数功能非常有限，需要将多个函数将组合成有向无环 DAG 图以实现复杂功能。对应 Serverless Computing 平台需要提供 DAG 图引擎支持复杂拓扑逻辑。集群资源管理器：需要实时地监控集群中各个节点上的资源使用量，保证可用性和性能稳定。负载均衡器：需要考虑应用中各个服务之间的冲突情况、数据传输压力以及资源使用量进行全局负载均衡，设计高效的调度策略满足资源利用率提升的目标。3.Serverless Computing 的未来展望 未来，Serverless Computing

149、会向着通用化、高效化和智能化三个方向进行发展。通用化：除了计算，也可以设计 Serverless 存储系统，设计更高效的执行架构以用于各种应用场景，不再局限于普通的计算加速。高效化：能够做硬件异构硬件的统一抽象，使得 Serverless Computing 平台不仅支持 CPU 上的函数，也可以使用 GPU、神经网络加速器等各种异构硬件，做统的一抽象和管理。研究预热模板和应用画像的结合，尽量使用最少的资源满足每一个函数都可以获得热容器的目标。Serverless Computing 技术架构 151 智能化：指导容器规格“恰好合适”，需要知道为每个容器分配多少 CPU 资源和内存资源可以刚刚

150、好达到预期目标，保证资源不浪费的同时也保证了延迟。实现 Serverless 混部的 SLA 保障，成千上万个容器混合在一个物理节点上，互相之间会存在严重的资源竞争。如何在混合部署的情况下控制容器之间的冲突，也是未来需要探索的方向。机密容器崛起和发展 152 机密容器崛起和发展 作者：冯世舫，阿里云操作系统技术专家 朱江云，Intel 系统软件部高级研发经理 机密容器是 CNCF 的一个 Sandbox 项目，用于解决云原生场景下的数据安全问题，满足数据合规、数据隐私保护、算法和模型等创新 IP 保护，数据可用但是不可见等使用需求，以及解决云厂商的信任依赖问题。机密容器具备以下几个特性：安全性

151、。机密容器基于硬件可信执行环境来保护容器中数据安全，云厂商以及具备高权限的第三方均无法直接窃取和篡改容器中的数据。易用性。用户应用无需进行任何改造，即可从传统容器环境中迁移到机密容器环境中。能够解决租户和云厂商之间的信任依赖问题。租户数据对于云厂商而言不再透明。可自证性。用户可以通过远程证明等手段证实当前使用的容器环境是真实可信的。机密容器崛起和发展 153 机密容器的安全性很大程度上依赖于硬件的可信执行环境，基于硬件实现对于运行态数据机密性、完整性和安全性的保护。近年来很多硬件厂商也推出了自己的 TEE 技术解决方案，比如英特尔SGX 和 TDX等，这意味着我们可以基于多种硬件平台构建机密容

152、器技术。阿里云是机密容器（Confidential Containers）项目的核心参与者，在参与开源项目开发的同时，也一直在推动机密容器的商用解决方案，目前已经完成了两种机密容器的解决方案构建：一种为 POD 级机密容器，一种为进程级机密容器。POD 级机 机密容器崛起和发展 154 密容器指将容器 POD 中的内容放到 TEE 中进行保护；进程级机密容器指将运行有敏感业务的容器进程放到 TEE 中进行保护。在使用 CPU TEE 保护运行态数据安全的同时，我们也结合镜像安全、存储安全，远程认证、网络安全等一系列安全技术，为用户提供从应用部署到执行的全链路的安全保证。同时，我们将机密容器引入

153、到龙蜥社区，基于龙蜥开源生态构建开源的、开箱即用的解决方案。目前我们已经完成了 ANCK、KVM、Rund 安全容器等组件对于机密容器的适配工作。构建开源解决方案，是希望能够借助开源社区与合作伙伴达成更便捷深入的合作，为机密容器寻找更多落地场景。机密容器崛起和发展 155 英特尔和阿里云都充分意识到，除了关注基础软件之外，为了促进机密容器的技术发展和普及，应用和生态也是非常关键的一环。机密计算的核心价值和能力在于能够对于高价值业务或敏感数据提供保护，BigDL PPML 就是这样一个典型应用。BigDL 是英特尔开源的一款人工智能解决方案平台，能够方便数据科学家和数据工程师便捷地开发出一套端到

154、端的分布式人工智能的应用。另外，BigDL 特别针对机密计算推出了 PPML（隐私保护机器学习），能够对分布式人工智能应用实现端到端的全链路保护。PPML 架构如上图所示。最底层在 K8s 集群中提供的英特尔TDX 和英特尔SGX 可信执行环境。再通过一系列软硬件底层安全技术加持，使得用户能够在不暴露隐私数据的前提下，使用标准的人工智能和大数据处理软件比如 Apache Spark，Apache Flink，TensorFlow、PyTorch 等熟悉的工具开发自己的应用。在此之上，PPML 还提供了 Orca 和 DLlib 两个分布式流水线。Orca 是在 AI 框架 API之上，增强了分

155、布式大数据的处理能力，而 DLlib 则能够帮助程序员将分布式深度学习应用转化成 Spark 应用。另外，BigDL 还提供了可信大数据分析、可信机器学习、深度学习以及联邦学习应用。如上图所示，BigDL PPML 基于可信的 Kubernetes 集群环境，通过机密容器技术能够构建出基于 TDX 的分布式可执行环境，从而确保业务、数据和模型在使用和计算过程中的安全性，包括不可见以及不可更改性。机密容器崛起和发展 156 从数据流角度，所有数据均以加密方式存储在数据湖和数据仓库中。BigDL PPML 加载这些机密数据，通过远程证明以及密钥管理系统获取数据密钥，置于可信执行环境中进行解密，再使

156、用大数据和人工智能的计算框架，对数据进行分布式预处理，模型训练以及模型推理等。最后，再把最终结果，数据或者模型，以安全或加密方式写回到分布式存储中。另外数据在节点之间，容器之间的数据均以 TLS 方式进行传输，从而做到全链路的隐私保护和数据安全。使用 TDX 机密容器运行 BigDL PPML workload 只需简单两步：首先，构建 PPML 的镜像并对其进行加密，然后把加密后的镜像推送到镜像仓库之中。其次，在 Kubernetes 中部署 PPML workload，开发者只需在标准 YAML 文件中指定所需机密容器运行时以及配置好的高性能存储卷，然后使用标准Kubernetes 命令拉

157、起即可。如果更深入一点看，Kubernetes 将 workload 调度到具有运行机密容器能力的目标主机：首先，主机上的机密容器运行时启动 TDX TEE。其次，在 TDX 可信执行环境里，执行远程证明并获取验证/解密容器镜像所需的密钥，镜像服务下载容器镜像，使用密钥验证及解密容器镜像；在数据方面，用 机密容器崛起和发展 157 户使用标准的 K8S CSI driver 比如 open-local 为容器挂载高性能本地 LVM 卷，机密容器会自动进行透明的加密存储来保护用户输入输出数据。最后，启动 BigDL PPML workload 相关容器，一个 BigDL PPML Driver

158、和多个Worker 以分布式的方式运行于 K8S 集群之上，这样可以基于 TDX 进行的可信的云原生大数据分析和人工智能应用了。英特尔和阿里云一直保持着紧密合作。我们两家都是 CoCo 上游社区的发起人，共同定义、设计和实现了 CoCo 软件栈的诸多关键特性，比如 TEE 内镜像下载，镜像的验签和解密，可信临时存储和可度量运行时环境，所有这一切都确保了 CoCo 这个项目的强安全属性。另外，我们在龙蜥社区也有紧密的合作，包括共同实现了基于 TDX 的机密容器端到端的解决方案，包括远程证明以及参考应用。又比如我们选择了龙蜥社区的 open-local driver，第一个支持了可信存储，一个支持

159、了 kata 的 direct volume 新特性等等。最后，英特尔还正在紧密配合阿里云的小伙伴实现阿里云机密容器的产品开发。龙蜥云原生社区未来展望 158 龙蜥云原生社区未来展望 作者：黄韶宇，龙蜥社区云原生 SIG 成立 SIG 之初，我们一直在思考，龙蜥云原生 SIG 应该是什么样？首先，我们希望自己是龙蜥云原生相关技术圆桌会议的提供者。云原生的技术非常繁杂，技术领域多样，容器社区与云原生相关的 SIG 有容器镜像、容器优化 OS、Sealer、混部、机密容器等。我们希望为这么多 SIG 提供沟通的平台，同时孵化新的 SIG，做 SIG 的拉通。另外，从定位上来看，我们也希望自己是需求

160、、组件和发行榜的 owner。发掘云原生相关的需求，将需求带给不同的 SIG 做拉通，组件和发行版也需要有 owner 来构建。龙蜥云原生社区未来展望 159 面向开发者，我们希望能够为其提供云原生基础能力支持，同时引入有技术竞争力的组件。由社区参与者、共建者或用户参与开发组件，以被集成的方式融入到用户解决方案中，构建 SIG 技术的影响力。面向用户，我们希望能够为其提供易用、好用、接地气的开箱即用的发行版，并输出场景化的解决方案，通过整体方案的输出吸引用户使用龙蜥，扩大用户数量以及规模。2022 年 6 月 16 日，龙蜥云原生 SIG 正式成立，发展至今，经历了以下几个阶段：探索阶段：补齐

161、了龙蜥社区的云原生基础能力，包括基础的云原生相关软件，包，引入了很多优势组件。组织了多场龙蜥大讲堂，累计观众 600+。发展阶段：制定了龙蜥 SIG 的软件引入包机制、容器镜像的构建规范，让开发者可以更好地加入到 SIG 参与开发工作。其次，基于前期引入的优势组件输出解决方案，包括镜像加速加速方案、在离线混部方案，让用户能够更方便地使用能力。将龙蜥云原生 SIG 里的优势组件的能力进行组合，输出了新产品 ACNS 出，为用户提供开箱即用的产品，提供更方便的云原生体验。龙蜥云原生社区未来展望 160 龙蜥云原生套件 ACNS 包含以下几个核心组件：ACK-D：阿里云容器服务团队推出的 kuber

162、netes 二进制发行版。Kata：被广泛应用的安全容器事实标准。Nydus：镜像加速方案。Dragonfly：强大的集群 P2P 镜像分发系统。LifseaOS：轻量、安全、原子升级的容器优化 OS。Koordinator：混合部署调度器。通过以上组件的组合，我们期望提供并且也事实实现了高效便捷、安全稳定、强大丰富的云原生套件。高效方面，提供了一键部署，开箱即用的能力。满足不同部署形态的需要，可以在离线的环境下做部署，也可以在在线环境下部署。安全方面，我们提供了安全 runtime 的能力比如 Kata。另外，从生产安全的角度，Kubernetes 的发行版已经经过上千次的实际环境交付，拥有

163、庞大集群的最佳实践经验，保证了安全稳定的状态。与此同时，ACNS 默认集成了当前龙蜥云原生的优势组件，通过组件的组合实现1+12 的效果。龙蜥云原生社区未来展望 161 期望未来有更多的组件可以加入我们，作为龙蜥云原生 SIG 的产品对外推广。一方面，为优秀的产品提供产品出口，另一方面也可以为用户带更多优势。也希望有更多的用户与开发者加入龙蜥云原生的 SIG，共同构建繁荣社区。我们需要更多开发者，提供更多先进的、有竞争力的项目和组件。另外，通过开发者也可以为用户场景提供更优秀的解决方案，参与项目的开发，影响、响应社区用户的需求。开发者在社区的最大作用是为用户提供先进的云原生技术和场景解决方案，能够为用户带来收益，也能够壮大用户群体。我们也需要更多的用户，有了用户才有足够丰富的应用场景信息，才能引导社区开发者提供有效的需求，引导开发者做有价值的开发。且更多用户使用社区技术以及产品，可以帮助开发者打磨技术。对于社区而言，用户是为开发者提供云原生技术和产品推广的平台。技术、解决方案和用户场景是相互耦合的三个系统。而有了开发者和用户，可以让齿轮转得更快，可以让 SIG 更好地运行，也可以让龙蜥在开源过程中发挥更大的作用。