← 返回

信创项目实战总结:从申威龙芯到数据库三大件与容器化部署

作者:林 | 系列:信创实战 | 适合读者:信创项目实施者、Java 后端/架构师、运维工程师


一、背景:为什么要做信创

信创(信息技术应用创新)的核心目标是自主可控。从芯片到操作系统,从数据库到中间件,逐步替换国外技术栈,降低供应链风险。

一个典型的信创项目涉及:

  • 芯片:申威、龙芯、飞腾、鲲鹏、海光、兆芯
  • 操作系统:麒麟(银河麒麟/中标麒麟)、统信 UOS、欧拉
  • 数据库:达梦、人大金仓、神通
  • 中间件:东方通 TongWeb、宝兰德 BES
  • 办公软件:WPS、永中 Office
  • 可信计算:国密算法(SM2/SM3/SM4)、可信平台模块
  • 容器化:Docker 适配、镜像编译

本文是实际项目中的踩坑总结,重点覆盖申威、龙芯、数据库三大件和容器化部署。


二、国产 CPU 处理器选型

2.1 六大国产 CPU 对比

厂商指令集代表型号定位生态成熟度
申威SW64(自主)SW1621、SW3231、HX 系列特种/超算/信创⭐⭐
龙芯LoongArch(自主)3A5000、3C5000、3A6000、3C6000桌面/服务器⭐⭐⭐
飞腾ARMv8/AArch64(授权)FT-2000、S2500桌面/服务器⭐⭐⭐⭐
鲲鹏ARMv8/AArch64(授权)鲲鹏 920服务器⭐⭐⭐⭐
海光x86(授权)海光 7000、海光 5000服务器⭐⭐⭐⭐⭐
兆芯x86(授权)开胜 KH-40000桌面/服务器⭐⭐⭐⭐

⚠️ 注意:海光和兆芯的 x86 授权有争议(AMD/VIA 授权),严格意义上不算"完全自主"。部分信创项目不接受 x86 路线。

2.2 申威处理器详解

申威的技术源头是 DEC Alpha 21164,后发展出自主指令集 SW64。神威·太湖之光超级计算机使用的就是申威 SW26010 处理器。

主要型号

型号核心数主频架构定位备注
SW162116 核~2.0 GHzSW64服务器信创服务器常用型号
SW323132 核~2.0 GHzSW64高性能服务器多路互联
SW26010256 核1.45 GHzSW64(众核)超算太湖之光专用
HX 系列以厂商资料为准以厂商资料为准SW64新一代公开资料有限

⚠️ 申威的公开技术资料非常少,以上参数来自公开招标文件和行业交流。HX 系列的具体参数建议联系申威官方或查阅当前公开的招标技术规范书。

申威的特点

  1. 自主指令集:SW64 是申威自研路线,软件生态和适配成本仍要结合具体 OS/发行版评估
  2. 生态薄弱:软件适配少,很多开源软件需要自己编译
  3. 性能需实测:不同代际、编译器和负载差异较大,应使用目标服务器和实际软件做基准
  4. 主要客户:军工、党政、特种行业

申威 vs 龙芯选型建议

处理器不能仅按行业名称直接推荐。选型先核对项目验收目录、操作系统与中间件适配、实际工作负载、供应与维保,再在候选机器上运行同一套编译、功能和性能测试。申威与龙芯采用不同指令集和生态路线,海光、鲲鹏、飞腾也各有兼容边界,结论要绑定具体型号、软件版本和测试日期。

2.3 龙芯处理器详解

龙芯在 2021 年发布了自主指令集 LoongArch(龙架构),不再依赖 MIPS 授权。

主要型号

型号核心数主频架构定位发布时间
3A50004 核2.3-2.5 GHzLoongArch桌面2021
3C500016 核2.0-2.2 GHzLoongArch服务器2022
3D500032 核(多芯片)2.0 GHzLoongArch高性能服务器2023
3A60004 核2.5 GHzLoongArch桌面(新一代)2023
3C6000以厂商资料为准以厂商资料为准LoongArch服务器(新一代)2025
3B6000以厂商资料为准以厂商资料为准LoongArch当前公开旗舰2025
2K20002 核1.5 GHzLoongArch嵌入式 SoC2023
2K3000以厂商资料为准以厂商资料为准LoongArch嵌入式(新一代)2025

