企业网站信创国产化改造怎么做？从云上选型、适配迁移到安全上线

我们接触企业网站信创改造时，经常会遇到一个很现实的问题：云服务器选好了，国产操作系统也装好了，数据库和中间件也都有了，网站是不是直接搬过去就行？

如果真这么简单，信创改造大概只需要一张采购清单。实际做下来，真正费心的往往不是“买什么”，而是这些东西放到一起之后，原来的官网还能不能照常打开，编辑还能不能照常发稿，数据还能不能照常查，最后上线时能不能少折腾用户。

所以我们更愿意把企业网站信创国产化改造理解成一次“换底座、不停生意”的搬家：先选好新房，再把水电线路理顺，家具一件件搬过去，最后确认门牌号没有挂错。

企业官网和一般的内部业务系统还有一点不同：它天然要面向公网访问，除了服务器和应用本身，还要考虑域名解析、备案、HTTPS、安全防护以及不同地区用户的访问体验。因此不少企业在做官网新建、迁移或信创改造时，会选择部署在公有云上。

本文就以阿里云作为具体实施平台来展开。后面的ECS、国产处理器、操作系统镜像、域名备案、SSL证书以及网站迁移等内容，也都会结合阿里云上的实际部署方式来说明。换成其他云平台，整体改造思路类似，但具体产品、镜像和操作方式会有所不同。

不过，云平台只是承载环境。真正开始选服务器之前，第一步还是要先看项目本身提出了哪些信创要求。

一、企业网站信创国产化改造：先看“底座”，再看网站

既然是“换底座”，第一件事自然不是看网站页面，而是先看项目要求里写了什么。处理器是海光（Hygon）、鲲鹏（Kunpeng）还是其他路线？操作系统用哪个版本？数据库和中间件有没有指定范围？这些往往决定了后面应用怎么改。

我们做前期梳理时，会先把现有环境和目标环境摆在一起看。原来是什么服务器、什么操作系统、什么数据库，程序用什么语言，CMS用了多久，还有没有历史接口和定时任务。这个过程有点像搬家前翻柜子：平时觉得东西不多，真要装箱时，角落里总能翻出几个“谁也不敢扔”的老物件。

这些老物件在网站里，往往就是旧驱动、老插件、特殊SQL、接口地址或者写死的文件路径。平时不声不响，换了环境以后，它们反而最容易先出来刷存在感。

二、云上信创选型：ECS、国产处理器和国产操作系统镜像要一起看

现有环境盘清楚、项目要求也确认以后，接下来才真正轮到“新房怎么选”。如果网站准备部署到云上，首先要落到云服务器选型上。但“有一台ECS”还不够，我们还会继续往下看：这台ECS是什么处理器架构、在哪个地域、能选什么操作系统镜像，后面的数据库和中间件能不能在这套组合里正常运行。

2.1 ECS与国产处理器：先把计算底座选对

项目要求海光，就先确认云平台上是否有对应的海光实例；要求鲲鹏，也同样先看实际可选的实例和地域。因为处理器架构一旦确定，后面的操作系统镜像、软件包和运行环境都会跟着它走。先把底座选对，后面会省掉不少“装到一半才发现不合适”的返工。

图-云服务器ECS国产处理器实例（海光Hygon处理器）

2.2 国产操作系统镜像：名字对了，版本也要对

处理器选完，接着就是操作系统镜像。比如项目要求银河麒麟V10，除了看名称，还要确认具体版本、处理器架构、镜像来源和授权方式。名字一样，不代表每个版本都能和后面的软件顺利搭伙。

这就像同一个型号的门锁，看着差不多，钥匙却不一定通用。真正要验证的，是“这一个版本”能不能和“这一个处理器、这一个数据库、这一个中间件”一起工作。

图-国产操作系统镜像与版本选择

镜像选好并不意味着操作系统这一项就结束了。服务器创建完成以后，我们还会进入实际环境确认系统版本、处理器架构、内核以及基础软件运行情况，确保最终部署出来的环境和前期选型一致。

