前段时间对外做了一个直播，主题是信创本土化。因为是公开直播，没有保密相关问题，当时PPT文案在这里公开，供大家参考。由于初审以涉嫌广告为由拒绝，我在这里将公司名称统一替换为XXX，在这里，我只是分享，没有任何广告目的。
1. 信创国产化背景&XXX产品定位过程
在进入本次分享的主题之前，首先要简单了解信创本土化的背景，以及XXX产品定位的过程。
1.1 信创国产化背景及要求
2020年初，随着我国伟大祖国的日益强大，以及计算机软硬件领域能力和实力的提高，国家提出了信息创新的口号，即信息创新或信息创新的定位。计划在3年内完成芯片、操作系统和数据库的国内替代，即2022年底。 
PPT从图中可以看出，我个人绘制的国产化全景图：
- 在国内芯片方面，将涉及：兆芯、龙芯、飞腾、坤鹏等，后续介绍将主要包括CPU型号详情。
- 在国内操作系统中，经常会遇到:中标麒麟、银河麒麟、统信软件。早年中标麒麟和银河麒麟独立运营，然后强强合并为麒麟软件。目前麒麟软件占据了国内操作系统的大部分市场份额。 近年来，统信软件在国内操作系统上发挥了迅速的作用，并逐渐形成了后起之势。
- 在国内数据库方面，主要有四个老牌：金仓、达梦、南通和神通。 需要补充的是，神通主要涉军，并通过了中国人民解放军军事信息安全产品的B级认证。在非军事相关项目的交付中，一般只会遇到前三个项目的可能性。
除了芯片、操作系统、数据库三个方面，在本地交付中经常遇到：本地中间件和国密算法支持等要求，从图中可以看出： 本地化中间件主要包括：东方通、中创、金蝶等，在实际交付中也可能遇到普元、宝兰德、华宇等国内中间件。 对于国密算法，首先可以简单了解到国密算法包括:国密算法1、国密算法2、国密算法3、国密算法4、国密算法7、国密算法4、国密算法1、国密算法4、国密算法4、国密算法1、国密算法4、国密算法4、国密算法4、国密算法4、国密算法4、国密算法4、国密算法4、国密算法4、国密算法4、国密算法4、国密算法4、国密算法4、国密算法4、国密算法4、国密算法4、国密算法4、国密算法4、国密算法4、国密算法4、国密算法4、国密算法4、国密算法4、国密算法4、国密算法4、国密算法1、国密算法4、国密算法4、国密算法4、国密算法4、国密算法4、国密算法4、国密算法4、国密算法4、国密算法4、国密算法4、国密算法4、国密算法4、国密码算法4、国密码算法4、国密算法4、国密码算法4、国密码算法4、国密算法4、国密码算法4、国密码算法4、国密码算法4、国密码算法4、国密码算法4、国密码算法4、国密码算法4、国密码算法4、国密码算法4、国密码算法4、国密码算法4、国密码算法4、国密码算法4、国密码算法4、国密码算法4、国密码算法4、国密码算法4、国密码算法4、国密码算法4、国密码算法4、国密码算法4、国密码算法4、国密码算法4、国密码算法4、国密码算法4、国密码算法4、国密码算法4、国密码算法4、国密码算法4、国密码算法5、国密码算法密码算法、国密码算法5、国密码算法、国密码算法、国密码算法、国密码算法、国密码算 不同国密算法会对应不同的密保强度，其国1可以认为与常用的AES对称加密算法处于同一水平。
在过去的2020年和2021年，全面支持国产化也可以说是政企行业的核心竞争力之一，但随着2022年的临近，新创国产化必将成为政企行业的必要门槛之一。
1.2 XXX产品定位过程
接下来，让我们向您介绍一下 XXX产品定位的过程和一些成果。 2020年是信创产业推广的第一年，XXX当年上半年完成了第一套，坤鹏920 达梦V8 统信V国产化适应，并取得相关认证。
从2020年下半年到2022年，XXX可持续发展和完善信创国产化，获得信创国产化相关认证10多套，覆盖组合类型200种 。由于篇幅有限，主要国产芯片、操作系统、数据库、中间件的认证证书只贴在这里。
2022年，XXX与过去取得的成就不满意，积极与国密厂商合作，继续投资国密支持。目前，国密支持的传输和储存已初具成效。
目前XXX产品本地化适配已经比较全面，适配范围足以涵盖实际交付中能遇到的绝大多数情况。XXX信创项目的实施经验也非常丰富，目前XXX可以说，信创相关领域的行业标准已经牵头制定。XXX在信创国产化方面成绩斐然，基本领先与同行厂商。
2.服务端国产化适配
接下来，我们将正式进入今天的话题。首先，我们将讨论我们在服务方面的弯路及其应对策略。
2.1 国内数据库命名建议
首先，我们来谈谈国内数据库的适应。2020年上半年，我是XXX国产化适应负责人带领团队完成XXX产品国产化适配项目一期工程，获得XXX项目初期，国产化认证证书是第一个国产化认证证书DB适配是工时投入比较大的一部分。一般来说， 支持SQL数据库由：存储服务（service）和存储引擎（engine）连接器负责两部分的组成client的连接及鉴权，分析器负责SQL执行器负责与存储引擎的交互SQL句子的执行。国内关系数据库分析器的水平SQL规范，但存储引擎不同。因此，尽管支持国内主要关系数据库SQL，但这并不意味着，MySQL上执行没有问题SQL在国内数据库中执行语句肯定没有问题。也不意味着，金仓上能跑通的SQL也可以在南通数据库下运行。尽量保证一个SQL在各关系数据库中执行语句没有问题，XXX建议:库/表/字段命名全部大写，避免单词命名。在极端情况下，个人认为可以列为开发规范，明确禁止。
- 全大写的优点是可以避免因数据库大小写敏感设置而找不到库/表或字段。需要注意的是，在实际交付中，国内DB它通常不由自己的人员安装，通常由国内数据库制造商提供。假如自己的适配工作不能有一定的包容性，那么在实际交付中，往往需要投入更多的人工成本。每个人都可能有一种感觉，制造商之间的合作和沟通往往更令人头痛和无助。
- 库/表/字段之所以不以单个单词命名，是因为前面提到的，虽然每个家庭都是基于的SQL，但是存储引擎不同，导致关键词不同。根据我们在国内的情况DB适应的经验，如果不以单词命名，关键词冲突的问题基本不会发生。
2.2 使用jdk-8u192做为Java运行环境
接下来，我们来谈谈服务端国产化适应的第二个问题。XXX典型的网络拓扑结构扑结构。说到网络拓扑，网络连接肯定会涉及到DMZ区、内网区、存储区等。XXX企业版为了保障系统的高性能，自研了高效的私有协议，我们称之为RMTP协议（Rong Message Transmit Protocol XXX该协议可理解为非标准消息传输协议MQTT协议，说到MQTT自然会想到它的简化)，序列化会使用高效Protobuf，大量使用缓存LRU缓存淘汰算法，RPC以经典为基础Actor同时使用所有接入/接口服务Netty实现框架。很多事情有利有弊，Netty虽然是高效的异步NIO框架，但Netty他们自己依赖的第三方包也更多，这必然会导致一些包不支持ARM或者MIPS也更有可能。很多事情有利有弊，Netty虽然是高效的异步NIO框架，但Netty他们自己依赖的第三方包也更多，这必然会导致一些包不支持ARM或者MIPS也更有可能。在国产化适应测试过程中，我们遇到了推送不可用的问题，经调查定位为netty引用的第三方包不支持arm。 最后，我们通过：。
需要补充的是，自2019年1月起，Oracle开始对JDK8进行收费，8u192是2018年的最后一个update，这意味着可以继续免费使用，没有任何问题。
2.3 性能测试覆盖了主要的国产交付组合
服务端定位适应的最后一个问题是：性能测试应覆盖主要定位交付组合。
2.3.1 国产CPU现状
在介绍这个问题之前，我们需要首先了解国内CPU的现状，说到CPU或者芯片，我们需要简单地理解芯片指令集的概念，简单地说，芯片指令集大致分为两个阵营，即：复杂的指令集和简化的指令集，这就是我们通常所说的CISC & RISC，需要特别说明的是，复杂指令集（RISC）设计的初衷是:高性能但高功耗，精简指令集（RISC）小尺寸低功耗。因此，我们可以得出一个简单的结论：相同规格的复杂指令集架构CPU性能必须高于精简指令集架构下的性能CPU。因此，我们可以得出一个简单的结论：相同规格的复杂指令集架构CPU性能必须高于精简指令集架构下的性能CPU。比如也是8核CPU，X86的最强或酷睿性能必须高于ARM昆鹏或飞行架构等。 如果你想深入了解这方面的本地化，你可能会看到：独立指令集的单词主要来自龙芯的独立性LoongArch架构的龙芯3A5000。关于LoongArch，你需要知道的是:LoongArch 仍为RISC但需要注意的是：LoongArch通过指令集翻译兼容MIPS、ARM及x龙芯的目标是在2025年消除指令集之间的壁垒。目前公开的翻译效率数据是：MIPS：100%、ARM：90%、x86：Linux下翻译的效率可达80%。有时你可能会看到独立的结构SW但从公开资料来看，SW其实架构比较小Alpha结构，其对应的芯片是申威，而且该芯片主要用于涉军项目，通常在交付中很难遇到。
在PPT在大多数情况下，我已经列出了当前国产化项目交付中可能遇到的情况CPU型号，这里就不赘述了。如果你需要，PPT以后可以扫描稿件备查阅。PPT关注最后一页的二维码XXX可获得微信官方账号。
2.3.2 建议覆盖范围
接下来，分享国产化性能测试应覆盖的范围。由于国产芯片以RISC大多数架构，显然项目交付时，所需的服务器资源不能用非国产化基数来估算。XXX对主要的本地交付组合进行了大量的性能测试和实际验证，最终获得了更合理的评价标准基础。通过服务器资源配置工具，可以快速评价服务器资源。因为这个性能指标基数必须结合起来CPU、OS、就系统本身而言，这就需要在不同的组合下测量自己的系统。建议覆盖:坤鹏:920/920S、飞腾：2000/2000 、龙芯：3B3000/4000，统信V20及麒麟V10。在开展这项摸底工作的过程中，经常会遇到得不到相应环境的问题，我们通过两种方式来解决：
- 从华为云中获得的坤鹏环境。
- 从合作制造商那里借用机器进行测试，并直接使用客户的测试环境。
需要补充的是，在国产化交付工作中，我需要大致了解操作系统与CPU的关系，由于涉及比较专业的操作系统基础知识，这里我不一一带读，大家只要简单知道：ARM下编译的builder只能在ARM运行，其他架构也是同样。在国产化项目交付的工作中，我们需要将操作系统与CPU架构一起来说，不同CPU架构下的同名操作系统需要认为是不同操作系统。因此今后不要只说UOS下的性能表现如何，ARM下的表现如何？而应该把两者结合在一起去说，否则都是不严谨的。
3. 客户端国产化适配
服务端国产化适配的相关问题和经验就此介绍完毕，接下来我们从客户端和部署交付这两个方面来谈谈其他问题和经验。
3.1 不同操作系统打包规范不同
在客户端国产化适配功能测试阶段，发现了很多因为不同操作系统打包规范不同所导致的问题，例如：桌面客户端卸载之后应用Ico图标未被清理、客户端托盘不能闪烁以及客户端托盘活生生的直接显示为2个图标等问题。这些问题，我们都可以归结为客户端的打包与相应系统的打包规范不一致所导致的。这个世界上，最难的事情往往不是解决问题本身，而是提出或者发现一个新的问题，该问题的解决策略可以直接而简单的去找国产操作系统厂商索要打包规范，然后依据规范进行打包即可。联系信创厂商这件事情，大家完全可以不要有任何的顾虑，因为目前芯片、操作系统、数据库等方面早已经迈过了基础能力建设的阶段，各大信创厂商自身也都十分重视生态发展，因此，各大信创厂商对此都是很开放的。
3.2 不同操作系统 libc 版本不一致
接下来我们来看另外一个客户端适配中所遇到的问题：不同操作系统 libc 版本不一致。
对于桌面的客户端的研发，相比于服务端，最为重要的一个区别是：服务端往往更多考虑高并发所引发的相关问题，而客户端则涉及的较少，毕竟一人用一端嘛。但是，客户端的研发，往往也会分层，同样也会涉及缓存、DB和其他复杂逻辑的组件封装，就是我们通常说的，客户端本地缓存、客户端本地DB以及客户端SDK或者协议栈和插件等。XXX企业版客户端RCE，协议栈使用C++做为开发语言，同时一些插件也是基于C++进行开发，例如：截屏插件。在XXX国产化适配的过程中，一个困扰客户端很长时间的问题就是这些C++的协议栈和插件因为不同操作系统 libc 版本不一致所引发的问题。根据我们的经验，建议：不管是ARM还是MIPS架构都在麒麟系统上进行编译，因为同一架构下麒麟系统的libc版本都比统信系统低，一般麒麟系统的libc版本为2.2.3，统信的则为2.2.8。
3.3 静态编译QT的基础上编译其他插件node文件
在国产化适配客户端功能测试中，客户端截屏功能无法正常使用是最早暴露的问题之一，和上一个问题类似，但是不同的是，这里只针对客户端插件的范畴去给出另外的一种解决方案，概要来说就是：客户端插件通过静态编译QT的基础上编译其他插件node文件方式来处理。静态编译后，最终的执行其实是基于解释性的执行方式，天生具备了良好的兼容性。而动态编译方式下，最终的执行则是由执行器直接执行编译产物。从上述的描述中大家应该能够明白为什么这里只是针对客户端插件的范畴，因为像截屏插件这种实现上选择不多，又不要求其执行效率要求多高的插件，利用静态编译天生具备的良好兼容性去解决，无疑更佳。
4.国产化部署交付
最后我们从国产化部署交付方面分享一下XXX产品国产化适配过程中所需要关注的问题。
4.1 不同操作系统 glibc 版本不一致
PPT中所展示是XXX企业版系统逻辑架构图，从图中我们可以看出，整个系统分为：界面UI层、接入/接口层、中间逻辑层、数据存储层。几乎所有的应用应用系统都会使用和依赖一些中间件或者工具，例如：数据存储中间件、消息队列中间件、缓存中间件等，另外进程管理工具在部署交付一般都会用到，例如：supervisor。从图中我们可以看出XXX企业版同样依赖这里所提到的几个方面的中间件，毕竟重复造轮子的事情需要有足够的理由才会去考虑。
在部署交付之前，大家常常都会预先把所有的部署资源提前准备好，包括：服务自身的编译包、中间件等，现场临时编译显然不是明智之举，这样即不能做到快速部署，过程也不可控。XXX企业版本所依赖的中间件中，一部分基于C或者其他非Java语言，万恶的国产化Linux C编译问题再次袭来。为了统一编译，达到泛部署的目的，我们需要找到一个合适的版本进行中间件的编译，以适应多数的场景。这个合适的版本不能过高也不能过低，因为过高的版本在遇到低版本一定出问题，过低的版本则有可能出现中间件依赖找不到的情况，我们针对麒麟、统信做了大量的摸索和尝试，终于使得预编译部署资源在多数场景下可以正常使用，从而达到了范部署的效果。
4.2 不同操作系统Path环境变量不同
不同操作系统Path环境变量不同，这个问题处理起来特别简单，其原因也特别浅显，就是：很多服务或者中间件的正常运行都依赖Path环境变量的设置。但是，这里我们给出的优先解决方式是：通过软链方式去解决该问题。我们的考虑是：做为操作系统的使用者，各方面的理解及评估能力一定远远不及厂商自身，不直接修改操作系统环境变量则一定能够完全规避修改环境变量引发其他问题的可能，无疑，这种解决方式是：将产生其他的影响的可能性降到最低的一种方式。
4.3 不同操作系统rpm包存在差异
最后，谈谈部署工具本身在国产化适配中碰到的问题，通常在自动化部署工具的实现上，大家都用python，毕竟，不会python的运维不是好运维。但是python的运行环境需要依赖python-rpm package。在不同操作系统rpm包存在差异情况下，就可能出现问题。自动化部署工具自身都出现各种问题，那么何谈快速部署？解决该问题的办法，优先推荐直接使用操作系统厂商所提供的rpm包。其实这个问题在非国产操作系统上也存在，那么我们推荐的做法是：直接从操作系统自身的yum源中去获取。这里再次提到了优先联系操作系统厂商获取帮助（之前介绍客户端国产化适配遇到的问题中，也提到找操作系统厂商获取打包规范）。这里，最后分享一条不是经验的经验就是：与国产化厂商建立良好的合作关系也是非常重要和必要的，因为出现问题后如果可以直接从对应厂商处获取到协助，无疑是最为高效及有效的。