自研鉴权撑不住了 公司原来的登录是各个系统各写一套 Session，互不相通。用户在我们三个产品里要登三次，运营吐槽了半年。我们决定用 Spring Authorization Server（基于 Spring Security 6）搭一个统一认证，做 OAuth2 授权中心，让所有子系统一处登录、
为什么关心 AOT Spring Boot 3.0 刚出，主打对 GraalVM 原生镜像的支持。我们一个网关侧边车想压启动时间，原来 JVM 冷启动要 2 秒多，在弹性伸缩场景里每次扩容都得等，想试试原生镜像能不能降到几百毫秒。决定试 AOT 之前，我先把"AOT 到底是什么"搞清楚，不然很容易把
一个偶发的空指针 服务启动时偶发 NPE，堆栈指向缓存预热器里取到的 RedisTemplate 是 null。但 RedisTemplate 明明配好了——问题是它被用在了配置类的 @PostConstruct 里，而那时它依赖的连接工厂还没就绪。重启三四次才复现一次，最磨人。这种"时灵时不灵"的
下单接口越来越慢 createOrder 接口 RT 一度到了 800ms，点进去一看，主链路里塞了发短信、记风控、推积分三件"顺带"的事。它们慢一点，用户下单就卡一下。最糟的是，积分服务抖动时连下单都失败了，核心链路被旁路拖死。监控里下单 RT 的 P99 曲线和积分服务的 RT 曲线几乎同涨同落
准备升级 Spring Security 6：配置风格全变了 Spring Security 6.0 要在 2022 年 11 月随 Spring Boot 3.0 一起 GA，但我们不想等上线了再手忙脚乱。10 月初我就拉了 6.0 的候选版本做预研，最大的冲击是：WebSecurityConfi
面试被问：REQUIRES_NEW 到底开了几个连接 前阵子面一个五年经验的候选人，我随口问："方法 A 用 REQUIRED 调方法 B，B 用 REQUIRES_NEW，这俩用的是同一个数据库连接吗？"对方答"应该是同一个吧，都在一个事务里"。这其实是个很常见的误解。REQUIRES_NEW 会
读源码时的一句注释，让我重新审视响应式 前阵子读 Spring Data R2DBC 的源码，看到 R2dbcEntityTemplate 里一句话："JDBC blocks the calling thread; R2DBC does not." 我当时手头正有个网关服务，Tomcat 的线程池经
同事的提问：改成构造器注入就启动失败了 11 月初，组里在推"统一用构造器注入"，小杨改完一个服务发现起不来了： org.springframework.beans.factory.BeanCurrentlyInCreationException: Error creating bean with
背景：一个新服务要不要上 WebFlux 9 月中旬要起一个新服务，作用是"详情页聚合"：前端调一次接口，我们并行调商品、库存、价格、营销、评价五个下游，聚合后返回。组里有人提议用 WebFlux，理由是"调用多、IO 密集，响应式最合适"。 我当时持保留态度，就花了一周做了个 POC，两边都实现一
同事的问题：我加了 @Cacheable，为什么没生效 上周三下午，组里的小杨问我："我在方法上加了 @Cacheable，压了 100 次，数据库慢查询日志里还是 100 条，Redis 里也看不到 key，是不是缓存没配好？" 我过去看了一眼他的代码： @Service public class