尤其是信创项目，不能只留下“选了某个镜像”的记录，最终实际运行的系统和版本也应该能够核对。

图-阿里云ECS海光处理器信息

图-银河麒麟操作系统信息

三、企业网站信创架构怎么搭：一台服务器够不够？

处理器和操作系统解决的是“选什么”，接下来还要解决“怎么搭”。服务器型号和操作系统确定以后，应用、数据库和公网入口怎么组合，才真正决定了网站后面的部署方式。

很多人第一次看方案都会问：官网到底需要几台服务器？

这个问题没有固定答案。访问量、业务重要程度、安全要求、预算，以及能不能接受单点故障，都会影响架构。

对不少正式企业官网来说，一个比较常见的起点是把应用和数据库分开。应用服务器跑CMS、网站程序和中间件，数据库服务器专门保存内容和业务数据。外部访问从公网入口进入，经过安全防护或代理，再到应用层；数据库尽量留在内网。

为什么要分开？不是为了把架构图画得更复杂，而是为了以后好维护。应用忙了，可以单独扩；数据库要备份，也更容易管；出了问题，还能更快判断到底是谁“闹情绪”。

如果只是一个访问量不大的普通官网，也没必要为了“看起来专业”硬拆成十几台机器。两个人吃饭摆二十套餐具，场面确实很大，收拾起来也是真累。架构够用、清楚、后面好维护，比堆数量更重要。

图-企业网站云上信创整体架构示意图

四、域名备案和 SSL 证书，也别等到上线前一天才想起来

云服务器选好了，架构也画清楚了，是不是就可以开始搬网站？还别急。有几个看起来不起眼、真到了上线时却很容易卡住的环节，需要提前准备：域名备案、DNS解析和SSL证书。

它们平时不太抢镜，但真少了其中一个，前面服务器、数据库、网站程序准备得再漂亮，也可能卡在最后一步。就像新办公室装修完了，桌椅电脑全到位，结果门牌、路线和钥匙还没办好——里面再整齐，客户也进不来。

4.1 域名备案：别等网站做完才开始准备

如果企业官网在中国境内提供非经营性互联网信息服务，ICP备案需要提前确认。新建网站要看备案准备是否就绪；已有网站迁移云平台或更换接入服务商时，也要检查原有备案和新的接入信息能不能顺利衔接。

这件事为什么要提前？因为网站程序可以赶进度，备案流程却有自己的节奏。真等到“网站明天上线，今天才想起来备案”，项目组再着急，也很难靠多喝两杯咖啡把流程压缩掉。

所以在规划企业官网上云或信创改造时，我们通常会把域名、备案状态、云服务器部署位置和接入方式一起确认。尤其是旧官网迁移，不能只问“服务器搬没搬完”，还要看看域名原来怎么接入，新环境上线后怎么继续访问。

图-阿里云ICP备案阿里云ICP备案域名检查

图-阿里云ICP备案信息填写界面

4.2 DNS解析：服务器搬了，域名也要找到“新地址”

备案解决的是网站能不能合规接入，DNS解析解决的则是用户输入域名以后，到底应该去哪里找这个网站。网站迁移到新的云环境以后，正式域名最终需要指向新的公网IP、负载均衡或其他公网入口。

迁移过程中，我们一般不会一开始就把正式域名切过去。新环境还在部署和测试时，可以先通过测试域名或Hosts等方式进行验证，等网站功能、数据、安全和性能都确认没有问题以后，再安排正式解析切换。

切换之前，还要把现有的A记录、CNAME记录以及相关子域名检查一遍。否则可能出现主站已经到了新环境，某个接口、静态资源或者二级域名还在找旧服务器的情况。

图-阿里云DNS域名解析配置

4.3 SSL证书：有了HTTPS，还要确认整条链路都正常

SSL证书关系到网站能不能通过HTTPS正常访问。现在企业官网基本都会使用HTTPS，所以除了申请和部署证书，还要检查证书绑定域名是否正确、证书链是否完整、有效期是否正常，以及HTTP跳转HTTPS以后，图片、附件、表单和接口还能不能正常访问。

