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

引言 上周领导在周会上问了一个问题："我们的日活用户到底有多少？哪个接口被调得最多？"团队沉默了几秒——产品有埋点方案，但排期在两个月后；数据组说要做完整的 BI 体系；风控那边倒是有数据，但要走数据同步流程。 散会后我打开 Kibana 看了看我们早已在采集的 API 访问日志，突然意识到：答案其实一直躺在日志里。每条 API 日志里有 userId、接口路径、响应码、耗时、时间戳——DAU 就是 userId 的去重计数，接口 TOP10 就是一次 terms 聚合，异常率就是 status≥500 的占比，慢接口排行就是耗时字段的 top_hits。不需要埋点、不需要加 SDK、不需要排期，把日志结构化好，Kibana 拖拖拽拽就是业务大屏。 这篇文章把这套"穷人版 BI"完整讲一遍： 链路：Logback 结构化日志（JSON）→ Filebeat 采集 → Elasticsearch 存储 → Kibana 可视化，每个环节怎么配 四个实战指标从日志里"算"出来：DAU、接口调用 TOP10、异常率趋势、慢接口排行 完整可抄的配置：Logback JSON 配置 + Fil....

引言 去年给订单系统加了个"AI 助手"，产品经理的原始需求只有一句话："用户在对话框里说'帮我查下最近的订单'，助手能直接把订单查出来回他。" 第一版我做得很快：关键词匹配 + 意图分支。if (msg.contains("订单")) 就查订单，if (msg.contains("退款")) 就走退款——上线三天，就暴露了灾难现场： 用户说"我的单子怎么还没到"——不含"订单"关键词，助手回复"抱歉我不明白您的意思" 用户说"昨天买的那杯咖啡去哪了"——命中了"咖啡"关键词，走错了咖啡优惠券分支 每加一种问法，就要加一组关键词、多一层 if——我在用代码模拟一个自然语言理解系统，而大模型本身就是干这个的 后来换成 Function Calling，思路彻底反转：我不写任何意图判断，只把 Java 方法"介绍"给大模型（方法名、用途、参数说明）。用户说"帮我查最近的订单"，大模型自己决定该调 getOrders，自己从对话里抽取参数（limit=5），Spring AI 帮我执行方法、把结果喂回去——意图识别、参数抽取这两件最难的事，全部交给了模型；Java 代码里只剩纯粹的业务方....

引言 上个月带新同事接手一个 Spring Boot 3.3 的项目，他打开 SecurityConfig 看了半天问我："这个项目是不是没有配 Security？"我说配了，就在你眼前——十行 Lambda，六个场景全覆盖：放行 Swagger、JWT 无状态、接口按角色鉴权、关 CSRF、开跨域、异常处理。他更困惑了："我学的是 extends WebSecurityConfigurerAdapter + @EnableWebSecurity，这个写法怎么一行像配置的都没有？" 这个困惑非常普遍。Spring Security 从 5.2 开始引入 Lambda DSL，5.7 把 WebSecurityConfigurerAdapter 标记废弃，6.x 彻底移除——网上大量教程还在教 5.x 之前的写法，新项目的官方写法早已换了一代。更让人头疼的是 7.x 又有新变化：方法级安全成为推荐、authorizeRequests 彻底移除、MockMvc 测试的写法也变了。 这篇文章把 6.x/7.x 的 Lambda DSL 一次讲清： Lambda DSL 的设计逻辑：为什么"....

引言 上个月的月结对账又双叒出问题了。凌晨 2 点的对账任务跑了 40 分钟，账单数据多了一倍——排查发现，两个订单服务实例各跑了一遍对账。单机时代用 @Scheduled 的代码，在部署第二个实例的那天起就埋下了这颗雷：没有分布式锁、没有分片、没有失败重试、没有告警，任务挂了只能靠第二天报表对不上才发现。 我们要的能力其实很明确： 需求@Scheduled 的现状期望 多实例不重复执行❌ 每个实例都会跑集群下同一任务只跑一次 大数据量提速❌ 单线程慢分片并行：10 个实例各处理 1/10 数据 任务失败感知❌ 日志里默默报错自动重试 + 告警通知 动态调整执行时间❌ 改 cron 要重启控制台改完立即生效 执行记录可查❌ 无记录每次执行的耗时/结果/日志留痕 手动触发/停止❌ 不支持控制台一键执行、终止 这些需求拼在一起，就是一个"分布式定时任务平台"。业界答案是 XXL-Job——它优雅地解决了上面所有问题，而且实现思路并不神秘。这篇文章先拆解 XXL-Job 的核心架构（调度中心做什么、执行器做什么、双方怎么协作），然后手写一个精简版：Quartz 调度 + HTTP....

