从 3.3.5 升到 3.5.3,踩了四个坑 八月底我们把手上 11 个服务从 Spring Boot 3.3.5 升到了 3.5.3。原本计划两天搞定,实际花了九天,中间回滚了一次。这篇记录升级过程和四个值得说的坑。 先说结论:值得升,但别在业务高峰期前升。ServiceConnection 和结
HPA 扩容跟不上流量,问题出在启动要 8 秒 10 月初做了一轮容量压测,暴露了个之前没重视的问题。我们的 AI 网关在 K8s 上配了 HPA,CPU 超过 60% 就扩容。压测时流量从 500 QPS 拉到 3000 QPS,HPA 在 15 秒内触发扩容,但新 Pod 从调度到 Ready
网关从 3.2 升到 3.3,我把虚拟线程打开了 国庆前最后一周,我把内部 API 网关从 Spring Boot 3.2.5 升到了 3.3.4。这次升级的动机不是安全补丁,而是 3.3 里那几个终于能用的东西:虚拟线程的正式支持、CDS 启动优化,还有服务连接抽象。 网关是个典型的 IO 密集型
有天凌晨告警:订单服务报错率突增。我登录 Kibana 翻日志,几千行文本里找那一条异常,正则写到手抖,花了 20 分钟才定位。痛定思痛,把日志从"人看"改成"机器看"——结构化输出,这套改造后来的排障时间从 20 分钟降到 40 秒。 为什么要从文本日志切到结构化 文本日志是给人扫的,机器分析要正
等到了 Spring Boot 3.2 的虚拟线程开关 Spring Boot 3.2 把虚拟线程集成做进了自动配置,一个属性就能让 Tomcat 用虚拟线程处理请求。我在 3.2 RC 阶段就拉下来试了,把订单查询接口从平台线程池切过去,吞吐数据很说明问题。不过 RC 阶段 API 还有微调,正式
背景:一次冷启动慢到被运维吐槽 五月初我把一个内部配置中心客户端容器化,K8s 里副本从 0 扩容到 10 时,启动要 8 秒多,滚动发布期间总有几秒请求打不到。运维说你这 Java 应用太重了。我琢磨着试一把 Spring Boot 3 的原生镜像——GraalVM 把应用直接编译成机器码,启动该
升级到 2.4,服务起不来了 6 月初,把一个服务从 Spring Boot 2.3.7 升到 2.4.6。改完 pom 里的版本号,启动,直接炸: *************************** APPLICATION FAILED TO START *******************
每次发版都有几十个 502,终于找到原因了 我们服务是 2019 年 11 月上的 Kubernetes,1.16 版本,Deployment 配 4 个副本。从上线那天起,每次滚动发布,网关那边都会报几十个 502,持续时间一两秒。因为量不大、用户基本无感,一直没排。 直到 1 月初做活动,晚上八
同事问我:为什么加个依赖就能用了 8 月中旬,刚入职的同事跑来问我一个他觉得"很魔幻"的事:他只在 pom 里加了 spring-boot-starter-data-redis,然后 @Autowired private StringRedisTemplate 就能用了,中间没写任何配置类。他问我
改了 application.yml 重启了八次,配置还是不生效 十一月底给服务加一个超时配置,我在 application.yml 里加了这么一行: http: connect-timeout: 5000 然后重启,打印出来还是默认值 3000。我以为没编译进去,clean 重新打包,还是