这里也不能只看云平台控制台里“证书已签发”几个字。证书最终还要部署到真正承接HTTPS访问的位置。在本次信创环境中，网站请求由东方通TongHttpServer国产中间件承接，因此还需要结合实际访问链路确认HTTPS和证书部署是否正常。

图-阿里云SSL证书管理界面

图-阿里云SSL证书下载界面

4.4 国产中间件东方通Tonghttpserver配置：域名和证书准备好了，还要真正接到网站上

域名解析和SSL证书准备好以后，请求最终还要进入网站应用。在本次信创环境中，我们使用的是国产中间件东方通 TongHttpServer，因此原来网站环境中的Web服务配置，也需要结合新的中间件重新进行适配。

这里关注的不只是“东方通TongHttpServer服务有没有启动”，还要继续检查HTTP/HTTPS访问、SSL证书、网站应用发布、静态资源、上传下载、请求超时以及相关访问参数是否配置正常。

有些问题还挺有迷惑性：**首页能打开，不代表整个网站已经适配完成。**后台上传图片、附件下载、接口调用或者某些特殊页面，都可能在真正使用时才暴露问题。所以中间件配置完成以后，我们还会顺着网站实际使用路径重新验证一遍。

图-东方通TongHttpServer国产中间件版本信息

图-东方通TongHttpServer国产中间件配置

等数据和网站都迁移完后，从浏览器真正访问一次网站，确认HTTPS连接正常、证书域名匹配，并且用户实际访问到的就是新环境。

图-访问网站确认证书和实际对应

4.5 最后还是要把整条访问链路串起来看

我们在做网站迁移时，会把域名解析、备案状态、SSL证书、公网入口、东方通TongHttpServer国产中间件和网站应用放在同一套上线检查里看。

因为用户最后看到的只是一个网址，但这个网址背后其实要经过不少“关卡”。域名要先解析到正确的公网入口，HTTPS访问正常，再由东方通TongHttpServer承接网站请求并进入网站应用，应用最后还要能够正常访问数据库和相关服务。

其中任何一环没接好，浏览器通常不会耐心告诉你“第三段线路出了点小问题”，最后给用户的答案往往只有一句：打不开。

图-企业官网信创环境访问链路示意图

五、网站信创适配改造：数据库、中间件和应用要一起看

前面解决的是“用户怎么访问到新网站”，接下来要解决的，才是“原来的网站怎么在这套新环境里正常跑起来”。

云资源、整体架构和访问链路都理清以后，真正容易“动到网站”的部分才刚刚开始：适配。

新环境准备好，只能说明“新房钥匙拿到了”，并不代表旧家具都能原样搬进去。真正的适配，往往要把原有环境和目标环境一项项对上：哪些可以直接迁，哪些要升级，哪些必须替换，哪些会牵涉代码修改。

图-网站程序信创适配关系图

5.1 国产数据库适配：数据搬过去了，程序还认不认识？

比如原来用的是MySQL、Oracle或SQL Server，目标环境改成国产数据库，最容易产生一个错觉：数据已经导入，新数据库也能启动，那是不是就结束了？

实际还要看网站怎么用这些数据。SQL写法、字段类型、函数、分页方式、字符集和数据库驱动都可能不同。我们会特别去试搜索、统计、排序、批量发布、定时任务这些不太显眼的功能。首页能打开当然是好事，但真正的“彩蛋”有时要等编辑点下发布按钮才跳出来。

图-国产数据库实际版本及运行环境1

图-国产数据库实际版本及运行环境2

5.2 国产中间件适配：东方通TongHttpServer服务正常，不等于网站已经正常

中间件换掉以后，我们不会只看服务有没有启动，而是顺着用户真正访问网站的路线去走：页面能不能打开，图片和附件能不能加载，HTTPS是否正常，后台能不能登录，大文件上传会不会失败，接口会不会超时。

