从新处理器到新操作系统，新生态构建过程与壁垒。

国产 5G、云计算、大数据、人工智能、区块链技术迅速腾飞，与此同时，它们也将作为新的基础设施支撑中国数字经济发展新的动能。新基建时代到来的时刻，我国计算生态却并不十分乐观，传统的计算基础设施所需的成本投入却居高不下，芯片产品的竞争力也还不能完全适配市场需求，国际巨头常年盘踞让随其伴生的软硬件生态同样难以撼动，中国科技的繁荣景象之下其实暗藏杀机。

在尖端技术赶超而底层支撑不足的情况下，要打破现有生态路径和生态体系，为国产技术持续高速发展护航，我们就要重塑属于自己的强算力生态，要打造能够支持国产化的操作系统、虚拟化软件，要能能造出中国桩，制出中国芯，建设出完善的新型算力基础设施。

这件事情，华为一直在做。多年来华为致力突破传统的老的计算框架和计算平台，打造一个全新的全栈计算框架，在对计算生态而言最为关键的软件上，华为也在不断通过操作系统开源、数据库开源、数据虚拟化引擎的开源，来支撑软件伙伴打造商业化的解决方案。

硬件开放、软件开源、使能伙伴是华为构建鲲鹏生态始终坚持的信条。从开放鲲鹏处理器到开源 openEuler 操作系统，华为坚持从“芯”到“魂”全面出击。在 DevRun 开发者沙龙——鲲鹏开发者嘉年华上，华为现场为开发者分享了“鲲鹏迁移”和“openEuler”的相关技术原理、实践经验和对应方法论，蓄力新生态下算力提升。

鲲鹏软件迁移

为什么要进行软件迁移

计算机是由软件和硬件组成的，要执行软件层的应用程序，就需要底层 CPU 支持由汇编器形成二进制的机器码（由指令和数据组成）去运行。因此就需要底层计算平台能够支持该 CPU 的指令，对于不同的处理器而言，它们能够支撑的指令也大不相同，这也是在 x86 和鲲鹏编译的区别之处。

通过上图左侧中的代码示例，我们可以看到，在 x86 和鯤鹏上编译之后的指令有三点差异，首先是汇编不同，x86 上使用了两条 mov 指令，鯤鹏上则是通过两条 ldr 指令、一条 add 指令以及一条 str 指令完成了整个过程；其次是指令长度不同，x86 上 mov 指令是 24 位的，ldr 指令是 16 位的，在鯤鹏上则都是 32 位；第三则是寄存器不同，x86 和鲲鹏处理器使用的向量寄存器不同，其向量指令级也存在差异。

正是因为在 x86 上面和鲲鹏上面使用的指令存在的这些差异，使得在 x86 上面运行的程序、二进制、动态库这时候需要在鲲鹏上面重新编译去运行，也就是需要软件迁移的原因。

软件迁移五步骤

通过大量项目和经验总结，要实现软件迁移需要以下五个步骤：

1. 迁移准备 -- 收集软件栈信息，准备迁移环境

在这个阶段，主要收集硬件和软件信息。硬件方面的信息主要是收集芯片和服务器的型号，从而方便提供配置性能差不多的鲲鹏服务器；其次是收集软件栈信息，主要分为操作系统、虚拟机、中间件、编译器、上层依赖的开源软件、商业软件、业务软件等信息。

2. 迁移分析 -- 分析软件栈，指定迁移策略

迁移分析要做的，就是对收集到的信息和软件栈做初步分析，判断是否真正需要迁移，评估迁移的工作量。

对开源软件来说，直接下载在 ARM 上已经被编译好的包，或者自行下载原码进行编译就可以了。自研软件的迁移则需要注意语言类型的差异，编译型语言需要重新编译之后才能运行在新环境上，不过对于解释型的语言来说只要更换所依赖的虚拟机就可以。对于商用软件，可以通过联系厂商获取它对应 ARM 架构下的软件版本，如果没有的话就需要寻找有类似功能的软件做替换。此外像运行环境、虚拟机、编译器和操作系统这些也是要进行替换，可以直接去华为云鯤鹏论坛内有软件仓库下载由鲲鹏官方所做的经过验证的版本。

3. 编译迁移 -- 软件编译打包，验证基本功能

