一、先统一口径:用一份公开公告替代所有厂商自述
信创选型最容易陷入的循环是:每家都说自己适配得最全,每家的适配清单都不一样,而买方没有独立判断的依据。打破这个循环的办法是找一个所有厂商都必须面对的公开口径作为锚点——目前最可行的是中国信息安全测评中心与国家保密科技测评中心发布的《安全可靠测评结果公告》。该公告依据《安全可靠测评工作指南》发布,逐批公布通过测评的产品名称、送测单位与安全可靠等级,并明确自发布之日起有效期三年。
这个锚点的价值有三层。第一,它是外部机构出具的结果,不是厂商自述,避免了「适配清单各说各话」。第二,它给出了等级维度,不同产品之间存在可比较的等级标注。第三,它带有有效期,意味着适配不是一次性动作,而是需要在有效期届满前关注产品是否有新的测评结果。
但必须同时把它的边界说清楚:安全可靠测评考察的是产品的安全可靠水平,并不等同于对性能、并发能力、业务功能适配程度的评价。也就是说,一款产品出现在公告里,只能说明它在安全可靠维度通过了测评,不能推断它一定跑得动你的月结批处理。选型时需要把「安全可靠测评结果」与「业务适配验证」两件事分开做,前者看公告,后者必须自己在测试环境里跑。
二、公告怎么核:批次、有效期与适用性
公告是按批次发布的,每一批只公布本期通过测评的产品,不同批次之间并不构成包含关系。因此核查时不能只看最新一期,而要核对目标产品是否出现在任何一期仍处于有效期内的公告中——这一点在采购合同中尤其重要,因为一旦所依据的公告过了有效期,之前的适配依据在形式上就失去了支撑。
以 2026 年 9 月 20 日发布的《安全可靠测评结果公告(2026 年第 3 号)》为例,其公布的中央处理器产品及测评情况如下表。需要强调的是,下表只是用来示范核查方法,不能当作产品推荐名单——真正的选型必须结合业务适配验证结果,并且核对所有仍在有效期内的公告批次。
| 产品名称 | 送测单位 | 安全可靠等级 |
|---|---|---|
| 龙芯 3A6000(C) | 龙芯中科技术股份有限公司 | Ⅲ 级 |
| 龙芯 3C3000 | 龙芯中科技术股份有限公司 | Ⅲ 级 |
| 鲲鹏 950 | 深圳市海思半导体有限公司 | Ⅲ 级 |
| 兆芯处理器 KH-50000 | 上海兆芯集成电路股份有限公司 | Ⅱ 级 |
| 威鑫 H8100 型微处理器 | 中电科申泰信息科技有限公司 | Ⅱ 级 |
| 海光 C86-4G/H | 海光信息技术股份有限公司 | Ⅱ 级 |
| 麒麟 9001X | 深圳市海思半导体有限公司 | Ⅱ 级 |
同一期公告还公布了服务器操作系统与集中式数据库的测评结果。这些配套基础软件同样重要,因为财务系统跑的是「处理器加操作系统加数据库加中间件」的组合,任何一层不在有效测评结果范围内,都可能在验收或检查环节被追问。因此核查应当是组合式核查,而不是只核处理器。
| 类别 | 产品名称 | 送测单位 | 安全可靠等级 |
|---|---|---|---|
| 服务器操作系统 | 银河麒麟高级服务器操作系统 V11 SP1(内核版本 Linux Kernel 6.6) | 麒麟软件有限公司 | Ⅱ 级 |
| 服务器操作系统 | 大云天元操作系统(BC-Linux)V21.10 U5(内核版本 Linux Kernel 5.10) | 中移(苏州)软件技术有限公司 | Ⅰ 级 |
| 集中式数据库 | 羲和通用数据库系统软件 V1.0 | 杭州易景数通科技有限公司 | Ⅰ 级 |
| 集中式数据库 | NetrixDB V3.0 | 华为云计算技术有限公司 | Ⅰ 级 |
| 集中式数据库 | TDSQL 集中式关系型数据库管理系统软件 V10.3 | 腾讯云计算(北京)有限责任公司 | Ⅰ 级 |
三、三条指令集路线:迁移代价的差异从哪里来
处理器层面的适配代价,本质上不是由处理器本身决定的,而是由它背后的软件包生态决定的。国产处理器目前大致沿三条路线发展:兼容 x86 指令集授权的路线、基于 ARM 架构授权的路线、以及采用自研指令集的路线。三者的差别,在服务器上最终体现为一条命令的输出结果不同。
| 路线 | 代表产品方向 | 架构标识(uname -m) | 生态包获取 | 适配验证的主要工作量 |
|---|---|---|---|---|
| 兼容 x86 指令集授权 | 面向服务器与桌面两条产品线,覆盖通用场景 | x86_64 | 通用发行版与商业软件的安装包相对齐全,多数可直接使用 | 主要在版本与补丁层面,通常不需要重新编译业务组件 |
| ARM 架构授权 | 以服务器与云计算场景为主,政务办公领域应用较广 | aarch64 | 主流 Linux 发行版都有对应架构,常见开源组件的包基本齐备 | 需要确认中间件、JDBC 驱动、客户端组件的 aarch64 版本是否同步提供 |
| 自研指令集 | 面向自主可控要求较高的场景,覆盖桌面与服务器 | loongarch64 | 包生态相对较薄,部分组件需要自行编译或由厂商提供定制版本 | 需要预留编译与联调时间,优先在上游确认依赖组件的支持情况 |
这张表想说明的是一件事:适配工作量的差异,主要来自「你要用的那些组件在这个架构上有没有现成的包」。所以验证的正确顺序是自上而下——先把业务系统要用到的组件清单列出来,逐个确认在该架构上有没有厂商支持的版本,再决定机器选哪一种。反过来先定机器再找包,就会把大量时间花在编译和踩坑上。
还有一个实操细节值得提醒:做离线包仓库时,不同架构的包应当分目录存放,目录名直接使用架构标识(x86_64、aarch64、loongarch64),不要混放。混放之后的错误往往不会立刻报错,而是在安装某个组件时以「包版本不匹配」的形式出现,排查成本远高于一开始就分开。
四、六层适配验证清单
把适配从一句口号变成一份可交付的验证记录,需要按层次拆开。下面六层覆盖了财务系统部署到国产环境时实际会遇到的验证点,每一层都要有明确的通过判据。
| 层次 | 验证项 | 通过判据 | 常见的不通过点 |
|---|---|---|---|
| 处理器与主板 | 架构标识确认、虚拟化与容器支持、加解密指令支持、内存与盘位扩展能力 | 架构标识与采购方案一致;虚拟化与容器可正常运行;扩展槽位满足五年规划 | 忽略了加密卡或密码模块对特定架构的驱动支持 |
| 操作系统 | 内核版本、字符集与时区、系统库版本、文件系统与大文件支持、系统补丁策略 | 系统层面无依赖缺失,字符集与财务系统要求一致,历史遗留的编码问题不出现 | 字符集设置导致中文与生僻字显示异常,报表导出出现乱码 |
| 中间件与运行时 | 应用服务器、Java 运行时、消息组件、定时任务组件 | 所有组件均有该架构的官方支持版本,且版本组合经过厂商验证 | 部分组件只有社区编译版,升级与补丁无官方支持 |
| 数据库 | 数据库版本、驱动、存储过程与函数兼容性、备份恢复工具、字符排序规则 | 现有业务 SQL 与存储过程在目标数据库上全部执行通过,备份恢复演练成功 | 排序规则差异导致对账与去重逻辑行为改变;自研报表 SQL 性能显著下降 |
| 应用与集成 | 财务系统本体、与业务系统的接口、与税务与银行等外部系统的连接组件 | 主流程与异常分支全部跑通,接口报文与数据对账结果一致 | 外部系统的客户端组件缺少对应架构版本,成为整条链路的短板 |
| 客户端与外设 | 浏览器兼容性、版式文件阅读器、打印与扫描设备、身份认证介质、扫码设备 | 在国产终端上完成一次完整的单据流转与打印归档,签名与阅读器可正常调用 | 打印控件、扫码枪或身份认证介质的驱动缺位,导致关键操作无法在国产终端完成 |
六层之中,被低估最多的是第六层。服务器侧的适配通常有厂商积极推动,而客户端与外设的适配往往无人牵头:打印机没有对应驱动、扫描仪只能通过专用软件取图、身份认证介质在国产终端上无法识别。这些问题在上线前的功能测试中不出现,等到全员切换终端时才集中爆发。因此验证清单里必须包含一次「在目标国产终端上完成一笔单据从提交到打印归档」的端到端实操。
五、财务系统特有的适配雷区
容易被忽略的六处
- 版式文件处理:电子发票的版式文件需要专用阅读器或组件解析,必须确认该组件在目标架构与操作系统的可用版本
- 报表与取数工具:自研报表或第三方报表工具对排序规则与数值精度敏感,同一份数据在不同数据库上可能得出不同顺序的结果,需要逐张报表核对
- 字体与打印排版:财务报表与凭证打印对字体依赖强,缺少字体时会静默替换,导致金额位数错位或符号显示异常
- 大批量导入导出:跨架构的数据搬运在字符编码与数值格式上更容易出问题,需要按实际最大量级做一次完整往返
- 密码与签名组件:涉及加密卡、身份认证介质与国密算法的组件,驱动与接口在自研指令集平台上需要单独确认
- 定时任务与批处理:月结批处理依赖系统级的调度与临时空间,需在目标环境实测耗时,不能沿用原环境的估算值
这些雷区的共同特征是:功能测试阶段发现不了,全员使用后才暴露。应对办法只有一个——把验证做实。验证环境应当尽量贴近最终部署形态,包括相同的处理器架构、相同的操作系统与内核版本、相同的数据库版本与参数配置、相同的浏览器与终端设备。用一台装了不同系统的开发机做适配验证,结论没有参考价值。
六、证据留存与合同写法
适配验证的成果如果不落成文件,半年之后就会变成「记得当时试过但找不到了」。建议在项目内维护一份适配验证记录,每个验证项记录四件事:验证对象与版本、验证方式与步骤、实际结果、验证人与日期。这份记录在验收、审计与后续升级时都会被反复使用。
- 梳理组件清单并逐项标注目标架构上的支持情况,形成一张覆盖处理器、操作系统、中间件、数据库、应用、客户端与外设的适配矩阵
- 对每一项支持情况,要求厂商提供书面说明:支持的版本范围、验证结论、已知限制与后续版本计划,并注明对应的安全可靠测评公告批次与有效期
- 在贴近生产形态的测试环境中执行一次端到端实操,覆盖主流程与至少三个异常分支,同时记录性能与批处理耗时
- 把适配矩阵与验证记录作为合同附件,约定升级或更换基础软件版本时的重新验证义务与响应时限
- 在合同中明确适配问题的责任划分:属于基础软件与业务系统之间的适配问题,由谁牵头定位、何时修复
- 约定一个检查节奏:安全可靠测评公告的有效期为三年,在有效期届满前应重新核对所依据的产品是否有新的测评结果,避免形式上的依据失效
把这六件事做完,信创适配就从一场关于性能的争论,变成一份可以逐项打勾的清单。对财务负责人和 IT 负责人来说,这才是能拿到会议上、能写进合同、能在验收时拿出来的东西。
资料来源:《安全可靠测评结果公告(2026 年第 3 号)》(中国信息安全测评中心、国家保密科技测评中心,2026 年 9 月 20 日发布,依据《安全可靠测评工作指南 V4.0》,自发布之日起有效期三年);《安全可靠测评工作指南 V4.0》。文中架构标识、生态现状与验证清单为实务观察与建议,具体产品的适配情况须以厂商书面说明与买方自测结果为准。