架构决策与容器化落地

我有个中型企业服务端的 Spring Boot 项目最近刚完成从单机到集群的迁移。团队只有 5 个人代码库 20 万行每天处理约 500 万 次 API 请求。上线前我纠结了整整两周最终决定放弃裸机部署全面转向 Docker 容器化加 Kubernetes 编排。说实话刚开始我也觉得上 K8s 是不是有点过度设计但真跑起来才发现回退简直噩梦级难度必须一步到位。架构决策与容器化落地为什么选 Docker 而不是传统 JAR 包部署主要是为了解决“在我电脑上能跑”这个千古难题。过去每次发版运维都得手动同步配置文件、打补丁版本混乱是常态。这次我直接写了多阶段构建的 Dockerfile利用 Maven 只打包依赖层大幅缩减镜像体积。这里有个关键决策点我面临两个方案。方案 A 是直接在宿主机用java -jar启动配合 systemd 守护方案 B 是封装成镜像交给 K8s 管理。我最终选了 B。虽然初期配置成本高但 K8s 的自愈机制和滚动更新能力在应对 500 万 次日请求的高并发场景下远比手动维护稳定。构建过程中踩过一个大坑。镜像构建特别慢每次都要 10 分钟以上。后来我检查发现是 Docker 缓存没利用起来且 Maven 依赖下载源不稳定。我在 Dockerfile 里加了.dockerignore文件并配置了本地 Maven 仓库挂载构建时间直接降到了 2 分钟。有意思的是这个优化不仅让 CI/CD 流程快了还让本地开发环境的启动速度提升了一倍。dockerfileFROM maven:3.9-eclipse-temurin-17 AS builderWORKDIR /appCOPY pom.xml .RUN mvn dependency:go-offlineCOPY src ./srcRUN mvn package -DskipTestsFROM eclipse-temurin:17-jre-alpineWORKDIR /appCOPY --frombuilder /app/target/*.jar app.jarEXPOSE 8080ENTRYPOINT [java, -jar, app.jar]CI/CD 流水线与监控告警有了镜像接下来就是自动化流水线。我基于 GitLab CI 搭建了一套简单的触发机制合并到 main 分支即触发构建、测试、推送镜像、最后部署到 Staging 环境。这里我特意把单元测试和集成测试的阈值设得很严只要覆盖率低于 80% 就阻断发布。监控这块我引入了 Prometheus Grafana。最初我想用 Spring Actuator 自带的/health端点做简单探活结果发现不够用。在高并发下JVM 的 GC 停顿经常导致接口超时但 Actuator 还是返回 200监控根本收不到报警。坑死了。后来我结合 Micrometer自定义了“慢查询”指标和“线程池阻塞”指标直接推送到 Prometheus。现在只要 P99 延迟超过 500msGrafana 面板就会变红并联动 Slack 通知。当时我觉得配置好基础监控就够了结果发现错了。生产环境出过一次内存泄漏因为没有细粒度的指标排查花了整整 3 小时。从那以后我把 JVM 堆内存、非堆内存、直接内存都拆分成独立指标甚至监控到了每个微服务实例的磁盘 IO。性能调优与上线细节上线前最后一轮压测发现 QPS 瓶颈不在 CPU而在数据库连接池。我原本用的是 HikariCP 默认配置最大连接数设成了 20。在 50 个 容器实例同时扩缩容时数据库连接瞬间爆满。我把连接池大小调整为根据实例数动态计算并引入了 Redis 作为一级缓存扛住了大部分热点数据读取。还有一个容易被忽略的点时区问题。Java 默认是 UTC但业务数据要求北京时间。我在代码里没做统一配置导致部分日志时间戳和数据库时间差 8 小时排查问题时极其混乱。最后我在application.yml里统一加了spring.jackson.time-zone: GMT8并强制数据库连接串带上时区参数才算根治。整个部署过程耗时 3 周从敲定架构到灰度发布全量用户经历了 4 次 回滚。每次回滚都因为监控体系比较完善能在 5 分钟内 定位问题所以没有造成业务事故。现在系统运行稳定平均 P99 延迟控制在 200ms 以内。本文基于实际项目经验整理欢迎在评论区交流技术问题。