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

引言 "帮我看看最近那单到哪了，顺便如果明天有雨就发个邮件提醒我带伞去取快递。"——这句话里藏了三个动作：查订单、查天气、发邮件。传统做法是让用户点三个按钮，或者写一堆关键词规则去猜意图，猜不中就回"我不明白您的意思"。 Function Calling 改变了交互模型：大模型不直接执行你的代码，它只负责"决定"调用哪个方法、传什么参数；LangChain4j 负责真正执行 Java 方法，再把结果喂回大模型；大模型拿到结果后组织自然语言回答。模型是大脑做决策，你的 Java 方法是手脚做执行——查数据库、调内部 API、发邮件，全是真实业务动作。 这篇文章用 LangChain4j 的最新 API（0.36.x，@Tool 注解体系）从零搭一个能多工具协作的助手，完整讲透 Function Calling 的通信原理、三个工具的定义注册、以及"查订单→查天气→发邮件"一条龙的多步编排。 一、Function Calling 的本质：模型不执行，只"点菜" 1.1 一个常见误解 很多人以为 Function Calling 是"大模型直接调用了你的接口"——不是。模型从始至终没有能力....

引言 "我明明加了 @Async，为什么接口还是变慢了？"——打断点一看，方法还在 Tomcat 线程里同步执行，注解形同虚设。另一个故事：压测时监控发现线程数一路涨到几千个，最后 unable to create new native thread 整个服务挂掉——排查发现 @Async 没指定线程池，任务全堆在一个无界队列里。 @Async 可能是 Spring 里"看起来最简单、坑却最密集"的注解：一个注解就让方法异步执行，但它背后是 AOP 代理、线程池、异常处理、上下文传递四套机制。这篇文章把生产中最常见的 8 个坑一次讲透——每坑给翻车代码、原理、修复代码，最后给一份可以直接抄的生产级配置。 一、前置：@Async 的工作原理 调用方线程 ──→ 代理对象（@Async 由 AOP 生成代理） │ ├─ 方法上有 @Async？ │ ├─ 是 → 把"方法调用"包装成 Task，提交给线程池 → 立即返回 │ └─ 否 → 直接反射调用目标方法（同步） │ └─ 代理只拦截"外部通过 Spring Bean 的调用" this.xxx() 内部调用不走代理 → 注解失效 ....

引言 周三下午 2 点，运营群反馈"用户行为分析看板打不开了"。运维查 Redis 监控：CPU 正常、内存正常、连接数正常，但命令延迟 P99 从 2ms 飙到 800ms——看起来一切正常却慢得离谱。接下来 10 分钟，越来越多的接口开始超时，告警从 3 条涨到 47 条，最终整个 Redis 集群不可用。 排查发现：一个名叫 user:behavior:all 的 Hash Key，存了全量用户行为日志，200MB。更致命的是，运维在试图 DEL 这个 Key 时，Redis 主线程被阻塞了 3 秒——3 秒内所有命令排队等待，集群雪崩。 根因出奇简单：业务把用户行为日志全塞进一个 Hash，没设过期时间，日积月累从 2KB 长到 200MB。Redis 是单线程的——一个慢命令阻塞主线程，整个实例都卡住。这篇文章从发现到修复完整复盘，附大 Key 扫描脚本和预防机制。 一、为什么一个大 Key 能拖垮整个集群 1.1 Redis 单线程模型 Redis 主线程（单线程处理所有命令） │ ├─ 命令1: GET user:1001 0.01ms ├─ 命令2: SET toke....

引言 "你简历上写了分布式锁，说说怎么实现的？"——这是 Java 后端面试的高频题。大部分候选人的回答停留在"用 Redis 的 SETNX"——面试官追问三个问题就卡住了：锁过期了任务还没执行完怎么办？Redis 主从切换锁丢了怎么办？同一个线程递归调用能不能重入？ 这三个问题才是分布式锁的真正考点：SETNX 只是"加锁"这一个动作，而分布式锁的完整语义包括——互斥、防死锁、可重入、防误删、续期、故障容忍。每一项都有对应的坑和解决方案。这篇文章从"为什么需要分布式锁"讲起，对比数据库/Redis/Zookeeper 三种实现的底层原理，再深入 Redisson 看门狗的自动续期机制，最后逐一拆解三大坑的成因与解法。 一、为什么需要分布式锁 1.1 本地锁管不住分布式场景 // 单机时代：synchronized / ReentrantLock 就能解决并发 public synchronized void deductStock(Long skuId) { Stock stock = stockMapper.selectBySkuId(skuId); if (stock.get....

