Spring Boot on Kubernetes:Liveness 与外部依赖检查的边界
数据库一抖就重启?Spring Boot 的 Liveness 别这样配 Kubernetes 的 Liveness 失败会触发容器重启,Readiness 失败则让 Pod 暂时不接收 Service 流量。把数据库、缓存和远端 API 的同一套检查直接挂到两种探针上,可能在外部依赖故障时重启所有
围绕 spring-boot 的技术文章与经验分享。
共 17 篇文章数据库一抖就重启?Spring Boot 的 Liveness 别这样配 Kubernetes 的 Liveness 失败会触发容器重启,Readiness 失败则让 Pod 暂时不接收 Service 流量。把数据库、缓存和远端 API 的同一套检查直接挂到两种探针上,可能在外部依赖故障时重启所有
Spring Boot 4.1 测数据库,别再只用 H2:Testcontainers 起一个 PostgreSQL 单元测试用 H2 跑得很快,但如果生产环境是 PostgreSQL,SQL 方言、数据类型和约束行为仍可能在上线时出现差异。针对数据访问层,比较直接的做法是让集成测试启动一个临时 P
最近 Spring 生态最值得关注的两条主线是:Spring Boot 4.1 继续补齐生产级基础设施,Spring AI 2.0 则把重点从“能接模型”推进到“能构建可组合、可校验、可观察的 Agent 应用”。 如果你最近还停留在 Spring Boot 3.x + Spring AI 1.x
以下是关于 Spring Boot 4.1 的新特性以及 Spring Boot 3.5 生命周期结束 (EOF/EOL) 的详细情况: 一、 Spring Boot 4.1 核心新特性 Spring Boot 4.1(基于 Spring Framework 7.x 系列)在 20
先说个真实遇到的问题。在多租户 SaaS 项目中,每个租户可以选择自己的消息推送方式:有的租户用邮件,有的用钉钉,有的用企业微信。 关键是:租户信息存在数据库里,系统启动时才知道有哪些租户,每个租户用什么渠道。 这就麻烦了。用@Bean
扩展 Spring Boot 应用不仅仅是添加更多服务器。它关乎工程效率——在水平扩展之前,从现有硬件中榨取每一分性能。 在本文中,我们将探讨如何为高性能、云原生环境调优、扩展和分析 Spring Boot 应用——包含实践示例、代码注释和架构可视化,你可以立即应用。 为什么性能优化很重要 大多数
生产环境的 NullPointerException 一直是困扰 Java 开发者的"幽灵"。每个人都遭遇过:这段代码在本地开发环境运行得好好的,但到了生产环境却莫名其妙地抛出 NPE 或触发其他边界异常。 问题的根源在于:Java 传统的类型检查无法在编译期区分可空与非空类型。 当你看到