服务启动更像餐厅把灯打开了。灯亮了当然是第一步，但厨房能不能出菜、端出来的菜对不对，还得真的点几道试试。

5.3 CMS与网站程序：最后还是要回到“能不能正常发稿”

技术团队很容易把注意力放在CPU、数据库和服务状态上，编辑真正关心的却很朴素：文章还能不能发？图片能不能传？搜索还能不能用？表单有没有丢？

所以CMS和网站程序的验证，最终要回到日常使用。栏目、文章、附件、账号权限、审核发布、搜索、表单、接口和历史链接，都应该真正走一遍。底层换得再漂亮，如果编辑每天发稿都要绕路，这个“平稳改造”就很难让人点头。

这也是为什么我们做网站信创验证时，会让实际使用网站的方式重新走一遍：登录后台、进入内容管理、编辑文章、上传图片或附件，再真正发布一篇测试内容。对网站运营人员来说，后台能正常发稿，比服务器上几十个服务全部显示绿色更有说服力。

图-CMS文章内容管理

图-CMS文章内容管理

六、信创对开发语言有要求吗？重点不在 Java、PHP，而在运行环境能不能自主可控

做网站信创适配时，经常有人问：原来的网站是 Java 开发的，是不是连开发语言也要换？PHP、Node.js 还能不能继续用？

这个问题的关键，其实不是 Java、PHP 还能不能用，而是它们依赖什么环境运行。

信创改造一般不是要求把 Java、PHP、Node.js 这些编程语言本身“国产化”。真正需要关注的，是网站运行所依赖的 JDK、运行时、数据库驱动、中间件、第三方组件等基础软件环境，是否符合项目要求，能不能在国产处理器和操作系统上稳定运行，以及后续的版本更新、安全补丁和技术支持是否有保障。

6.1 Java 不一定要改，但 JDK 需要重点评估

以 Java 网站为例，Java 是开发语言，JDK 则是 Java 程序运行所依赖的基础环境之一。

原来的 Java 业务代码可能完全不需要重写，但如果项目原来长期使用 Oracle JDK，做信创适配时，就需要进一步评估它的授权方式、版本生命周期、安全更新、技术支持，以及在目标国产环境中的兼容情况。

这里考虑的不只是“今天网站能不能启动”。

企业官网通常要持续运行很多年。对于有信创、自主可控或软件供应链要求的项目，还要继续考虑：几年以后安全补丁从哪里获得？版本能不能持续维护？授权和技术支持政策发生变化，会不会影响现有生产环境？

因此，信创项目关注 JDK 等基础运行环境的替换，一个重要目的就是降低关键业务对单一国外商业软件授权、更新和技术支持体系的依赖，提高基础软件供应链的可控性和长期可维护性。

简单来说，不是因为 Java 不能继续用，而是要尽量避免网站已经完成国产化改造，最后却仍然在关键运行环境上留下一个长期受制于外部厂商授权和支持策略的环节。

6.2 JDK 可以根据项目要求选择国内维护的发行版

如果项目对信创、自主可控或软件供应链有相应要求，可以根据项目适配清单和验收标准，评估将原有 JDK 替换为符合要求的 OpenJDK 发行版。

例如本文以阿里云作为实施平台，在 Java 运行环境方面，可以根据实际项目要求评估 Alibaba Dragonwell（龙蜥 JDK） 等国内维护的 OpenJDK 发行版。

这里也不能简单理解成“把 Oracle JDK 换成一个国内 JDK，信创适配就完成了”。

更完整的过程应该是：

尽量保持原有 Java 业务代码不变 → 替换或升级 JDK 运行环境 → 检查数据库驱动和第三方组件 → 验证国产处理器、国产操作系统、国产数据库和中间件兼容性 → 完成功能、性能和稳定性测试。

这样做的好处，是在尽量减少业务代码改动的同时，把底层运行环境逐步调整到符合项目要求的技术体系中，也为后续长期运行、版本维护和安全更新留下更可控的空间。