龙芯的关键里程碑

  • 2021 年:发布 LoongArch 自主指令集,摆脱 MIPS 授权
  • 2022 年:UEFI 官方支持 LoongArch(继 x86、ARM、RISC-V 之后第四个)
  • 2023 年:3A6000 发布,IPC 接近 AMD Zen1 水平
  • 2025 年:3B6000/3C6000 通过安全可靠测评 Ⅱ 级(更高等级)
  • 2025 年:龙芯设备成功运行 DeepSeek R1 7B 模型

三、数据库三大件

信创数据库替换是复杂的环节之一。核心三大件:达梦人大金仓神通

3.1 三大数据库对比

维度达梦 DM8人大金仓 KingbaseES神通 Oscar
技术来源自研PostgreSQL 兼容/演进路线PostgreSQL/openGauss 兼容/演进路线
Oracle 兼容⭐⭐⭐⭐⭐ 高度兼容⭐⭐⭐⭐ 较好⭐⭐⭐ 一般
MySQL 兼容⭐⭐⭐⭐⭐⭐⭐⭐
分布式能力DM8 DSC(类似 RAC)无原生 RAC无原生 RAC
性能接近 Oracle接近 PostgreSQL接近 PostgreSQL
生态成熟度⭐⭐⭐⭐ 更稳妥⭐⭐⭐⭐⭐
价格较高中等较低
典型客户金融、电信、政务党政、教育军工、特种

3.2 从 Oracle/MySQL 迁移到达梦

迁移评估

迁移前评估清单:
  1. 存储过程/函数数量 → 达梦兼容度高,大部分可直接跑
  2. 触发器、序列、同义词 → 达梦支持
  3. 数据量 → 超过 1TB 考虑分库分表
  4. 性能要求 → 达梦单机性能接近 Oracle,集群方案需评估
  5. 第三方依赖 → MyBatis/JPA 通常无需改代码

JDBC 配置差异

# Oracle
spring.datasource.url=jdbc:oracle:thin:@192.168.1.100:1521:orcl
spring.datasource.driver-class-name=oracle.jdbc.OracleDriver

# 达梦
spring.datasource.url=jdbc:dm://192.168.1.100:5236/DMDB
spring.datasource.driver-class-name=dm.jdbc.driver.DmDriver

# 人大金仓
spring.datasource.url=jdbc:kingbase8://192.168.1.100:54321/TEST
spring.datasource.driver-class-name=com.kingbase8.Driver

# 神通
spring.datasource.url=jdbc:oscar://192.168.1.100:2003/OSRDB
spring.datasource.driver-class-name=com.oscar.Driver

常见踩坑

1. 分页语法差异

-- Oracle / 达梦
SELECT * FROM (
  SELECT t.*, ROWNUM rn FROM (
    SELECT * FROM product ORDER BY id
  ) t WHERE ROWNUM <= 20
) WHERE rn > 10;

-- 达梦也支持 LIMIT(兼容 MySQL 模式)
SELECT * FROM product LIMIT 10 OFFSET 10;

-- 人大金仓(PostgreSQL 语法)
SELECT * FROM product LIMIT 10 OFFSET 10;

2. 字段类型映射

Oracle VARCHAR2     → 达梦 VARCHAR / VARCHAR2(都支持)
Oracle NUMBER       → 达梦 NUMBER / BIGINT / INT
Oracle DATE         → 达梦 DATE(含时间)/ TIMESTAMP
Oracle BLOB         → 达梦 BLOB
Oracle CLOB         → 达梦 CLOB / TEXT

3. 序列语法

-- Oracle
SELECT seq_product.NEXTVAL FROM DUAL;