引言 去年做代码安全审计，SpotBugs 报了一个 SQL_INJECTION 告警，定位过去一看： <select id="listOrders" resultType="Order"> SELECT * FROM orders WHERE status = #{status} ORDER BY ${sortColumn} ${sortOrder} </select> 开发同事很委屈："WHERE 条件我全部用的 #{} 预编译啊，注入不了！"我问他：如果 sortColumn 传入 (CASE WHEN (SELECT 1=1) THEN id ELSE status END)，这条 SQL 会发生什么？他愣住了。 测试一下：请求带上 sortColumn=(CASE WHEN (substr(database(),1,1)='p') THEN id ELSE create_time END)，接口返回的排序结果不一样——攻击者可以通过排序结果的变化，一个字符一个字符把数据库名、表名、数据全部拖走。这就是经典的 ORDER BY 注入，也是绝大多数 My....

引言 上个月安全审计，我们被点名了三个问题： 订单导出接口把用户手机号明文吐给了客服系统，客服离职后导出名单卖给竞品 前端页面直接展示身份证号全串，截图发朋友圈就是一次个人信息泄露 日志里打印了完整的银行卡号，等保测评直接不给过 整改要求：所有出参中的敏感字段必须脱敏。第一反应是写个工具类 DesensitizeUtil.maskPhone(...)，然后在几十个 Controller 里逐个调用——改了三天，漏了两处，还把一个不需要脱敏的字段误伤了（测试同事的订单列表手机号变成 138****5678 无法回显）。 后来换成注解 + Jackson 序列化器方案：在 DTO 字段上标注解 @Sensitive(type = PHONE)，序列化时自动脱敏，业务代码零改动。原来的三天工作量，现在每个字段只需加一行注解，而且脱敏规则集中在枚举里统一维护。 这篇文章把我们踩过的坑和最终方案完整讲一遍： 三种脱敏方案的对比（Jackson 序列化器 / MyBatis TypeHandler / AOP），各自的适用边界 @Sensitive 注解 + 自定义 Jackson 序列化器....

引言 前年接一个第三方平台对接，对方技术说"我们用 OAuth2.0 密码模式对接吧，简单直接"。我图省事同意了。上线三个月后出事了——合作方的服务器被黑了，攻击者从日志里捞到了一批用户密码（明文记在请求日志里），拿这些密码去试其他平台的撞库，引发了客诉。 事后复盘，问题的根源不是日志没脱敏，而是密码模式本身的设计缺陷：用户的密码经过了第三方客户端，客户端就是不可信的。一旦客户端被攻破或日志管理不严，密码必然泄漏。而用户在不同平台复用密码的比例高达 60%——一个平台泄密，多个平台遭殃。 后来我们把对接方式全部迁移到授权码模式：用户密码只在授权服务器上输入，客户端永远接触不到密码，只能拿到一个一次性的授权码（code），用 code 换 token。再后来 SPA 和移动端普及，授权码又暴露了"code 拦截"风险，于是有了 PKCE 增强。 这篇文章把 OAuth2.0 四种授权模式从"为什么不安全"到"怎么变安全"完整讲一遍，最后附 Spring Security OAuth2 的实现代码。面试被问"授权码模式为什么最安全"，这篇的内容够你聊二十分钟。 一、OAuth2.0 到底....

