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

引言 "一个实例已经下线 20 秒了，消费者还在往它上面发请求，每隔一段时间报一批 connect timeout。" 排查时发现 Nacos 控制台里这个实例先变红（不健康）、过一会儿才彻底消失，而消费端的地址列表更新又比控制台晚了好几秒——三层时间差叠在一起，就是那批超时的全部来源。 要算清这笔时间账，光靠"知道 Nacos 有心跳、有推送"是不够的，必须回答四个源码级问题：服务实例是什么时候、被谁注册上去的？心跳 5 秒一次是谁在发，服务端凭什么 15 秒判不健康、30 秒才摘除？消费者本地的地址列表多久更新一次，UDP 推送和定时拉取到底谁兜底？ 这篇文章以 spring-cloud-alibaba 2.2.x + nacos-client 1.4.x + nacos-naming 1.4.x（HTTP 心跳模式）为准，按一条实例从启动到被发现的真实路径，把 NacosServiceRegistry、NamingProxy、ServiceManager、BeatReactor、HostReactor、PushReceiver 六个核心类串起来。代码均有删减只保留主干，文末会单独....

引言 "帮我看看昨晚订单服务为什么变慢了。" 这句话背后至少有三个动作：查日志里有没有异常堆栈、查监控里 CPU/延迟/QPS 的曲线、把两边的线索拼成一份事故结论。我们最初把所有 @Tool 挂在一个 Agent 上让它自己规划，跑了两周发现三个问题：工具越加越多（查日志、查指标、查链路、查发布记录……12 个工具）后模型开始选错；每个工具的返回值都进同一个上下文，日志片段和指标数据互相干扰；提示词里"日志专家"和"监控专家"的行为要求互相打架，模型谁的都不听。 解法是从"一个全能 Agent"换成"一个主管 + 多个专家"：主管 Agent 只负责听懂需求、拆解任务、汇总报告，手底下没有具体工具；三个执行者 Agent 各自只带自己领域的工具、用自己的专家提示词，并行干活、结果上报。这篇文章用 LangChain4j 实现一个智能运维助手：主管拆解 → 日志/监控执行者并行调查 → 主管汇总成报告，并重点讲清单 Agent 的瓶颈、并行编排的确定性收敛（防止主管反复派活死循环）、以及新增 Agent 不改编排代码的注册表设计。 一、先想清楚：单 Agent 为什么不够用 1.1 ....

引言 客服机器人上线一周，用户的吐槽集中在一句话上："它是不是失忆了？" 用户：我上周买的那双跑鞋想换货，订单尾号 8821 Agent：好的，请提供订单号和商品名称。 用户：我刚说了啊，跑鞋，8821！ Agent：好的，请提供订单号和商品名称。 每轮对话都是一次独立的 HTTP 请求，模型本身是无状态的——你以为它"记得"上一轮，其实是你的应用每次都得把历史重新喂给它。大多数人实现的第一步也确实是"把对话存数据库"，但存了照样失忆：数据库里有历史 ≠ 模型看到了历史。这中间缺的是"记忆注入层"——每次生成前，把该让模型看到的历史和事实，以它能直接利用的格式放进请求。 这篇文章按工程落地的顺序讲清三种记忆：短期记忆（滑动窗口 + Token 裁剪）、长期记忆（偏好向量化 + 检索注入）、会话隔离（userId/sessionId 两级主键），最后用 LangChain4j 实现一个"记得你上次问了什么"的电商客服 Agent。 一、先澄清：模型没有记忆，记忆是你的应用伪造的 1.1 一次请求的真相 // 模型 API 是完全无状态的：每轮对话都要把完整上下文带上 chatMode....

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

引言 "我们想做一个 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-....