07 行业落地与工程迁移方法论

本文回答：各行业替到哪一步了、有哪些可参照的公开案例；一个信创迁移项目应该分几阶段推进、每阶段的门禁是什么；Java / Spring Boot + MyBatis + PageHelper + Redis + MySQL/MongoDB 技术栈具体要改什么。

前置依赖：05 基础软件、06 安全合规。后续：09 风险挑战、10 决策建议

说明：文中出现的配置示例均为示意，采用 application.yml + 环境变量占位，不硬编码连接信息；实际以项目现有配置规范与厂商驱动文档为准。

1. 「2+8+N」行业进度：多源对照

口径警告：下表渗透率来自不同机构、不同分母（系统数量 / 采购金额 / 终端台数 / 核心系统占比），只能判断梯队顺序，不能横向相减或求平均。

可核查的结构性判断（比具体百分比更可靠）：

1. 从外围到核心：OA/门户/邮件 → 经营管理 → 数据分析平台 → 核心交易/账务/调度，风险与工期逐级上升。
2. 从硬到软：硬件替代占比由 2022 年约 68% 降至 2025 年约 52%，软件与服务占比上升〔B，信通院白皮书转述〕。
3. 从合规到价值：行业观察认为政策重点从「替代比例」转向「替代质量」（性能不低于原系统、安全合规不打折扣）〔C〕。

2. 行业案例库（按可借鉴点组织）

案例数据均为厂商/行业媒体公开披露口径〔B/C〕，存在幸存者偏差，用于说明「可行路径」，不作为性能承诺或成本基准。完整数据库与电信案例清单见 05 §2.4。

三条共性经验：

• 兼容性预检先行，而不是「装新系统导数据」。
• 双轨并行 + 秒级回退是高风险核心系统的安全阀，不是保守。
• 冷/热数据分层 + 数据关联图 + 逐批演练，比一次性全量导出导入可靠得多。

3. 迁移方法论：六阶段 + 门禁（全站唯一阶段主表）

口径声明（v1.1）：本章 S0—S5 是全站唯一的迁移阶段划分与门禁定义。02 §6、06 §7、09 §9 是同一 S 阶段下的合规材料 / 风险动作清单，不另立阶段；10 §6 的 W1—W13 是 S0—S5 的周计划时间展开，同样不是独立阶段口径。

S0 摸底评估  →  S1 环境验证  →  S2 代码与 SQL 适配
    →  S3 数据迁移与双轨并行  →  S4 灰度切换与回退演练
    →  S5 验收与持续运维

S0 摸底评估

门禁 S0：依赖矩阵中不存在「无对应架构版本且无替代方案」的硬阻塞项；性能基线经业务方签字。

S1 环境验证

• 搭建与生产 1:1 的国产化测试环境（同 CPU 型号、同 OS 与内核版本、同数据库大版本、同中间件版本）。
• 至少跑 2—3 周冒烟测试，验证三件事：应用能否启动、常用外设能否识别、压测结果是否达到原系统基线的约定比例。
• 行业经验值常引用「性能达到原系统 80% 以上」或「与 x86 基线差距控制在 15%—20% 以内」〔C，技术博客/实施方经验，非国家标准〕。项目应在合同中自行约定阈值，不要引用行业经验值当验收标准。
• 执行 uname -m、file $(which java) 确认架构确实切换，避免「在同一架构上做了一周迁移」。

门禁 S1：1:1 环境跑通核心流程；适配问题清单已建立并分派责任；性能对比报告出具（含差异说明，不回避差距）。

S2 代码与 SQL 适配

高发问题清单（详见 §5 Java 专项）：

门禁 S2：适配问题跟踪表（现象 → 定位 → 方案 → 回归结果）全部闭环；全量回归测试通过。

S3 数据迁移与双轨并行

• 原则：先备份、再迁移、多校验；全量 + 增量同步；冷数据一次性导入、热数据分批。
• 校验三层：行数比对 → 抽样比对 → 字段级/业务逻辑比对；核心系统建议字段级每日比对，差异归零才准切换。
• 双轨：新旧库实时同步，新环境并行运行（案例周期从两周到三个月不等），持续观测同步延迟与错误日志。
• 不要忽略 DDL 同步：源端表结构变更常是盲点，需确认同步工具对特定 DDL 的支持范围。
• 高频 TOP SQL 在迁移前做语法优化，迁移后继续观测资源占用与慢事务。

门禁 S3：数据一致性差异归零；同步延迟在约定阈值内；回退脚本演练成功。

S4 灰度切换与回退

