引言：为什么“把.NET换成Java”这件事被我们想简单了

2025年初，宏远培训考试系统的一个能源行业客户提出了明确需求：系统需要部署在国产化服务器环境中，操作系统从Windows Server迁移到麒麟、龙蜥等国产化环境，数据库从SQL Server迁移到达梦、人大金仓等国产数据库。

这个需求看起来只是一个“环境替换”问题，但当我们真正启动项目时才发现，我们面对的并不是一次普通的版本迭代，而是一次完整的业务系统迁移。

彼时，宏远培训考试系统的早期版本已经运行八年以上，底层技术体系采用.NET + Windows + SQL Server。系统中积累了几万名学员的人员数据、数万道试题、几百场历史考试的答卷和成绩记录，还有大量已经归档的培训证书、培训档案和操作日志。

旧系统不是一个可以“关掉重来”的空壳，而是承载着客户多年培训、学习、考试和档案管理业务的数据资产。

更关键的是，客户的使用场景也在发生变化。

考试系统与普通办公系统不同，其流量往往具有明显的脉冲特征。正式开考时，大量考生可能在很短时间内集中登录、获取试卷、保存答案和提交试卷。

例如5000人同时在线考试，开考前30秒产生的系统访问压力，可能是平时业务访问量的数十倍甚至上百倍。

旧版.NET单体架构在原有Windows环境下能够满足此前的使用要求，但当服务器、操作系统、数据库逐步迁移至国产化环境之后，数据库连接池、SQL查询、缓存机制、静态资源分发、服务扩容等环节都需要重新设计和验证。

这也是宏远培训考试系统决定进行架构升级的真正起点：不是因为.NET本身存在问题，而是原有技术架构已经越来越难同时满足国产化部署、高并发考试、移动端应用以及第三方系统集成等新的业务要求。

一、迁移的第一原则：这不是代码翻译

项目启动初期，团队内部曾经出现过一种看似简单的思路：

“把.NET的Controller、Service、DAL分别改写成Java的Controller、Service、Mapper，是不是就可以了？”

我们用了大约两周时间进行技术验证，最终得出的结论非常明确：

如果只是按照原来的系统结构重新写一遍，最终得到的只会是一个“Java版本的旧系统”。

旧系统真正需要解决的问题，并不是使用什么编程语言，而是原有架构中存在的耦合问题。

在传统架构中，浏览器直接访问.NET Web应用，页面、业务逻辑和数据访问之间耦合较深。随着移动端、小程序以及第三方业务系统逐渐增加，每增加一种终端，都可能需要重新进行接口适配。

因此，这次迁移最终确定的原则是：

保留有价值的数据和成熟的业务规则，重新设计已经不适合继续扩展的技术实现。

新的宏远培训考试系统采用前后端分离架构：

前端：PC端、移动端、小程序统一通过API接口调用后台服务。

后端：采用Java技术体系，根据业务需要对用户、课程、培训、考试等核心模块进行服务化拆分。

部署：全面支持Linux服务器环境，并逐步适配国产操作系统、国产数据库及相关基础软件。

这一架构决策，也决定了后续整个迁移项目中技术方案的主要方向。

二、数据库迁移：真正难的是“业务语义”

数据库迁移，是整个升级过程中工作量最大、验证周期最长的环节之一。

表面上看，从SQL Server迁移至达梦、人大金仓等国产数据库，无非是字段类型、函数、存储过程、SQL语法之间的适配。

但真正实施以后我们发现，数据库迁移最难的并不是字段怎么转换，而是如何完整保留旧系统中的“业务语义”。

1.人员数据不能简单按照登录名迁移

旧系统早期的人员设计中，很多业务关系与登录名存在较深关联。

但随着系统规模不断扩大，登录名已经不适合作为稳定的业务身份标识。

新系统要求每名人员拥有独立且不可变的内部ID，而登录名、工号等信息仅作为人员属性存在，可以根据管理要求进行修改。

因此，在数据迁移过程中，不能简单地把人员表直接导入新数据库，而是必须重新建立人员ID映射关系，并同步修复考试记录、培训记录、证书、档案等相关业务表中的人员关联关系。

这类数据如果处理不完整，表面上看人员数量可能完全一致，但进入历史成绩、考试档案或证书记录后，就可能出现“人员存在、历史记录找不到”的问题。

2.历史试卷不能只迁移当前题库

这是考试系统数据迁移过程中最容易被低估的问题之一。

部分旧系统中的试卷保存的是抽题规则，而不是每一次考试最终生成的完整题目内容。

但一场考试一旦结束，其试卷内容实际上已经成为历史业务凭证。

如果迁移时只保留当前题库，而没有保存历史考试时实际使用的题目，那么一旦后续题库发生修改、删除或题目内容调整，历史考试就可能无法完整还原。

因此，我们最终采用的策略是：

