服务端开发博客 | 后端架构 · 高并发 · 性能优化 · 微服务实战 👋🏼

公司用 Nacos 做配置中心，Gateway 路由也放 Nacos 里动态刷新。运维改了一条路由规则，配置一刷新，Gateway 就开始间歇性 502——大概持续了 2 到 3 秒。排查发现是路由表在热更新的时候，旧的被清空了、新的还没加载完，中间有一个空窗期。请求进来找不到路由，全部 502。 热更新本来是为了不重启，结果还是搞出了服务中断。问题不在热更新本身，而在更新的姿势不对——路由表是"先清空再加载"而不是"先准备好再切换"。今天聊聊怎么用双缓冲让路由切换做到真正的零宕机。 问题出在哪里：单路由表的空窗期 Spring Cloud Gateway 的 RouteDefinitionRouteLocator 在接收到 Nacos 配置变更时，默认行为是： 收到新配置 │ ├─ 清空旧路由表 ├─ 逐条解析新路由 ├─ 校验路由合法性 └─ 加载完成 从"清空"到"加载完成"之间，路由表是空的。这段时间进来的请求，全部 502。加载几十条路由可能只要 100ms，但如果路由规则复杂、或者有外部依赖校验，这个窗口可能拉到秒级。 双缓冲：新路由加载完再切过去 双缓冲的思路很朴素....