• 流量顺序：先查询后写入，先非核心后核心，先单部门试点后全量。
• 双轨期间新旧两套并行录入或实时同步比对，周期通常 1—2 周起，核心系统更长。
• 回退通道全程开放，老环境完整待命（案例建议两周），严禁为腾机柜提前关闭旧环境。
• 切换窗口选业务低峰；准备一键回滚脚本与决策人。

门禁 S4：灰度各阶段无 P0/P1 缺陷；回退演练在真实数据规模下成功。

S5 验收与运维

• 交付：适配问题清单及解法、性能基线对比、安全测评报告、试运行报告（含适配调优专项）、运维培训记录、声明函与证书归档。
• 持续：三级等保每年测评、密评每年至少一次、测评证书三年到期预警、SBOM 与漏洞治理、版本升级后重测适配。
• 迁移工具导出的中间数据用完即毁，并留存销毁记录。

门禁 S5：全部合规材料齐备并与 06 §7 清单逐项勾对。

4. 六层适配检查单（可直接用于项目自查）

5. Java / Spring Boot 技术栈专项

针对 Spring Boot + MyBatis + PageHelper + Redis + MySQL/MongoDB 这一典型栈，给出逐层改造点与验收动作。这是全站与工程实践最贴合的一节。

5.1 为什么 Java 栈相对好迁

JVM 字节码屏蔽了大部分指令集差异，纯 Java 应用的核心代码通常无需修改。因此「信创迁移 = 改 Java 业务代码」是错误认知。工作量分布的经验判断：数据库方言与 SQL 改写占比最高，其次是闭源依赖与控件、中间件配置、OS/驱动，最后才是 CPU 架构本身〔C，多篇迁移实践一致〕。

反过来也要警惕：正因为「Java 天然跨平台」的说法流行，团队容易漏查 native 依赖（Netty 的 netty-transport-native-epoll、JNI 库、APM Agent、加密 UKey 驱动、lib 字体库），这些才是启动失败或性能骤降的高频根因。

5.2 JDK 选型与验证矩阵

四个隐形杀手〔C，迁移实践共性〕：

1. JCE 无限制强度策略：部分 Java 8 国产发行版默认关闭 unlimited policy，使用 AES-256 时抛 Illegal key size。检查 $JAVA_HOME/jre/lib/security/java.security 中 crypto.policy=unlimited。
2. SecureRandom 阻塞：国产服务器熵源不足时，/dev/random 会导致启动卡住数分钟、加密性能骤降；需评估 securerandom.source 与熵源服务。
3. 字符集与时区：国产 OS 默认 locale 未必 UTF-8，中文乱码与 8 小时时差高发。JDK 18+ 起 JEP 400 已默认 UTF-8，Java 8/11 发行版仍需显式确认 -Dfile.encoding；sun.jnu.encoding 是 JVM 依据平台 locale 推导的只读系统属性，用 -D 指定通常不生效，不应列为必选启动参数。最小启动参数示例：

      java -XX:+UseG1GC \
           -Dfile.encoding=UTF-8 \
           -Duser.timezone=Asia/Shanghai \
           -jar app.jar

4. GC 参数不可移植：x86 上调优过的 CMS/G1 参数不是可移植资产；ARM 多核场景需重新评估 G1/ZGC 与堆分代比例，并按 TPS/P99 重测。

版本矩阵风险：Spring Boot 2.1.x 属 Java 8 时代、javax.* 命名空间。若外置到国产应用服务器，需核对其支持的 Servlet / Java EE 版本；若保留 Spring Boot 内嵌容器，则改动最小。JDBC 驱动对高版本 JDK 的支持常滞后（早期达梦驱动在 JDK 17+ 撞过模块化反射限制），因此「文档写支持」不等于「组合可用」，必须用实际驱动版本 × 目标 JDK × 目标架构压测。

5.3 Spring Boot 配置改造（yml 示意）

spring:
  datasource:
    driver-class-name: ${XC_JDBC_DRIVER}     # 例：dm.jdbc.driver.DmDriver / com.kingbase8.Driver
    url: ${XC_JDBC_URL}
    username: ${XC_DB_USER}
    password: ${XC_DB_PASSWORD}
    hikari:
      maximum-pool-size: ${XC_POOL_MAX:20}
      connection-test-query: ${XC_TEST_QUERY}
  redis:
    host: ${XC_CACHE_HOST}
    port: ${XC_CACHE_PORT}
    password: ${XC_CACHE_PASSWORD}
  data:
    mongodb:
      uri: ${XC_MONGO_URI}

pagehelper:
  helper-dialect: ${XC_PAGE_DIALECT}        # 见 5.4
  reasonable: "true"
  support-methods-arguments: "true"

要点：