6.3 PHP、Node.js 也是同样的思路

PHP、Node.js 等开发环境也是一样。

重点不是给开发语言贴一个“国产”标签，而是检查它们背后的运行时、扩展、原生模块、数据库驱动和第三方组件。

比如原来的 PHP 网站可能不需要重新开发，但某个扩展在新的国产操作系统上没有对应版本；Node.js 本身可以正常运行，但项目依赖的某个原生模块不支持目标处理器架构；程序代码没有问题，数据库驱动却无法正常连接新的国产数据库。

这些才是实际适配过程中更容易遇到的问题。

所以这一层的信创适配可以简单理解成一句话：

开发语言通常不用为了信创而重写，真正需要重点评估和替换的，是承载这些代码运行的基础环境和关键依赖。

代码可能很淡定，真正先举手反对的，往往是一个用了很多年的 JDK 版本、数据库驱动或者没人敢动的老插件。

如果适配过程中发现数据库连接、驱动、文件路径、接口或第三方组件存在兼容问题，就需要回到网站源码进行针对性调整。这并不意味着做一次信创改造就要把整个网站推倒重写，更多时候是根据测试结果定位具体依赖，再对相应配置或代码进行修改。

图-检查和调整企业网站源码1

图-检查和调整企业网站源码2

七、网站信创迁移怎么少停机：旧站继续跑，新环境先验证

该选的选好了，该适配的也基本跑通了，接下来就要面对一个很现实的问题：怎么把网站真正搬过去，而且尽量少影响正在访问的用户？我们更倾向于把大部分工作放在新环境里完成。旧网站继续对外服务，新环境在旁边部署、迁移、适配和测试。这个过程很像店铺搬家：新店先把水电、货架和收银系统试好，没必要第一天就把老店卷帘门拉下来。

旧站继续运行，就意味着期间还会新增新闻、产品资料或者其他内容，所以数据通常不能只迁一次。正式切换前，需要把这段时间新增和修改的数据补齐，再安排最终切换。

实际迁移时，通常还要把“网站文件”和“数据库”分开处理。网站源码、上传附件、图片等文件可以提前同步到新环境；数据库则根据业务情况安排初次迁移和最终增量同步。对仍在持续更新内容的官网来说，最后一次数据同步尤其重要，避免测试期间新增的新闻、图片或表单数据还留在旧环境里。

图-企业官网文件迁移1

图-企业官网文件迁移2

真正切换时，还要顺着访问链路再看一遍：正式域名解析、备案接入信息和SSL证书是否已经就绪；域名或公网入口进来以后，经过安全防护、代理或负载均衡，最终是不是落到新的应用和数据库上。否则最尴尬的情况不是新站打不开，而是大家庆祝“新站上线”以后，真正忙着出页面的还是那台兢兢业业的旧服务器。

八、企业网站信创上线前：安全漏洞扫描、渗透测试和性能验证

数据迁过来了，正式域名也准备切了，新网站测试访问一切正常——这时候是不是就能直接上线？

我们通常不会这么快下结论。

网站“能打开”和“适合正式上线”其实是两回事。信创改造动过操作系统、数据库、中间件和运行环境，原来没暴露的问题，到了新环境可能会换个地方冒出来。

所以在正式切换前，我们会把功能、安全和性能再过一遍。安全检查也不只是“跑一次扫描”。从实际报告的结构来看，基础环境会关注开放服务、HTTP/HTTPS、证书、SSL/TLS、SSH等内容；到了网站应用层，还要继续看登录与权限、会话、接口输入、文件上传、信息泄露以及CMS和中间件相关问题。

这有点像新办公室装修完以后验收：灯能亮只是说明通电了，门锁、消防、网络和各个房间能不能正常使用，还得一项项确认。网站也是一样，首页打开只是起点，不是安全检查的终点。

图-安全漏洞扫描报告示例-1

图-安全漏洞扫描报告示例-2