-- 达梦(兼容 Oracle)
SELECT seq_product.NEXTVAL FROM DUAL;

-- 人大金仓(PostgreSQL 语法)
SELECT nextval('seq_product');

3.3 达梦数据库集群方案

达梦的高可用方案类似 Oracle RAC:

形态组成使用前需要确认
单机一个 DM8 实例适合开发和功能验证,不提供节点级高可用
数据守护主备主库、备库、守护进程及监视器切换策略、数据保护模式、客户端重连和演练结果
DSC多数据库实例、共享存储、集群同步服务共享存储可靠性、集群版本限制和运维能力

四、可信计算与国密算法

4.1 国密算法概述

信创项目中常常需要支持国密算法(GM/T),尤其是政务、金融、能源等合规要求明确的场景:

国密算法替代用途说明
SM2RSA/ECDSA非对称加密、数字签名基于椭圆曲线,256 位安全强度相当于 RSA 2048
SM3SHA-256哈希摘要输出 256 位,安全性与 SHA-256 相当
SM4AES-128对称加密128 位密钥,分组加密
SM9基于身份的加密无需证书,用身份标识做公钥

4.2 Java 中使用国密算法

Bouncy Castle 支持

<dependency>
    <groupId>org.bouncycastle</groupId>
    <artifactId>bcprov-jdk18on</artifactId>
    <version>1.78</version>
</dependency>

SM2 签名示例

import org.bouncycastle.crypto.AsymmetricCipherKeyPair;
import org.bouncycastle.crypto.generators.ECKeyPairGenerator;
import org.bouncycastle.crypto.params.*;
import org.bouncycastle.jce.provider.BouncyCastleProvider;
import org.bouncycastle.crypto.signers.SM2Signer;

import java.security.*;

public class Sm2Utils {

    static {
        Security.addProvider(new BouncyCastleProvider());
    }

    /**
     * 生成 SM2 密钥对
     */
    public static AsymmetricCipherKeyPair generateKeyPair() {
        ECKeyPairGenerator generator = new ECKeyPairGenerator();
        generator.init(new ECKeyGenerationParameters(
                GMObjectIdentifiers.sm2p256v1, new SecureRandom()));
        return generator.generateKeyPair();
    }

    /**
     * SM2 签名
     */
    public static byte[] sign(byte[] data, ECPrivateKeyParameters privateKey) {
        SM2Signer signer = new SM2Signer();
        signer.init(true, new ParametersWithID(
                new ParametersWithRandom(privateKey, new SecureRandom()),
                "1234567812345678".getBytes()));
        signer.update(data, 0, data.length);
        return signer.generateSignature();
    }

    /**
     * SM2 验签
     */
    public static boolean verify(byte[] data, byte[] signature,
                                  ECPublicKeyParameters publicKey) {
        SM2Signer signer = new SM2Signer();
        signer.init(false, new ParametersWithID(publicKey,
                "1234567812345678".getBytes()));
        signer.update(data, 0, data.length);
        return signer.verifySignature(signature);
    }
}

SM4 加密示例

import org.bouncycastle.crypto.engines.SM4Engine;
import org.bouncycastle.crypto.modes.CBCBlockCipher;
import org.bouncycastle.crypto.paddings.PaddedBufferedBlockCipher;
import org.bouncycastle.crypto.params.KeyParameter;
import org.bouncycastle.crypto.params.ParametersWithIV;

public class Sm4Utils {

    /**
     * SM4-CBC 加密
     */
    public static byte[] encrypt(byte[] data, byte[] key, byte[] iv) {
        PaddedBufferedBlockCipher cipher = new PaddedBufferedBlockCipher(
                new CBCBlockCipher(new SM4Engine()));
        cipher.init(true, new ParametersWithIV(new KeyParameter(key), iv));

        byte[] output = new byte[cipher.getOutputSize(data.length)];
        int len = cipher.processBytes(data, 0, data.length, output, 0);
        len += cipher.doFinal(output, len);
        return Arrays.copyOf(output, len);
    }

