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

引言 线上又出故障了——接口变慢、内存飙高、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....

引言 线上告警：订单查询接口 P99 飙到 5 秒，用户疯狂投诉。 打开监控一看，QPS 不高，机器负载也不高，但就是慢。典型的"代码写得烂"型性能问题。 本文记录这个接口从 5 秒优化到 200ms 的全过程，7 步走，每一步都有前后对比数据。不是理论，是真实线上案例。 零、问题接口 0.1 接口描述 GET /api/orders/{orderId} 功能：根据订单 ID 查询订单详情 返回：订单基本信息 + 用户信息 + 商品列表 + 物流信息 + 优惠信息 0.2 初始代码（慢得离谱的版本） @Service public class OrderQueryService { @Autowired private OrderMapper orderMapper; @Autowired private UserMapper userMapper; @Autowired private ProductMapper productMapper; @Autowired private LogisticsMapper logisticsMapper; @Autowired privat....

引言 Spring Boot 的"魔法"从哪来？为什么加一个依赖，DataSource 就自动配置好了？为什么 @SpringBootApplication 一个注解就能启动整个应用？ 答案藏在 AutoConfigurationImportSelector 这个类里。 本文从 @SpringBootApplication 注解出发，逐层深入源码，拆解自动配置的完整执行链路。读完后，你将彻底理解 Spring Boot 自动配置的工作原理，并能自己写一个 starter。 本文基于 Spring Boot 3.3.x / Spring Framework 6.1.x 源码分析。 一、从 @SpringBootApplication 开始 1.1 注解的"套娃"结构 @SpringBootApplication public class MyApplication { public static void main(String[] args) { SpringApplication.run(MyApplication.class, args); } } 点开 @SpringBo....

引言 你有没有经历过这些场景： 限流阈值从 1000 改成 500，要走提工单→审批→打包→发布的完整流程，半小时过去了 同一个服务三套环境（dev/staging/prod），三个 application.yml 改来改去，有人改错环境配置导致线上事故 数据库密码要轮换，但密码写死在 application.yml 里，轮换一次要重新打包发版 新来的同事不知道某个配置项是干嘛的，因为配置没有版本历史 这些痛点的根源都是同一个：配置和代码混在一起。 本文从实际问题出发，用 Nacos Config 一步步解决配置中心化、动态刷新、多环境管理、变更审计和灰度发布。全流程代码，附踩坑记录。 一、配置硬编码的痛点 1.1 典型场景 # application.yml server: port: 8080 app: # 限流配置 rate-limit: qps: 1000 burst: 2000 # 数据库连接 datasource: url: jdbc:mysql://prod-db:3306/order?useSSL=true username: order_app password....

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

引言 每个月 Java 生态都在冒出新工具，但大部分是"重复造轮子"。怎么判断一个新工具值不值得投入时间？我的标准很简单：它是否解决了一个我实际遇到的痛点。 8 月份有 5 个工具更新引起了我的注意，不是因为它们有多酷，而是因为每一个都踩中了 Java 开发者日常的真实痛点：单体应用模块混乱、Native Image 编译太慢、Testcontainers 命令行难用、Native Image 安全扫描空白、配置文件类型不安全。 下面逐个拆解。 雷达图总览 采用(Adopt) ↑ Testcontainers Desktop │ Spring Modulith 1.3 │ 试验(Trial) ←────────┼────────→ 评估(Assess) │ Pkl 0.27 │ DependencyCheck 11.0 │ 暂缓(Hold) ↓ GraalVM NBT 0.10 （编译速度提升，但仍需评估场景） 工具雷达位置一句话评价 Spring Modulith 1.3采用单体应用的模块化救命稻草 GraalVM NBT 0.10评估编译快了 40%，但先确认你真的需要....

引言 "线上有个订单，用户付款成功了，但一直没收到发货通知。查了订单系统，状态是已付款；查了通知系统，根本没收到这条消息。消息就这么……没了？" 这是上周三凌晨收到的一起线上事故。最终定位下来，不是什么高深的 Bug，而是一个不起眼的参数配错了——sendMsgTimeout 设成了 200ms。 但排查过程值得记录，因为每一步都是 RocketMQ 消息可靠性的实战教科书。本文完整复盘这次排查全过程，附排查命令速查表和消息可靠性配置模板。 一、问题现象 1.1 故障描述 维度描述 故障时间周三凌晨 2:00-2:30（高峰期） 影响范围37 笔订单付款后未触发发货通知 用户反馈"我付款半小时了，怎么还没发货？" 业务影响用户投诉 + 客服介入 + 需手动补发 1.2 系统架构 RocketMQ ┌──────────┐ ┌──────────┐ │ Topic: │ ┌──────────────┐ │ 订单系统 │──│ order- │──│ 通知系统 │ │ Order-Svc│ │ notify │ │ Notify-Svc │ └──────────┘ └──....

引言 你有没有遇到过这些线上事故： 用户连续点了两次"提交订单"，结果创建了两个一样的订单 前端传了个 null 字段进来，接口直接 500 报错 不同的异常返回不同格式的错误信息，前端对接痛不欲生 上线一个新版本接口，老版本直接挂了 这些问题不是什么高深的技术难题，而是接口健壮性没做好。本文分享 5 个实战技巧，每个都有完整代码，直接抄进你的项目就能用。 一、接口幂等性：防止重复提交 1.1 问题场景 用户点击"提交订单" → 网络抖动，响应慢 → 用户又点了一次 → 创建了两个相同订单 或者更隐蔽的：支付回调重试机制触发，同一笔支付扣了两次款 1.2 方案设计 核心思路：每次请求携带唯一标识（幂等 Key），服务端用 Redis 记录该 Key 是否已处理过。 第一次请求： Client → 带 IdempotentKey=abc123 → Server Server → Redis 查 abc123 → 不存在 → 处理业务 → 存入 Redis Server → 返回正常结果 第二次请求（重复）： Client → 带 IdempotentKey=abc123 → Se....

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

引言 8 月刚开局，Java 生态就热闹非凡。Spring Boot 4.0 正式版发布时间敲定，JDK 22 对 Virtual Threads 做了一波关键性能修复，OpenTelemetry 也终于从 CNCF 毕业了。三件事，每件都跟你的技术选型直接相关。 一、Spring Boot 4.0 正式版发布时间确定 Spring 团队本周确认，Spring Boot 4.0 将于 2025 年 11 月正式发布（ GA ），目前 milestone 版本已可体验。核心新特性包括：默认启用 Virtual Threads、原生支持 GraalVM Native Image（零额外配置）、全面拥抱 Jakarta EE 11、新增 Spring AI 模块作为一等公民依赖。此外，4.0 将最低要求 JDK 17，推荐 JDK 21+。 点评：这次更新最大的意义不是某个单一特性，而是"默认值"的变化——Virtual Threads 和 Native Image 从"可选"变成"默认"，这意味着即使你不主动学习，升级后也会自动获得这些能力。建议从现在开始用 Spring Boot 3.....