实际的安全扫描报告通常会把发现项按高、中、低风险分开，再按SSL/TLS、SSH、WWW等服务继续归类。读者并不需要逐条看懂每一个编号，项目真正关心的是：有没有需要优先处理的问题，问题落在哪一层，以及整改以后有没有重新验证。

渗透测试会再往应用里面走一步。登录、权限控制、会话、接口参数、文件上传这些地方，平时正常使用时可能看不出问题，只有换一个角度去尝试，才知道有没有能“绕过去的门”。这也是为什么扫描结果和渗透测试不能完全互相替代。

发现问题以后，报告不是终点。更关键的是形成“扫描或测试—确认风险—整改—复测—再上线”的闭环。体检报告打印得再漂亮，也不能替代治疗，这个道理放到网站安全上也一样。

性能测试则结合网站真实访问规模，看页面响应、数据库查询、上传下载和资源使用是不是正常。普通企业官网没必要为了一个漂亮数字把服务器压到“冒烟”，但至少要知道正常高峰来了，它能不能稳稳接住。

九、做完企业网站信创国产化改造，最后应该交付什么？

企业网站完成信创改造以后，交付的不应该只是“服务器已经开通、网站已经能访问”。从前期环境建设，到适配、迁移、测试和正式上线，过程中涉及的关键配置、验证结果和运维信息，都应该形成相应的交付记录。

不同项目的建设范围和验收要求会有所不同，一般可以从下面这些内容进行梳理：

这些材料放在一起，才比较接近一套完整的企业网站信创项目交付结果。它们不只是为了项目验收，后续网站升级、故障排查或者换人维护时，也能知道这套环境是怎么搭起来的、改过哪些地方、出了问题应该从哪里查。

十、几个关于网站信创改造的常见问题

前面的流程走完以后，还有几个在企业网站信创改造项目里经常被问到的问题，我们放在最后一起回答。

Q：企业网站信创国产化改造通常要改哪些东西？

通常会从云服务器和处理器选型开始，再看操作系统、数据库、中间件、CMS或网站程序、数据迁移，最后做到功能验证、安全漏洞扫描、应用安全测试、性能验证和上线切换。具体改到哪一层，要以项目要求和现有系统情况为准。

Q：选了国产处理器，是不是就算完成云上信创了？

还不够。处理器只是底座，后面还要看操作系统镜像、数据库、中间件和应用能不能在这套组合里正常工作。把几个国产产品名称放在一起，并不等于业务已经跑通。

Q：应用服务器和数据库一定要分开吗？

不是绝对要求，但正式企业官网通常值得优先考虑分开部署。访问量很小、要求简单时，也可以结合预算和安全要求调整。架构不是台数越多越正确。

Q：Java、PHP这些开发语言一定要换吗？

先看项目要求。即使语言本身不要求替换，也要确认JDK、PHP版本、扩展、数据库驱动和相关组件能否在目标处理器和操作系统上稳定运行。

Q：数据库换成国产数据库，网站代码一定要改吗？

不一定。原网站使用的SQL越简单，适配可能越轻；如果大量使用特定数据库的函数、存储过程或特殊语法，需要调整的地方就会更多。最终还是要通过实际测试判断。

Q：网站信创改造期间会停很久吗？

多数部署、适配和测试可以提前在新环境完成。真正需要控制影响的，通常是最后的数据同步和流量切换。前面的验证做得越充分，最后的切换窗口越容易控制。

准备建设、改版或做信创适配？先把官网现状和目标理清楚

说到底，不同企业现在面对的问题并不一样。有的是准备从零建设官网，有的是现有网站用了很多年，需要重新设计和升级；也有一些央国企和大型集团，在官网建设之外，还要同时考虑国产化、信创适配和安全要求。

我们参与过央国企及大型企业官网建设、改版和技术适配项目。无论你现在是准备新建官网、旧站改版、迁移上云，还是在现有网站上推进信创国产化改造，都可以先把现有情况、功能需求和目标环境梳理清楚。先弄明白网站要解决什么，再决定是重建、迁移还是适配，通常比一开始就围着产品清单转更省事。