    /**
     * SM4-CBC 解密
     */
    public static byte[] decrypt(byte[] data, byte[] key, byte[] iv) {
        PaddedBufferedBlockCipher cipher = new PaddedBufferedBlockCipher(
                new CBCBlockCipher(new SM4Engine()));
        cipher.init(false, new ParametersWithIV(new KeyParameter(key), iv));

        byte[] output = new byte[cipher.getOutputSize(data.length)];
        int len = cipher.processBytes(data, 0, data.length, output, 0);
        len += cipher.doFinal(output, len);
        return Arrays.copyOf(output, len);
    }
}

4.3 SSL/TLS 国密化

信创项目中,HTTPS 需要支持国密 SSL(GM/T 0024):

标准 TLS 握手:
  Client → ClientHello (RSA/ECDSA) → Server
  Server → Certificate (RSA/ECDSA) → Client

国密 TLS 握手(双证书模式):
  Client → ClientHello (SM2) → Server
  Server → Sign Certificate (SM2) + Enc Certificate (SM2) → Client
  → 使用 SM4 加密通信,SM3 做摘要

⚠️ 国密 SSL 需要专门的国密 SSL 库(如 GmSSL、Tongsuo 铜锁),Java 标准库不直接支持。


五、Docker 容器化:申威平台编译指南

这是信创项目中更痛的部分。申威平台(SW64 架构)的 Docker 镜像生态几乎为零,大部分需要自己编译。

5.1 为什么申威的 Docker 镜像这么难搞

公开镜像对 amd64 的覆盖通常更完整,arm64 覆盖取决于项目,SW64 制品则需要逐项核实。不要用未经统计的占比代替检查结果。迁移前读取镜像 manifest,确认基础镜像、JDK、数据库客户端和 Native 依赖是否包含目标架构;缺失项列入源码构建清单。

申威的 Docker 支持取决于:

  1. 操作系统:麒麟/统信是否支持 Docker
  2. 内核版本:Docker 需要 Linux 内核 3.10+
  3. 编译工具链:GCC 是否支持 SW64 目标
  4. 基础镜像:是否有 SW64 的 Debian/CentOS 基础镜像

5.2 MySQL 编译指南

前提条件:
  - 申威服务器已安装麒麟/统信操作系统
  - 已安装 Docker(从操作系统厂商获取)
  - 已获取 SW64 基础镜像(如 sw-ubuntu:22.04)

Dockerfile

# 基础镜像(需从操作系统厂商获取 SW64 版本)
FROM sw-ubuntu:22.04

