阳光那么灿烂的最近刚帮客户做完一轮Nacos的信创改造，核心要求就一句话：把Nacos默认内嵌的Tomcat换掉，统一改成保兰德的Web中间件。这活儿看着简单，真落地的时候全是细节。Nacos自身是Spring Boot应用，默认用内嵌Tomcat对外提供HTTP服务，信创环境要求中间件必须是国产可控产品，于是Tomcat就成了第一个要“动刀”的地方。这篇文章我把整个改造过程、踩过的坑和验证思路完整记录下来，主要面向做信创适配的Java后端、运维和中间件工程师。整篇文章会围绕Nacos 2.5.4版本展开，替换目标以保兰德中间件为例，思路同样适用于同类型的国产应用服务器。
1. 改造前先理清思路：为什么是Nacos，为什么动Tomcat
1.1 Nacos默认架构里的Tomcat是什么角色
Nacos在信创项目中几乎是绕不开的组件，分布式系统里服务注册、配置管理都靠它。但很多人没细想过，Nacos本身并不只有一个“注册中心”的身份，它的控制台、开放API、配置推送通道，都是跑在一个Web容器里的。
默认情况下，这个Web容器就是Spring Boot内嵌的Tomcat。Nacos控制台的管理页面、/v1/ns、/v1/cs这类HTTP接口，全部由Tomcat处理。换句话说，你日常打开Nacos控制台、通过SDK调用它的Open API，流量其实都经过了内嵌Tomcat。
这里面有个关键点很多人容易忽略：Nacos 2.x开始，客户端和服务端之间的核心通信已经改成gRPC了，走的是Netty端口，默认是8848再加上1000偏移，也就是9848。这段链路从头到尾不经过Tomcat，是Nacos自己用Netty拉起来的。
所以严格说，把Nacos里的Tomcat替换成保兰德，替换的是“HTTP对外服务层”，不是“整个运行时”。这个边界如果不在一开始划清楚，后面做方案的时候就会被绕进去。
改造前的第一件事，就是梳理清楚哪些流量走Tomcat、哪些流量走Netty。以我这次基于Nacos 2.5.4的实测来看，走Tomcat的部分主要是控制台静态资源、登录鉴权接口、HTTP Open API、部分管理端点。而服务注册发现、配置监听推送这些核心链路，走的是gRPC。
1.2 保兰德中间件好在哪，替换的真正目标是什么
保兰德是国内比较常见的Java应用服务器中间件，在信创名录里经常能见到它。它面向的是企业级Java应用部署场景，和Tomcat这种“嵌入式容器”定位不同，它更像一个完整的应用服务器，自带管理控制台、集群管理、JVM监控、部署发布这类能力。
替换的真正目标并不是“把Tomcat干掉”这么简单，而是把Web容器这个底座换成一个符合信创要求、可统一管控、有服务化运维能力的中间件。
打个比方，Tomcat像是一个随应用一起运行的嵌入式引擎，启动方便但分散在各应用里，每套应用都得单独维护。保兰德这类中间件像一个“公共机房”，多个应用可以部署在同一个中间件实例下，由统一的控制台去管理，监控、日志、启停都在一个地方。
这在信创大环境里很重要。等保合规、国产化验收的时候，中间件清单里写的是保兰德，而不是一堆分散的Tomcat，审计上少了很多麻烦。
但这里也要泼一盆冷水：替换容器不能只停留在“能跑起来”，必须保证原有功能完全兼容，还要考虑部署形态变化带来的连锁问题。比如Nacos原本是单进程直接启动的，现在变成war包扔到中间件里，进程管理、日志路径、环境变量、端口占用就全都变了。
1.3 替换前需要明确的边界
结合我这次实操，建议在动手前先把“改什么”和“不改什么”列成一张表，免得改着改着把手伸到不该碰的地方。
不改的部分很明确：Nacos的核心逻辑、服务发现算法、配置管理模型、gRPC通信层统统不动。这些是Nacos之所以是Nacos的东西，改了他们等于自己重写了一个注册中心，维护成本直接失控。
必须改的部分主要有四个方面：
一是打包形式，Nacos默认是Spring Boot的fat jar，要部署到保兰德浏览器里，必须改成war包，并且把内嵌Tomcat依赖的scope调成provided。
二是部署方式，从“直接执行startup.sh启动一个进程”变成“上传war包到中间件管理控制台发布”，启动方式、启停命令、开机自启逻辑都要重新适配。
三是端口和会话，8848这个HTTP端口原来由Tomcat监听，替换后要交给保兰德接管，9848的gRPC端口还是Nacos自己监听，两项要分开考虑。控制台登录态的管理也随着容器切换发生变化，保兰德有自己的会话机制。
四是安全和存储，信创环境对数据库国产化有要求，很多项目会顺手把后端从MySQL换成达梦；同时Nacos默认不开鉴权，这种“裸奔状态”在等保环境下是肯定过不去的，必须借助这次改造一并处理。