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

引言 团队新来了个挺优秀的同学，简历上写着"深度使用 Spring Cloud Gateway"。线上网关出了个诡异问题：某个接口偶发 502，我问他"转发这块的连接池配置在哪"，他愣了一下："网关不就是个配置文件吗？" 不是嘲讽谁。用框架和懂原理，从来是两回事。 Spring Cloud Gateway 把 3000 多个类打包成一个 starter，也把"网关到底怎么工作"这件事打包黑盒里了： 为什么全局过滤器（GlobalFilter）的 order 会决定整个链路行为？ 为什么网关的 EventLoop 线程上绝不能写阻塞代码？ 令牌桶限流怎么做到并发下"不超卖"？ 负载均衡的"平滑加权"和普通加权差在哪？ 一次转发请求头要改写哪些字段，漏改一个就是 502？ 这些问题，读框架源码要翻几千行；自己写一个 800 行的迷你网关，全部答案扑面而来。 所以这篇文章我们做一件事：不依赖 Spring Cloud Gateway，甚至不依赖 Spring，用 Netty + 800 行核心代码，手写一个能跑的网关，包含完整四大能力：路由转发（YAML 路由表）、令牌桶限流、JWT 鉴....

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

一、限流阈值设置的痛点 上个月，我在为一个电商系统做性能优化时，遇到了一个非常棘手的问题： "我们的系统在高峰期经常出现限流误杀，而在低峰期又限流不足，"技术总监皱着眉头说，"固定的限流阈值根本无法适应业务的动态变化，我们需要一个智能的方案来自动调整限流阈值。" 我查看了他们的限流配置，发现问题确实很严重： 系统使用固定的限流阈值，无法适应流量的动态变化 高峰期阈值设置过低，导致正常请求被误杀 低峰期阈值设置过高，无法有效保护系统 无法根据历史流量数据进行智能调优 没有自动推荐合理的限流阈值的机制 限流策略缺乏灵活性和适应性 更关键的是，他们根本不知道如何设置一个合理的限流阈值，只能依靠经验和猜测。 二、传统方案的局限性 1. 固定阈值限流 使用固定的限流阈值，无论流量如何变化，都使用相同的限制。 // 固定阈值限流 @Bean public RateLimiter rateLimiter() { return RateLimiter.create(100); // 固定100 QPS } 这种方案的问题： 无法适应流量变化：无法根据流量的动态变化调整阈值 高峰期误杀：高峰期阈....

前言 在现代 Web 应用中，WebSocket 已成为实现实时通信的重要技术。它允许服务器主动向客户端推送数据，实现了真正的双向通信。然而，随着用户量的增长，WebSocket 连接的管理变得越来越重要。如果不进行有效的连接数限制，可能会导致服务器资源耗尽，影响服务的稳定性。 想象一下这样的场景：你的应用支持实时聊天功能，每个用户可以建立多个 WebSocket 连接。如果某个用户恶意或误操作建立了大量连接，可能会占用服务器的大量资源，影响其他用户的正常使用。更严重的是，如果多个用户都这样做，服务器可能会因为资源耗尽而崩溃。 WebSocket 连接数限流和防资源耗尽是解决这个问题的有效方案。通过限制单个用户的最大连接数，以及采取其他防资源耗尽的措施，可以保障服务的稳定性。本文将详细介绍如何在 SpringBoot 项目中实现 WebSocket 连接数限流和防资源耗尽功能。 一、WebSocket 连接数限流的核心概念 1.1 什么是 WebSocket 连接数限流 WebSocket 连接数限流是指限制单个用户或单个 IP 地址可以建立的 WebSocket 连接数量，以防止资源....

一、血泪教训：那个被“慢请求”拖垮的深夜 去年双11前压测，系统突然雪崩！ 监控显示：某个查询接口RT从50ms飙升到2秒，线程池瞬间打满，整个服务瘫痪。 复盘发现： ❌ 固定QPS限流设了1000，但RT变慢时，1000个慢请求已耗尽所有资源 ❌ 人工调整阈值？等发现时，雪崩已完成 你是否也踩过这些坑？ 🌪️ 大促时固定阈值“水土不服”，限了正常流量，放行了慢请求 🤯 依赖运维半夜调参数，响应速度决定系统生死 💸 为扛流量盲目扩容，成本飙升却治标不治本 今天，教你用“RT动态阈值”给系统装上“智能呼吸阀” 响应变慢？自动收紧流量！恢复健康？自动放开！真正的自适应防护👇 二、为什么固定阈值是“纸老虎”？ 限流方式场景问题 固定QPS=1000正常RT=50ms✅ 有效 固定QPS=1000异常RT=2000ms❌ 1000个慢请求占满线程池，系统雪崩 固定线程数=200高并发+慢查询❌ 线程池满，新请求全拒绝 💡 核心洞察： 限流的本质不是“限数量”，而是“保资源” 当RT变长，同样QPS会消耗更多线程/连接！ → 动态阈值 = f(当前RT, 健康RT, ....

传统网关的痛点 在我们的日常开发工作中，经常会遇到这样的场景： 新增一个限流策略，需要修改网关代码并重启整个服务 业务方需要自定义日志格式，但网关已经打包部署 不同租户需要不同的鉴权逻辑，但网关是统一的 想要快速上线一个新功能，却因为网关改动需要走完整的发布流程 传统的网关架构往往是硬编码的，每个功能都写死在代码里，灵活性差，扩展性更差。今天我们就来聊聊如何构建一个插件化的网关架构。 解决方案思路 今天我们要解决的，就是如何用SpringBoot构建一个支持动态加载插件的网关架构。 核心思路是： 插件化设计：将限流、鉴权、日志等功能抽象为独立插件 热加载机制：支持动态加载、卸载插件，无需重启服务 配置驱动：通过配置文件控制插件的启用和优先级 沙箱环境：确保插件安全运行，避免影响主程序 插件化架构设计 1. 插件接口抽象 首先，我们需要定义一个通用的插件接口，所有具体的插件都实现这个接口： public interface GatewayPlugin { /** * 插件执行逻辑 */ PluginResult execute(PluginContext context); /*....