企业官网建设流程全解析

1. 从一次“三方会谈”说起：war包问题到底卡在哪

先交代背景。最近接手一个老项目，SpringBoot + SpringCloud微服务架构，模块拆了十多个，平时本地IDE里mvn spring-boot:run跑得飞起，注册中心、配置中心、网关、业务服务各玩各的，一切岁月静好。直到甲方甩过来一句话：公司内网环境不允许跑jar，必须部署到已有的Tomcat容器里，而且要走传统的war包方式。

我当时第一反应是：SpringBoot不是内置Tomcat吗，打jar直接java -jar不就完事了？但内网环境和运维规范摆在那里，容器路径、启动脚本、日志采集都是围绕Tomcat搭的，硬上jar意味着要改一整套运维体系，不现实。只能改造成war。

真正动手才发现，SpringCloud微服务环境下打war包，跟单体SpringBoot打war完全不是一回事。网上搜了一圈，大部分教程讲的是单模块SpringBoot转war，步骤倒也简单：改打包方式、继承SpringBootServletInitializer、排除内置Tomcat。但一旦换成SpringCloud多模块工程，问题一下子变得立体起来——依赖怎么处理、注册中心怎么连、配置中心怎么加载、网关路由怎么配、静态资源路径怎么算，全都没人系统讲。

这篇文章就是把我在生产环境实操踩坑的过程完整记录下来。整个过程从改造pom到最终三套服务全部在Tomcat里跑通，前后花了一天半时间。后面所有内容我都按“先讲原理，再给做法”的方式写，尽量让看完的人能少走弯路。

2. 为什么SpringCloud多模块war比想象中麻烦

2.1 单模块改造的“经典三步”为何不够用

传统SpringBoot单体应用转war，业内总结的三步操作长这样：

• pom.xml里将<packaging>从jar改成war；
• 启动类继承org.springframework.boot.builder.SpringBootServletInitializer，并重写configure方法；
• 在pom.xml中把内置Tomcat依赖的scope标记为provided，避免和外部Tomcat冲突。

这套逻辑本身没毛病，原理也简单：SpringBootServletInitializer能让SpringBoot应用被外部Servlet容器识别，通过WebApplicationInitializer机制完成启动。但到了SpringCloud多模块环境下，光做这三步远远不够。因为每个微服务模块不只是“一个SpringBoot应用”，它还同时是注册中心客户端、配置中心客户端、网关路由节点，这些角色会引入额外的初始化和启动时序问题。

我见过不少人卡在第一步就懵了：打出来的war包只有几十KB，丢进Tomcat后应用压根不启动，日志只报“Unable to start web server”。原因就是多模块工程里依赖继承关系复杂，子模块改了packaging以后，父pom和兄弟模块的依赖机制没有同步调整，导致真正的业务代码没有被打进war包，war里只有壳。

2.2 多模块war打包的三个隐藏难点

多模块SpringCloud工程打war，我实操下来主要有三个隐藏难点，这几个难点在官方文档和大多数教程里都找不到现成答案：

第一，依赖剪裁与瘦身。多模块工程的每个服务模块可能依赖了三四个兄弟模块，这些兄弟模块里又会传递引入一堆中间件客户端（比如Redis、MQ、ORM），全部打进war会让war包体积动辄两三百MB，Tomcat启动时要加载老半天。而且依赖里如果混入了和外部Tomcat冲突的Servlet API版本，启动阶段就会报class加载错误。

第二，外部化配置的优先级重置。SpringBoot原本的配置加载顺序里，jar包同级的config目录、环境变量、命令行参数各有优先级。改装war以后，很多配置不再从原来的路径读取，而SpringCloud的配置中心地址如果还写死在application.yml里，各种环境的切换就会变得很僵硬。

第三，资源路径和上下文路径。同一个Tomcat里往往不止部署一个服务，每个war的context-path如果不统一规划，静态资源、接口调用路径、网关转发路径全都会乱套。SpringCloud网关的StripPrefix配置也会跟着受影响，前后端联调时简直是连环坑。

这三个难点集中在一起，决定了多模块war不能靠简单“复制粘贴单模块方案”来搞定，必须有一套整体设计。

3. 开头先想清楚三件事再动手改代码

3.1 第一件事：确认部署形态选“单Tomcat多应用”还是“多Tomcat单应用”