当前题库按照最新业务规则进行迁移；

已经完成的历史考试按照试卷快照进行固化迁移。

通过这种方式，即使未来题库继续调整，也不会影响过去某一场考试的试卷、答题记录和成绩追溯。

对于培训考试系统而言，历史试卷不是普通业务数据，而是考试全过程留痕的重要组成部分。

3.密码迁移是最容易被忽略的一块

旧系统和新系统采用的密码存储及加密机制不同，如果简单迁移原密码哈希值，很可能出现数据库迁移完成后所有用户无法正常登录的问题。

为了尽可能减少升级过程对用户的影响，我们没有采用统一重置密码的方式，而是设计了兼容过渡机制。

旧系统密码哈希暂时保存在迁移字段中，用户第一次登录新系统时，后台首先使用旧规则完成校验。验证通过以后，再自动按照新系统的安全策略重新生成密码哈希。

这样可以在用户基本无感知的情况下，逐步完成密码机制升级。

4.国产数据库环境下，连接池需要重新调优

从SQL Server切换到达梦、人大金仓等国产数据库以后，我们还遇到了一个比数据转换更隐蔽的问题：数据库连接管理。

不同数据库在连接建立、连接保持、连接释放以及并发处理方面的策略存在差异。

以KingbaseES等国产数据库环境为例，在实际优化过程中，我们发现数据库连接池的idle-timeout、maximum-pool-size等参数必须结合国产CPU、数据库以及考试业务的访问特点重新调整。

在传统x86 + SQL Server或MySQL环境中并不明显的参数差异，在国产CPU + 国产数据库环境下，可能直接影响集中登录和集中交卷阶段的响应速度。

经过多轮压测和参数优化后，在5000并发登录测试场景下，连接超时率由迁移初期约8%逐步下降至0.3%以下。

这也让我们更加明确：信创迁移绝不是把数据库安装完成就算结束，真正的国产化适配还需要大量性能测试和参数调优。

三、接口兼容：API版本管理从迁移阶段就要开始

培训考试系统通常不会独立存在。

很多大型企业和集团客户已经建设了OA、HR、人力资源、统一身份认证、数据中台等业务系统。

旧版宏远培训考试系统中，也存在大量已经被其他业务系统调用的接口，例如：

OA系统同步人员信息；

HR系统同步组织机构；

统一身份平台进行用户认证；

数据中台获取考试成绩；

第三方业务平台获取培训记录。

这些接口不可能在新系统上线的同一天全部完成改造。

因此，我们在迁移初期就确定了API版本管理方案。

旧系统接口以v1版本继续提供兼容能力，新系统按照新的接口规范提供v2版本。

在一段时间内，两套接口可以并行运行，由客户根据OA、HR、数据中台等外围系统的改造进度逐步切换。

这种方案的优势是，培训考试系统本身的升级不会因为某一个外部系统暂时无法改造而被整体卡住。

接口并行运行也带来了新的问题：新旧系统的数据必须保持同步。

为此，我们在迁移阶段设计了数据同步机制。

新系统产生关键业务数据后，通过消息机制将相关变更同步至兼容层，使旧接口在过渡阶段仍然能够获取到需要的数据。

事实证明，这套方案在灰度迁移阶段发挥了非常重要的作用。

四、灰度切换：最危险的方式是“周五晚上直接关旧系统”

在一些系统升级项目中，经常会出现一种做法：

选择周五晚上关闭旧系统，周末迁移数据，周一早上直接启用新系统。

对于培训考试系统来说，这种方式风险很高。

因为一旦历史成绩、人员映射、试卷记录或第三方接口出现问题，正式考试业务很可能受到直接影响。

因此，我们将整个切换过程划分为三个阶段。

第一阶段：迁移测试库，不影响正式系统

首先在独立测试环境中完成全量数据迁移。

这个阶段重点验证：

人员数量是否一致；

组织架构是否一致；

题库数量是否一致；

历史考试能否正常打开；

历史试卷能否完整还原；

成绩统计是否一致；

证书和培训档案是否能够正常查询；

人员与历史业务数据之间的关联是否正确。

这个阶段发现了大量“看起来相同，但业务含义并不完全相同”的问题。

例如，一些早期考试中的成绩计算规则，与新系统默认计算规则存在细微差异。如果不进行专项兼容，最终统计结果就可能出现偏差。

第二阶段：新系统进入真实业务验证

完成数据验证之后，选择少量非关键业务单位首先使用新系统。

此时旧系统仍然保留运行能力。

这个阶段重点验证的不是“有没有这个功能”，而是系统在真实业务环境中的稳定性。

主要验证场景包括：

大规模人员登录；

批量获取试卷；

考试过程自动保存；

集中交卷；

成绩统计；

大批量成绩导出；

移动端访问；

第三方接口调用。

特别是在培训考试场景中，平时运行正常并不意味着正式考试时一定稳定。