引言 "我们想做一个 AI 客服"——产品同学在需求会上说。"简单，接个 GPT API 不就行了？"——这是 90% 团队的第一反应。然后做完发现：用户说"帮我查一下订单 SO20250912001 的物流"，模型回了一句"作为 AI 助手，我无法查询您的订单"。 问题出在哪？接了个聊天 API，不是做了个 Agent。聊天 API 只能基于训练知识"说话"，不能"做事"——查不了数据库、调不了接口、记不住用户身份。Agent 的本质区别不是"更聪明的聊天"，而是"LLM + 工具 + 记忆 + 规划"四件套的组合体：LLM 是大脑，工具是手脚，记忆是上下文，规划是行动方案。 这篇文章是 AI Agent 系列的开篇，用 LangChain4j 拆解 Agent 的四层架构，最后给一个能跑的最小 Agent——它能在"我帮不了你"时主动调工具查数据库，在多轮对话中记住你是谁。全程纯 Java，不写一行 Python。 一、Agent 的本质：不是聊天，是行动 1.1 聊天 vs Agent 的区别 用户：帮我查一下订单 SO20250912001 的物流状态 聊天 API（gpt-....

引言 "让 AI 帮我写了个工具类，review 时发现连参数校验都没有，单测覆盖率 0%。"——这不是 AI 不行，是 prompt 不行。大部分开发者用 AI 写代码的方式是："帮我写一个 XX 工具类"——这就像跟新人说"做个订单功能"然后期望他交付生产级代码。 AI 的输出质量 = prompt 的精确度。同一个需求，"帮我写个单测"出来的测试覆盖三条路径，而"用 JUnit5 + Mockito，覆盖正常/边界/异常三个维度，覆盖率目标 90%，Mock 外部依赖"出来的测试能直接进 CI。差距不在模型能力，在 prompt 的约束密度——你把技术栈、质量标准、验收口径告诉它，它就按工程标准交付；你只说个大概，它就给你个大概的东西。 这篇文章给 Java 开发者 5 个可以直接复制粘贴的 prompt 模板，每个覆盖一个高频场景：单元测试、代码重构、性能优化、Bug 定位、技术选型。每个模板给完整示例 + 调优技巧，模板里的方括号 [...] 是你要替换的变量。 一、模板一：单元测试生成 1.1 模板 你是一个资深的 Java 开发工程师，请为以下方法生成单元测试。 【技术....

引言 大促压测到第 8 分钟，订单服务调用库存服务开始超时。运维的第一反应是调超时时间——把 Feign 的 readTimeout 从 3 秒调到 10 秒，结果更糟了：原本 3 秒失败的请求变成 10 秒失败，线程池被占满，订单服务自己也被上游超时拖垮，整条链路雪崩。调回来想加重试，又发现库存扣减接口不是幂等的——重试一次多扣一遍库存。 这三种痛——超时设多少、重试敢不敢做、调用链断了怎么定位——是微服务调用链治理的核心三问。本文用 OpenFeign + Sentinel + OpenTelemetry 三件套一次配齐，附完整配置和踩坑清单。 一、超时与重试：不是设个数就完事 1.1 超时双层模型 客户端发请求 ──connectTimeout(2s)──→ 建连成功 ──readTimeout(5s)──→ 收到响应 │ │ │ 连不上 │ 连上了但响应慢 ▼ ▼ 连接超时（网络不可达/队列满） 读取超时（下游处理慢/GC/锁等待） 参数含义默认值调优方向 connectTimeout建立 TCP 连接的超时10s（太久）调到 1~2s（连不上就是连不上，别等） r....