动手改pom之前，得先想明白一个根本问题：是全部微服务塞进同一个Tomcat，还是每个服务各自用一个Tomcat？这两种形态对改造的影响天差地别。

如果选单Tomcat多应用，节省机器资源，运维管理集中，但要注意几个麻烦：所有war包共享同一个JVM，存在内存竞争和类加载器隔离问题；各服务的context-path必须不同（比如http://ip:8080/order/、http://ip:8080/user/）；配置中心、注册中心这些基础组件一般不会放在这个Tomcat里，需要独立部署。

如果选多Tomcat单应用，每个服务一个Tomcat实例，相互隔离更干净，也能单独重启和调优，但机器资源占用高，端口规划麻烦。我这次因为内网资源紧张，选了第一种——单Tomcat挂三个业务服务，注册中心和配置中心单独拿两个轻量Tomcat部署。这个选择直接影响了后续所有路径和端口设计。

个人建议：如果你的场景里微服务数量不多（十个以内）、并发压力不大，单Tomcat多应用完全可以接受；一旦服务数量上去了，或者某个服务有独立的性能要求（比如网关、文件服务），就别省那点资源，老老实实一台Tomcat一个服务。

3.2 第二件事：统一版本和依赖管理，避免war包变成“杂货铺”

多模块工程最常见的坑之一就是各模块的依赖版本参差不齐。开发阶段还好，因为SpringBoot的依赖仲裁机制能自动兜底；但打war部署到Tomcat后，外部容器的类加载机制变了，各种隐形的版本冲突都会被放大。

我之前接手这个项目时，父pom里SpringBoot版本是2.2.x，SpringCloud是Hoxton.SR系列，但因为模块多、开发周期长，个别子模块里散落着一些历史遗留依赖，版本不统一。改造前我花了一个小时专门做了一次“依赖审计”：

mvn dependency:tree -Dverbose > dependency-all.txt

然后人工扫了一遍输出结果，重点看有没有如下情况：

• 同一个groupId + artifactId出现多个版本；
• 意外引入了不同版本的Servlet API；
• 子模块里有与父pom冲突的SpringBoot/SpringCloud版本锁定。

发现并修复了两个问题：一个是某个工具模块里藏了一个旧版javax.servlet-api，另一个是某个业务模块里多引了一个没用的spring-boot-starter-tomcat依赖。这两个问题如果不提前清掉，就算war能打出来，Tomcat里跑起来也会出幺蛾子。

3.3 第三件事：规划好端口、路径与注册中心地址

改代码之前先把部署拓扑定下来，后面所有配置都有据可依。我当时定了一套简单的规划表：

这里面注册中心和配置中心的war是静态war（没有内置SpringBoot Servlet初始化器逻辑，而是传统SpringMVC方式），其实理论上也可以用jar跑，但既然运维要求统一Tomcat，就一起改了。业务服务统一挂在Tomcat-B下，用不同context-path区分。

需要注意的是，这种规划里网关的server.servlet.context-path通常是空的（根路径），因为它要对外统一暴露入口；业务服务的context-path则必须和网关转发时的StripPrefix配置对齐，否则会闹出“网关转发成功但业务服务404”的经典事故。

4. 手工一步步实现多模块springcloud war包改造

4.1 第一步：修改父pom与子模块的packaging约定

首先确认你的多模块工程结构。我的项目结构大概是这样的：

springcloud-demo ├── pom.xml (父模块，packaging=pom) ├── common-module (公共工具模块) ├── eureka-server (注册中心) ├── config-server (配置中心) ├── gateway-service (网关服务) ├── order-service (订单服务) └── user-service (用户服务)

要打war包，需要明确一条规则：只有真正要独立部署的应用模块需要改成war，公共模块和基础库保持jar不变。具体操作上，就是每个独立应用模块的pom.xml里加上：

<packaging>war</packaging>

而父pom和公共模块维持jar或pom不变。这一步看着简单，但很多人会顺手把父pom也改成war，结果整个工程全部乱套。记住一句话：改成war的模块，是未来能被Tomcat直接启动的模块；公共依赖模块改了war毫无意义，还会破坏依赖传递关系。

4.2 第二步：给启动类增加Servlet初始化支持

每个需要打成war的SpringBoot应用模块，启动类需要做如下改造：