引言 去年双十一压测，订单链路在 3000 QPS 时出现零星超时。监控大盘显示一切"绿色正常"——各服务 QPS 正常、P99 < 200ms、错误率 0.01%。但用户侧反馈"下单偶尔转圈 5 秒"。 我们花了 4 小时定位问题。过程极其痛苦： 订单服务日志说"调用支付超时"，支付服务日志说"没收到请求"——谁在说谎？ 网关日志显示请求确实到了支付服务，耗时 3.2s——3.2 秒花在哪了？ 支付服务的 JVM 监控正常、DB 监控正常、Redis 监控正常——那 3.2 秒到底在等什么？ 最后发现是支付服务调用的某银行网关 TLS 握手偶发慢（银行侧负载均衡抖动），但定位过程暴露了一个致命问题：我们有监控、有日志、有告警，但它们是三个孤岛。Metric 告诉你"有问题"，但看不到调用链；Log 能搜到报错，但串不起来跨服务的因果关系；Trace 压根没接。 那之后我们花了三周搭了完整的可观测性体系：OpenTelemetry 采集 + Jaeger 存 Trace + Prometheus 存 Metric + Loki 存 Log，全部用 traceId 串联。再遇到....

引言 去年做了一次安全合规审查，结果出来后团队集体沉默了： pom.xml 里的 log4j-core 2.14.0——Log4Shell（CVE-2021-44228）在本地躺了 14 个月，无人察觉 某个内部工具类里用 Statement 拼接 SQL——一处 SQL 注入，被安全团队用扫描器秒穿 Git 历史里翻出了 3 套数据库密码和 2 个云厂商 AK/SK——早就换过了，但历史记录里明晃晃躺着 线上容器镜像里有 47 个已知 CVE，其中 3 个是 Critical 一个内部管理后台，ZAP 跑了 10 分钟报了 12 个安全问题，包括越权访问和 XSS 这些问题没有任何一个是"高深漏洞"，全是通过常规工具可以自动发现的已知问题。我们只是没有把工具接进 CI/CD 流水线。 这不是个例。大部分团队的安全现状是：出了事才人工排查，不出事就当不存在。但攻击者不会等你准备好了再来——自动化扫描器 7×24 小时扫 GitHub、扫 CVE 库、扫暴露的接口。你需要的不是"更努力"，而是"工具化"。 这篇文章介绍 5 个我们接入 CI/CD 后显著提升安全基线的工具，覆盖安全漏....

引言 凌晨 4:07，值班手机震动。安全团队告警：GitHub 上一份内部仓库的 application.yml 被同事不小心 push 到了公开仓库，里面赫然躺着 JWT 签名密钥 jwt.secret=MyJwtSecret2024。更要命的是——三小时前刚推上去，GitHub 爬虫和自动化扫描脚本早已抓到了。 值班的几个问题砸过来，一个比一个要命： 这个密钥能干什么？伪造任意用户的 Token，包括管理员——拿到密钥的人可以签发一个 role=admin, exp=2099 的 Token，以任何身份调任何接口 现在换密钥会怎样？所有已登录用户的 Token 立刻失效，几十万在线用户被踢下线，大面积 401 报错 不换行吗？密钥已经在公网暴露 3 小时，每一秒都可能有人在伪造 Token 探测系统 这不是假设。这是真实发生过多起的事件——Uber 2022 年的泄露就是因为攻击者从内部仓库拿到了 AWS 凭证和 JWT 密钥。很多团队都以为"密钥泄露"是小概率事件，直到它发生在自己身上。 这篇文章把我们走过的一遍完整流程写下来：应急止损四步（30 分钟内止血）→ 排查泄露范围....

引言 去年我们开放了一组 API 给合作方调用。上线两周，安全团队做了一次渗透测试，结果三连暴击： 篡改：合作方调"创建订单"接口，金额参数被中间人从 amount=9900 改成 amount=1，9900 的货一块钱拿走。HTTPS？用的是自建代理抓包改的，HTTPS 只防链路嗅探，不防应用层改包 重放：攻击者抓到一条"发放优惠券"的成功请求，原封不动重放了 873 次，券池被薅干 泄漏：合作方把 secretKey 明文写在前端 JS 里，被 F12 一秒扒走，拿着 key 想签什么签什么 三个问题，一个比一个疼。我们的修复方案叫 timestamp + nonce + sign 三合一签名：时间戳防重放窗口、随机数防重放、HMAC-SHA256 签名防篡改和防 key 泄漏。上线后渗透复测三项全部通过。 这篇文章把整套方案从需求拆解到代码实现完整讲一遍，覆盖： 三合一设计的底层逻辑：每个字段为什么必须有、HTTPS 为什么不够 客户端签名算法：参数排序 → 拼接 → HMAC-SHA256 → Base64 服务端校验全流程：时间窗口 → nonce 去重 → 重算签名比....

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