在这一阶段，涉及到代码迁移和软件包迁移两种场景。对代码的迁移，不同语言要做不同的修改，像 C/C++ 这种编译性语言需要重新进行编译，因为涉及到指令级，跟指令级相关性比较大，所以在编译脚本、代码都需要做出修改，但是对纯解释性语言开发的应用来说，它们的程序代码是不需要修改的。

对于软件包迁移来说，首先需要扫描该软件包是否存在依赖库或者依赖的可执行程序，这些库和可执行程序如果是用 C 语言写的是需要重新编译的，编译之后重新把软件包打包即可。

4. 性能调优 -- 利用五步法优化软件性能

在迁移完成之后需要对性能进行调优，有【建立基准 - 压力测试 - 确定瓶颈 - 实施优化 - 确认效果】五个步骤。

建立调优基准，该基准根据当前的硬件配置、组网、测试模型来做综合评估，以建立合理的条有目标；其次在调优目标建立后，通过压测工具对软件或系统进行加压，在加压过程中暴露性能瓶颈，确定瓶颈之后对瓶颈进行优化；第四，注意在优化过程中要及时记录，因为优化并不一定是正向的，出现负向优化时需要及时回退；最后在优化措施实施完成后，需要重新启动压力测试工具以确认优化效果。

5. 测试与认证 -- 保证商用上线，共建鲲鹏生态

在性能调优环节结束后，需要做一些压力测试、长稳测试，使软件能够达到商用的目标，最后实现规模上线。此外也可以拿软件和系统到鲲鹏上做鯤鹏展翅认证，其可以扩展应用的软件使用空间并能够加入鲲鹏生态。

代码迁移

C/C++ 代码迁移

C、C++、GO 都是非常典型的编译型语言，编译型语言所开发的程序从 x86 平台移植到鯤鹏平台时一般都需要重新编译才能运行。编译构建脚本类文件在迁移过程中，一般会涉及到编译选项的移植，源码类文件会涉及到编译宏，另外可能还会有编译器自带的 Builtin 函数的移植、SSE intrinsic 函数移植等。

在 C/C++ 代码编译构建过程有六大步骤，首先是获取源码，可以通过 GitHub 等开源社区来获取；其次需要选择所需的编译环境，就是安装编译器 gcc 等；之后根据源码的编译脚本生成 Makefile 文件，再用 Makefile 编译生成可持续文件。如果这部分代码之中有依赖 x86 平台的 SO 库，那么这部分的依赖库是需要重新编译替换的。在编译完成之后进行安装部署，之后进入到实际的系统之中进行测试。

Java/Python 代码迁移

对于 Java、Python 这样解释性语言写的程序，它们涉及到的迁移与编译型语言大有不同。

从上图中可以看到 Java 的技术架构和源码运行过程。对 Java 而言，在实现迁移的过程中，涉及修改的部分首先就是 JDK，因为 JDK 有一些 C 的代码，而且在 JDK 层屏蔽了很多跟指令级相关的内容，所以需要对 JDK 层进行替换；第二个修改点就是 SO 库，SO 库可能是由解释性语言编译的，它们跟指令集的关系十分密切，需要重新编译才能运行；除此之外，还需注意在程序运行中的错误，这类问题或许并非迁移造成，但因为关乎运行性能也需多加注意。

Python 的运行过程和 Java 类似，在编译修改上也是类似的，也是需要从编译环境和 SO 库两大方面入手修改。环境上推荐使用 A32，Python3 你也可以通过样本安装，也可以通过源码安装；SO 库有多种类型，但对于各种方式的 SO 库，最后都是对应为一个 SO，定义为 SO 库，需要的步骤也都是一致的，即装配环境、重新编译、重新替换。

Maven 仓软件构建

对熟悉 Java 的开发者而言 Maven 已经不陌生了，我们需要用 Maven 去管理 Java 项目。Java 程序依赖着它的 jar 包，而把 jar 包重新下载编译是十分耗时的，Maven 的作用就是把所有的开源软件编辑成一个 jar 包放在 Maven 仓库上面，需要时直接在 Maven 上调用，，这也叫作.jar 的依赖管理。

jar 依赖的分类有分本地仓库、远程仓库和中央仓库。在构建 jar 包的过程中，首先需要查询本地仓库，本地仓库如果找不到就去远程仓找，第三步需要编译实现，并且验证该版本在鲲鹏上是否可用，如果不可用，则需要重新编译这个包，然后替换到本地的仓库，再重新构建，编译出可使用的版本。