公司用本地消息表做分布式事务的最终一致性。每笔订单创建后往消息表里插一条"待发送"记录，后台定时任务轮询发送。业务量上来以后，消息表单表积压了几千万条数据，每次 INSERT 都要等几十毫秒，DB 连接池打满，主库 CPU 飙到 80%。订单创建都跟着变慢了。 本地消息表本来是为了解耦，结果自己成了瓶颈。今天聊聊怎么把消息表的高频写入从主库的业务路径上剥离，用异步批量落盘加分表来扛住海量消息。 问题到底出在哪 本地消息表最朴素的实现是业务代码里直接 INSERT： @Transactional public void createOrder(Order order) { orderMapper.insert(order); // 订单入库 messageMapper.insert(new Message( // 消息入库 —— 跟订单在同一个事务 order.getId(), "ORDER_CREATED", "PENDING" )); } 这种写法，消息的 INSERT 跟业务 SQL 在同一个事务里。单看一条没问题，但当每秒几千个订单同时创建，消息表的 INSERT 就变成了主....

公司微服务上了 Spring Cloud Gateway，一切正常直到有一天运维发现某个下游服务挂了，Gateway 还是把流量往那台死掉的实例上发，前端一阵 502。查了注册中心，Nacos 上那台实例的状态还是 UP。原来是服务进程虽然活着，但业务线程池被耗尽了，所有请求都在排队超时。Nacos 的心跳包是单独的线程处理的，业务线程池死了不影���心跳，所以注册中心一直认为它是健康的。 这就是"假在线"——健康检查过了不代表服务能用。今天聊聊怎么在 Gateway 层做主动业务探测，把假在线的节点从路由表里动态踢出去。 注册中心健康检查的盲区 Nacos、Eureka 这些注册中心判断服务是否健康，靠的是心跳。客户端定期发一个心跳包给注册中心，注册中心收到了就认为服务活着。 但心跳包只能证明网络没断、进程没死。以下场景心跳都是正常的： 业务线程池打满，所有请求都在排队超时 数据库连接池耗尽，每次数据库查询都失败 依赖的下游全挂了，返回的全是 500 死锁，只有心跳线程还在工作 这些情况下，注册中心说服务是 UP，Gateway 就把流量发过去，结果全是 502 或 500。 ....

公司线上出了个支付异常，三四个微服务都有日志，但各打各的，谁也不知道哪条日志和哪条日志是同一个请求。运维在 ELK 里翻了一个小时，靠着时间戳和 userId 硬猜，最后猜错了版本，回滚到错误的代码上又出了一波事故。要是每条日志头上都有一个贯穿全链路的请求 ID，一秒就能搜出这个请求的完整轨迹。 X-Request-ID 不是什么新技术，但落地起来细节不少。谁生成、怎么传、下游怎么接、日志怎么打，任何一个环节断了，链路就断了。今天把这些细节串起来。 谁负责生成 Request ID 生成责任只有一个：第一个接收到请求的网关。 客户端不生成，因为你不能信任客户端传上来的值——重复、太短、甚至包含注入字符。 如果客户端已经传了 X-Request-ID（比如从另一个系统透传过来的），网关应当尊重它，直接转发。但如果客户端没传，网关必须生成一个。 请求到达 Gateway │ ├─ 检查 Header: X-Request-ID │ ├─ 有值 → 直接用（跨系统透传） │ └─ 没值 → 生成新 ID │ └─ 写入 Header → 转发到下游微服务 ID 格式建议用 UUID 去横....

公司的在线客服系统用的是 WebSocket。每次发版滚动更新，旧 Pod 一停，挂在上面的几千个 WebSocket 连接全断。前端虽然做了自动重连，但重连期间用户发了一条消息，没收到回复，以为客服不理他，直接给了差评。更糟糕的是，客服正在输入的内容也丢了——WebSocket 断了，会话状态没了。 WebSocket 跟 HTTP 不一样。HTTP 是无状态的，请求断了重试一次就好。WebSocket 是长连接，一旦断了，连接上的状态全丢。发版又是必然事件——你不能为了 WebSocket 永远不发版。 今天聊聊怎么让 WebSocket 在服务发版时平滑过渡，不让用户感知到断线。 WebSocket 发版的三个痛点 滚动更新时，K8s 或者运维平台会给旧 Pod 发 SIGTERM 信号，然后等一段时间（默认 30 秒）后 SIGKILL。WebSocket 没有 HTTP 那样的负载均衡重试机制，Pod 一死连接直接断。 三个痛点： 连接断开——旧 Pod 停了，上面的 WebSocket 连接瞬间全断。用户端要么看到连接断开提示，要么消息发不出去。 状态丢失——客服正在输入....

隔壁组一个 RabbitMQ 消费者服务，每隔几天就 OOM 重启一次。查了 heap dump，发现 Delivery 对象占了 80% 的堆内存——全是未 ACK 的消息。根因是他们用的是默认的自动 ACK，后来改成了手动 ACK 防止消息丢失，但忘了设 prefetch。RabbitMQ 一股脑把所有消息都推给了 Consumer，Consumer 处理不过来，消息在堆内存里越堆越多，直到撑爆。 RabbitMQ 的 Push 模式有个很容易忽略的坑：如果你不设 prefetch，Broker 会用最快的速度把所有消息推给 Consumer。 Consumer 处理慢了，消息就在堆内存里排队等处理。每条消息至少占几百字节，10 万条消息就是几十 MB，轻松打满 JVM。 今天聊聊怎么用 prefetch 限流和自动降级，让 Consumer 不会把自己撑死。 问题出在哪：Push 模式的无限制投递 RabbitMQ 默认的行为是：Consumer 一连接上，Broker 就把当前队列里所有的消息一口气推过去。Consumer 处理不过来没关系——消息已经在你的 JVM 堆里了。....

公司的风控系统出了个诡异的 bug。用户 A 在页面上看到自己被拒绝了，但查日志发现规则里引用的是用户 B 的订单金额。两个人完全不相干，数据却串了。排查了两天，最后定位到 QLExpress 的 DefaultContext 被当成了单例 Bean，所有请求共享同一个 context 对象，并发请求下变量互相覆盖。 这种 bug 的特征很典型——低并发时一切正常，压测或者高峰期才出现，而且数据是"偶尔串"而不是"一直错"。如果你问 QA 能不能复现，他们的回答多半是"有时候能有时候不能"。这就是并发问题的经典症状。 今天聊聊怎么在规则引擎的场景下，用 ThreadLocal 把上下文彻底隔离开，再加一个清理钩子防止内存泄露。 问题怎么发生的 先还原一下事故现场。很多人在用 QLExpress 的时候，为了省事会把 DefaultContext 注入成 Spring Bean： @Component public class RuleService { // ❌ 单例 Bean！所有请求共享 private final DefaultContext<String, Object....

公司做物流系统，订单状态变更通过 RocketMQ 广播。刚开始只有一个消费者，所有消息照单全收。后来业务拆分，多了十几个微服务各自订阅感兴趣的消息。问题来了——每个服务都从 Broker 拉全量消息，然后自己过滤。一天几千万条消息，每个服务实际需要的不到 10%，90% 拉过来就扔了。内网带宽跑满，消息堆积，消费延迟越来越大。 这个问题特别容易被忽视。因为消息队列用起来太简单了，Producer 发、Consumer 收，中间不用管。但当你有了十几个 Consumer 各自只需要不同子集的消息时，全量拉取就是在用带宽换便利。 今天聊聊 RocketMQ 的 Tag 和 SQL92 两种 Broker 端过滤方式，把过滤逻辑从消费端前移到 Broker，让不需要的消息根本不出 Broker 的门。 客户端过滤的问题在哪 默认的 Push Consumer 模式，客户端从 Broker 拉消息的流程是这样的： Broker ──拉取──→ Consumer（全量消息） │ ├─ 需要的消息（10%）→ 处理 └─ 不需要的消息（90%）→ 丢弃 看起来没什么问题？你丢你的，又不占硬盘....

运营在后台配了一条规则：orderAmount > 10000 && userLevel == 'VIP' 标记为大额订单。配完觉得没问题，直接上线。半小时后客服被用户打爆——所有 VIP 用户的订单都被拦截了，不管金额大小。排查下来发现是规则里多打了个 >，本来应该是 <。就一个字符，损失了几十万。 规则引擎的优点是灵活——运营可以随时改规则，不用开发介入。但灵活的另一面是危险：没有编译器帮你检查，一个手误就上线了。 今天聊聊怎么给规则加上自动化测试——让 1000 条用例在规则上线前跑一遍，逻辑错误当场拦截。 规则引擎的测试为什么难做 传统代码的测试很成熟：JUnit、Mockito、覆盖率工具，流水线上跑一下，绿了就上线。但规则引擎面前，这套流程用不上。 规则不是 Java 代码。它是运营在后台配的一段表达式字符串，比如： productPrice * 0.8 > competitorPrice && stockQty < 100 这段东西没有编译期检查。你没法给它写 JUnit，因为在 Java 眼里它只是一个字....

公司有个规则引擎服务，每天运营要更新几百条风控规则。QLExpress 每次执行规则都会编译生成一个匿名类，然后装进 JVM 的 Metaspace。运行了两周之后，服务开始频繁 Full GC，再后来直接 Metaspace OOM 崩了。重启能续命两周，但规则数量只增不减，两周变成十天，十天变成一周，最后每天都得重启。 这个问题在脚本引擎场景下几乎必现。GroovyShell、QLExpress、Aviator，甚至 Nashorn，只要是"动态编译 → 生成类 → 装载到 JVM"的模式，都会往 Metaspace 里塞东西。而且 Metaspace 默认没有上限——它只会一直涨，直到物理内存耗尽。 今天聊聊怎么用 ClassLoader 隔离 + 定时回收，让 Metaspace 不炸。 Metaspace 里到底装了什么 Java 8 以前叫 PermGen，Java 8 以后改名为 Metaspace。换了个名字，但干的活一样——存类的元数据。 你写的每一个类，编译后的字节码，字段名、方法名、注解信息、常量池，全部放在这里。普通的 Java 类在应用启动时加载一次，之后不....

朋友公司做秒杀，限流用的是固定窗口计数器——每分钟最多 1000 个请求。每次秒杀开始的瞬间，前 0.5 秒冲进来 800 个请求，计数器直接打满，后面 59.5 秒的正常用户一个都进不来。更要命的是，这个计数器在第 60 秒重置，第 61 秒又是一波 800 个请求冲进来。限流器没有挡住流量洪峰，反而把正常用户拦在了门外。 固定窗口的问题是它不管流量分布。1000 个请求挤在前 5 秒和均匀分布在 60 秒里，对它来说是一样的——反正超了就拒。但业务上，前 5 秒的 800 个秒杀请求是正常的，后面的零散查询也是正常的。你需要的不是"别超过 1000"，而是"别把服务器打爆"。 这就是令牌桶擅长的事。 令牌桶和固定窗口的差别在哪 固定窗口的逻辑很粗暴：一个计数器，到时间清零。令牌桶的思路完全反过来——以固定的速度往桶里放令牌，请求来了要先拿到令牌才能通过。 令牌桶模型： 令牌生成器 —→ 每秒放 100 个令牌 —→ [桶容量: 200] │ 请求到达 ────────────────────────────────┤ │ 有令牌？—→ 拿走一个，放行 │ 没令牌？—→ 拒绝 │....

运营说后台管理页面打不开了。查日志，全是 HikariPool-1 - Connection is not available, request timed out after 30000ms。连接池配了 20 个连接，监控显示全部是 active，一个 idle 都没有。等了十分钟也没恢复——不是流量高，是连接被人借走没还。重启能好，但过两天又犯。 连接泄露比内存泄露更难排查。内存泄露至少还有 heap dump 可以分析，连接泄露你只能看到连接池满了，但看不到是谁借了没还、从哪里借的。等你发现的时候，池子已经空了，所有需要数据库的请求都在排队等超时。 今天聊聊怎么用 HikariCP 自带的一个配置项，把连接泄露的元凶精准揪出来。 连接是怎么被"偷"走的 正常情况下的连接使用流程是这样的： 借连接 → 执行 SQL → 还连接 Spring 的 @Transactional 和 JdbcTemplate 会帮你自动管理这个过程。方法结束，事务提交或回滚，连接自动归还池子。 但有些写法会悄悄地把连接"偷"走： 经典泄露场景：Stream 没关 // ❌ 连接泄露 jdbcTemp....

公司一个微服务，启动一次要两分多钟。每次发布都是煎熬——CI/CD 等两分钟，滚动更新每起一个新 Pod 又是两分钟，发个版十分钟起步。他们以为是 Spring Boot 就这样，直到有一天我在控制台加了一行 -Dspring-startup-analyzer，发现有个 Bean 的 @PostConstruct 里竟然在同步加载全量字典数据，光它一个就花了 40 秒。 Spring Boot 启动慢这件事，大多数时候不是你 Bean 太多，而是有几个 Bean 初始化的时候干了不该干的活。今天聊聊怎么把这几颗老鼠屎找出来，以及怎么做懒加载优化。 先定位：到底是哪些 Bean 在拖后腿 Spring Boot 启动慢，第一件事不是优化，是找到瓶颈。没有数据支撑的优化就是瞎改。 最简单的方式：Spring Boot Actuator 的 Startup 端点 Spring Boot 2.4+ 内置了一个 ApplicationStartup 机制。在配置文件里开一下就能用： # application.yml spring: application: startup: step-rec....

大促的时候，运营在首页挂了一个爆款商品。瞬间几十万用户涌进来，同一个商品详情接口被疯狂调用。Redis 里这个商品的缓存 Key 被打到单节点 QPS 上限，响应时间从 1ms 飙升到 50ms，Redis 线程池打满，带着其他 Key 的请求也一起慢了。一块热铁掉进水里，整锅水都烫了。 这就是典型的热点 Key 问题。一个 Key 太热，把 Redis 单节点打穿了。因为 Redis 是单线程处理命令的，一个慢不会拖累别的，但如果请求量超过这个单节点的处理能力上限，所有请求都得排队。 今天聊聊怎么用 Caffeine 本地缓存做二级缓存，配合过期时间抖动防止缓存雪崩。 热点 Key 为什么难搞 先搞清楚热点 Key 的问题本质。正常缓存访问是这样的： 请求 → Redis → 命中 → 返回（1ms） 热点 Key 的情况下： 1000 个并发请求 → Redis 同一个 Key │ └─ 1000 次网络 IO（即使是 Redis，单节点也有处理上限） 问题不在"数据能不能被缓存"，而在"所有请求都打到了同一个 Redis 节点上"。如果你的 Redis 是集群模式，这个热点....

去年双十一，隔壁组出了个事故。交易系统在高并发的时候偶发超时，运维翻日志找原因，结果发现那个时间段的 ERROR 日志全是空的。排查了一圈才搞明白——Logback 设了 AsyncAppender，队列满了之后，新来的日志直接被丢弃了。问题日志没留下来，复盘都无从下手。 异步日志本来是提升性能的好东西，但如果没搞懂它"队列满了怎么办"，关键时刻它会把你最需要的那条日志扔掉。 今天聊聊怎么用好 Logback 的异步日志——既不让日志拖慢业务线程，也不让关键日志在队列溢出时被丢弃。 同步日志慢在哪 先说清楚为什么需要异步。一次常规的日志写入，背后是好几步操作： 业务线程调用 log.info() │ ├─ 格式化：把参数拼进日志模板 → "订单 12345 支付成功" ├─ 编码：转成字节数组（UTF-8） ├─ 写磁盘：fsync 刷到文件 └─ 返回，业务线程继续 其中"写磁盘"这一步最慢。固态硬盘一次随机写入大约 0.1ms，机械硬盘可能到几毫秒。如果业务代码里日志打得很密，每次 log.info() 业务线程都要等磁盘写完才能继续——高并发下这个等待会非常可观。 异步日志....