无限动力营销型网站建设,安米网在线app制作,包装设计公司浙江,广州seo营销培训核心系统国产平台迁移验证 摘要#xff1a;信息技术应用创新#xff0c;旨在实现信息技术领域的自主可控#xff0c;保障国家信息安全。金融领域又是关系国家经济命脉的行业#xff0c;而对核心交易系统的信息技术应用创新是交易所未来将要面临的重大挑战。为了推进国产化进…核心系统国产平台迁移验证 摘要信息技术应用创新旨在实现信息技术领域的自主可控保障国家信息安全。金融领域又是关系国家经济命脉的行业而对核心交易系统的信息技术应用创新是交易所未来将要面临的重大挑战。为了推进国产化进程选取核心交易系统的典型模块实践了基于鲲鹏平台的迁移验证在各技术栈迁移流程方法、性能调优、典型问题等方面做了大量的探索与尝试。 一、背景
信息技术应用创新旨在实现信息技术领域的自主可控保障国家信息安全。目前信创产业蓬勃发展未来将会形成一条庞大的产业链主要包括基础设施CPU、服务器、存储、交换机等基础软件操作系统、数据库、中间件等以及应用软件和信息安全产品等。
金融领域又是关系国家经济命脉的行业加速推进核心交易系统的信息技术应用创新势在必行。通过选取核心交易系统部分典型模块作为信创试点基于鲲鹏平台进行迁移验证在各技术栈迁移流程方法、性能调优、典型问题等方面做了大量的探索与尝试为实现核心交易系统的全面信创改造筑牢技术基础。 二、引言
此次迁移过程是将核心交易系统中某一系列典型的业务功能模块M模块C模块、S模块进行剥离使其能够独立运行在信创平台上并可以与核心交易系统进行实时通信以实现完整的业务处理流程形成独立运行的业务系统简称典型业务信创系统。选取场景从技术栈的角度尽量覆盖核心交易系统中的大部分应用场景开发语言以C为主同时涵盖了JAVAGOLANG汇编C内嵌等。中间件采用KafkaZookeeper以及相关开源第三方项目Protobuflibrdkafkaotlv4等。
验证环境基础设施基础软件包括TaiShan 200服务器搭载鲲鹏920处理器麒麟操作系统Kylin-v10达梦数据库DM8。后文将详细介绍各技术栈迁移流程、方法、典型问题以及注意事项等。 三、典型业务信创系统技术架构 ::: hljs-center
图1 系统架构图
:::
典型业务信创系统以Kafka集群作为消息中间件交易系统数据通过网关Gate与典型业务信创系统交互M模块处理业务逻辑C模块负责数据格式转换S模块业务数据同步至达梦数据库J工具为Java数据抽取工具抽取达梦数据库中作为系统启动的初始化数据。
四、系统迁移
一环境准备
基础设施TaiShan 200服务器搭载鲲鹏920处理器。鲲鹏处理器基于ARM架构有别于Intel、AMD CPU采用CISC复杂指令集Complex Instruction Set Computers复杂指令集计算机ARM CPU 采用RISC精简指令集Reduced Instruction Set Computers精简指令集计算机。
x86ARM指令集CISCRISC供应商主要有intel和AMDintel处于垄断地位开放的授权策略众多供应商产业链成熟快速发展中
鲲鹏处理器架构ARM特点
优点
1. 低功耗、集成度高更多的硬件CPU核具备更好的并发性能
2. 支持64位指令集能很好的兼容从IOT、终端到云端的各类应用场景
3. 大量使用寄存器大多数数据操作都在寄存器中完成指令执行速度更快
4. 采用RISC指令集指令长度固定寻址方式灵活简单执行效率高
缺点
1. 刚刚起步其生态处于快速发展阶段
2. CPU主频相对较低对于某些应用场景限制了性能 基础软件麒麟操作系统Kylin v10达梦数据库DM8
鲲鹏工具链鲲鹏代码迁移工具、鲲鹏性能分析工具
其他依赖列表
名称版本otlv4v4tinyxml/tinyxml2v1/v2zookeeperv3.7.0kafkav2.7.1openjdkv1.8Bisheng jdkv1.8gcc/gv7.3.0v9.3.1(kunpeng定制)make/cmakeV3.12.1librdkafkav1.7.0golangv1.16.5shellv5.0.17二编译迁移
典型业务信创系统包括编译类代码C/C/Go和解释类代码Java。
1. C/C代码迁移
麒麟Kylin v10默认GCC编译器版本为v7.3.0同时华为鲲鹏还提供了两款定制的C/C编译器分别是gcc-9.3.1-2021.03-aarch64-linuxKunpeng gcc 1.3.2.b023和基于llvm的毕昇编译器bisheng-compiler-1.3.1-aarch64-linux本次迁移分别采用了v7.3.0和v9.3.1Kunpeng 1.3.2两个版本的GCC编译器进行编译。
1编译
由于CPU架构的差异编译时需要调整和增加以下编译选项。
x86ARM说明-m64-mabilp64-m64是x86 64位应用编译选项m64选项设置int为32bits及long、指针为64 bits为AMD的x86 64架构生成代码。在ARM64平台无法支持。-fsigned-charchar变量在不同CPU架构下默认符号不一致在x86架构下为signed char在ARM64平台为unsigned char移植时需要指定char变量为signed char。-marcharmv8-a在编译时增加编译选项指定处理器架构为Armv8使编译器按照鲲鹏处理器的微架构和指令集生成可执行程序提升性能。-mtunetsv110如果使用了gcc 9.1以上的版本在编译时增加编译选项指定使用tsv110流水线 使编译器按照鲲鹏处理器的流水线编排指令执行顺序充分利用流水线的指令级并行提升性能。
2内存屏障
现代CPU被设计成在从内存中获取数据的同时可以执行其他指令和内存引用这就导致了指令和内存引用的乱序执行。为了解决这一内存乱序问题引入了各种同步原语这些原语通过使用内存屏障来实现多处理器之间内存访问的顺序一致性。然而内存模型在不同架构下存在着差异x86下为强内存序而ARM则为弱内存序。下表列出x86与鲲鹏架构之间的内存序差异
内存乱序行为x86arm读-读乱序不允许允许读-写乱序不允许允许写-读乱序允许允许写-写乱序不允许允许原子操作-读写乱序不允许允许
x86和ARM的汇编指令是不同的因此原有代码中使用的嵌入式汇编需要修改cpu内存屏障指令移植方案如下
x86arm说明__asm__ __volatile__(“sfence” : : : “memory”);__asm__ __volatile__(“dmb ishst” : : : “memory”);前后的写入(store/release)指令__asm__ __volatile__(“lfence” : : : “memory”);__asm__ __volatile__(“dmb ishld” : : : “memory”);前后的读取(load/acquire)指令__asm__ __volatile__(“mfence” : : : “memory”);__asm__ __volatile__(“dmb ish” : : : “memory”);之前的写入(store/release)指令
在程序编译的时候特别是加入了优化选项-O2或-O3之后编译器可能会将代码打乱顺序执行即编译生成后的汇编代码的执行顺序可能与原始的高级语言代码中的执行顺序不一致。所以编译器提供了编译阶段的内存屏障用于指导编译器及时刷新寄存器的值到内存中保证该编译器屏障前后的内存访问指令在编译后是定序排布的。常见的编译型屏障定义如下所示
#define barrier() __asm__ __volatile__(“”: : :“memory”)
x86属于强内存序架构大部分情况使用编译型屏障或者volatile访问c 标准不建议用于跨线程变量就可以保证多线程内存访问的一致性。但是在arm架构下就无法保证这一点。需要修改为对应的cpu内存屏障必要的时候增加cpu内存屏障。为了支持跨平台要么使用预编译条件要么引入C 11的内存屏障原语。引入C 11内存屏障原语提高了可移植性增加了可读性选为最终方案。
相比ARMv7ARMv8增加了load-acquireLDLARBLDLARH和LDLAR和store-releaseSTLLRBSTLLRH和STLLR指令这可以直接支持c原子库中的相关语义。这些指令可以理解成半屏障。这些半屏障指令的执行效率要比全屏障更高所以在能够使用这种类型的屏障时我们尽可能使用acquire和release语义来做线程间的同步。Read-Acquire用于修饰内存读取指令一条 read-acquire的读指令会禁止它后面的内存操作指令被提前执行即后续内存操作指令重排时无法向上越过屏障。Write-Release用于修饰内存写指令一条Write-Release的写指令会禁止它上面的内存操作指令被乱序到写指令完成后才执行即写指令之前的内存操作指令重排时不会向下越过屏障。
通过统一使用标准库的atomic_thread_fence以及acquire-release语义简化了跨平台代码的实现。编译器会在arm平台替换为合适的指令而在x86下则精简为普通变量访问。x86下测试表明使用标准库的实现相比汇编实现性能降低幅度在5%以内在arm上也有较好的性能表现。
2. Go代码迁移
Go与C类似同为编译型语言需要在不同CPU架构上安装对应的编译器。使用Go编译器版本为go1.16.5 linux/arm64。项目中未使用嵌入式汇编因此在编译器成功安装后Go工程目录下执行go install即可编译通过。
3. JAVA代码迁移
JAVA应用是运行在JVMjava虚拟机上的解释性语言迁移过程如下
1安装鲲鹏或ARM版本jdk可以使用OpenJDK也可以使用鲲鹏提供的毕昇JDK这里我们对两个版本的JDK分别做了尝试。
2配置JDK环境
3替换依赖jar包匹配鲲鹏或ARM架构手动或maven
4重新打包Java应用
4. Shell代码迁移
Bash从4.2版本升级到5.0版本修复了很多BUG但也存在一些旧语法在新版本上无法运行需要进行适当的调整例如
二维数组ids${temp[2][]}这种语法在4.2上是可以运行的但在5.0需要分开写成
temp_ids${temp[2]}
ids${temp_ids[]}
5. 鲲鹏代码迁移工具
鲲鹏代码迁移工具提供如下功能
1软件迁移评估自动扫描并分析软件包非源码包、已安装的软件提供可迁移性评估报告。
2源码迁移当用户有软件要迁移到基于鲲鹏916/920的服务器上时可先用该工具分析源码并得到迁移修改建议。
3软件包重构帮助用户重构适用于鲲鹏平台的软件安装包。
4专项软件迁移使用华为提供的软件迁移模板修改、编译并产生指定软件版本的安装包该软件包适用于鲲鹏平台。
5增强功能支持x86平台GCC 4.8.5~GCC 9.3版本32位应用向64位应用的64位运行模式检查结构体字节对齐检查和鲲鹏平台上的弱内存序检查。
通过手动迁移结合鲲鹏代码迁移工具根据不同工程的特点可以大大提高迁移效率。
本文重点讨论迁移流程不对工具使用细节过多描述。
三数据库迁移
1. 迁移目标
数据库是典型业务信创系统中重要的组成部分迁移目标是将Oracle数据库中的数据对象表、视图、存储过程等全部迁移至达梦数据库DM8中且保证功能完整。数据库迁移主要包括两个部分一是数据库server端主要是数据对象的迁移和业务逻辑的验证。二是client端包括各类API接口如OCI/OCCIJDBC等的迁移。
2. API及应用迁移
信创系统与数据库相关的应用包括S模块和J模块两个模块分别使用C和JAVA开发。
1OCI应用迁移
DM8提供了多种C/C接口包括DCI/OCIDPIODBC。原项目S模块采用OCI接口与Oracle数据库进行通信。因此建议过程中选取了DCI接口与DM8进行通信。DM DCI 是参照 OCI 的接口标准结合自身的特点为开发人员提供向 Oracle 兼容功能的一款接口产品。
修改CMakeLists.txt或Makefile将链接路径、头文件路径、动态库指向DCI驱动路径$DMDBMS/drivers/dci和动态库文件libdmdpi.so。修改完成后重新编译注意运行时需要确认LD_LIBRARY_PATH是否已包含dpi动态库路径。DM8对Oracle有较好的兼容性且应用针对持久化层有封装因此迁移OCI接口过程相对简单。
2JDBC应用迁移
典型业务信创系统的J模块使用JDBC与Oralce链接JDBC已经对数据库接口进行了抽象DM8提供了JDBC驱动$DMDBMS/drivers/jdbc/DmJdbcDriver18.jar18表示对应的jdk版本如18对应jdk 1.8迁移只需将驱动进行替换后重新打包应用即可。另外可以使用针对鲲鹏定制的毕昇jdkJDK8BiSheng JDK 1.8.0_292-b13。
3. 数据对象迁移
达梦数据库提供“DM数据迁移工具”DTS对常规对象进行迁移常规对象指的是序列、表和视图但存在一些兼容性的问题。整体上大部分常规迁移操作可以通过迁移工具完成部分不兼容功能需要调整代码或规避。 四功能验证
经过代码迁移需对典型业务信创系统进行功能验证验证方式为回归生产系统单元测试用例和集成测试用例。性能结果作为性能调优的基准数据功能验证结果如下
软件类型Kunpeng-920鲲鹏处理器Kylin-v10银河麒麟DM8达梦数据库M模块自研通过通过-C模块自研通过通过S模块自研通过通过通过Kafka开源通过通过otlv4开源通过通过通过tinyxml/tinyxml2开源通过通过Gate自研通过通过zookeeper开源通过通过openjdk工具通过通过gcc/g工具通过通过make/cmake工具通过通过librdkafka开源通过通过golang通过通过通过J模块通过SQL自研
五性能优化
1. 应用性能优化
鲲鹏提供一系列硬件加速手段如加解密、解压缩等。本小节只讨论软加速手段且不包括对业务代码本身的优化只基于CPU架构和操作系统层面的优化以确保与x86基准版本性能对比的准确性。
1NUMA-Aware亲和度优化
鲲鹏920共有有4个NUMA节点 CPU 节点每个 CPU 节点由多个鲲鹏920有32/24/16个 CPU组成并且具有独立的本地内存、 I/O 槽口等相同 node 之间 CPU 和内存之间的访问称为本地访问不同 node 之间的访问称为远程访问。很显然访问本地内存的速度将远远高于访问远地内存的速度。可以使用numactl -H查看node、cpu、内存之间的关系以及node之间的距离。之后可以通过numactl -C绑定NUMA节点减少CPU跨域访问内存提高3级缓存使用率提高进程运行性能。通过绑定NUMA节点应用性能可提升10%值得一提的是绑定节点后性能波动得到很好的改善。
2编译优化
a.-marcharmv8-a在编译时增加编译选项指定处理器架构为Armv8使编译器按照鲲鹏处理器的微架构和指令集生成可执行程序提升性能。
b.-mtunetsv110如果使用了gcc 9.1以上的版本在编译时增加编译选项指定使用tsv110流水线使编译器按照鲲鹏处理器的流水线编排指令执行顺序充分利用流水线的指令级并行提升性能。
3内存分配优化
鲲鹏GCC编译器基于开源GCC-9.3版本开发并进行了优化和改进实现软硬件深度协同优化挖掘OpenMP、SVE向量化、数学库等领域极致性能是一种Linux下针对鲲鹏920处理器的高性能编译器。
使用v9.3.1(Kunpeng定制)Kunpeng GCC 1.3.2编译器可是用其自带的jemalloc库jemalloc是一个通用的malloc实现着重于减少内存碎片和提高并发性能以动态库的方式放置于鲲鹏GCC编译器内。
编译器内置两种版本的jemalloc库命名相同放置于不同目录适用于不同类型的场景。
a.开源版jemalloc适用于通用场景位于编译器gcc-9.3.1-2021.03-aarch64-linux/lib64目录下通过如下选项使能选项-ljemalloc。
b.优化版jemalloc针对HPC高性能计算领域位于编译器gcc-9.3.1-2021.03-aarch64-linux/lib64/libhpc目录下通过如下操作使能
export LD_LIBRARY_PATH/opt/aarch64/compiler/gcc-9.3.1-2021.03-aarch64-linux/lib64/libhpc:$LD_LIBRARY_PATH 2. 数据库性能优化
1参数调优
根据当前软硬件平台包括CPU架构数量内存大小操作系统等需要调整默认参数以达到数据库最有性能。
DM8参数可以通过动态调整也可以修改数据库实例目录下的dm.ini文件启动时需要在指定对应的配置文件如./dmserver/your/dm/path/dm.ini。
参数优化参见附录A达梦配置参数优化列表。 2客户端
客户端主要是针对达梦提供的API接口调用进行调优本次主要针对批量处理和批量提交进行优化。批量处理需满足一下几个条件a.ATCH_PARAM_OPT配置为1b.表上有主键实测只有唯一索引不能触发批量操作c.SQL的条件where需要落在主键上当前版本必须满足以上三个条件。在触发批量的前提下每1000~2000条进行一次提交可以达到应用最大性能。
通过上述优化S数据同步写模块单进程单Session每秒可同步数据3.5w条。
五、总结
本文通过对核心交易系统部分典型业务模块信息技术应用创新平台的迁移实践尽可能涵盖了包括C/C、Java、Golang、数据库中间件等核心技术栈。对基础设施鲲鹏平台基础软件Kylin-v10操作系统、DM8数据库以及主流开源软件KafkaZookeeper和自研应用部分核心应用做了全面的验证。对指令集架构和数据库兼容性对交易系统的影响有了跟进一步的了解为核心系统的全面迁移和新系统的研发储备重要技术基础。
信息技术应用创新平台处于蓬勃发展的阶段生态也在不断的完善中。期货行业作为关系国家经济命脉的行业是推进信息技术应用创新发展的主要力量也为信创产业提供了更多的应用场景是信创产业的土壤和温床。通过本次实践希望能对金融行业和信创生态提供更多的借鉴与思考。
六、附录
一达梦配置参数优化列表
参数名默认值优化值参数说明COMPATIBLE_MODE02是否兼容其他数据库模式。0不兼容1兼容 SQL92 标准2部分兼容 ORACLE3部分兼容 MS SQL SERVER 4部分兼容 MYSQL5兼容 DM66部分兼容 TERADATADATETIME_FMT_MODE01是否兼容 ORACLE 日期格式。0不兼容1兼容CASE_COMPATIBLE_MODE01涉及不同数据类型的 CASE 运算是否需要兼容 ORACLE 的处理策略。0不兼容1兼容本模式下当函数 DECODE()中的多个 CASE 类型不一致时 DECODE 会从其中选择一个类型进行匹配2兼容本模式下当函数 DECODE()中的多个 CASE 类型不一致时DECODE 根据第一个CASE 的类型来决定匹配类型MEMORY_POOL20020000共享内存池大小以M为单位。共享内存池是由DM 管理 的内存 。有 效值范 围 32位平台为64~200064位平台为64~67108864MEMORY_MAGIC_CHECK20是否开启对所有内存池的校验。0不开启1开启校验校验码基于分配出的块地址计算在被分配空间的头部和尾部写入校验码2增强校验在 1 的基础上如果是内存池分配的则对尾部未使用空间也计算校验码写入未使用空间的头部BUFFER100180000系统缓冲区大小以 M 为单位。推荐值系统缓冲区大小为可用物理内存的 60%80%。有效值范围8~1048576BUFFER_POOLS19100BUFFER 系统分区数每个 BUFFER 分区的大小为 BUFFER/BUFFER_POOLS。有效值范围1~512RECYCLE6419000RECYCLE 缓冲区大小以 M 为单位。有效值范围8~1048576RECYCLE_POOLS1941RECYCLE 缓冲区分区数每个 RECYCLE 分区的大小为 RECYCLE/RECYCLE_POOLS。有效值范围1~512SORT_BUF_SIZE250原排序机制下排序缓存区最大值以 M 为单位。有效值范围1~2048SORT_BUF_GLOBAL_SIZE10009000新排序机制下排序全局内存使用上限以 M为单位。有效值范围10~4294967294SORT_FLAG01排序机制0原排序机制1新排序机制HJ_BUF_GLOBAL_SIZE50073000HASH 连接操作符的数据总缓存大小HJ_BUF_SIZE系统级参数以 M 为单位。有效值范围(10~500000)HJ_BUF_SIZE50512单个 HASH 连接操作符的数据总缓存大小以 M为单位必须小于 HJ_BUF_GLOBAL_SIZE。有效值范围2~100000HAGR_BUF_GLOBAL_SIZE50019000HAGR、DIST、集合操作、SPL2、NTTS2 以及HTAB 操作符的数据总缓存大小HAGR_BUF_SIZE系统级参数以 M 为单位。有效值范围(10~1000000)HAGR_BUF_SIZE50512单个 HAGR、DIST、集合操作、SPL2、NTTS2以及HTAB 操作符的数据总缓存大小以M 为单位。有效值范围2~500000。如果 HAGR_BUF_SIZE设置的值满足范围且大于 HAGR_BUF_GLOBAL_SIZE那么会在HAGR_BUF_GLOBAL_SIZE/2 和 500000 两个值中选出较小的那个作为新的HAGR_BUF_SIZE值。DICT_BUF_SIZE550字典缓冲区大小以 M 为单位有效值范围1~2048。单位MBVM_POOL_SIZE648000系统执行时虚拟机内存池大小在执行过程中用到的内存大部分是从这里申请的它的空间是从操作系统中直接申请的有效值范围32~1024*1024SESS_POOL_SIZE648000会话缓冲区大小以 KB 为单位有效值范围16~1024*1024。若所申请的内存超过实际能申请的大小则系统将按 16KB 大小重新申请WORKER_THREADS464工作线程的数目有效值范围1~64TASK_THREADS464任务线程个数有效值范围1~1000BATCH_PARAM_OPT01是否启用批量参数优化0不启用1启用默认不启用。当置为 1 时不返回操作影响的行数VIEW_PULLUP_FLAG01是否对视图进行上拉优化把视图转换为其原始定义消除视图。可取值 0、1、2、4。0不进行视图上拉优化1对不包含别名和同名列的视图进行上拉优化2对包含别名和同名列的视图也进行上拉优化4强制允许带变量的查询语句进行视图上拉优化有可能造成结果集错误8 表示不对 LEFT JOIN 的右孩子RIGHT JOIN 的左孩子\FULL JOIN 左右孩子进行上拉支持使用上述有效值的组合值如 3 表示同时进行 1 和 2 的优化ADAPTIVE_NPLN_FLAG30是否启用自适应计划机制仅OPTIMIZER_MODE1 时生效。0不启用1对索引连接、嵌套含 VAR 连接等复杂连接启用自适应计划2ORDER BY 在 HASH 连接时启用自适应计划 3同时启用 1 和 2 的优化机制IO_THR_GROUPS28非 WINDOWS 下有效表示 IO 线程组个数。有效值范围1~512MAX_SESSIONS1001500系统允许同时连接的最大数同时还受到LICENSE 的限制取二者中较小的值有效值范围1~65000MAX_SESSION_STATEMENT10020000单个会话上允许同时打开的语句句柄最大数有效值范围64~20480TEMP_SIZE101024默认创建的临时表空间大小以 M 为单位。有效值范围10~1048576CACHE_POOL_SIZE202048SQL 缓冲池大小以 M 为单位。有效值范围32 位平台下为1~204864 位平台下为1~67108864。单位MBRLOG_BUF_SIZE51210240单个日志缓冲区大小以日志页个数为单位取值只能为 2 的次幂值最小值为 1最大值为 20480RLOG_POOL_SIZE1281024最大日志缓冲区大小以 M 为单位。有效值范围1~1024RLOG_PARALLEL_ENABLE01是否启动并行日志1启用0不启用PARALLEL_PURGE_FLAG01是否启用并行事务清理0不启用1启用MSG_COMPRESS_TYPE20与客户端的通信消息是否压缩0不压缩1压缩2系统自动决定每条消息是否压缩