但这个过程还是很繁琐的，使用鲲鹏 Maven 仓则能大大简化这一过程。鲲鹏 Maven 仓实质就是一个远程仓，里有各种各样适用于鲲鹏平台的 jar 包，开发效率得到显著提升。也就是说，基于上面的构建过程，在本地仓没有找到合适的 jar 包时，就到鲲鹏的远程仓找，下载出来就是在鲲鹏平台可以使用的 jar 包，无需重复校验、编译，就可以得到一个鲲鹏上可以用的版本包。

软件包迁移

rpm 就是把应用程序进行打包，在应用程序里面不可避免存在一些二进制或者 SO 库，它们和 C、指令集都密切相关，因此软件包部分也做一些程序编译和替换，实现重新打包可以分为四个步骤。

首先下载 x86 软件包，利用 Dependency Advisor 工具进行扫描。然后再鲲鹏上重新编译 x86 依赖文件，为了减少劳动，在这一步骤，首先优先从鲲鹏 Maven 仓上查找文件，如果鲲鹏 Maven 仓中未找到，则在鲲鹏上重新编译依赖文件。第三步时在鲲鹏上小红心生成 rpm 包，首先得到 rpm 包对应的 spec 文件，然后解压 x86 rpm, 再把包替换成 x86 依赖文件，最后打包生成新的 rpm 包。最后一个步骤是验证，需要重新扫描，确认是否还有 x86 依赖文件，如果存在，则继续编译打包，直到没有 x86 依赖文件存在。

openEuler

在计算多样性的时代，鲲鹏有机组合为业界提供了最强算力的服务器处理器和 AI 处理器，以满足全栈全场景的不同需求，但从计算产业生态的层面来讲，稳定和强大的操作系统是一切的前提。去年年底，华为操作系统 openEuler 正式开源，我们的计算世界因此真正地变得既有相似，更有不同起来。

A-Tune

一个系统想要达到性能最优，从底层的芯片到深层的应用涉及到各个方面都需要做调节，特别是像 openEuler 这样基于宏内核的操作系统，在软件设计的时候更要考虑各方面的场景，保证在大部分的场景下都是通用且有益的。而随着数字化技术的不断升级，新应用、新计算、新架构的出现，调优对象、业务场景数量随之暴增，业务复杂度也直线上升，传统系统调优越来越难以满足当前需求。A-Tune 的出现，就是为了降低调优门槛，提升调优效率。

A-Tune 的目标

A-Tune 自优化的终极目标，是要通过自身充分发挥鲲鹏的硬件和 openEuler 基础软件性能，释放鲲鹏芯片的算力，降低优化成本。在实现上，A-Tune 就是要通过感知上层的业务场景，自动完成调优配置。针对不同的场景，A-Tune 需要找到不同的需求，根据相应需求实现自动调优。

A-Tune 的技术实现

A-Tune 自动调优具备两大关键能力。第一是在运行时自调优，这一能力使用了系统画像技术，基于离线训练好的业务模型，对数据进行采集，再通过聚类、分类相结合的方法，精准识别上层业务，匹配最佳资源模型；第二是面向专业工程师的离线自调优，这需要工程师给一个参数集，并且给业务评价指标，通过反馈式的不断地迭代，再传递到贝叶斯优化算法，最终反馈给工程师最优的参数。

在运行时自调优过程中，用户下发命令后，A-Tune 的服务端将采集数据进行负载识别，对上层业务或应用的类型进行识别感知，并在为其匹配合适的资源模型，然后将配置进行下发。这一过程非常迅速，在一分钟之内就可以完成，大大减轻了人工调优的负担。

对于离线自调优，当客户端发送请求信息到服务端之后，服务端将构建一个由形象性能的参数组成的参数集，再把这一参数集传给贝叶斯优化算法，贝叶斯优化算法会返回新的参数，通过不断地循环迭代，得到最优的参数，随后服务端就会把最优的参数返回给用户。

iSulad

从 2019 年开始，容器迎来了浪潮，大多数的企业开始全面拥抱容器化，容器的规模、密度更加扩大，它的问题和麻烦也随之出现，重新打造一个容器引擎成为一种必然的选择。面对新的挑战，鲲鹏也造出来一个新轮子 --iSulad。

为什么要造新轮子？