引言 "AI 这波我们 Java 开发者能不能不学 Python 也跟上？"——这是过去一年团队里被问得最多的问题。确实，AI 生态的教程九成是 Python 的，LangChain、LlamaIndex、各种 Agent 框架，清一色 pip install。Java 开发者想做一个"接入大模型的客服助手"，面对的是 Python 教程里 from langchain.chains import xxx 的陌生世界，而团队的技术栈、CI/CD、监控、服务治理全是 Java 的——为了一个 AI 接口引入 Python 技术栈，代价远大于收益。 LangChain4j 就是 Java 开发者对这个问题的回答：它把 LangChain 的核心能力（LLM 抽象、提示词模板、记忆、RAG、Agent/Tool Calling）用纯 Java API 重新实现，和 Spring Boot 无缝集成，不需要写一行 Python。这篇文章盘点 LangChain4j 生态里 Java 开发者做 AI 应用的 5 个必备组件，从核心抽象到向量存储到 Spring Boot 集成，每个组件给定位、核....

引言 上周四晚上，运维同学改了一个 Redis 连接池参数，然后经历了这样的流程： ① 改 application.yml → ② git commit → ③ Jenkins 构建 → ④ 打包 → ⑤ 上传服务器 → ⑥ kill -9 停服务 → ⑦ java -jar 启动 → ⑧ 健康检查 → ⑨ 通知客服切换流量 → ⑩ 全过程 12 分钟 改一个参数，12 分钟。如果这个参数改错了，再来 12 分钟。一晚上能改几次？更尴尬的是安全审计那天扫出的配置文件截图： spring: datasource: password: "P@ssw0rd!2024" # 明文密码进了 git redis: password: "redis123" # 明文密码进了 git cloud: alibaba: seata: password: "seata@prod" # 明文密码进了 git 三个生产密码在 git 历史里躺了两年，谁 fork 过、谁 clone 过，全不可追溯。 配置管理的三个痛点——改配置要重启（12 分钟）、多环境配置混乱（dev/test/prod 靠 yml 文....

引言 凌晨 3 点被电话叫醒，打开日志发现定时任务又双击了——上次跑的实例还没结束，这次又开始了，两份并行把库存扣了两遍。这不是什么复杂的分布式 bug，就是单机 @Scheduled 在多实例部署下没有做幂等也没有做调度协调，各跑各的。 找运维要个控制台看看任务状态，答："没有控制台，任务定义在代码里，改 Cron 要重新发版。" 要个失败重试和告警，答："自己写 log + 钉钉机器人。" 要个任务执行历史，答："去 ELK 里搜。" @Scheduled 是个很好的起点，但业务长到"多实例部署 + 任务可视化 + 动态调整 + 失败告警"这四件事里的任何一个，它就不够用了。 团队开始找替代方案：Quartz？XXL-Job？PowerJob？每个方案看起来都能解决一部分问题，但谁也说不清哪个最适合自己。这篇文章把四个方案按"从简单到复杂"排开，逐个拆解能力边界，最后给一张决策树——照着选就行。 一、四个方案速览 1.1 一句话定位 方案一句话定位调度 vs 执行 @ScheduledSpring 原生注解，单机定时器应用内线程池 QuartzJava 生态老牌调度框架，....

引言 三年前我们把单体拆成微服务时，调用关系是这样配置的： # order-service/application.yml user-service: url: http://10.0.1.23:8081 # 用户服务写死 IP stock-service: url: http://10.0.1.24:8082 # 库存服务写死 IP 第一次故障来得毫无悬念：用户服务那台 1.23 物理机宕机，运维紧急在 1.55 拉起实例，然后挨个改 20 个服务的配置、重启、祈祷没有漏网之鱼——光改配置就花了 40 分钟。第二次故障更尴尬：大促临时扩容 10 台库存服务，新实例起来后订单服务一个都调不到——没有地方让它知道“新来的兄弟住在哪”。 IP 漂移（实例挂了换机器）和动态扩容（实例数量随时变）这两个问题，本质上是同一个诉求：服务之间不能用"写死地址"通信，必须有一个"地址簿"动态维护"谁在线、住哪、健不健康"——这就是注册中心。 但选哪个地址簿，团队一直有分歧：老系统跑着 Eureka，新架构组推 Nacos，运维同学说他们更熟 Consul。 这篇文章把注册中心的本质讲透，再对三个候选....

