欢迎阅读我的文章！更多精彩内容，欢迎关注：
• B站主页：🫱小枫Geek
• 微信公众号：Procode  

---

前言

随着 容器化与 Kubernetes 的普及，越来越多的 Spring Boot 应用运行在容器编排环境中。容器化让部署与扩缩容变得更容易，但同时也带来了一些 网络相关的新问题：

• Pod IP 动态变化，导致直连服务不可用。

• 负载均衡策略不当，引发请求漂移或长连接中断。

• 会话保持未配置，出现“用户频繁掉线”“登录状态丢失”的情况。

本文将深入剖析这些问题产生的原因，并提供最佳实践方案。

---

一、Pod IP 动态变化问题

1. 问题场景

在 Kubernetes 中，Pod 是最小的运行单元：

• Pod 被销毁或重建时，IP 会发生变化。

• 如果 Spring Boot 应用或外部服务依赖 Pod IP，会出现连接失败。

举个例子：

• 服务 A 通过 Pod IP 调用服务 B。

• 当服务 B 滚动更新时，Pod IP 改变，A 无法再访问 B。

2. 解决方案

✅ 使用 Service 代替 Pod IP

• Kubernetes 提供了 Service 作为稳定的访问入口。

• Service 会自动将流量转发到后端 Pod。

apiVersion: v1
kind: Service
metadata:
  name: myapp-service
spec:
  selector:
    app: myapp
  ports:
    - protocol: TCP
      port: 8080
      targetPort: 8080

Spring Boot 服务之间调用时，使用：

http://myapp-service:8080

而不是 Pod 的 IP。

✅ DNS 解析

• Kubernetes 内置 DNS，可通过 <service-name>.<namespace>.svc.cluster.local 访问。

---

二、负载均衡问题

1. 问题场景

当 Spring Boot 应用运行在多副本模式下：

• Service 会将请求负载均衡到多个 Pod。

• 默认的负载均衡是 Round Robin（轮询）。

问题：

• 某些请求需要“粘性”，但流量可能被打散。

• WebSocket、SSE 等长连接被中途切换，导致断开。

2. 解决方案

方案一：开启会话粘性（Session Affinity）

在 Kubernetes Service 中配置 sessionAffinity: ClientIP：

spec:
  sessionAffinity: ClientIP

这样，来自同一客户端 IP 的请求会始终转发到同一个 Pod。

📌 适用场景：短期内保持会话一致，例如购物车、短期登录。

---

方案二：Ingress / Nginx Sticky Session

如果使用 Ingress，可以配置 基于 Cookie 的会话保持：

upstream myapp {
    sticky cookie srv_id expires=1h path=/;
    server pod1:8080;
    server pod2:8080;
}

📌 优点：更灵活，可跨 IP 保持会话。 📌 缺点：Pod 挂掉时，Cookie 会话可能失效。

---

方案三：外部负载均衡（如 ALB、SLB）

在云环境中（如 AWS、阿里云），负载均衡器本身支持 会话保持。 只需在控制台配置 Sticky Session 即可。

---

三、会话保持问题

1. 问题场景

在单体部署时，Spring Boot 使用 HttpSession 存储用户会话，默认存在本地内存中。 但在容器化 + 多副本部署时：

• 用户第一次请求到 Pod A，Session 存在 Pod A 内存里。

• 第二次请求可能被负载均衡到 Pod B，导致 Session 丢失。

• 用户表现：频繁掉线，需要重新登录。

2. 解决方案

方案一：Session 共享（推荐）

使用 Spring Session + Redis 统一存储会话：

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

配置 Redis：

spring:
  session:
    store-type: redis
  redis:
    host: redis-service
    port: 6379

📌 优点：所有实例共享会话，扩缩容无影响。 📌 缺点：依赖 Redis 可用性。

---

方案二：Token + 无状态认证（JWT）

• 用户登录后返回 JWT Token，存储在客户端（Cookie/LocalStorage）。

• 服务端验证 Token，不依赖 Session。

📌 优点：无状态，更适合微服务和多实例。 📌 缺点：Token 过期刷新、撤销管理需要额外机制。

---

方案三：Sticky Session（不推荐长期使用）

• 通过负载均衡配置粘性会话。

• 适合小规模应用，但扩展性差。

---

四、实战案例：Spring Boot 聊天室

假设我们实现一个 WebSocket 聊天室：

• 单 Pod 模式下正常工作。

• 部署多个副本后，用户 A 和用户 B 可能被分配到不同 Pod，消息无法互通。

解决方案：

1. 使用 Sticky Session，确保同一个房间的用户落在同一 Pod（临时方案）。

2. 使用 Redis Pub/Sub 或 Kafka，将消息广播到所有 Pod。

Redis 发布消息：

redisTemplate.convertAndSend("chat", message);

所有 Pod 订阅消息并转发给用户。

📌 最佳实践：WebSocket + Redis Pub/Sub，实现真正的分布式聊天室。

---

结语

在 Spring Boot 应用容器化后，常见的网络问题主要集中在：

1. Pod IP 变化 → 使用 Service/DNS，而不是 Pod IP。

2. 负载均衡漂移 → 配置 Session Affinity 或 Sticky Session。

3. 会话保持问题 → 推荐使用 Spring Session + Redis 或 JWT 无状态认证。

如果你的业务场景涉及 实时通信（WebSocket/SSE），建议结合 消息中间件 来解决多副本消息同步问题。

👉 容器化带来灵活性，但也需要在 网络与会话管理上多做设计，才能保证 Spring Boot 应用在分布式环境下的高可用与一致性。

---