真正需要关注的是开考前后的瞬时流量，以及考试结束前集中交卷形成的并发峰值。

第三阶段：冻结旧系统写入，完成增量数据迁移

正式切换前，首先停止旧系统产生新的业务数据。

然后将测试迁移完成之后新增的人员、考试、成绩、培训记录等增量数据再次迁入新系统。

完成最终数据对齐以后，再正式切换业务入口。

与此同时，我们提前设计了回退方案。

正式切换后的前两周，旧系统仍然保留只读访问能力。

如果新系统出现影响核心业务的严重问题，可以根据预案恢复相关业务访问。

最终这个回退方案并没有真正启用，但它降低了系统升级过程中的业务风险，也增强了客户和项目团队推进正式切换的信心。

五、迁移后的实际效果

此次架构升级从2025年初逐步启动，到2026年9月完成主要客户环境的迁移及国产化适配工作，前后经历约500天。

整个升级带来的变化，可以概括为三个方面。

1.部署能力进一步扩展

旧版本主要运行在Windows Server + SQL Server环境。

完成Java架构升级以后，宏远培训考试系统逐步支持Linux环境，并完成对麒麟、龙蜥等操作系统以及达梦、人大金仓、海量数据库等国产数据库环境的适配。

2026年9月，宏远智诚与海量数据完成产品兼容互认证，Vastbase G100作为国产企业级关系型数据库，为信创环境下的培训考试系统提供了新的数据库部署选择。

目前，系统正在持续完善芯片、服务器、操作系统、数据库、中间件、浏览器等不同技术环境之间的兼容适配能力，为国企、能源、煤矿、电力、政务等客户提供更加灵活的私有化和国产化部署方案。

2.高并发考试场景的性能得到提升

新架构将用户、课程、培训、考试等核心业务进行服务化设计，不同业务模块可以根据压力情况独立进行资源扩展。

针对5000人集中登录、集中交卷等考试场景，我们重点重新设计了：

数据库连接池；

缓存策略；

接口调用机制；

试卷数据加载；

答案自动保存；

集中交卷处理；

静态资源访问。

在5000并发登录测试和实际业务验证过程中，通过数据库连接池和缓存策略持续优化，连接超时率由迁移初期约8%下降至0.3%以下。

对考试系统而言，真正需要解决的不是“平时访问快不快”，而是在几千人同时操作时，系统是否依然能够保持稳定。

3.技术生态更加开放

前后端分离以后，同一套Java后台服务可以同时支撑PC端、移动端、小程序以及第三方业务系统。

人员、组织、课程、培训、考试和成绩等数据通过标准API进行统一管理。

客户原有的OA、HR、人力资源平台、统一身份认证以及数据中台，可以按照标准接口逐步与培训考试系统进行数据互通。

这也为后续进一步建设统一学习平台、人才画像、岗位胜任力分析以及培训数据分析提供了更加稳定的数据基础。

写在最后

500天的迁移过程中，我们最深的体会是：

系统迁移真正迁移的，不只是代码，而是“业务连续性”。

人员ID映射、历史试卷快照、密码平滑迁移、旧接口并行运行、数据库参数调优、灰度切换以及回退窗口，这些看似技术层面的方案，最终解决的其实都是同一个问题：

让客户在系统升级过程中尽可能做到不丢数据、不中断业务，并且让多年积累的培训、考试和档案数据继续发挥价值。

对于正在考虑培训考试系统信创迁移、国产化替代或者架构升级的企业，我们有三点经验可以分享。

第一，不要为了追求迁移速度而忽略灰度切换。

正式系统中存在大量真实业务数据，尤其是人员、试题、考试、成绩、证书和档案。相比一次性快速切换，分阶段验证和保留回退窗口更加重要。

第二，数据库迁移的重点不是字段，而是业务语义。

人员身份、试卷快照、历史成绩、证书归属、培训记录等业务关系，需要进行逐项验证。数据数量一致，并不等于业务数据真正迁移成功。

第三，接口兼容必须从迁移开始就进行规划。

大型企业的信息系统往往彼此关联，培训考试系统很可能已经与OA、HR、统一认证、数据中台等多个系统完成对接。API版本管理和新旧接口兼容，不应该等系统上线前再考虑。

目前，宏远培训考试系统的Java架构升级已经基本完成，但国产化适配和技术演进仍将持续。

未来，我们还将继续推进与国产操作系统、国产数据库、中间件以及相关信创软硬件生态的兼容适配，同时持续优化大规模在线考试、集中交卷、移动端局域网考试以及高并发访问场景下的系统性能。

如果企业正在评估培训考试系统国产化替代、信创迁移、.NET系统升级Java或者历史数据迁移方案，可以结合现有系统架构、人员规模、考试并发量、数据库类型以及第三方接口情况，制定适合自身业务的迁移路径。