• 禁止硬编码连接信息、驱动类名、方言；全部通过配置/环境变量注入，便于一套代码在 x86 与信创双环境并行。
• 建议用 Spring Profile（application-xinchuang.yml）隔离差异，避免为迁移拉分支。
• connection-test-query 需按目标库调整（部分国产库不支持 SELECT 1 的写法或需要 FROM DUAL）。
• 连接池参数（最小/最大、超时、验证间隔）需按国产库的连接建立成本重新压测，不能沿用 MySQL 经验值。

5.4 MyBatis / PageHelper 与 SQL 方言

PageHelper 方言：需确认项目所用 PageHelper 版本是否内置目标数据库方言（常见发行版内置部分国产库方言标识）；若不支持，应通过 PageHelper 的自定义 Dialect 扩展或改用显式物理分页，而不是在 XML 里散落 LIMIT/? 硬编码。切换方言后必须对每个分页查询做边界回归（首页/末页/空结果/排序/总数）。

MyBatis 层改造清单：

Hibernate/JPA（若项目使用）：需引入厂商提供的 Dialect 类或社区实现，并核对 DDL 自动生成、序列生成策略与分页 SQL。

5.5 中间件替换

5.6 Redis 与 MongoDB 的替代路径

判断原则：许可证允许商用、纯 Java/无 native 依赖、可自行编译的组件优先保留（「开源」需按当前许可证核对，不能沿用历史称谓）；把改造预算集中在被招标或合规明确点名的层，以及确实无法获得目标架构版本的闭源组件。

5.7 国密改造

注意：国密改造属于密评范畴，不是「信创适配」的副产品；应在立项阶段单列工作包与预算（见 06 §3）。

5.8 构建、镜像与 CI

• 多架构镜像：docker buildx + manifest list，分别为 linux/amd64、linux/arm64（必要时 linux/loong64）构建；容器平台标识用 Go/Docker 的 loong64，不是 uname -m 的 loongarch64，写错会导致 manifest 不被识别、拉取失败。基础镜像中的 JDK、glibc、字体、CA 证书、时区数据需逐架构对齐。
• CI：增加目标架构构建节点（或交叉编译 + QEMU），并在流水线中加入「目标架构启动冒烟测试」。
• 依赖仓库：配置国产 Maven/Gradle 镜像；核对私有二方包是否含 native 依赖。
• 监控/APM：确认 Agent 有目标架构版本，否则上线后将出现「应用正常但无可观测性」。

5.9 Java 栈迁移验收清单（20 项）

1. uname -m 与 file $(which java) 输出符合预期架构
2. JDK 发行版、版本与 crypto.policy 已核对
3. 启动参数含 UTF-8 字符集与 Asia/Shanghai 时区
4. SecureRandom 无阻塞，启动耗时在基线内
5. GC 策略已按目标架构重测（TPS/P99 对比报告）
6. 全量第三方 jar 与 native 库完成架构盘点
7. 监控/APM/日志 Agent 有对应架构版本
8. JDBC 驱动版本 × JDK 版本 × 架构 组合压测通过
9. 数据源配置全部外置到 yml / 环境变量，无硬编码
10. connection-test-query 在目标库可用
11. 连接池参数按目标库重压测
12. PageHelper 方言已确认并覆盖所有分页查询回归
13. 全量 SQL 已扫描：分页/序列/函数/递归/隐式转换/保留字
14. 存储过程、触发器、包体逐个改写并回归
15. 高频 TOP SQL 按新执行计划重调索引
16. 应用服务器（如替换）部署描述符与命名空间核对完成
17. 缓存/消息/文档库客户端 SDK 兼容性与协议回归完成
18. 国密算法与 TLCP 链路通过密评相关验证
19. 多架构镜像、CI 构建与启动冒烟测试通过
20. 双轨并行数据比对差异归零、回退脚本演练成功

6. 工期与成本的主要变量

7. 本章小结

• 行业进度呈「党政先行 → 金融/电信/电力攻坚 → 医疗教育起步」的梯队，但渗透率数字口径混乱，只看梯队顺序不看绝对值。
• 可复用的成功路径是：预检先行、1:1 环境、双轨并行、字段级比对、灰度切换、回退通道全程开放。
• 六阶段各有明确门禁，且为全站唯一阶段口径（§3）；任何阶段跳过门禁，问题都会在切换当晚集中爆发。
• Java 栈的改造重点不在 CPU 而在 SQL 方言、闭源 native 依赖、中间件配置、国密与多架构构建；纯 Java/开源组件优先保留。
• 性能验收阈值应由项目自行约定并写入合同，不引用「行业经验值」当标准；所有案例数据仅作可行性证据。