1. 从一次真实的OA替换项目说起去年下半年我参与了一个集团型企业的OA办公系统整体迁移项目。这个项目的核心诉求很直接原有的OA系统跑在x86服务器加国外商业数据库、国外中间件的技术栈上现在要把整套底座换成自主可控的技术路线——国产芯片、国产操作系统、国产数据库、国产中间件、国产浏览器。项目涉及的用户量大概在两万人左右日均流程实例三万多条公文流转、审批、会议、档案这些模块一个都不能少。这类项目最近两年特别多。很多做企业信息化的同行都在问同一个问题OA这种看起来没啥技术含量的系统为什么一换底座就浑身是坑答案其实不复杂。OA系统是典型的历史包袱重、技术栈老、集成面广的应用。它不像一个新建的互联网应用可以随便挑技术栈它往往已经运行了七八年甚至十几年代码里塞满了各种定制化的报表、插件、ActiveX控件、老版本框架。你动它的底座等于给一个跑了十几年的老车换发动机还得保证它照样能上高速。这篇文章我想聊的不是政策解读那个层面有很多官方渠道说得比我清楚。我更想从一个技术落地者的角度把这套事情拆开讲信创环境下OA系统到底要做哪些适配、技术选型怎么权衡、迁移过程里那些真正会卡住你的点在哪、有没有可以少走弯路的经验。适合正在做或者准备做这类项目的技术负责人、架构师、运维同学参考也适合刚接触这个方向、想搞清楚信创适配到底要适配什么的人。全文不涉及任何具体的合规建议只讲技术实现层面我踩过的和见过的坑。信创这个词这几年出现频率很高配套的信创目录产品名单、信创产品目录最新版本也成了选型时大家反复查的东西。但目录只是起点真正难的是把目录里的产品组合成一个能稳定跑起来的系统。2. 信创OA的整体架构设计与选型思路2.1 为什么是全栈替换而不是局部替换很多刚接触这个方向的团队会有一个朴素的想法我就把数据库换掉行不行或者我只换操作系统行不行从技术上讲当然可以分步走但从项目实践看局部替换往往比全栈替换更痛苦。原因在于信创适配的难点不在单个组件的替换而在组件之间的兼容性缝隙。举个具体的例子。你把操作系统从CentOS换成麒麟如果JDK还是原来那个Oracle JDK中间件还是Tomcat数据库还是MySQL那大部分情况下确实能跑。但问题在于一旦你的芯片从x86换成了ARM架构或者LoongArch架构JDK就得换对应的版本Tomcat本身是Java的没大问题可你依赖的那些native库、加密卡驱动、打印控件驱动全都是按x86编译的这时候就开始连环出问题。与其一个一个去救火不如一次性把底座捋清楚做整体规划。我在实际项目里总结的经验是先确定芯片和操作系统的组合这是地基然后确定JDK和中间件这是承重墙再确定数据库和应用本身这是房间。地基一动上面的东西全都要重新评估。这个顺序不能反。全栈替换的另一个理由是运维统一。如果你搞成混合栈一半国产一半国外运维团队要维护两套知识体系出了问题排查链路特别长长期成本反而更高。2.2 选型要看哪几个维度选型这件事我见过太多团队只盯着是不是在信创目录里这一个维度结果选完发现性能扛不住、生态不成熟、社区没资料。我在项目里一般会从五个维度去评估按权重排序大概是这样的评估维度具体看什么权重建议兼容性与现有应用、框架、第三方组件的适配程度高稳定性生产环境实际运行案例、故障率口碑高性能同等硬件下的TPS、响应时间、并发承载中高生态与文档官方文档质量、社区活跃度、问题可搜索性中运维成本团队学习曲线、监控工具配套、备份恢复方案中兼容性排第一是有血的教训的。我见过一个项目选了一款比较新的国产数据库功能确实全但它的JDBC驱动和项目里用的老版本连接池有冲突连接泄漏问题查了整整两周。这种问题不是产品不好是组合不对。芯片层面目前主流的是ARM架构鲲鹏、飞腾和x86兼容架构海光、兆芯还有LoongArch龙芯。选哪个很大程度上取决于你的应用有没有native依赖、有没有历史编译产物。纯Java应用对架构不敏感但有C/C扩展的应用就要重点评估。操作系统层面麒麟和统信UOS是绕不开的两个选择服务器端的适配成熟度都还可以主要差异在具体版本的内核参数、软件源、以及和某些硬件的驱动适配情况。我一般的做法是拿一个真实的测试环境把要用的组合跑一遍压力测试别只看厂商的兼容性列表。中间件这块东方通TongWeb、宝兰德BES、金蝶Apusic都是常见选项功能上覆盖Tomcat/Jetty/WebLogic的主流场景迁移时主要是配置文件和部署方式的调整。2.3 容器化是不是必选项有个高频问题容器平台在信创环境下能不能用像KubeSphere这类平台有没有专门的信创适配版本实际答案是主流的容器平台本身是Go语言写的跨架构编译支持成熟在ARM和LoongArch上都能跑。真正的适配重点是底层的容器运行时、镜像仓库、以及网络和存储插件在国产操作系统上的兼容性。我的建议是如果你的团队本来就有容器化运维能力那信创环境下继续用容器是加分项因为容器能把应用依赖和操作系统差异隔离开迁移时改的是基础镜像而不是应用本身。但如果团队原来是纯物理机或虚拟机部署为了信创项目临时上容器反而会引入额外的复杂度。技术选型要跟着团队能力走不要为了技术先进性硬上。3. OA信创适配的核心技术点拆解3.1 芯片与操作系统层的适配细节这一层的适配对纯Java的OA应用来说大部分是无感的但有几个地方必须提前确认。第一是JDK的架构版本。Oracle JDK在很多架构上的支持已经受限实际项目里大家用的是OpenJDK系的各种发行版比如毕昇JDKARM架构优化好、龙井Dragonwell、以及龙芯自己的JDK。不同JDK发行版在垃圾回收器默认策略、JVM参数支持上有细微差别我之前遇到过一个性能问题就是新JDK默认的GC策略和老应用的内存模型不匹配导致Full GC频繁后来手动指定了G1参数才稳定下来。第二是native库的问题。老OA里常见的native依赖有加密卡驱动、PDF/OFD转换库、字体渲染库、图像处理库比如ImageMagick。这些都要重新找对应架构的版本。特别是字体国产操作系统自带的字体集和原来的可能不一样会导致公文排版错位这个坑非常隐蔽测试时一定要用真实公文模板验证。第三是操作系统的内核参数。麒麟和UOS的默认文件句柄数、TCP参数、共享内存配置和CentOS不完全一样。OA系统如果有大量文件上传下载、长连接建议按原系统的参数基线做对齐能省掉很多莫名其妙变慢的问题。3.2 数据库迁移最难啃的那块骨头数据库替换是整个项目里工作量最大、风险最高的环节。从MySQL或Oracle迁到国产数据库表面上是SQL语法差异实际上是整个数据访问层的重新验证。常见的坑我整理过一张对照表都是实际迁移中真会遇到的问题类型典型表现处理思路分页语法limit/rownum写法不兼容改写为国产库支持的分页方式或ORM层适配自增主键序列或自增列语义不同改用序列或应用层生成ID大小写敏感表名/字段名大小写规则不同统一规范并全局检查SQL函数差异date_format、concat等函数行为不一致逐个替换或封装兼容函数存储过程语法差异大移植成本高尽量在应用层重写减少存储过程依赖字符集中文排序、emoji存储问题统一UTF8系列字符集并验证排序规则我在项目里的做法是先做SQL梳理把应用里所有的SQL语句、存储过程、触发器都提取出来用脚本做一次静态扫描把高风险的写法全部标出来。这一步能提前发现百分之七八十的问题比等到测试环境报错再一个个查效率高得多。数据迁移本身如果是同构迁移比如MySQL到达梦可以用官方提供的迁移工具但要注意数据类型映射特别是decimal精度、datetime时区、blob大字段这几类。异构迁移Oracle到达梦建议留足验证时间因为Oracle的一些特性在国产库里是形似神不似。迁移完必须做数据校验行数、校验和、抽样字段比对三个都要做不能只看行数对上了就放心。3.3 中间件与运行时的替换要点中间件替换看着简单——改个部署包的事但实际有几个细节要抠。一是类加载顺序。不同的应用服务器Tomcat、TongWeb、BES在类加载的委派机制上有差异如果项目里有自定义的类加载器或者依赖了容器提供的某些类迁移时容易出现ClassNotFoundException或者版本冲突。我一般会在切换前先用一个最小化的测试包验证类加载链路。二是连接池配置。DBCP、Druid、HikariCP这些连接池在国产数据库上的表现不完全一样特别是连接有效性检测的SQL语句不同数据库写法不同。配置错了会导致连接被中途断开表现为偶发的连接已关闭错误非常难查。三是会话和集群。如果原来用的是Tomcat的会话共享或者WebLogic的集群迁移到国产中间件后要重新配置集群和会话复制方案。这块如果搞不定用户的登录状态会在多节点间丢失体验直接崩坏。我倾向于在中间件前面加一层负载均衡用粘性会话先保证能用再逐步优化会话共享。四是日志和监控集成。国产中间件的日志格式和路径和原来的不同如果你们的监控系统是按日志采集做的要重新配解析规则。3.4 前端与浏览器兼容最容易被低估的部分很多技术负责人把注意力全放在后端结果前端栽了跟头。OA系统的前端兼容问题主要集中在几类ActiveX控件。老OA里几乎必然存在比如电子签章、UKey读卡、打印机控件、扫描仪调用。这些东西在国产浏览器奇安信、红莲花、360政企版等上根本不支持。解决办法是把这些能力重构成HTML5方案电子签章对接服务端签章接口UKey调用改为浏览器的标准接口或者客户端代理程序。这块工作量不小要提前排期。浏览器内核差异。国产浏览器大多基于Chromium内核但也有的用了不同版本或做了定制CSS渲染、JS引擎行为可能有细微差别。老OA里常见的IE-only写法比如document.all、条件注释、滤镜必须全部清理。OFD格式。公文场景下OFD正在替代PDF作为版式文档标准。前端预览OFD需要引入专门的渲染库各浏览器的支持情况要逐个验证特别是打印输出的效果。单点登录。OA通常要和企业门户、其他业务系统做SSO协议可能是CAS、OAuth2或者自研。迁移时注意国密算法SM2、SM3、SM4在加密签名环节的替换如果原来用的是RSA要整体切换到国密体系这涉及服务端和客户端两边的改造。4. 实操过程一套可复用的迁移落地流程4.1 前期盘点与评估阶段项目启动的第一周我会做三件事环境盘点、代码扫描、风险清单。环境盘点是把手头所有服务器的配置、操作系统版本、中间件版本、数据库版本、JDK版本、依赖的第三方组件全部列出来做成一张清单。这一步看着枯燥但不做的话后面会出现这个服务没人知道它依赖什么的尴尬。代码扫描是把应用代码和配置做静态分析找出所有的SQL、native调用、系统调用、硬编码路径、外部服务依赖。我一般用脚本加人工抽查结合的方式重点看和底层强相关的部分。风险清单是前两步的产出把每个风险点标注等级、影响面、处理方案、责任人。这份清单会在整个项目周期里反复更新是所有排期的基础。4.2 搭建对标测试环境评估完之后先在测试环境搭建一套和信创生产环境一致的技术栈把应用部署上去跑通基本功能。这一步的目标不是性能是能不能跑起来。很多兼容性问题会在这一步集中爆发早发现早处理。测试环境要注意两点一是架构要和生产一致别用x86测ARM的东西二是版本要和采购的最终版本一致别用旧版本测然后上线新版本。跑通之后进入功能验证阶段把OA的每个模块按业务场景过一遍重点测公文流转、附件上传下载、流程审批、报表导出、电子签章、打印这些和底层交互多的功能。4.3 性能压测与调优功能跑通不代表能上线。OA系统在上班高峰期会有明显的并发压力尤其是早上九点前后大量用户集中登录和发起流程。压测的时候我会重点关注四个指标登录响应时间、流程发起的TPS、附件上传下载吞吐、报表查询的响应时间。用JMeter或者类似工具模拟真实场景用户行为要贴近实际别只测单一接口。调优的方向后端常见的调整有JVM参数、连接池大小、数据库索引和慢SQL优化、缓存策略。我遇到过一次迁移后流程列表页特别慢查下来是国产数据库对某个关联查询的执行计划选择和原来的数据库不一样加了个索引就解决了。所以压测阶段一定要盯执行计划和慢查询日志别只看表面响应时间。4.4 灰度切换与回滚预案正式切换我强烈建议灰度进行。先选一个部门或者一个分公司试点观察一周没有问题再逐步扩大。如果有条件做双轨运行老系统和新系统并行一段时间数据做同步出问题能快速切回。回滚预案必须提前写好而且要演练过。包括回滚的触发条件、操作步骤、数据回灌方案、通知机制。没演练过的预案等于没有预案真出事的时候你会发现自己连回滚脚本都没测过。5. 常见问题与排查技巧实录5.1 高频问题速查表这是我项目里积累的问题库都是实际遇到过的按现象分类现象可能原因排查方向应用启动报ClassNotFound中间件类加载机制差异检查类加载委派配置、依赖冲突偶发连接已关闭连接池检测SQL不兼容检查连接池validationQuery配置中文乱码或排序错乱字符集或排序规则不一致检查库、表、连接的字符集设置公文排版错位字体缺失或渲染差异补齐字体、验证真实公文模板电子签章失败国密算法或控件不支持检查签名算法、替换ActiveX为H5方案上传大文件失败操作系统或中间件限制检查文件句柄数、上传大小、超时配置定时任务不执行时区或调度框架问题检查系统时区、调度器配置打印效果异常浏览器渲染差异用目标浏览器实测、调整打印样式5.2 几个反直觉的坑第一个坑跟字体有关。测试环境验证都通过了上线后用户反馈公文格式全乱了。查了半天发现是生产环境的操作系统没有装某个特定字体测试环境装了所以没暴露。教训就是字体这类资源一定要和生产环境对齐别想当然。第二个坑是时间。国产操作系统默认时区配置可能和原来的不一样导致定时任务在错误的时间执行或者流程里的时间戳差了八个小时。这类问题很隐蔽上线初期容易漏测。第三个坑是编码。老系统里有些文件是用GBK编码写的配置文件迁移到新环境后如果默认编码变成UTF-8读取配置就会乱码。这个要在迁移清单里专门列一项检查。第四个坑是并发。有些国产组件在低并发下表现完美一上高并发就出问题比如连接数打满、锁等待。所以压测一定要做到接近生产峰值甚至是峰值的1.5倍。5.3 排查问题的通用思路信创环境下的问题排查我总结了一个从下往上、逐层剥离的方法。先确认操作系统层面正常资源、网络、磁盘、时区再确认JDK和中间件正常进程、日志、线程栈再确认数据库正常连接、慢SQL、锁最后才是应用本身的逻辑。很多看似应用的问题根源在下层。另外强烈建议把日志级别在测试阶段调高把关键链路的信息都记下来。上线后再排查问题第一手信息往往就靠这些日志。生产环境日志级别调低是上线稳定之后的事别一上来就省钱。工具方面jstack、jmap、arthas这些Java诊断工具在国产JDK上基本都能用数据库端用官方自带的性能视图和慢日志。跨层排查时我会画一条从浏览器到数据库的完整链路逐段打点定位问题在哪一段。关于KubeSphere这类容器平台如果信创项目用了它排查问题时要注意容器内的时区、DNS、存储挂载这些和物理机不一样的地方很多玄学问题都出在容器环境配置上。6. 一个脱敏的标杆案例拆解6.1 案例背景与挑战某大型制造集团的OA系统使用年限超过十年用户规模一万五千人日均流程两万条。系统里有大量定制开发包括几十个自定义报表、十几个第三方集成接口、还有一套基于老控件的公文签章模块。最初的技术栈是x86服务器、CentOS、Oracle数据库、WebLogic中间件、IE浏览器。项目的主要挑战有三个一是历史包袱重代码经过多轮外包开发风格混杂二是集成面广OA和财务、人力、门户等系统都有对接三是业务不能停必须保证平滑过渡。6.2 方案设计与实施路径技术选型上芯片选了ARM架构操作系统选麒麟服务器版数据库达梦中间件东方通TongWebJDK用毕昇前端切换到国产浏览器并重写了签章和打印模块。实施路径分成四步走第一步是代码梳理和SQL改造把Oracle特有的语法迁移到兼容写法第二步是搭建测试环境并做功能验证重点攻签章和报表两个模块第三步是性能压测和调优把高峰期场景模拟到位第四步是灰度上线先试点两个部门稳定后全量切换。签章模块的改造是重点。原来的ActiveX控件方案在国产浏览器上完全不可用最后改成服务端签章加H5预览的方案国密算法用的是SM2和SM3整个过程花了大概六周。6.3 效果与经验沉淀切换完成后系统在同等用户规模下的稳定性达到了预期核心流程的响应时间比原来还有提升主要是数据库和中间件的调优起了作用。上线初期也有几个小问题比如字体导致的排版问题、连接池参数问题都在一周内解决了。这个项目最大的经验是前期评估的时间花得越多后期踩的坑越少。他们光代码梳理和风险评估就用了将近一个月很多人觉得慢但正是这一个月的准备让后面的实施少走了很多弯路。另一个经验是关键模块提前攻坚别把所有难点堆到上线前。7. 我个人在项目里的一些体会做这类项目这些年我最大的感受是信创适配本质上是一个系统性工程问题不是技术炫技。它考验的不是你会不会用某个新技术而是你能不能把一个复杂的、充满历史包袱的系统在约束条件下稳稳地迁移到新底座上。这中间大量的工作是评估、验证、调优、兜底看起来不那么光鲜但每一环都不能省。还有个体会是关于团队。这类项目特别需要有人能同时理解老系统和新环境能在兼容性问题上做判断。光靠厂商的适配文档是不够的文档能告诉你支持但告诉不了你在这个特定组合下会遇到什么。这种判断力只能靠一个个项目积累。最后分享一个小习惯我在每个信创项目里都会维护一份自己的适配问题日志把遇到的所有兼容性问题、处理方案、验证结果都记下来。这玩意儿越攒越值钱下一次做类似项目的时候翻一遍就能避开一大半坑。如果你也在做这方面的项目建议从现在就开始记。
信创OA全栈适配迁移：芯片、数据库、中间件与前端改造
1. 从一次真实的OA替换项目说起去年下半年我参与了一个集团型企业的OA办公系统整体迁移项目。这个项目的核心诉求很直接原有的OA系统跑在x86服务器加国外商业数据库、国外中间件的技术栈上现在要把整套底座换成自主可控的技术路线——国产芯片、国产操作系统、国产数据库、国产中间件、国产浏览器。项目涉及的用户量大概在两万人左右日均流程实例三万多条公文流转、审批、会议、档案这些模块一个都不能少。这类项目最近两年特别多。很多做企业信息化的同行都在问同一个问题OA这种看起来没啥技术含量的系统为什么一换底座就浑身是坑答案其实不复杂。OA系统是典型的历史包袱重、技术栈老、集成面广的应用。它不像一个新建的互联网应用可以随便挑技术栈它往往已经运行了七八年甚至十几年代码里塞满了各种定制化的报表、插件、ActiveX控件、老版本框架。你动它的底座等于给一个跑了十几年的老车换发动机还得保证它照样能上高速。这篇文章我想聊的不是政策解读那个层面有很多官方渠道说得比我清楚。我更想从一个技术落地者的角度把这套事情拆开讲信创环境下OA系统到底要做哪些适配、技术选型怎么权衡、迁移过程里那些真正会卡住你的点在哪、有没有可以少走弯路的经验。适合正在做或者准备做这类项目的技术负责人、架构师、运维同学参考也适合刚接触这个方向、想搞清楚信创适配到底要适配什么的人。全文不涉及任何具体的合规建议只讲技术实现层面我踩过的和见过的坑。信创这个词这几年出现频率很高配套的信创目录产品名单、信创产品目录最新版本也成了选型时大家反复查的东西。但目录只是起点真正难的是把目录里的产品组合成一个能稳定跑起来的系统。2. 信创OA的整体架构设计与选型思路2.1 为什么是全栈替换而不是局部替换很多刚接触这个方向的团队会有一个朴素的想法我就把数据库换掉行不行或者我只换操作系统行不行从技术上讲当然可以分步走但从项目实践看局部替换往往比全栈替换更痛苦。原因在于信创适配的难点不在单个组件的替换而在组件之间的兼容性缝隙。举个具体的例子。你把操作系统从CentOS换成麒麟如果JDK还是原来那个Oracle JDK中间件还是Tomcat数据库还是MySQL那大部分情况下确实能跑。但问题在于一旦你的芯片从x86换成了ARM架构或者LoongArch架构JDK就得换对应的版本Tomcat本身是Java的没大问题可你依赖的那些native库、加密卡驱动、打印控件驱动全都是按x86编译的这时候就开始连环出问题。与其一个一个去救火不如一次性把底座捋清楚做整体规划。我在实际项目里总结的经验是先确定芯片和操作系统的组合这是地基然后确定JDK和中间件这是承重墙再确定数据库和应用本身这是房间。地基一动上面的东西全都要重新评估。这个顺序不能反。全栈替换的另一个理由是运维统一。如果你搞成混合栈一半国产一半国外运维团队要维护两套知识体系出了问题排查链路特别长长期成本反而更高。2.2 选型要看哪几个维度选型这件事我见过太多团队只盯着是不是在信创目录里这一个维度结果选完发现性能扛不住、生态不成熟、社区没资料。我在项目里一般会从五个维度去评估按权重排序大概是这样的评估维度具体看什么权重建议兼容性与现有应用、框架、第三方组件的适配程度高稳定性生产环境实际运行案例、故障率口碑高性能同等硬件下的TPS、响应时间、并发承载中高生态与文档官方文档质量、社区活跃度、问题可搜索性中运维成本团队学习曲线、监控工具配套、备份恢复方案中兼容性排第一是有血的教训的。我见过一个项目选了一款比较新的国产数据库功能确实全但它的JDBC驱动和项目里用的老版本连接池有冲突连接泄漏问题查了整整两周。这种问题不是产品不好是组合不对。芯片层面目前主流的是ARM架构鲲鹏、飞腾和x86兼容架构海光、兆芯还有LoongArch龙芯。选哪个很大程度上取决于你的应用有没有native依赖、有没有历史编译产物。纯Java应用对架构不敏感但有C/C扩展的应用就要重点评估。操作系统层面麒麟和统信UOS是绕不开的两个选择服务器端的适配成熟度都还可以主要差异在具体版本的内核参数、软件源、以及和某些硬件的驱动适配情况。我一般的做法是拿一个真实的测试环境把要用的组合跑一遍压力测试别只看厂商的兼容性列表。中间件这块东方通TongWeb、宝兰德BES、金蝶Apusic都是常见选项功能上覆盖Tomcat/Jetty/WebLogic的主流场景迁移时主要是配置文件和部署方式的调整。2.3 容器化是不是必选项有个高频问题容器平台在信创环境下能不能用像KubeSphere这类平台有没有专门的信创适配版本实际答案是主流的容器平台本身是Go语言写的跨架构编译支持成熟在ARM和LoongArch上都能跑。真正的适配重点是底层的容器运行时、镜像仓库、以及网络和存储插件在国产操作系统上的兼容性。我的建议是如果你的团队本来就有容器化运维能力那信创环境下继续用容器是加分项因为容器能把应用依赖和操作系统差异隔离开迁移时改的是基础镜像而不是应用本身。但如果团队原来是纯物理机或虚拟机部署为了信创项目临时上容器反而会引入额外的复杂度。技术选型要跟着团队能力走不要为了技术先进性硬上。3. OA信创适配的核心技术点拆解3.1 芯片与操作系统层的适配细节这一层的适配对纯Java的OA应用来说大部分是无感的但有几个地方必须提前确认。第一是JDK的架构版本。Oracle JDK在很多架构上的支持已经受限实际项目里大家用的是OpenJDK系的各种发行版比如毕昇JDKARM架构优化好、龙井Dragonwell、以及龙芯自己的JDK。不同JDK发行版在垃圾回收器默认策略、JVM参数支持上有细微差别我之前遇到过一个性能问题就是新JDK默认的GC策略和老应用的内存模型不匹配导致Full GC频繁后来手动指定了G1参数才稳定下来。第二是native库的问题。老OA里常见的native依赖有加密卡驱动、PDF/OFD转换库、字体渲染库、图像处理库比如ImageMagick。这些都要重新找对应架构的版本。特别是字体国产操作系统自带的字体集和原来的可能不一样会导致公文排版错位这个坑非常隐蔽测试时一定要用真实公文模板验证。第三是操作系统的内核参数。麒麟和UOS的默认文件句柄数、TCP参数、共享内存配置和CentOS不完全一样。OA系统如果有大量文件上传下载、长连接建议按原系统的参数基线做对齐能省掉很多莫名其妙变慢的问题。3.2 数据库迁移最难啃的那块骨头数据库替换是整个项目里工作量最大、风险最高的环节。从MySQL或Oracle迁到国产数据库表面上是SQL语法差异实际上是整个数据访问层的重新验证。常见的坑我整理过一张对照表都是实际迁移中真会遇到的问题类型典型表现处理思路分页语法limit/rownum写法不兼容改写为国产库支持的分页方式或ORM层适配自增主键序列或自增列语义不同改用序列或应用层生成ID大小写敏感表名/字段名大小写规则不同统一规范并全局检查SQL函数差异date_format、concat等函数行为不一致逐个替换或封装兼容函数存储过程语法差异大移植成本高尽量在应用层重写减少存储过程依赖字符集中文排序、emoji存储问题统一UTF8系列字符集并验证排序规则我在项目里的做法是先做SQL梳理把应用里所有的SQL语句、存储过程、触发器都提取出来用脚本做一次静态扫描把高风险的写法全部标出来。这一步能提前发现百分之七八十的问题比等到测试环境报错再一个个查效率高得多。数据迁移本身如果是同构迁移比如MySQL到达梦可以用官方提供的迁移工具但要注意数据类型映射特别是decimal精度、datetime时区、blob大字段这几类。异构迁移Oracle到达梦建议留足验证时间因为Oracle的一些特性在国产库里是形似神不似。迁移完必须做数据校验行数、校验和、抽样字段比对三个都要做不能只看行数对上了就放心。3.3 中间件与运行时的替换要点中间件替换看着简单——改个部署包的事但实际有几个细节要抠。一是类加载顺序。不同的应用服务器Tomcat、TongWeb、BES在类加载的委派机制上有差异如果项目里有自定义的类加载器或者依赖了容器提供的某些类迁移时容易出现ClassNotFoundException或者版本冲突。我一般会在切换前先用一个最小化的测试包验证类加载链路。二是连接池配置。DBCP、Druid、HikariCP这些连接池在国产数据库上的表现不完全一样特别是连接有效性检测的SQL语句不同数据库写法不同。配置错了会导致连接被中途断开表现为偶发的连接已关闭错误非常难查。三是会话和集群。如果原来用的是Tomcat的会话共享或者WebLogic的集群迁移到国产中间件后要重新配置集群和会话复制方案。这块如果搞不定用户的登录状态会在多节点间丢失体验直接崩坏。我倾向于在中间件前面加一层负载均衡用粘性会话先保证能用再逐步优化会话共享。四是日志和监控集成。国产中间件的日志格式和路径和原来的不同如果你们的监控系统是按日志采集做的要重新配解析规则。3.4 前端与浏览器兼容最容易被低估的部分很多技术负责人把注意力全放在后端结果前端栽了跟头。OA系统的前端兼容问题主要集中在几类ActiveX控件。老OA里几乎必然存在比如电子签章、UKey读卡、打印机控件、扫描仪调用。这些东西在国产浏览器奇安信、红莲花、360政企版等上根本不支持。解决办法是把这些能力重构成HTML5方案电子签章对接服务端签章接口UKey调用改为浏览器的标准接口或者客户端代理程序。这块工作量不小要提前排期。浏览器内核差异。国产浏览器大多基于Chromium内核但也有的用了不同版本或做了定制CSS渲染、JS引擎行为可能有细微差别。老OA里常见的IE-only写法比如document.all、条件注释、滤镜必须全部清理。OFD格式。公文场景下OFD正在替代PDF作为版式文档标准。前端预览OFD需要引入专门的渲染库各浏览器的支持情况要逐个验证特别是打印输出的效果。单点登录。OA通常要和企业门户、其他业务系统做SSO协议可能是CAS、OAuth2或者自研。迁移时注意国密算法SM2、SM3、SM4在加密签名环节的替换如果原来用的是RSA要整体切换到国密体系这涉及服务端和客户端两边的改造。4. 实操过程一套可复用的迁移落地流程4.1 前期盘点与评估阶段项目启动的第一周我会做三件事环境盘点、代码扫描、风险清单。环境盘点是把手头所有服务器的配置、操作系统版本、中间件版本、数据库版本、JDK版本、依赖的第三方组件全部列出来做成一张清单。这一步看着枯燥但不做的话后面会出现这个服务没人知道它依赖什么的尴尬。代码扫描是把应用代码和配置做静态分析找出所有的SQL、native调用、系统调用、硬编码路径、外部服务依赖。我一般用脚本加人工抽查结合的方式重点看和底层强相关的部分。风险清单是前两步的产出把每个风险点标注等级、影响面、处理方案、责任人。这份清单会在整个项目周期里反复更新是所有排期的基础。4.2 搭建对标测试环境评估完之后先在测试环境搭建一套和信创生产环境一致的技术栈把应用部署上去跑通基本功能。这一步的目标不是性能是能不能跑起来。很多兼容性问题会在这一步集中爆发早发现早处理。测试环境要注意两点一是架构要和生产一致别用x86测ARM的东西二是版本要和采购的最终版本一致别用旧版本测然后上线新版本。跑通之后进入功能验证阶段把OA的每个模块按业务场景过一遍重点测公文流转、附件上传下载、流程审批、报表导出、电子签章、打印这些和底层交互多的功能。4.3 性能压测与调优功能跑通不代表能上线。OA系统在上班高峰期会有明显的并发压力尤其是早上九点前后大量用户集中登录和发起流程。压测的时候我会重点关注四个指标登录响应时间、流程发起的TPS、附件上传下载吞吐、报表查询的响应时间。用JMeter或者类似工具模拟真实场景用户行为要贴近实际别只测单一接口。调优的方向后端常见的调整有JVM参数、连接池大小、数据库索引和慢SQL优化、缓存策略。我遇到过一次迁移后流程列表页特别慢查下来是国产数据库对某个关联查询的执行计划选择和原来的数据库不一样加了个索引就解决了。所以压测阶段一定要盯执行计划和慢查询日志别只看表面响应时间。4.4 灰度切换与回滚预案正式切换我强烈建议灰度进行。先选一个部门或者一个分公司试点观察一周没有问题再逐步扩大。如果有条件做双轨运行老系统和新系统并行一段时间数据做同步出问题能快速切回。回滚预案必须提前写好而且要演练过。包括回滚的触发条件、操作步骤、数据回灌方案、通知机制。没演练过的预案等于没有预案真出事的时候你会发现自己连回滚脚本都没测过。5. 常见问题与排查技巧实录5.1 高频问题速查表这是我项目里积累的问题库都是实际遇到过的按现象分类现象可能原因排查方向应用启动报ClassNotFound中间件类加载机制差异检查类加载委派配置、依赖冲突偶发连接已关闭连接池检测SQL不兼容检查连接池validationQuery配置中文乱码或排序错乱字符集或排序规则不一致检查库、表、连接的字符集设置公文排版错位字体缺失或渲染差异补齐字体、验证真实公文模板电子签章失败国密算法或控件不支持检查签名算法、替换ActiveX为H5方案上传大文件失败操作系统或中间件限制检查文件句柄数、上传大小、超时配置定时任务不执行时区或调度框架问题检查系统时区、调度器配置打印效果异常浏览器渲染差异用目标浏览器实测、调整打印样式5.2 几个反直觉的坑第一个坑跟字体有关。测试环境验证都通过了上线后用户反馈公文格式全乱了。查了半天发现是生产环境的操作系统没有装某个特定字体测试环境装了所以没暴露。教训就是字体这类资源一定要和生产环境对齐别想当然。第二个坑是时间。国产操作系统默认时区配置可能和原来的不一样导致定时任务在错误的时间执行或者流程里的时间戳差了八个小时。这类问题很隐蔽上线初期容易漏测。第三个坑是编码。老系统里有些文件是用GBK编码写的配置文件迁移到新环境后如果默认编码变成UTF-8读取配置就会乱码。这个要在迁移清单里专门列一项检查。第四个坑是并发。有些国产组件在低并发下表现完美一上高并发就出问题比如连接数打满、锁等待。所以压测一定要做到接近生产峰值甚至是峰值的1.5倍。5.3 排查问题的通用思路信创环境下的问题排查我总结了一个从下往上、逐层剥离的方法。先确认操作系统层面正常资源、网络、磁盘、时区再确认JDK和中间件正常进程、日志、线程栈再确认数据库正常连接、慢SQL、锁最后才是应用本身的逻辑。很多看似应用的问题根源在下层。另外强烈建议把日志级别在测试阶段调高把关键链路的信息都记下来。上线后再排查问题第一手信息往往就靠这些日志。生产环境日志级别调低是上线稳定之后的事别一上来就省钱。工具方面jstack、jmap、arthas这些Java诊断工具在国产JDK上基本都能用数据库端用官方自带的性能视图和慢日志。跨层排查时我会画一条从浏览器到数据库的完整链路逐段打点定位问题在哪一段。关于KubeSphere这类容器平台如果信创项目用了它排查问题时要注意容器内的时区、DNS、存储挂载这些和物理机不一样的地方很多玄学问题都出在容器环境配置上。6. 一个脱敏的标杆案例拆解6.1 案例背景与挑战某大型制造集团的OA系统使用年限超过十年用户规模一万五千人日均流程两万条。系统里有大量定制开发包括几十个自定义报表、十几个第三方集成接口、还有一套基于老控件的公文签章模块。最初的技术栈是x86服务器、CentOS、Oracle数据库、WebLogic中间件、IE浏览器。项目的主要挑战有三个一是历史包袱重代码经过多轮外包开发风格混杂二是集成面广OA和财务、人力、门户等系统都有对接三是业务不能停必须保证平滑过渡。6.2 方案设计与实施路径技术选型上芯片选了ARM架构操作系统选麒麟服务器版数据库达梦中间件东方通TongWebJDK用毕昇前端切换到国产浏览器并重写了签章和打印模块。实施路径分成四步走第一步是代码梳理和SQL改造把Oracle特有的语法迁移到兼容写法第二步是搭建测试环境并做功能验证重点攻签章和报表两个模块第三步是性能压测和调优把高峰期场景模拟到位第四步是灰度上线先试点两个部门稳定后全量切换。签章模块的改造是重点。原来的ActiveX控件方案在国产浏览器上完全不可用最后改成服务端签章加H5预览的方案国密算法用的是SM2和SM3整个过程花了大概六周。6.3 效果与经验沉淀切换完成后系统在同等用户规模下的稳定性达到了预期核心流程的响应时间比原来还有提升主要是数据库和中间件的调优起了作用。上线初期也有几个小问题比如字体导致的排版问题、连接池参数问题都在一周内解决了。这个项目最大的经验是前期评估的时间花得越多后期踩的坑越少。他们光代码梳理和风险评估就用了将近一个月很多人觉得慢但正是这一个月的准备让后面的实施少走了很多弯路。另一个经验是关键模块提前攻坚别把所有难点堆到上线前。7. 我个人在项目里的一些体会做这类项目这些年我最大的感受是信创适配本质上是一个系统性工程问题不是技术炫技。它考验的不是你会不会用某个新技术而是你能不能把一个复杂的、充满历史包袱的系统在约束条件下稳稳地迁移到新底座上。这中间大量的工作是评估、验证、调优、兜底看起来不那么光鲜但每一环都不能省。还有个体会是关于团队。这类项目特别需要有人能同时理解老系统和新环境能在兼容性问题上做判断。光靠厂商的适配文档是不够的文档能告诉你支持但告诉不了你在这个特定组合下会遇到什么。这种判断力只能靠一个个项目积累。最后分享一个小习惯我在每个信创项目里都会维护一份自己的适配问题日志把遇到的所有兼容性问题、处理方案、验证结果都记下来。这玩意儿越攒越值钱下一次做类似项目的时候翻一遍就能避开一大半坑。如果你也在做这方面的项目建议从现在就开始记。
查询的入门经典)
