微服务容器化改造：传统 Spring Boot 应用迁移到 Docker 与 K8s 的步骤与坑点

一、为什么要把Spring Boot应用塞进容器？

兄弟们，不知道你们有没有遇到过这种场景：本地开发跑得好好的Spring Boot应用，一到测试环境就各种水土不服。不是配置文件对不上，就是依赖库版本打架，再不就是JVM参数没调好。这时候老张拍着你的肩膀说："要不咱们试试Docker？"

容器化就像给应用打包了一个随身行李箱，里面装着运行所需的一切：JDK版本、配置文件、依赖库、甚至操作系统环境。我去年接手的一个老项目，从物理机迁移到K8s集群后，部署时间从原来的2小时缩短到10分钟。特别是当需要横向扩展时，kubectl scale命令一敲，新实例秒级就位。

二、改造前的准备工作

2.1 检查应用的健康状况

先别急着动手，咱们得给应用做个全面体检。重点检查这几个指标：

// 技术栈：Spring Boot 2.7 + Java 11
// 健康检查端点示例
@RestController
@RequestMapping("/actuator")
public class HealthCheckController {
    
    // 内存健康检查
    @GetMapping("/memory")
    public String checkMemory() {
        long usedMB = (Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory()) / 1024 / 1024;
        return usedMB < 512 ? "OK" : "WARNING"; 
    }
    
    // 数据库连接检查
    @Autowired
    private DataSource dataSource;
    
    @GetMapping("/db")
    public String checkDB() throws SQLException {
        try (Connection conn = dataSource.getConnection()) {
            return conn.isValid(1000) ? "OK" : "DOWN";
        }
    }
}

2.2 配置文件大瘦身

传统应用经常把配置散落在各处：properties文件、环境变量、甚至代码里。咱们需要：

用Spring Cloud Config集中管理配置
区分不同环境的配置文件
敏感信息移交给Vault管理

# application-k8s.yml 示例
spring:
  datasource:
    url: jdbc:mysql://${DB_HOST:localhost}:3306/order_db
    username: ${DB_USER}
    password: ${DB_PASSWORD}
    
  redis:
    host: ${REDIS_HOST}
    port: 6379

三、Docker化改造实战

3.1 编写Dockerfile的学问

别小看这个Dockerfile，这里面的坑我踩了至少三回。来看个优化后的版本：

# 使用多阶段构建减小镜像体积
FROM eclipse-temurin:11-jdk-jammy as builder
WORKDIR /app
COPY .mvn/ .mvn
COPY mvnw .
COPY pom.xml .
# 先只下载依赖（利用Docker缓存层）
RUN ./mvnw dependency:go-offline

COPY src/ src/
# 打包应用
RUN ./mvnw package -DskipTests

