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

引言 前年接一个第三方平台对接，对方技术说"我们用 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 串联。再遇到....

引言 上线第二个月的某个周五晚上，运营在群里发了个爆款活动链接。十分钟后，订单服务的监控曲线齐刷刷跳水——不是宕机，是一个"查优惠券"的接口被人写脚本疯狂调用，单机 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....

引言 线上又出故障了——接口变慢、内存飙高、GC 频繁。但你的反应是： 接口多慢？不知道，没有 QPS 和响应时间监控 内存为啥飙？不知道，没有 JVM 指标 GC 多频繁？不知道，没有 GC 日志采集 没有指标，排障就是"猜"。 本文从零搭建一套完整的指标体系：Micrometer 采集 → Prometheus 存储 → Grafana 可视化 → AlertManager 告警。全实战，附完整配置和仪表盘 JSON。 一、指标体系全景 1.1 为什么需要指标 问题场景需要的指标 接口慢了QPS、响应时间（P50/P95/P99） 内存溢出堆内存、非堆内存、GC 次数 线程耗尽活跃线程数、线程池队列长度 业务异常错误率、订单量、支付成功率 依赖故障DB 连接数、Redis 响应时间 1.2 技术选型 组件作用选型 采集应用内指标暴露Micrometer（Spring Boot 默认） 存储指标拉取和存储Prometheus 可视化仪表盘展示Grafana 告警规则触发通知AlertManager 1.3 数据流 Spring Boot App (Mic....

引言 "这个请求慢了，具体慢在哪一步？" 如果你的回答是"看日志猜"，那说明你的系统还没有链路追踪。 分布式链路追踪是可观测性三支柱中最快见效的一个——不改动一行业务代码，加上一个 JVM 参数，立刻就能在 UI 上看到请求在各个服务之间的调用链路。 本文纯实战，10 分钟，三步搞定。然后逐步深入自定义埋点、跨服务传递、采样策略。 一、三步接入：零侵入方案 1.1 架构预览 ┌──────────────┐ ┌──────────────┐ │ order-service│ │ user-service │ │ (8080) │ │ (8081) │ │ │ HTTP │ │ │ GET /orders │────────→│ GET /users │ │ ↓ │ │ ↓ │ │ OTel Agent │ │ OTel Agent │ │ (自动埋点) │ │ (自动埋点) │ └──────┬───────┘ └──────┬───────┘ │ │ │ OTLP (gRPC) │ └────────┬───────────────┘ │ ▼ ┌───────────────┐ │....

引言 你是否遇到过这些场景： 线上出了问题，看日志发现关键信息没打，只能加日志重新发版 一个请求经过 5 个微服务，排查时要在 5 个系统的日志之间来回跳 监控大盘倒是有一堆，但没有人说得清哪个指标代表什么意思 团队用了 3 种 APM 工具，每年光 License 费就十几万 这些问题的根源都是同一个：没有统一的可观测性体系。 本系列将带你从 0 开始搭建一套完整的可观测性体系，这是第 1 期，先搞清楚架构和选型。 一、什么是可观测性 1.1 监控 ≠ 可观测性 监控（Monitoring）：告诉你系统出了什么问题 可观测性（Observability）：让你能搞清楚为什么出问题 监控是"已知未知"——你知道要监控什么（CPU、内存、QPS），设置阈值告警。可观测性是"未知未知"——你不知道问题会在哪里发生，但系统提供足够的信息让你能排查。 1.2 可观测性三支柱 ┌─────────────────────────┐ │ 可观测性 Observability │ └────────────┬────────────┘ ┌────────────────────┼──────....