信创项目越来越多，但很多团队对「信创改造」的理解还停留在「数据库换成达梦、服务器换成鲲鹏」。真做起来会发现，麻烦的不是换，是换完之后跑不动、或者生态里根本没有对应组件。
这篇按六类组件拆开讲，每类说清换什么、难在哪、成本多少。
六类组件替换
一、芯片与服务器
从 x86（Intel/AMD）换到 ARM（鲲鹏、飞腾）或自主架构（龙芯、海光）。
难点在依赖编译。所有带原生扩展的组件都要重新编译：Node.js 的 native 模块、Python 的 C 扩展、Java 的 JNI 库。物联网平台常有的图像处理库（OpenCV）、视频解码库（FFmpeg）、加密库，都要在目标架构上重新编译并验证。
实测数据：一个中等规模平台在鲲鹏上迁移，纯编译适配的工作量约 2-4 周，性能调优再 2-4 周。
性能方面，ARM 在多核并发上表现不错，但单核性能和某些向量运算弱于 x86。视频解码、加密运算这类吃单核和 SIMD 的场景，性能可能下降 20-40%。要提前做压测，别等上线才发现扛不住。
二、操作系统
CentOS/Ubuntu → 麒麟（Kylin）、统信 UOS、openEuler。
相对简单，但要注意：系统自带的内核版本、glibc 版本、包管理器不同。Docker 镜像要重新构建基础镜像，systemd 服务配置要调整，SELinux/AppArmor 策略要重写。
常见坑：某些国产系统的默认内核参数（文件句柄数、网络缓冲区）比 CentOS 保守，高并发场景下会先撞到这些限制。要按业务实测调整，不能照搬原来的调优参数。
三、数据库
MySQL → 达梦、人大金仓、OceanBase、TDSQL；PostgreSQL → 高斯、瀚高。
这是改造中最重的一块。三类问题：
- SQL 语法差异：分页（LIMIT vs ROWNUM）、字符串拼接、日期函数、正则、窗口函数支持度。一个几千行的业务系统，SQL 改写的工作量通常 3-8 周。
- 数据类型差异：JSON 字段、数组、枚举、大对象。国产库对 JSON 的支持程度不一，很多地方要拆成关系表。
- 驱动和 ORM：MyBatis/JPA 的方言适配、连接池参数、事务隔离级别行为差异。
特别提醒时序数据库。物联网平台的设备数据量最大，原来用 InfluxDB、TimescaleDB、TDengine。信创目录里可选的很少，TDengine 是国产的（相对好办），InfluxDB 没有国产替代。常见做法是换到国产关系库的分区表 + 压缩，或者用国产时序库（如 IoTDB，Apache 顶级项目、国产团队主导）。性能要重新验证，压缩比和查询延迟可能差一倍。
四、中间件
消息队列（Kafka/RabbitMQ → 国产 MQ 或 RocketMQ）、缓存（Redis → 国产缓存）、Web 服务器（Nginx → 国产化版本或 Tengine）。
Kafka 的国产替代是难点，很多信创目录里没有对等产品。RocketMQ 是 Apache 项目但有国内主导，通常可作为替代。迁移时要注意消息语义（至少一次 vs 精确一次）、分区策略、消费组重平衡行为都不同，物联网的海量设备消息场景要重新压测。
五、浏览器与客户端
前端要兼容国产浏览器（奇安信、360 政企、红莲花等）。这些浏览器大多基于 Chromium，但版本可能落后 2-3 年。
影响：新语法（如可选链、顶层 await）可能不支持，某些 CSS 特性（container queries、:has）不可用。要用较低的编译目标（ES2018）并做真机测试。
另外大屏项目要注意：国产系统上的显卡驱动和硬件加速支持有限，WebGL 三维场景可能跑不起来或帧率很低。这类项目建议提前在目标环境做 POC。
六、密码算法
从 AES/RSA/SHA 换到国密 SM2/SM3/SM4。三级等保和信创项目通常都要求。
涉及：HTTPS 证书（SM2 证书）、数据加密存储（SM4）、签名验签（SM2）、摘要（SM3）。
难点在设备侧。存量设备基本不支持国密，要么在网关做转换（网关支持国密，对内网设备用原协议），要么设备整体替换。这是信创改造里最容易被忽略、也最花钱的部分。
成本：原项目的 30-150%
| 改造范围 | 成本占比 | 周期 |
|---|---|---|
| 仅服务器 + 操作系统 | 10-25% | 1-2 个月 |
| + 数据库 | 30-60% | 3-5 个月 |
| + 中间件 | 50-90% | 4-6 个月 |
| 全量（含设备侧国密） | 80-150% | 6-12 个月 |
这里的「成本占比」是相对原项目软件合同额。一个 200 万的平台，全量信创改造要再投 160-300 万。
新建项目做信创，增量成本能控制在 20-40%（因为设计阶段就按国产组件选型，不用返工）。所以如果预判项目后续要过信创审查，一开始就按信创栈设计，别等做完再改。
三个不能踩的坑
坑一：性能断崖，上线才发现
国产数据库在复杂查询、大表关联上的性能可能只有 MySQL 的 50-70%，国产时序方案在压缩比和聚合查询上也可能明显落后。
做法：迁移前用真实数据量做基准测试（不是 1000 条测试数据，是至少 1 亿条设备记录）。关键 SQL 逐条对比执行计划。压测报告要作为验收材料。
坑二：生态缺失，某个组件根本没有替代品
典型的：某些地理信息引擎、视频分析算法库、特定的消息协议栈。这些在信创目录里找不到对应产品。
做法：先做组件清点。把技术栈列全，逐个在信创目录里查有没有对应产品，标出「有替代 / 有但功能不全 / 无替代」。无替代的提前和甲方沟通，争取豁免或换方案，别做到一半才发现。
坑三：只改一半，混合环境更难维护
常见情况：服务器换了国产，数据库还是 MySQL；或者主库换了达梦，从库和备份还是 MySQL。混合环境看着省事，实际运维复杂度翻倍，而且过不了审查。
做法：一次改到底，或者明确分期边界（比如第一期只改应用层，数据层不动，但要在合同里写清第二期的时间和预算）。
下一步
信创改造本质是一次技术栈迁移，方法论和平台自建还是买里的评估逻辑相通。要了解合规侧的要求，看等保 2.0 的十二个必改项。
要按改造范围估算投入，用物联网项目报价测算器，把「信创适配」作为单独条目列进去。行业侧看智慧校园和智慧水务，这两个领域的信创要求最明确。