# 运行时阶段
FROM eclipse-temurin:11-jre-jammy
WORKDIR /app
# 从构建阶段拷贝jar包
COPY --from=builder /app/target/*.jar app.jar
# 使用非root用户运行
RUN useradd -ms /bin/bash springuser && chown -R springuser:springuser /app
USER springuser
# 健康检查
HEALTHCHECK --interval=30s --timeout=3s \
  CMD curl -f http://localhost:8080/actuator/health || exit 1
# 启动命令
ENTRYPOINT ["java","-jar","app.jar"]

关键点说明：

多阶段构建让最终镜像从300MB+降到150MB左右
分离依赖下载和编译过程，利用缓存加速构建
使用非root用户增强安全性
健康检查确保容器状态可监控

3.2 本地测试那些坑

第一次构建镜像后别急着上生产，先在本地验证：

# 构建镜像
docker build -t order-service:v1 .

# 运行测试（注意映射端口和环境变量）
docker run -p 8080:8080 \
  -e DB_HOST=mysql-host \
  -e DB_USER=root \
  -e DB_PASSWORD=secret \
  order-service:v1

常见问题排查：

端口冲突：检查应用配置的server.port和容器映射是否一致
启动超时：数据库等依赖服务没就绪时，建议加上--restart=on-failure
时区问题：在Dockerfile中添加RUN ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime

四、Kubernetes部署进阶

4.1 Deployment配置详解

把容器扔到K8s集群可不是简单的事，来看个生产级配置：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-service
  labels:
    app: order-service
spec:
  replicas: 3
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
    type: RollingUpdate
  selector:
    matchLabels:
      app: order-service
  template:
    metadata:
      labels:
        app: order-service
    spec:
      containers:
      - name: order-service
        image: registry.example.com/order-service:v1.2
        ports:
        - containerPort: 8080
        envFrom:
        - configMapRef:
            name: order-service-config
        - secretRef:
            name: order-service-secrets
        resources:
          requests:
            cpu: "500m"
            memory: "512Mi"
          limits:
            cpu: "1000m"
            memory: "1024Mi"
        livenessProbe:
          httpGet:
            path: /actuator/health
            port: 8080
          initialDelaySeconds: 30
          periodSeconds: 10
        readinessProbe:
          httpGet:
            path: /actuator/health/readiness
            port: 8080
          initialDelaySeconds: 20
          periodSeconds: 5

4.2 必须知道的运维技巧

优雅停机配置：

// Spring Boot配置
server:
  shutdown: graceful
spring:
  lifecycle:
    timeout-per-shutdown-phase: 30s

日志收集方案：

# 在Deployment中添加sidecar容器
- name: log-agent
  image: fluent/fluentd:v1.14
  volumeMounts:
  - name: app-logs
    mountPath: /var/log/app
volumes:
- name: app-logs
  emptyDir: {}

配置动态更新：

# 更新ConfigMap后滚动重启Pod
kubectl rollout restart deployment/order-service

五、避坑指南

5.1 内存杀手：JVM与容器共舞

最大的坑莫过于内存配置。在容器中运行JVM需要特别注意：

务必设置-XX:+UseContainerSupport
堆内存不要超过容器limit的75%
预留内存给Metaspace和堆外内存

# 正确的启动命令示例
java -XX:+UseContainerSupport \
     -XX:MaxRAMPercentage=75.0 \
     -XX:+HeapDumpOnOutOfMemoryError \
     -XX:HeapDumpPath=/opt/traces/heapdump.hprof \
     -jar app.jar

5.2 服务发现的坑

在K8s中，传统的服务注册方式可能需要调整：

// 旧的Eureka客户端配置
@Bean
@Profile("!k8s")
public EurekaInstanceConfigBean eurekaInstanceConfig() {
    // ...
}

// K8s环境使用Service DNS
@Bean
@Profile("k8s")
public DiscoveryClient discoveryClient() {
    return new KubernetesDiscoveryClient();
}

六、改造后的效果评估

我们某个订单系统的改造前后对比：

部署效率：从每次2人天降到15分钟
资源利用率：服务器成本降低40%
可用性：SLA从99.5%提升到99.95%
扩容速度：从小时级降到秒级

但也要注意容器化不是银弹，以下场景要慎重：

有状态服务（需要额外处理存储卷）
需要特定内核模块的应用
对启动速度有毫秒级要求的场景

七、未来演进方向

向Service Mesh演进：引入Istio处理服务通信
无状态化改造：将Session等状态外移到Redis
镜像安全：加入漏洞扫描和签名验证
GitOps实践：使用ArgoCD实现声明式部署

# 简单的ArgoCD Application示例
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: order-service
spec:
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  source:
    repoURL: https://git.example.com/kubernetes.git
    path: apps/order-service
    targetRevision: HEAD
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

改造路上没有终点，但每一步都能让我们的系统更健壮、更弹性。记住关键原则：小步快跑、充分验证、监控先行。下次遇到部署问题时，不妨试试容器化这剂良药。

敲码拾光专注于编程技术，涵盖编程语言、代码实战案例、软件开发技巧、IT前沿技术、编程开发工具，是您提升技术能力的优质网络平台。