目录
一.应用迁移背景
1.国产化历程
1.信创：信息技术应用创新产业。
2.863计划：1986年3月启动实施的“高技术研究发展计划（863计划）” ，旨在提高我国自主创新能力，坚持战略性、前沿性和前瞻性，以前沿技术研究发展为重点，统筹部署高技术的集成应用和产业化示范，充分发挥高技术引领未来发展的先导作用。
3.核高基：是对核心电子器件、高端通用芯片及基础软件产品的简称，是2006年国务院发布的《国家中长期科学和技术发展规划纲要(2006-2020年)》中与载人航天、探月工程并列的16个重大科技专项之一。
4.AK：面向党政的具备安全可靠特性的国产化替代项目，信息技术应用创新的前身。
2.信创发展--内驱力
中国在信息技术底层标准、架构、生态掌控力等方面非常薄弱，已成为其信息产业发展的重要制约和阻碍；是中国在进军社会主义现代化强国征程中的绊脚石。
3.信创发展--国家意志
1.有关信创产业，近期国家又出台了新的政策。2022年9月底下发的79号文，全面指导国资信创产业发展和进度，要求所有央企+地方国企落实信创全替代。
2.未来的信创为持久化、常态化产业，在国家意志的大背景下各大国产化厂商持续发力，人才缺口呈井喷式增长。
4.信创发展--市场规模
从信创产业整体市场来看，相关数据显示，2021年信创产业整体市场规模6886.3亿元，近五年复合增速达到35.7%，预计2025年市场规模将达到23354.6亿元。
5.信创发展--行业
国家此前制定的“2+8+N”的信创三步走战略。
1.“2”就是首先实现机关范围内的国产替代，同时顺带打磨产品、培育骨干企业。
2.“8”指的是金融、电信、电力、石油、交通、航空航天、教育、医疗8大关键行业。在产品相对好用、生态比较成熟后，信创将由党政系统扩大到8大关键行业。
3. “N”就是其他行业，最终将信创产品扩展到全行业。
6.信创产业离我们很近：信创会逐渐影响到每一个人。
二.应用系统适配与迁移概览
1.信创图谱
2.国产化CPU与架构
3.国产化CPU与架构
4.国产操作系统
5.国产化历程
6.国产化数据库
7.国产化数据库
8.国产化中间件
9.国产化中间件
三.从源码到执行
1.应用系统适配与迁移概述
应用系统适配迁移是一个系统工程，包含了从底层芯片-整机-云-操作系统-数据库-中间件-应用的整体，每个组件之间都要相互适配，然后再以系统的角度进行组装适配，最终实现应用系统整体的适配与迁移。
为了更好的理解应用迁移与适配，我们有必要先了解从源码到执行的整体过程。
2.在不同CPU架构下编译源码
- 编写一份测试代码：
#vim hello.c
#文件内容如下
#include <stdio.h>
int main() {
printf("hello world");
return 0;
}- 编译成汇编进行比较：
#gcc hello.c -S -c -o hello.s 注：分别在x86架构cpu的主机，arm架构cpu的主机上执行操作。
- 左面的是x86架构，右面的是arm架构。
小结：查看编译产生的汇编文件。对比左右两张图片，不难看出，同一样一份源码，生成的汇编文件是不一样的，汇编指令的区别非常明显。
Arm 汇编指令不一样，比如调用 printf 使用bl，x86下使用是 call。
- 把源码编译成可执行文件
#gcc hello.c -o hello 注：把源码hello.c直接编译成可执行文件hello。虽然是一条指令，但背后其实包含了刚才的把源码编译成汇编，再链接相关函数库，最后再输出可执行文件多个过程。
- 通过objdump查看二进制文件
#objdump -d hello注：编译生成的可执行文件是二进制的，不能直接查看，必须通过objdump 指令来查看。
对可执行文件进行分析，通过objdump。
以下图中，分成四列：
第一列为内存地址；
第二列为十六进制，表示真正装入机器中的代码数据；cpu执行的机器码
第三列+第四列是对应的汇编代码； 比如 push %rbp压到寄存器中（不用讲）
首先对比第二列，上图的为 x86_64 体系的机器码，下图为arm 体系的机器码，可以很明显的观察到 x86 CPU 是变长指令集，而arm CPU为定长指令集。
再对比对三列，很明显同样的源码对应的汇编指令也是不同的。
****同样一份源代码，就因为cpu的不同，编译所生成的执行文件也是不一样的****
3.不同指令集之间差异
这里我们进行一个小结：
机器码
机器码顾名思义是单片工作且能识别和运行的一类代码，常见的格式有二进制格式、十进制格式等。简单来说就是便于机器识别的高低电平组合，每个单片机里都有状态分析电路能分析每个机器码的含义从而驱动单片机运行。机器码的优点是一般存储较小，便于单片机识别，缺点也很明显就是人无法读懂和直接进行功能修改。
汇编代码
汇编代码的概念就是面向机器的程序设计语言，在汇编语言中用助记符号代替操作码，用标号或者地址符代替地址码，用符号代替机器码，把机器语言转换成可简单读懂的汇编语言，也称做符号语言。这里所说的可读懂只是对于熟悉编程的专业人员可以部分，如果需要进行比较复杂的逆向工程功能分析修改、注册码寻找、漏洞分析等，通常难以完成的，所以在逆向工程领域又要引出另外一种代码-源代码的概念。
源代码
源代码也称源程序，这是一种人类可读可修改的计算机语言，源代码即我们技术人员平时的开发代码，通常以C语言、JAVA语言、PYTHON语言等工具实现，其中C语言是大家使用最广泛也是最为熟悉的工具。拥有源代码的好处不言而喻，既可以立即读懂（专业人员）也可以实现任意功能修改，在逆向工程领域，掌握源代码即掌握程序的所有权。
计算机底层的运行逻辑是电流的“脉冲”，因为电路的结构只有开关两种状态，所以电脑能识别的信号只有两种对立的状态，可以是二进制中的0,1或布尔逻辑中的Ture,False或电压的高,低电平。
我们在使用高级语言如python，Java时输入的英文电脑看不懂，它们需要翻译成电脑看得懂的语言即由二进制组成的机器码“01001010001”，我们在编程时不可能面对一大串数字（特别是对于密集恐惧症患者来说想想都头皮发麻），因此为了偷懒人类发明了汇编语言以简化写代码的难度，但这还不够，于是就有了现在的c语言，python，Java等更简便的高级语言。而高级语言翻译成机器码这个过程要走三道工序。
1 高级语言借助编译器转化为汇编语言。
2 汇编语言借助汇编器转化为机器码。
3 cpu依据指令集和机器码执行操作。
这样cpu就可以读懂并执行我们写的代码了。
（打个比喻：汇编语言与机器码的关系就像摩斯电码，元素周期表H—氢，He—氦中的对应关系，计算机依据机器码和指令集进行运算）。
4.国产芯片架构
5.六大主流芯片厂商的优势
国产六大主流芯片厂商的技术路线各有优势，生态建设各有特色。
龙芯源于中科院计算所，已有超过 20 多年的芯片技术积累。2001 年，在中科院计算所知识创新工程的支持下，龙芯课题组正式成立。2010 年，龙芯中科技术有限公司正式成立。龙芯起步最早，适配厂商多，自主化程度高。龙芯坚持“市场带技术”的道路，而不是“市场换技术”的道路，坚持自主研发和市场化的机制。龙芯已获MIPS指令集修改权限，自主化程度大，2021年4月发布的自研LoongArch指令，不包含国外授权，已实现完全的自主产权。
鲲鹏源于华为1991年成立的ASIC（Application Specific Integrated Circuit）专用集成电路,是针对特定用户要求和特定电子系统设计、制造的专有应用程序芯片 设计中心，在成立两年后就研发出第一块数字专用集成电路。2004年在ASIC基础上，华为海思诞生，十几年间一直更新迭代。鲲鹏基于ARM V8架构永久授权，处理器核、微架构和芯片均由华为自主研发设计，实现了计算芯片的全面自研，并且鲲鹏计算产业兼容全球ARM生态。华为还在ARM架构之上研发了AI（Artificial Intelligence）硬件处理单元——达芬奇架构，为通用处理器添加了AI加速器功能。为推进生态建设，华为还提供鲲鹏开发套件，包括分析扫描、代码迁移、加速库、编译器和性能优化等一系列软件工具。
飞腾由国防科技大学研究团队创造，起步于1999年，采用ARM授权以及自研方式，已获得ARM V8架构层级永久授权，自主化程度大，产品线丰富。
兆芯源于2013成立的上海兆芯，已获X86和ARM授权，其中X86可基于指令集授权自主设计芯片（2018/4 之前已授权和后续自研的指令集），其优势是自主化程度较高，生态为 X86 生态体系，易迁移，但扩充指令集难度较大，难兼容新的X86 指令集。无法使用英特尔新的 X86 专利及相关软件，未来的 X86 产品升级将因此遇阻；此外，因为在引进的 X86 源代码和微结构基础上改进优化，可能存在后门无法完全发现的风险。
海光源于天津海光，2016年AMD将Zen1架构（X86）授权给海光，海光在Zen1架构上设计，拥有长期自主研发能力，其生态较为完善。但AMD 不再向其授权最新架构，实现自主迭代还要看公司的再创新能力。
申威源于上海高性能集成电路中心，成立于2016年，技术源于DEC（Digital Equipment Corporation，美国数字设备公司）的Alpha 21164，Alpha架构（属于RISC）先被康柏收购，后被惠普收购。目前Alpha已经被束之高阁，指令集和微结构都已经不再更新，技术专利已经过期。申威是目前Alpha阵营中仅存的硕果，采用基于Alpha架构的SW64 自研指令集，自主化程度最高，基本实现了自主可靠，成功应用在国产超级计算机中，相对其他架构生态体系需加强培育。
四.编译型语言应用移植
1.编译型语言开发应用移植方案
作为编译型语言，必须经过编译编程可执行的机器码才能最终执行。
如果一款应用，之前由编译型语言c或者c++编写。现在要把它移植到xc环境，可以遵从上图所示的策略路径。
1 首先在信创环境中进行二进制文件依赖检查。 细节为第一步检查安装所需的依赖库是否存在并且存在，以保证应用能够正常安装， 第二步检查运行时所需的静态链接库、so库也就是动态链接库是否存在并且好用，以保证该应用能够正常运行。
2 再检查是否需要 修改C/C++源码，常见的检查点有源码中是否包含了汇编代码，如果包含了汇编代码，由于CPU技术路线的问题汇编代码都需要重新编写。 源码中是否使用了特殊的宏定义、built-in函数、attribute这些都需要针对xc环境进行修改才能保证编译通过。源码在编译执行时，是否需要添加特定的参数比如gcc 编译时加入 –f signed-char。如果整个工程的编译是通过makefile，cmakelists控制的，还要检查相关的构建文件。到此如果你做的不错就能保证编译通过了。
3 编译成功，不代表移植成功。还需要进行功能性测试、兼容性测试，以保证该应用在信创环境中能用。
4 测试验证通过后只能保证该应用在信创环境中能用，但是否好用呢？还要进行性能测试。比如一个oa系统的请假功能，在xc环境中经过以上步骤可以请假了，但是一旦10个人同时使用此功能，系统就会响应慢，甚至崩溃。这当然也是不行的，我们必须通过软件性能分析、性能调优以保证该应用不但能用，还要好用。
5 最后如果通过了所有的测试，就可以把源码重新打包发布了。
2.编译型语言应用移植案例
- 准备文件demo.c 文件内容如下：
#include <stdio.h>
int main() {
char num = -1;
printf("num = %d\n", num);
return 0;
}
- 我们观察到在x86环境编译执行后，结果为 -1
- 同样的代码我们拿到鲲鹏920芯片的麒麟系统中执行，结果为255
- 原因分析：
-1的二进制原码是10000001，它的补码是除了符号外取反加 1，最后补码就是11111111。在x86架构下，char默认是有符号的，所以打印的时候正常打印-1，
但是在鲲鹏架构下char默认是无符 号的，这个二进制的11111111正好就是无符号的255。
所以，出现这种情况的原因就是x86架构和鲲鹏架构对于char的 默认处理不一样，一个是默认有符号，另一个是默认无符号。 - 修改编译参数：
- 对于这种情况，有两种处理方式：
（1）一种就是在编译时指定参数，把默认无符号型 改成默认为有符号型。编译-fsigned-char
（2）一种是修改源代码，把数据类 型指定为有符号型；
- 修改源代码：
#include <stdio.h>
int main() {
signed char num = -1;
printf("num = %d\n", num);
return 0;
}需要注意的是，刚才的方法，通过修改编译选项会把源代码中所有的char类型变量都当作 有符号类型，如果只是更改其中部分char变量，这种方式就不合适了。
此时可以通过修改源代码的方式，直接编译即可。这种方式需要对源码有足够的理解。两种方式可以依据应用场景，区分使用。
3.技术要点
- 源代码修改 对于源代码修改的场景，主要分为以下几种:
- 对内嵌的汇编指令的修改
- char数据类型的修改，把char数据类型更改为signed char。
- 双精度浮点型转整型溢出处理的修改
- 编译选项修改
- char数据类型默认无符号
- 指定编译64位应用
- 目标指令集
- 编译宏
五.应用移植Makefile
1.Makefile概述
2.Makefile实操
- hellomake.c内容如下
#include "hellomake.h"
int main() {
myPrintHelloMake();
return 0;
}- hellofunc.c 内容如下
#include <stdio.h>
void myPrintHelloMake() {
printf("Hello makefiles!\n");
return;
}- hellomake.h 内容如下
void myPrintHelloMake();- 编译并执行
[root@jd1 make_demo]# gcc -o hellomake hellomake.c hellofunc.c -I .
[root@jd1 make_demo]# ./hellomake
Hello makefiles!- 如果相关的文件较多，这样去执行gcc编译就太麻烦了。
- 我们可以通过编写makefile 来简化这个过程：
- #vim Makefile
target ... : prerequisites
... commandhellomake: hellomake.c hellofunc.c
gcc -o hellomake hellomake.c hellofunc.c -I.
clean:
rm hellomaketarget
可以是一个object file（目标文件），也可以是一个执行文件，还可以是一个标签（label）。
如果大家对什么是label不清楚也没关系，先跳过。
prerequisites
生成该target所依赖的文件
command
该target要执行的命令（任意的shell命令）
这是一个文件的依赖关系，也就是说，target这一个或多个的目标文件依赖于prerequisites中的文件，其生成规则定义在command中。说白一点就是说:
prerequisites中如果有一个以上的文件比target文件要新的话，command所定义的命令就会被执行。
这就是makefile的规则，也就是makefile中最核心的内容。
hellomake: hellomake.c hellofunc.c ##hellomake 就是gcc –o要生成的目标文件
: hellomake.c hellofunc.c 生成目标文件所需的依赖
gcc -o hellomake hellomake.c hellofunc.c -I. ##具体执行的指令
clean: ##就是执行make clean ，就是执行下面的指令
清除编译产生物 rm hellomake
- 执行make 生成hellomake
之前我们通过gcc -o hellomake hellomake.c hellofunc.c -I . 才能编译生成hellomake
现在只需要把编译规则定义好在Makefile中，直接一条make命令就搞定了。
- 执行make clean 观察效果
3.Makefile 与 应用迁移适配
六.解释型语言应用移植
1.Java语言简介
Java是一种技术
说起Java，人们首先想到的是Java编程语言，然而事实上，Java是一种技术，它由四方面组成：Java编程语言、Java类文件格式、Java虚拟机和Java应用程序接口(Java API)。它们的关系如上图所示。
运行期环境代表着Java平台，开发人员编写Java代码(.java文件)，然后将之编译成字节码(.class文件)，JVM才能识别并运行它，JVM针对每个操作系统开发其对应的解释器，所以只要其操作系统有对应版本的JVM，那么这份Java编译后的代码就能够运行起来，这就是Java能一次编译，到处运行的原因。
JVM运行字节码：字节码被装入内存，一旦字节码进入虚拟机，它就会被解释器解释执行，或者是被即时代码发生器有选择的转换成机器码执行。
利用Java API编写的应用程序(application) 可以在任何Java平台上运行而无需考虑底层平台, 就是因为有Java虚拟机(JVM)屏蔽了与具体操作系统平台相关的信息，实现了程序与操作系统的分离，从而实现了Java 的平台无关性，使Java程序只需生成在Java虚拟机上运行的目标代码（字节码）,就可以在多种平台上不加修改地运行。JVM在执行字节码时，实际上最终还是把字节码解释成具体平台上的机器指令执行。
对于以Java语言为代表的解释型语言来说，应用迁移相对简单一 些，因为Java的虚拟机JVM屏蔽了不同处理器之间指令集架构的区别，所以，纯Java语言编写的程序不需要重新编译。
2.查询本地Java环境
3.安装Java相关的开发环境
4.验证Java，Javac版本
5.编写Java测试代码
6.编译并执行
7.在目标环境中查看Java环境
8.移植Java代码
9.移植Java代码
10.基于解释型语言开发应用移植方案
七.rpm打包
1.rpm包概述
RPM有五种基本的操作功能：安装、卸载、升级、查询和验证。
linux软件包分为两大类：
- （1）二进制类包，包括rpm安装包（一般分为i386和x86等几种）
- （2）源码类包，源码包和开发包应该归位此类（.src.rpm）。
spec file是制作rpm包最核心的部分，rpm包的制作就是根据spec file来实现的。
2.rpm包实操
- RPMbuild环境准备
- #yum install rpm-build rpmdevtools rpmlint -y
- 步骤1 执行rpmdev-setuptree ，创建rpmbuild目录 :
#rpmdev-setuptree
- 步骤2 创建Demo软件包
#mkdir rpmbuild-1.0
#vim rpmbuild-1.0/rpmbuild_hello.sh
#cat rpmbuild-1.0/rpmbuild_hello.sh
#!/usr/bin/env bash echo "Hello rpmbuild"
#chmod +x rpmbuild-1.0/rpmbuild_hello.sh
- 步骤3 打包
#tar czvf rpmbuild/SOURCES/rpmbuild-1.0.tar.gz .
- 步骤4 创建与编辑SPECFILE
rpmdev-newspec rpmbuild/SPECS/rpmbuild.spec
- 执行编辑指令
#vim rpmbuild/SPECS/rpmbuild.spec
- 步骤5 生成rpm包
#rpmbuild -bb rpmbuild/SPECS/rpmbuild.spec
#ls rpmbuild/RPMS/aarch64/
rpmbuild/RPMS/aarch64/rpmbuild-1.0-1.ky10.aarch64.rpm
注：rpmbuild -bb rpmbuild/SPECS/rpmbuild.spec
该指令会按照之前编写好的spec文件生成rpm软件包
该rpm包生成在rpmbuild/RPMS/aarch64/目录下，这里的aarch64会根据你的芯片技术架构自动产生。
- 步骤6 安装rpm包并测试
RPM 是 Linux 下常用的软件包类型。RPM 包移植时本质上是移植一些二进制文件，将 x86 依赖的文件替换为信创平台的。
移植时首先寻找有没有对应信创平台的 RPM 包，从以下渠道尝试获取：
- 操作系统的本地源；
- 操作系统的远端源；
国内厂商社区（比如华为，阿里）所有途径都失败，则下载源码重新编译。RPM 包重构时
首先找出 x86 依赖项，依赖项有对应的文件能直接替换的就直接替换，否则就用源码编译。之后替换打包再做验证。
八.总结
（1）信创迁移的重要性：
- 业务停机时间短 ：数据迁移开始至完成针对原业务系统不停机或停机时间较短
- 迁移平滑过渡 ：数据迁移以及应用改造阶段对于前端用户使用体验影响小
- 迁移全程数据保障 ：迁移全过程存在安全保障，保障迁移数据不丢失，业务数据可回退
- 应用改造阶段“双轨”机制 ：数据迁移在应用改造阶段提供数据的“双轨”，保障业务正常使用，以及提供数据进行应用调试
（2）机遇与挑战：
新机遇：
信创产业人才数量严重不足， 爆发式行业落地项目与信创从业人员比例偏失。
新挑战：
（1）关键技术仍未完全突破，尤其是上游核心技术，仍有部分被国外企业垄断，需要进一步加强技术攻关和资源扶持。
（2）从全球范围来看，信创产业的绝对用户数量仍然难以与国外巨头抗衡。需要加强产品研发和营销推广，在国际上赢得用户和市场的认可。
（3）信创产业格局较为分散，真正具有很强实力的国内龙头企业不多，产业链条较为零散，面对国际巨头，尚无法发挥合力优势。
5512
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
