Docker部署Spring Boot MVC应用扩容多实例后出现异常

端口硬编码是否是问题根源？ #

分两种情况判断：

• 同一EC2实例运行多个容器副本：如果Docker stack.yml中硬编码了主机端口（例如ports: - "8080:8080"），同一主机的端口无法被多个容器绑定，理论上会有实例启动失败，但你提到日志显示所有实例正常启动，这种情况概率较低。可能是你实际使用了动态端口映射（比如ports: - "8080"），只是误以为是硬编码。
• 每个EC2实例运行一个容器副本：硬编码主机端口（比如每个EC2的8080端口映射容器8080）本身没问题，不会导致端口冲突，这种情况下端口不是问题根源。

核心排查方向与解决方案 #

1. 会话一致性问题（最可能的原因） #

Spring Security默认依赖HttpSession存储用户登录状态，多实例部署时如果没有共享会话存储，负载均衡会将请求随机分发到不同实例：

• 当请求落到未保存用户会话的实例时，会触发重新登录逻辑，甚至因会话状态不一致导致ERR_INVALID_RESPONSE。

解决方案：
配置Spring Session共享会话，以Redis为例：

1. 添加Maven依赖：

<dependency>
    <groupId>org.springframework.session</groupId>
    <artifactId>spring-session-data-redis</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>

2. 在application.properties中配置Redis连接：

spring.redis.host=your-redis-host
spring.redis.port=6379
spring.session.store-type=redis

这样所有实例共享会话数据，无论请求分发到哪个实例，都能正确识别用户登录状态。

2. 负载均衡健康检查配置问题 #

如果负载均衡的健康检查配置不合理，可能会将请求转发到未完全启动或已异常的实例，导致间歇性错误：

解决方案：

• 配置健康检查路径为Spring Boot Actuator的健康端点（需先引入spring-boot-starter-actuator依赖）：/actuator/health
• 调整健康检查的间隔（如30秒）和超时时间（如5秒），确保实例完全启动后才被加入负载均衡池
• 检查负载均衡目标组的端口配置，确保指向容器的监听端口（而非随机主机端口，如果用了动态映射）

3. Docker端口映射优化 #

如果确实在同一EC2运行多个容器副本：

• 不要硬编码主机端口，改用动态端口映射：

services:
  your-app:
    image: your-image:tag
    ports:
      - "8080"  # Docker会随机分配主机端口

• 确保AWS负载均衡的目标组配置为容器端口（例如8080），而非主机端口，这样负载均衡能自动发现容器的实际端口。

4. 资源竞争问题 #

多实例运行在同一EC2时，可能出现CPU、内存不足，导致实例偶尔无法处理请求：

• 查看EC2的监控指标（CPU使用率、内存使用率），确认是否存在资源瓶颈
• 调整EC2实例规格，或减少单EC2上的实例数量

5. Spring Security补充配置检查 #

• 若未禁用CSRF，多实例下CSRF Token存储在会话中，会话不共享会导致验证失败，可临时添加.csrf().disable()测试（不推荐生产环境禁用，优先解决会话共享）
• 确保登录页面的请求路径/content/login在所有实例上都能正常访问，检查Controller是否有遗漏的映射

内容的提问来源于stack exchange，提问作者Jon H