@SpringBootApplication @EnableDiscoveryClient @EnableFeignClients public class OrderServiceApplication extends SpringBootServletInitializer { @Override protected SpringApplicationBuilder configure(SpringApplicationBuilder builder) { // 注意这里要return的是builder return builder.sources(OrderServiceApplication.class); } public static void main(String[] args) { SpringApplication.run(OrderServiceApplication.class, args); } }

这里的关键点有两个。第一，必须继承SpringBootServletInitializer，并且重写configure方法，让外部Tomcat能把应用加载进Servlet容器。第二，configure方法里的sources要指向当前启动类；如果你的配置类不是启动类（比如用了独立的@Configuration类做配置源），这里就要指向那个配置类。

有个容易踩的坑是：有些SpringCloud项目会在启动类上加@EnableEurekaClient或@EnableConfigServer之类的注解，这些注解本身和war改造不冲突，但你要确认这些注解对应的自动装配类能被正确扫描到。如果启动类换了位置（比如包路径变了），扫描不到注册中心客户端配置，war包启动后会出现无法注册到Eureka的情况。

4.3 第三步：排除内置Tomcat，务必用provided作用域

SpringBoot默认通过spring-boot-starter-web里的内置Tomcat启动应用。打war包部署到外部Tomcat时，这个内置Tomcat必须排除掉，否则会出现两个Tomcat抢端口的冲突，通常表现是启动时报“Port already in use”或者奇怪的类转换异常。

标准做法是在pom.xml中把spring-boot-starter-tomcat的scope设为provided：

<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-tomcat</artifactId> <scope>provided</scope> </dependency>

不过在实际多模块工程里，你会遇到一个更讨厌的情况：子模块不直接依赖spring-boot-starter-web，但通过别的兄弟模块间接拿到了web启动器，这时你要排除内置Tomcat，就得用exclusions排除传递依赖：

<dependency> <groupId>com.example</groupId> <artifactId>common-web-starter</artifactId> <exclusions> <exclusion> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-tomcat</artifactId> </exclusion> </exclusions> </dependency>

这里有一个安全边界：provided作用域意味着“编译和测试时存在，运行时由外部容器提供”。所以war包解压出来后，WEB-INF/lib下不会有内置Tomcat的jar，而外部Tomcat自带的Servlet API和容器类会被用到。这样既避免了冲突，也让war包体积进一步变小。

4.4 第四步：配置三个地方保障注册中心与配置中心可用

SpringCloud的核心机制就是注册中心与配置中心。war包部署后，如果这两个地方没配好，业务服务即使启动也会处于“游离”状态。

第一处是注册中心自身的配置。如果你用Eureka做注册中心，要确保它的application.yml里配置了正确的端口和hostname，并且设置register-with-eureka: false、fetch-registry: false（单节点模式），避免它自己跟自己注册：

server: port: 8080 eureka: instance: hostname: localhost client: register-with-eureka: false fetch-registry: false

第二处是服务提供方（业务服务）的注册配置。每个业务服务的application.yml里，要明确写好Eureka服务器的地址和自身实例的IP、端口。注意端口这块，因为war包由外部Tomcat提供服务，实际端口就是Tomcat的HTTP端口（比如8081），而不是某个随机端口。如果你之前用的是server.port=0随机端口策略，走war部署时必须改成固定的物理端口，否则注册中心里会出现一堆莫名其妙的随机端口实例。

第三处是配置中心的加载顺序。SpringCloud Config客户端在启动时，会先去拉取远端配置中心的配置，拉取成功后才真正启动应用上下文。war包部署在Tomcat里时，这个“先拉配置再启动”的顺序依然生效，但有个隐患：如果Tomcat启动时配置中心还没就绪，客户端应用会反复重试，最终可能启动失败。所以部署顺序上，别一股脑全把war包丢进Tomcat的webapps目录，让Tomcat一次全启动，建议分两批：先启动注册中心和配置中心，等它们完全可用后，再启动业务服务和网关。

4.5 第五步：使用maven命令打war，并验证war包结构

全部改完之后，进入工程根目录执行：

mvn clean package -DskipTests

注意这里我特意加了-DskipTests，因为多模块工程里很多单测会启动Spring上下文，一旦依赖环境不完整（比如测试阶段连不上配置中心），会导致打包失败。如果你对单测没把握，就跳过，后面有时间再单独跑。

打包完成后，进入每个应用模块的target目录，找到生成的.war文件。这里一定要验证war包结构：

jar tf order-service.war

正常war包应该包含如下层次：

WEB-INF/ classes/ # 编译后的class和resources lib/ # 所有依赖jar包（不含内置Tomcat） web.xml # 由SpringBoot生成的Servlet初始化描述 META-INF/ MANIFEST.MF

如果发现WEB-INF/classes下没有你的配置文件，或者WEB-INF/lib里没有spring-boot-starter-tomcat，那说明打包逻辑出了问题。最典型的异常表现在这个阶段：war包只有几KB，内容只有META-INF/MANIFEST.MF，这是因为模块里没有真正的代码依赖（比如换成war后，子模块没依赖到父模块的具体模块），或者打成的是“空壳war”。

4.6 第六步：部署到Tomcat并检查启动日志

将打好的war包复制到Tomcat的webapps目录下：

cp order-service.war /opt/tomcat8081/webapps/ cp user-service.war /opt/tomcat8081/webapps/ cp gateway-service.war /opt/tomcat8081/webapps/

启动Tomcat：

/opt/tomcat8081/bin/catalina.sh start

然后必须第一时间看日志，不要直接去访问接口。日志位置一般在/opt/tomcat8081/logs/catalina.out。关注以下几个关键日志点：

• 注册中心是否被成功加载；
• 配置中心是否拉取到远端配置；
• 服务是否成功完成实例注册；
• 网关路由是否加载到服务列表。

如果启动了却没看到这些日志，八成是war包没被正确解析。这时候要看localhost.log，Tomcat会在里面记录war包部署失败的具体原因，比如类加载异常、找不到SpringBootServletInitializer、端口冲突等。

5. 三个核心服务的改造实录与最终效果

5.1 注册中心Eureka war化：一个“假war”也藏坑

我们的注册中心用的是Eureka Server。严格来说，它本身是SpringBoot应用，但只需要页面和注册接口，改造逻辑相对简单。不过有两个细节值得注意。

第一，注册中心不需要自定义context-path为空时，访问地址就是http://ip:8080/，如果加上Eureka默认的context路径，页面会变成http://ip:8080/eureka。我给注册中心设的context-path是/eureka，这样在浏览器里访问Eureka控制台的路径是http://ip:8080/eureka/，所有服务的注册地址也带上这个前缀。

server: servlet: context-path: /eureka port: 8080

第二，注册中心的启动类也要继承SpringBootServletInitializer，做法和普通业务服务一样。但这里我遇到一个匪夷所思的问题：继承后启动，Eureka控制台界面加载出HTML了，但所有静态资源（CSS、JS）全部404。排查半天发现是context-path的影响——Eureka的静态资源路径依赖根路径，如果自定义了路径，它不会自动感知。解决方式也很粗暴：给Eureka加了一层路径重写过滤器，把/eureka/下的静态资源请求映射到正确位置。这个坑在jar部署时完全不会出现，纯粹是war+context-path组合引发的。

5.2 网关服务war化：路由与StripPrefix的“恩怨”

网关服务用的是Spring Cloud Gateway。war化以后有个大坑：Spring Cloud Gateway基于WebFlux，默认不依赖Servlet容器。你可能会想，它靠Netty跑，怎么打war？实际上Spring Cloud Gateway确实能在Servlet容器里跑，但方式不同——它会以Servlet适配形式运行在外部Tomcat中。

这意味着网关模块的pom里除了排除内置Tomcat，还得确认它没有错误地加入spring-boot-starter-web（WebFlux和SpringMVC不能共存，否则启动直接报错）。我的做法是网关模块明确只用spring-boot-starter-webflux，不引入spring-boot-starter-web。

gateway的路由配置，需要留意context-path和StripPrefix的配合。比如订单服务部署在http://localhost:8081/order，网关希望对外暴露成http://localhost:8081/api/order/**，那么路由配置可以写成：

spring: cloud: gateway: routes: - id: order-service uri: lb://order-service predicates: - Path=/api/order/** filters: - StripPrefix=1

这里StripPrefix=1会把/api剥掉，转发给后端服务时路径变成/order/**，而订单服务本身的context-path就是/order，所以正好能对上。如果搞反了，比如后端服务的context-path是空，你却又配了StripPrefix，后端404就是家常便饭。

网关这种对转发路径高敏感的服务，最适合在改war之前先用jar跑通一版路由，确认逻辑没问题，再进行war化，排查起来会轻松很多。

5.3 业务服务war化：注册成功但调用失败？多半是instanceId惹的祸

业务服务的war化步骤和普通服务一样，继承SpringBootServletInitializer、排除Tomcat、改packaging，理论上不复杂。但我实际部署后遇到了一个非常隐蔽的bug：服务启动成功、注册中心里也看得见实例，可是微服务之间用Feign调用却一直超时失败。

排查到最后，问题出在eureka.instance.instance-id配置上。原来jar部署时，实例的IP和端口是直接注册的（比如192.168.1.10:8082）；但改war后，服务实际跑在Tomcat里，对外端口变成了Tomcat的8081，而server.port如果还保留着旧值8082，注册中心里就会登记一个不存在的端口，调用方按照这个错误端口去请求，自然是必败无疑。

解决办法是在每个业务服务里显式指定注册实例的IP和端口：

eureka: instance: prefer-ip-address: true instance-id: ${spring.cloud.client.ip-address}:${server.port} ip-address: 192.168.1.100

并且确认server.port和外部Tomcat的实际端口一致。如果你想完全避免手动指定IP，也可以利用spring.cloud.client.ip-address自动获取，但在多网卡环境下，手动指定更稳。

另外一个就是Feign的HTTP客户端连接超时。war包部署走Tomcat，Tomcat默认keep-alive和连接池行为和Netty不太一样，Feign调用容易因为连接懒加载或超时时间太短而失败。建议在配置里给Ribbon或Feign的超时参数留足余量：

ribbon: ReadTimeout: 60000 ConnectTimeout: 30000

别问我为什么会莫名其妙超时，我排查了一个多小时才怀疑到超时配置。Tomcat启动时线程池预热慢、类加载多，第一次Feign调用极易踩着默认1秒超时线。

6. 部署成功后的验证思路与效果分析

6.1 如何确认所有服务真正注册成功

部署完成后，不要急着点接口，先把验证流程走完整。第一步看注册中心控制台，确认所有业务服务实例都在UP状态。如果Eureka配置了context-path，那就访问http://localhost:8080/eureka/。

第二步，检查网关是否拉到了路由。Spring Cloud Gateway配合注册中心时，路由通常用lb://前缀，这意味着网关会从注册中心动态发现服务实例。如果网关控制台日志里能看到从Eureka拉取到服务实例的动作，说明“发现”环节没问题。

第三步，找一个不依赖外部参数的内部接口做一次完整调用链路测试：前端请求网关、网关转发到业务服务、业务服务之间再通过Feign调用另一个服务。这一步跑通了，整套war化才算真正成功。

我在现场跑通了一个下单接口，完整链路是：浏览器访问网关/api/order/create，网关路由到订单服务，订单服务再Feign调用用户服务获取用户信息，最终返回下单结果。整个过程日志无error，注册中心三个实例稳定UP，那一刻才算松了口气。

提醒一下：Eureka有默认的自我保护模式，如果服务实例注册后最早几秒内显示红色不可用，不一定是真故障，先等一两分钟让它心跳稳定再说。别一看变红就重启Tomcat，这是新手最常干的事。

6.2 性能与体积结果

我这次改完的war包大小如下（压缩后）：

相比jar包并没有变大太多，因为排除了内置Tomcat后，省掉了一部分体积。启动时间比jar包略慢1-2秒，主要开销在Tomcat容器初始化和Servlet上下文加载上，完全可以接受。

6.3 稳定性实测与处理策略

部署后我连续压测了一小段时间，观察内存和GC情况。单Tomcat挂三个应用，初始堆内存占用大概1.2GB左右，堆外内存和元空间也会一起吃，给Tomcat的JAVA_OPTS留充足空间很重要。

我的启动参数可以参照：

JAVA_OPTS="-Xms1024m -Xmx1536m -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m"

如果Tomcat里挂的应用更多，建议加大元空间，因为每个SpringBoot应用都会加载大量class和动态代理类，元空间默认上限容易被顶满。

稳定性方面，三天内未出现服务掉线或内存泄漏迹象。唯一要注意的是Tomcat的access log默认会不断累积，如果磁盘空间紧张，建议配置日志滚动策略。

7. 常见问题与排查技巧实录

7.1 启动报错“Unable to start web server”

这个报错最常见于改造不彻底。原因通常是war包启动时，SpringBoot容器初始化器没有生效，或者恰好有两个WebServerFactoryCustomizer导致逻辑混乱。排查顺序是这样的：

1. 确认启动类是否继承了SpringBootServletInitializer，以及configure方法是否写对；
2. 确认pom里是否排除了内置Tomcat，且provided作用域没写错位置；
3. 确认war包结构里有没有WEB-INF/classes和WEB-INF/lib，如果war只有几KB，基本就是依赖没打进去。

7.2 context-path 导致Feign调用404

业务服务加context-path后，服务之间的Feign调用路径要同步处理。比如订单服务Feign调用用户服务，如果用户服务context-path是/user，那么Feign客户端注解里的路径也必须以/user开头：

@FeignClient(name = "user-service") public interface UserFeignClient { @GetMapping("/user/info") String getUserInfo(@RequestParam("id") Long id); }

如果不加/user前缀，Feign调用会落到用户服务的根路径上，然后404。这个坑在jar部署时因为没设context-path，基本不会出现；一旦war化引入context-path，就必须重新梳理所有Feign接口路径。

7.3 外部Tomcat的版本不要高于SpringBoot支持版本

SpringBoot 2.2.x支持的Servlet规范是4.0。如果你外部Tomcat用了较新版本（比如Tomcat 10+），它默认支持的是Servlet 5.0+规范，而SpringBoot 2.x用的还是javax.servlet包。两者冲突的典型表现是启动时各种NoClassDefFoundError，或者初始化器无法被识别。

所以先确认SpringBoot版本对应的Servlet规范，再选择Tomcat版本。如果是SpringBoot 2.x系列，用Tomcat 9.x是最稳的。别用太新的Tomcat，除非你把SpringBoot升级到3.x并全面切换到jakarta.servlet命名空间。

7.4 配置中心启动顺序导致的连环失败

如果配置中心没先启动，业务服务war在Tomcat里就会反复拉配置失败，最终启动中断。小技巧是给配置中心客户端的重试次数和超时时间调大一点：

spring: cloud: config: fail-fast: false retry: max-attempts: 30 max-interval: 5000

这样即使你手误把业务服务和配置中心同时丢进了Tomcat启动，业务服务也会等配置中心起来后继续启动，而不是启动失败。

这类问题排查时最好养成看启动顺序日志的习惯：先看配置中心日志，再看业务服务日志，上线时严格按依赖顺序部署，能省去大量无意义的故障排查时间。

7.5 常见问题速查表

8. 这套方案的实际适用范围与后期改进建议

8.1 什么场景适合用war部署

经过这次改造，我的体会是：war部署不是银弹，但在特定场景下确实是最优解。适合war化的场景包括：

• 内网环境已有成熟的Tomcat集群管理工具、监控脚本和统一日志采集，无法快速切换到jar部署模式；
• 运维团队对Tomcat有强运维规范，节点注册、启停、健康检查全部围绕Tomcat接口实现；
• 单机部署多服务，希望通过Tomcat的ClassLoader隔离来降低部署复杂度（虽然隔离并不彻底）。

不适合war化的场景也很明确：如果你一切从零开始，没有历史包袱，也没有强制容器要求，直接jar+容器编排是更省心的方案。war包部署本质上是在用“传统容器的兼容性”交换“SpringBoot原生体验的简化”。

8.2 可以从哪些层面继续优化

这次跑通以后，我又整理了三个后续优化方向：

1. 统一配置外置：war包里的application.yml虽然能跑，但每次环境变更都要重新打war，很蠢。最好是让Tomcat启动时读取外部配置文件，利用SPRING_CONFIG_LOCATION环境变量或者–spring.config.location参数指定外部目录，这样war包可以做到环境无关。

2. 加一层软负载均衡：单Tomcat多应用虽然省资源，但网关和业务服务挤在一起，热修一个服务会影响另一个。可以考虑在前面加一层软负载（如Nginx），按路径分发到不同的Tomcat实例，降低耦合。

3. 构建流程脚本化：多模块工程四个应用模块，每回手动mvn package再手动拷贝war包，次数多了容易出错。可以写一个简单的shell脚本，把打包、拷贝、重启Tomcat、检查日志这几个动作串起来，能节省大量重复劳动。

这套流程走完，我对SpringCloud多模块war化部署算是彻底摸清了。如果你也在做类似改造，按我上面这套顺序来：先想清楚部署形态，再改pom和启动类，然后配置好外部化参数，打包部署，最后严格验证注册和调用链路，基本上不会出现大问题。中间那些小坑，我踩过的都已经写进常见问题速查表里了，遇到类似报错直接对号入座，比什么都强。