引言 上个月给支付网关做虚拟线程迁移，团队里两种声音吵了起来： 乐观派说："加一行 spring.threads.virtual.enabled=true，官方一键开启，完了。" 保守派说："别天真了，我们 30 万行代码，几十个自定义线程池、一堆 synchronized、手写对象池，一键开启约等于一键爆炸。" 两边都有道理。一键开启只对"干净"的应用成立——而我们 Review 完代码库后发现：17 个自定义线程池、23 处 synchronized 包裹 IO、4 个手写对象池。直接开，就是拿生产环境赌运气。 最终我们走了"三步迁移 + 完整改造清单"的路线：先替换 @Async 线程池、再升级 HTTP 客户端、然后给数据库连接池加保护，最后才开启虚拟线程开关。灰度上线后压测数据： 指标迁移前（传统线程池）迁移后（虚拟线程）变化 P99 延迟（下单链路）412ms124ms↓70% 吞吐（单实例 QPS）1,8507,400×4 峰值线程数200 + 32 async + 16 scheduler24 carrier + 万级虚拟线程内存↓30% 压测 30min 错误....

引言 上线第二个月的某个周五晚上，运营在群里发了个爆款活动链接。十分钟后，订单服务的监控曲线齐刷刷跳水——不是宕机，是一个"查优惠券"的接口被人写脚本疯狂调用，单机 QPS 冲到 8000，把 Tomcat 的 200 个工作线程全部占满，正常的下单请求全部在排队超时。 那一刻我们才意识到：限流不是"高可用锦上添花"，是保命的。 当时团队内部手写的限流方案长这样——每个需要限流的接口里塞一段： // 散落在 20 多个 Controller 里的"祖传代码" if (!rateLimiter.tryAcquire("coupon/query", 100)) { throw new BizException("操作太频繁，请稍后再试"); } doQuery(); 三个致命问题： 代码侵入：业务逻辑里混着限流细节，改限流阈值要发版 策略写死：硬编码在代码里，运营说"大促期间查询放宽到 200/s"，得走发布流程 单机视角：只限了单台实例，集群 8 台实例就是 8 倍配额，"100 次/秒"名存实亡 这篇文章把我们最终落地的方案完整讲一遍：自定义 @RateLimit 注解（支持 k....

引言 凌晨 3 点，值班手机第 137 次震动。迷迷糊糊划开一看，还是那条「磁盘使用率超过 80%」——同一块盘，Prometheus 每 30 秒评估一次，没人处理就一直报。 第二天早上复盘，最讽刺的一幕来了：真正的大故障恰恰发生在凌晨 4 点，一条 P0「订单服务全部实例下线」，被 137 条 P2 的重复轰炸彻底淹没。值班同学后来承认："我把告警群设成免打扰了，反正是磁盘告警。" 这不是个例。我们统计了自己环境的 30 天告警数据，结果触目惊心： 指标数值 日均告警条数24,187 条 单人单夜被通知次数平均 9.2 次 有效告警占比（需要人介入的）2.7% P0 告警平均响应时间11 分钟（且漏报 2 次/月） 97% 的告警是噪音。而噪音的代价不是"烦"，是把真正致命的告警稀释掉——这就是告警疲劳（Alert Fatigue）。 这篇文章把我们从 2.4 万条/天优化到 362 条/天的完整方案讲一遍，覆盖四块内容： 告警分级设计：P0（服务挂了）→ P1（P99 > 1s）→ P2（磁盘 > 80%），不同级别不同响应策略 AlertManager....