# 安装依赖
RUN apt-get update && apt-get install -y \
    cmake \
    gcc \
    g++ \
    make \
    libncurses5-dev \
    libssl-dev \
    bison \
    pkg-config \
    && rm -rf /var/lib/apt/lists/*

# 下载 MySQL 源码
ARG MYSQL_VERSION=8.0.35
ADD https://dev.mysql.com/get/Downloads/MySQL-8.0/mysql-${MYSQL_VERSION}.tar.gz /tmp/
RUN tar -xzf /tmp/mysql-${MYSQL_VERSION}.tar.gz -C /opt/

# 编译 MySQL
WORKDIR /opt/mysql-${MYSQL_VERSION}
RUN mkdir build && cd build && \
    cmake .. \
        -DCMAKE_INSTALL_PREFIX=/usr/local/mysql \
        -DWITH_SSL=system \
        -DWITH_ZLIB=bundled \
        -DDOWNLOAD_BOOST=1 \
        -DWITH_BOOST=/opt/boost \
        -DENABLED_LOCAL_INFILE=1 \
        -DWITH_UNIT_TESTS=OFF \
    && make -j$(nproc) \
    && make install \
    && rm -rf /opt/mysql-${MYSQL_VERSION}

# 配置
COPY my.cnf /etc/my.cnf
COPY init-db.sh /docker-entrypoint-initdb.d/

EXPOSE 3306
CMD ["mysqld", "--user=mysql"]

编译注意事项

常见问题及解决方案:

1. cmake 报错 "Unknown processor architecture"
   → 添加 -DCMAKE_SYSTEM_PROCESSOR=sw64

2. 编译时间超长(申威单核性能弱)
   → 使用 -j$(nproc) 多核编译,SW1621 用 -j16

3. 内存不足
   → 减少并行度:-j4,或增加 swap

4. Boost 库下载失败
   → 提前下载放到本地,用 -DWITH_BOOST=/local/path

5. OpenSSL 版本不兼容
   → 使用系统自带的 OpenSSL,不要编译新版

5.3 Redis 编译指南

Redis 相对简单,纯 C 代码,架构无关性好:

FROM sw-ubuntu:22.04

RUN apt-get update && apt-get install -y \
    gcc \
    make \
    && rm -rf /var/lib/apt/lists/*

ARG REDIS_VERSION=7.2.4
ADD https://download.redis.io/releases/redis-${REDIS_VERSION}.tar.gz /tmp/
RUN tar -xzf /tmp/redis-${REDIS_VERSION}.tar.gz -C /opt/ && \
    cd /opt/redis-${REDIS_VERSION} && \
    make -j$(nproc) && \
    make install PREFIX=/usr/local && \
    mkdir -p /data/redis && \
    rm -rf /opt/redis-${REDIS_VERSION}

COPY redis.conf /etc/redis/redis.conf

EXPOSE 6379
CMD ["redis-server", "/etc/redis/redis.conf"]

Redis 编译踩坑

1. jemalloc 编译失败
   → 使用 make MALLOC=libc(使用系统 malloc 替代 jemalloc)

2. 原子操作不支持
   → 检查 GCC 版本,SW64 需要 GCC 10+

3. 性能比 x86 差很多
   → 正常,单核性能差 3-5 倍,用多实例弥补

5.4 Nacos 编译指南

Nacos 本身是 Java 项目,主体逻辑架构基本无关;真正要看的是 SW64 可用的 JDK 版本,以及 RocksDB JNI 这类本地依赖是否已适配:

FROM sw-ubuntu:22.04

# 安装 SW64 版本的 OpenJDK(从操作系统厂商获取)
RUN apt-get update && apt-get install -y \
    openjdk-17-jdk-headless \
    && rm -rf /var/lib/apt/lists/*

ENV JAVA_HOME=/usr/lib/jvm/java-17-openjdk-sw64

# 下载 Nacos(通用 JAR 包,架构无关)
ARG NACOS_VERSION=2.3.1
ADD https://github.com/alibaba/nacos/releases/download/${NACOS_VERSION}/nacos-server-${NACOS_VERSION}.tar.gz /opt/
RUN tar -xzf /opt/nacos-server-${NACOS_VERSION}.tar.gz -C /opt/ && \
    rm /opt/nacos-server-${NACOS_VERSION}.tar.gz

WORKDIR /opt/nacos

EXPOSE 8848 9848 9849
CMD ["sh", "-c", "bin/startup.sh -m standalone && tail -f logs/start.out"]

Nacos 在申威上的问题

1. JDK 版本问题
   → 申威环境可用的 JDK 版本取决于 OS/厂商包
   → Nacos 2.x 通常可用 JDK 8,Nacos 3.x 需要 JDK 17+

2. JVM 参数不兼容
   → 申威的 JVM GC 参数可能不支持 G1/ZGC
   → 使用 -XX:+UseSerialGC 或 -XX:+UseParallelGC

3. 性能问题
   → JVM 在申威上性能比 x86 差 50%+
   → 增加 JVM 堆内存:-Xmx4g

5.5 其他常用组件编译

OpenResty (Nginx + Lua)

FROM sw-ubuntu:22.04

RUN apt-get update && apt-get install -y \
    gcc make libpcre3-dev libssl-dev \
    && rm -rf /var/lib/apt/lists/*

ARG OPENRESTY_VERSION=1.25.3.1
ADD https://openresty.org/download/openresty-${OPENRESTY_VERSION}.tar.gz /tmp/
RUN tar -xzf /tmp/openresty-${OPENRESTY_VERSION}.tar.gz -C /opt/ && \
    cd /opt/openresty-${OPENRESTY_VERSION} && \
    ./configure --prefix=/usr/local/openresty \
        --with-pcre-jit \
        --with-http_ssl_module \
    && make -j$(nproc) && make install

EXPOSE 80 443
CMD ["/usr/local/openresty/bin/openresty", "-g", "daemon off;"]

RabbitMQ

RabbitMQ 依赖 Erlang,需要先编译 Erlang:

1. 编译 Erlang(OTP 26+)
   → ./configure --prefix=/usr/local/erlang
   → make -j$(nproc) && make install

2. 编译 RabbitMQ
   → 使用 Erlang 编译 RabbitMQ 源码
   → 或者使用 generic-unix 包(Erlang 字节码,架构无关)

5.6 编译通用踩坑总结

申威平台编译的通用问题:

1. configure 脚本不认识 sw64
   → export HOSTTYPE=sw64
   → 或手动指定 --host=sw64-linux-gnu

2. 汇编代码不兼容
   → 禁用汇编优化:--without-asm 或 CFLAGS="-O2 -no-asm"

3. 原子操作/内存屏障
   → 使用 GCC 内建函数:__sync_* 或 __atomic_*
   → SW64 支持这些内建函数

4. 时间函数/平台判断
   → 部分开源项目的架构分支没有覆盖 SW64
   → 优先使用 CLOCK_MONOTONIC,并补齐 __sw_64__ 等平台判断

5. 网络字节序
   → SW64 常见环境为小端序(Little Endian),与 x86 一致
   → 写网络协议仍按规范使用 htonl/ntohl,不要依赖本机字节序偷懒

六、信创项目常见架构方案

6.1 典型信创架构

flowchart TB Client["业务流量"] --> LB["负载均衡与健康检查"] LB --> A1["应用实例 1"] LB --> A2["应用实例 2"] LB --> A3["应用实例 3"] A1 --> Nacos["Nacos 注册与配置"] A2 --> Nacos A3 --> Nacos A1 --> Redis["Redis 高可用部署"] A2 --> Redis A3 --> Redis A1 --> MQ["消息队列集群"] A2 --> MQ A3 --> MQ A1 --> DB["达梦主备或 DSC"] A2 --> DB A3 --> DB Ops["监控、日志、备份与演练"] -.观测.-> LB Ops -.观测.-> Nacos Ops -.观测.-> Redis Ops -.观测.-> MQ Ops -.观测.-> DB

6.2 Java 项目信创适配清单

代码层面:
  □ JDBC 驱动替换(Oracle → 达梦/金仓)
  □ 分页语法适配(ROWNUM / LIMIT / OFFSET 按目标库兼容模式调整)
  □ 序列语法适配
  □ 字段类型映射
  □ 存储过程改写(如有)
  □ 国密算法集成(SM2/SM3/SM4)
  □ 硬编码路径检查(/usr/local → 变量化)

中间件层面:
  □ Tomcat → 东方通 TongWeb(可选)
  □ Nacos 编译部署
  □ Redis 编译部署
  □ MQ 编译部署

运维层面:
  □ Docker 镜像编译
  □ CI/CD 流水线适配
  □ 监控工具适配
  □ 日志采集适配

七、参考资料


八、落地前需要复核的资料

⚠️ 以下内容基于公开资料整理,落地采购和验收前应以厂商资料、招标技术规范书和安全可靠测评公告为准:

  1. 申威 HX 系列的具体参数(核心数、主频、功耗)
  2. 申威 SW1621/SW3231的精确主频和 SPEC CPU 跑分
  3. 龙芯 3C6000/3B6000的核心数和主频
  4. 申威平台 OpenJDK的当前公开支持版本
  5. 申威 Docker 基础镜像的获取渠道(通常从麒麟/统信厂商获取)

如有补充或纠正,欢迎留言交流。