这是一个写给 Java 架构师的连载专栏。我们不谈炼丹、不讲 Transformer 原理只回答一个问题手上这套跑了多年的 Spring Cloud怎么稳稳当当地把大模型用起来、用到生产里。全篇按顺序推进今天是第一堂课给微服务装上「大脑」的最小闭环。〇、先说清楚这个系列要带你做什么过去两年我见过太多团队把 AI 用成了「高级玩具」某个后端同学在 Controller 里偷偷塞了一段 HTTP 调用大模型的代码Demo 效果惊艳然后呢API Key 散落在三四个服务里、高峰期一次调用 40 秒拖垮线程池、账单月底超支三倍、模型偶尔胡说八道还被客户截图投诉。问题不在大模型而在没有人用架构师的方式对待它。这个系列一共十篇路线是这样的服务接入(本篇) → RAG 知识库 → Function Calling 工具调用 → 多模型路由与成本 → 稳定性治理 → 可观测性 → 智能体编排 → 安全 → 企业级 AI 中台全景跟着走完你会得到一套能直接搬进公司项目的工程化方案。准备好的话上课。一、心智转换大模型是一个「又贵、又慢、还会犯错」的服务架构师的第一课永远不是写代码而是给新东西定性。请先把对大模型的三个错误幻想扔掉幻觉现实它是无所不知的大脑它是一个按 token 计费的外部 HTTP 服务它很快像查 Redis同步调用秒级起步长文本 10s必须按高延迟依赖设计它说的都对它会一本正经地编造幻觉输出只能当「建议」不能当「事实」定性之后结论就清晰了大模型在你的架构图里和 MySQL、Redis、支付接口一样是一个被依赖的下游资源——只不过它贵、慢、不稳定且返回的是自然语言。你过去积累的所有微服务治理经验超时、熔断、隔离、降级、监控、成本核算对它全部适用只是参数要重新标定。这是整个系列的基石后面每一篇都是在这张「定性表」上做展开。二、架构定位AI 能力必须收敛成一个独立服务最忌讳的做法是让订单、客服、内容三个微服务各自直连大模型。三周后你一定会收获三套 Key、三套超时配置、三份无法合并的 token 账单以及一次「模型供应商涨价全团队加班改代码」的惨痛经历。正确姿势是新增一个基础设施类服务ai-service┌─────────┐ ┌─────────┐ ┌─────────┐ │order-svc│ │ticket-svc│ │content-svc│ 业务服务保持纯粹 └────┬────┘ └────┬────┘ └────┬────┘ └───────────┼───────────┘ Feign / HTTP ▼ ┌─────────────────┐ │ ai-service │ 统一密钥/限流/路由/记账/降级 │ (Spring AI) │ └────────┬────────┘ ▼ ┌──────────┬──────────┐ LLM 厂商 向量库 内部工具(Function Calling)它的职责边界也很明确只做五件事统一持有各家大模型的密钥与配置对内暴露领域化接口总结、抽取、问答、分类而不是裸的/chat统一做超时、熔断、限流与成本统计屏蔽底层模型差异——今天用 A 厂明天换 B 厂业务方零感知后续承载 RAG 知识库与工具调用本系列第 2~4 篇会逐步往里加。技术选型上Java 生态目前就两个主流选择Spring AI 与 LangChain4j。我们整个系列统一用Spring AI1.0 GA 版本理由很简单你团队已经会 Spring Boot自动装配、yaml 配置、Micrometer 监控全是现成的学习成本最低这对要在团队里推动落地的架构师来说是决定性因素。三、最小闭环30 分钟跑通第一个对话接口环境要求JDK 17、Spring Boot 3.2、Spring AI 1.0.x。注意这是硬性门槛Spring AI 不支持 JDK 8还在 JDK 8 的团队需要先规划升级路径这也是架构师要提前向团队说明的成本。3.1 引入依赖与配置dependency groupIdorg.springframework.ai/groupId artifactIdspring-ai-starter-model-openai/artifactId /dependency国内团队不想折腾网络可以直接用兼容 OpenAI 协议的国产模型只改地址即可spring: ai: openai: api-key: ${LLM_API_KEY} # 密钥走环境变量严禁提交到 Git base-url: ${LLM_BASE_URL:https://api.openai.com} chat: options: model: deepseek-chat temperature: 0.3 # 业务场景默认压低减少胡言乱语3.2 用 ChatClient 而不是 ChatModelSpring AI 有两套 API。ChatModel是底层原语ChatClient是带 System 预设、支持流式的 fluent API——业务代码一律用后者Service public class AiChatService { private final ChatClient chatClient; // 构造时设定「人设」所有对话共享统一的系统提示词 public AiChatService(ChatClient.Builder builder) { this.chatClient builder .defaultSystem( 你是企业内部技术助手回答必须 1. 基于用户提供的信息不确定就明说禁止编造 2. 先给结论再给不超过三点理由 3. 涉及操作步骤时给出可执行命令。 ) .build(); } /** 同步问答适合后台批处理类场景 */ public String ask(String question) { return chatClient.prompt() .user(question) .call() .content(); } /** 流式问答面向前端交互token 逐个返回首字延迟从 10s 降到 1s 内 */ public FluxString askStream(String question) { return chatClient.prompt() .user(question) .stream() .content(); } }3.3 暴露 SSE 接口并扛住网关这一关流式是 AI 应用体验的分水岭用 WebFlux 输出 SSERestController RequestMapping(/api/ai) public class AiChatController { private final AiChatService aiChatService; public AiChatController(AiChatService aiChatService) { this.aiChatService aiChatService; } GetMapping(value /chat, produces MediaType.TEXT_EVENT_STREAM_VALUE) public FluxString chat(RequestParam String q) { return aiChatService.askStream(q); } }到这里代码能跑了但架构师的工作才刚开始——这个接口一旦经过 Nginx/Spring Cloud Gateway大概率会出现「转圈十秒答案瞬间全部吐出」的诡异现象。原因是响应缓冲。两处必须改Nginx 层关闭缓冲location /api/ai/ { proxy_pass http://ai-service/; proxy_buffering off; proxy_read_timeout 120s; add_header X-Accel-Buffering no; }GatewayWebFlux 版本身是响应式透传不会缓冲但要记得把全局超时调到大于模型最长响应时间并对 SSE 路径关闭重试——重试一个流式接口用户会收到两遍答案token 也扣两遍钱。用 curl 验证curl -N http://localhost:8080/api/ai/chat?q微服务里如何设计超时看到文字逐字蹦出来最小闭环就完成了业务服务 → ai-service → 大模型 → SSE 回前端。四、第一堂课的作业两个必须现在就想清楚的问题我不给玩具代码当终点留两个生产环境必答题你可以在评论区写下你的方案第 5、6 篇我会给出完整实现线程池怎么隔离ai-service 里一个 40 秒不返回的模型调用会不会把 Tomcat 工作线程占满拖垮同进程的其他接口提示信号量隔离、响应式栈、超时预算三选一或组合。用户看到「服务繁忙」时怎么办模型超时或限流后前端不能一直转圈。降级策略是返回固定话术、转人工还是切换到更小更快的备用模型这两个问题想不明白AI 功能就只能停在内网 Demo 阶段——它们正是本系列中段稳定性治理篇的核心内容。五、本讲小结与下讲预告今天我们只做了一件事但它是后面所有内容的地基把大模型定性为一个贵、慢、会犯错的外部服务并用一个独立的 ai-service 把它收敛进 Spring Cloud 体系最后跑通了同步与流式两个接口。下一篇我们进入真正让 AI「懂业务」的关键技术——RAG检索增强生成为什么把公司文档直接塞给大模型是死路文档怎么切片、怎么生成 Embedding、Redis 和 Milvus 到底怎么选我们下周四晚同一时间动手搭一个能回答内部知识库问题的问答服务。系列导航一服务接入 · 本篇 下一篇二RAG 落地上——文档切片、Embedding 与向量库选型如果这个系列对你有帮助点个关注每周更新不掉队。运行环境说明本文代码基于 JDK 17 Spring Boot 3.3 Spring AI 1.0.x 实测国产兼容模型可直接运行。 
长河君 · 2026/10/15 3:25:39 · 阅读 1.2k Java 架构师的 AI 工程化落地（一）：当 Java 微服务开始「思考」——把大模型装进 Spring Cloud 的第一堂课
这是一个写给 Java 架构师的连载专栏。我们不谈炼丹、不讲 Transformer 原理只回答一个问题手上这套跑了多年的 Spring Cloud怎么稳稳当当地把大模型用起来、用到生产里。全篇按顺序推进今天是第一堂课给微服务装上「大脑」的最小闭环。〇、先说清楚这个系列要带你做什么过去两年我见过太多团队把 AI 用成了「高级玩具」某个后端同学在 Controller 里偷偷塞了一段 HTTP 调用大模型的代码Demo 效果惊艳然后呢API Key 散落在三四个服务里、高峰期一次调用 40 秒拖垮线程池、账单月底超支三倍、模型偶尔胡说八道还被客户截图投诉。问题不在大模型而在没有人用架构师的方式对待它。这个系列一共十篇路线是这样的服务接入(本篇) → RAG 知识库 → Function Calling 工具调用 → 多模型路由与成本 → 稳定性治理 → 可观测性 → 智能体编排 → 安全 → 企业级 AI 中台全景跟着走完你会得到一套能直接搬进公司项目的工程化方案。准备好的话上课。一、心智转换大模型是一个「又贵、又慢、还会犯错」的服务架构师的第一课永远不是写代码而是给新东西定性。请先把对大模型的三个错误幻想扔掉幻觉现实它是无所不知的大脑它是一个按 token 计费的外部 HTTP 服务它很快像查 Redis同步调用秒级起步长文本 10s必须按高延迟依赖设计它说的都对它会一本正经地编造幻觉输出只能当「建议」不能当「事实」定性之后结论就清晰了大模型在你的架构图里和 MySQL、Redis、支付接口一样是一个被依赖的下游资源——只不过它贵、慢、不稳定且返回的是自然语言。你过去积累的所有微服务治理经验超时、熔断、隔离、降级、监控、成本核算对它全部适用只是参数要重新标定。这是整个系列的基石后面每一篇都是在这张「定性表」上做展开。二、架构定位AI 能力必须收敛成一个独立服务最忌讳的做法是让订单、客服、内容三个微服务各自直连大模型。三周后你一定会收获三套 Key、三套超时配置、三份无法合并的 token 账单以及一次「模型供应商涨价全团队加班改代码」的惨痛经历。正确姿势是新增一个基础设施类服务ai-service┌─────────┐ ┌─────────┐ ┌─────────┐ │order-svc│ │ticket-svc│ │content-svc│ 业务服务保持纯粹 └────┬────┘ └────┬────┘ └────┬────┘ └───────────┼───────────┘ Feign / HTTP ▼ ┌─────────────────┐ │ ai-service │ 统一密钥/限流/路由/记账/降级 │ (Spring AI) │ └────────┬────────┘ ▼ ┌──────────┬──────────┐ LLM 厂商 向量库 内部工具(Function Calling)它的职责边界也很明确只做五件事统一持有各家大模型的密钥与配置对内暴露领域化接口总结、抽取、问答、分类而不是裸的/chat统一做超时、熔断、限流与成本统计屏蔽底层模型差异——今天用 A 厂明天换 B 厂业务方零感知后续承载 RAG 知识库与工具调用本系列第 2~4 篇会逐步往里加。技术选型上Java 生态目前就两个主流选择Spring AI 与 LangChain4j。我们整个系列统一用Spring AI1.0 GA 版本理由很简单你团队已经会 Spring Boot自动装配、yaml 配置、Micrometer 监控全是现成的学习成本最低这对要在团队里推动落地的架构师来说是决定性因素。三、最小闭环30 分钟跑通第一个对话接口环境要求JDK 17、Spring Boot 3.2、Spring AI 1.0.x。注意这是硬性门槛Spring AI 不支持 JDK 8还在 JDK 8 的团队需要先规划升级路径这也是架构师要提前向团队说明的成本。3.1 引入依赖与配置dependency groupIdorg.springframework.ai/groupId artifactIdspring-ai-starter-model-openai/artifactId /dependency国内团队不想折腾网络可以直接用兼容 OpenAI 协议的国产模型只改地址即可spring: ai: openai: api-key: ${LLM_API_KEY} # 密钥走环境变量严禁提交到 Git base-url: ${LLM_BASE_URL:https://api.openai.com} chat: options: model: deepseek-chat temperature: 0.3 # 业务场景默认压低减少胡言乱语3.2 用 ChatClient 而不是 ChatModelSpring AI 有两套 API。ChatModel是底层原语ChatClient是带 System 预设、支持流式的 fluent API——业务代码一律用后者Service public class AiChatService { private final ChatClient chatClient; // 构造时设定「人设」所有对话共享统一的系统提示词 public AiChatService(ChatClient.Builder builder) { this.chatClient builder .defaultSystem( 你是企业内部技术助手回答必须 1. 基于用户提供的信息不确定就明说禁止编造 2. 先给结论再给不超过三点理由 3. 涉及操作步骤时给出可执行命令。 ) .build(); } /** 同步问答适合后台批处理类场景 */ public String ask(String question) { return chatClient.prompt() .user(question) .call() .content(); } /** 流式问答面向前端交互token 逐个返回首字延迟从 10s 降到 1s 内 */ public FluxString askStream(String question) { return chatClient.prompt() .user(question) .stream() .content(); } }3.3 暴露 SSE 接口并扛住网关这一关流式是 AI 应用体验的分水岭用 WebFlux 输出 SSERestController RequestMapping(/api/ai) public class AiChatController { private final AiChatService aiChatService; public AiChatController(AiChatService aiChatService) { this.aiChatService aiChatService; } GetMapping(value /chat, produces MediaType.TEXT_EVENT_STREAM_VALUE) public FluxString chat(RequestParam String q) { return aiChatService.askStream(q); } }到这里代码能跑了但架构师的工作才刚开始——这个接口一旦经过 Nginx/Spring Cloud Gateway大概率会出现「转圈十秒答案瞬间全部吐出」的诡异现象。原因是响应缓冲。两处必须改Nginx 层关闭缓冲location /api/ai/ { proxy_pass http://ai-service/; proxy_buffering off; proxy_read_timeout 120s; add_header X-Accel-Buffering no; }GatewayWebFlux 版本身是响应式透传不会缓冲但要记得把全局超时调到大于模型最长响应时间并对 SSE 路径关闭重试——重试一个流式接口用户会收到两遍答案token 也扣两遍钱。用 curl 验证curl -N http://localhost:8080/api/ai/chat?q微服务里如何设计超时看到文字逐字蹦出来最小闭环就完成了业务服务 → ai-service → 大模型 → SSE 回前端。四、第一堂课的作业两个必须现在就想清楚的问题我不给玩具代码当终点留两个生产环境必答题你可以在评论区写下你的方案第 5、6 篇我会给出完整实现线程池怎么隔离ai-service 里一个 40 秒不返回的模型调用会不会把 Tomcat 工作线程占满拖垮同进程的其他接口提示信号量隔离、响应式栈、超时预算三选一或组合。用户看到「服务繁忙」时怎么办模型超时或限流后前端不能一直转圈。降级策略是返回固定话术、转人工还是切换到更小更快的备用模型这两个问题想不明白AI 功能就只能停在内网 Demo 阶段——它们正是本系列中段稳定性治理篇的核心内容。五、本讲小结与下讲预告今天我们只做了一件事但它是后面所有内容的地基把大模型定性为一个贵、慢、会犯错的外部服务并用一个独立的 ai-service 把它收敛进 Spring Cloud 体系最后跑通了同步与流式两个接口。下一篇我们进入真正让 AI「懂业务」的关键技术——RAG检索增强生成为什么把公司文档直接塞给大模型是死路文档怎么切片、怎么生成 Embedding、Redis 和 Milvus 到底怎么选我们下周四晚同一时间动手搭一个能回答内部知识库问题的问答服务。系列导航一服务接入 · 本篇 下一篇二RAG 落地上——文档切片、Embedding 与向量库选型如果这个系列对你有帮助点个关注每周更新不掉队。运行环境说明本文代码基于 JDK 17 Spring Boot 3.3 Spring AI 1.0.x 实测国产兼容模型可直接运行。