引言 系统拆成微服务后第一个要回答的问题就是：服务之间怎么调？ 这个选择 90% 的团队是在"沿用上一代的习惯"中度过的——Java 老项目接着用 Dubbo，Spring Cloud 全家桶自然 Feign，新起的多语言团队上 gRPC。但真到大促压测时，选型的差异会以三个维度同时砸到你脸上：一个下单接口拆成"订单调库存"两段后，吞吐掉了 40%——这 40% 是消耗在了网络、序列化还是连接管理上？换一个框架能追回来多少？ 带着这个真实场景的问题，我们做了一次严格对照的压测：同一套业务接口（扣减库存），用 Feign、Dubbo、gRPC 三种方式各实现一遍，在同一台机器、同一套 JMeter 10,000 并发口径下跑。这篇文章完整记录测试方法、数据、三个框架各自的胜场与代价，最后给一张选型决策表。 一、三位选手速览 1.1 一句话定位 框架一句话定位本质协议 FeignHTTP 声明式客户端，Spring Cloud 标配，写接口像调本地方法HTTP/1.1 + JSON Dubbo阿里出品的高性能 RPC 框架，TCP 长连接 + 自定义序列化TCP + Dubbo ....

引言 看一眼我们线上早期接口的报错，很容易理解为什么前端同学会崩溃： {"timestamp": "2025-08-22T10:23:01.882", "status": 500, "error": "Internal Server Error", "path": "/order/create"} {"timestamp": "2025-08-22T10:23:03.114", "status": 500, "error": "Internal Server Error", "message": "订单服务异常: java.lang.NullPointerException", "path": "/order/create"} {"code": "A0001", "msg": "系统繁忙"} {"code": "500", "message": "下单失败：库存不足！"} {"errCode": 10010, "errMsg": "param error"} 同一个团队，五种返回结构、三套错误码风格、有的暴露堆栈有的吞掉。前端只能靠 if (res.code === 'A0001' ....

引言 大促彩排当晚，秒杀压测到 3000 并发时，下单接口开始批量报错，日志里刷屏的是同一句话： Deadlock found when trying to get lock; try restarting transaction DBA 的第一反应是“死锁了，MySQL 会自动回滚一个，重启事务就行”——问题是这个死锁每秒都在发生：被回滚的那一半请求里，一部分重试成功，一部分又撞进下一轮死锁，订单创建成功率从 100% 跌到 62%，压测被迫中断。 更蹊跷的是业务视角的死锁描述：两个事务根本“没有”操作同一行——事务 A 更新的是 SKU 1001 的库存，事务 B 更新的是 SKU 2002 的库存，它们凭什么互相等待？带着这个“不相干的行为什么会死锁”的疑问，我们拉开了一次教科书级的 InnoDB 锁排查：SHOW ENGINE INNODB STATUS 的死锁日志 → lock_mode X locks gap 字样 → 真相是间隙锁。这篇文章完整还原排查过程，并附上死锁日志的逐行解读技巧。 一、30 秒补课：InnoDB 的锁到底有几种 看懂死锁日志的前提是分清锁类型。....

引言 上个月运营做了一场大促预售，活动开始 10 分钟后客服反馈开始堆积：同一个用户下了两单。查日志发现不是并发 bug，也不是库存逻辑问题——用户在网络卡顿时连点了两次提交按钮，第一次请求 300ms 才返回，第二次请求几乎是同时到达的。前端虽然有按钮置灰，但置灰逻辑在“请求发出后”才生效，两道请求都穿了过去。 这类问题防得住吗？防得住，而且手段成熟——接口幂等。但幂等实现恰恰是“看起来简单、做对很难”的典型：网上随手搜到的 Redis SETNX 三行代码，放进真实系统里至少有四个坑等着你（并发窗口、异常回滚、过期时间、重复提交的用户体验）。 这篇文章用那次事故开题，把四种幂等方案一次讲透：唯一索引、Redis SETNX、Token 机制、乐观锁。每种给完整可跑的 Spring Boot 3.x 代码、适用场景、防坑要点——最后给一张选型决策表，照着抄就行。 一、为什么需要幂等：不只是双击 1.1 重复请求的四个来源 双击只是冰山一角。生产系统里重复请求的来源比想象中多： 来源场景特点 用户行为双击提交、刷新重发、返回键重放单用户、低频、难彻底在前端防住 网络重试HTT....