1. 从一个真实困境说起为什么“能跑起来的 AI Demo”和“能上线的 AI 应用”是两回事过去一年多我参与过好几个企业内部的 AI 应用落地项目从最早的“接个大模型 API 做个问答机器人”到后来的知识库检索、工单智能分类、合同要素抽取几乎每一个项目都经历过同一个尴尬阶段Demo 演示的时候全场鼓掌真到了要接入生产环境、要过安全审计、要扛住几百个并发、要跟现有业务系统打通的时候整个东西就散架了。散架的地方往往不是模型本身而是模型外面那一圈“脏活累活”密钥往哪放、调用怎么限流、会话上下文怎么存、多个业务线怎么复用同一套能力、模型换了之后上层要不要改代码、日志和审计怎么留痕、灰度发布怎么做、出问题了怎么快速回滚。这些问题跟“AI 能力”本身关系不大但每一个都能让项目卡住。这就是AI 应用底座这个概念出现的背景。而QuickBlue就是我在这个方向上重点关注的一个项目。它想做的事情说白了就是把 AI 应用里那些重复的、跟业务无关的、但又必须有人干的工程问题收敛成一套标准化的底座能力让业务团队只关心“我要用 AI 干什么”而不是“我要怎么把 AI 接进来”。这篇文章我会围绕 QuickBlue 这个项目把 AI 应用底座到底解决什么问题、它的技术选型为什么这么选、微服务架构在这里扮演什么角色、以及实际落地时有哪些坑尽量讲透。适合正在做企业级 AI 应用的技术负责人、架构师也适合想从“调 API”进阶到“做平台”的后端开发。2. QuickBlue 到底是什么把 AI 能力从“散装”变成“基础设施”2.1 一句话定位与它要解决的核心矛盾如果只用一句话概括 QuickBlue我会说它是一套面向企业内部的 AI 应用运行时底座把模型接入、能力编排、流量治理、权限审计这些横切关注点统一收口让上层业务以标准接口的方式消费 AI 能力。注意这里的关键词是“运行时底座”不是“模型训练平台”也不是“Prompt 管理工具”。它不负责训练模型也不负责帮你写 Prompt它负责的是模型能力进入企业系统之后的那一整套工程支撑。它要解决的核心矛盾其实很朴素AI 能力的供给方模型、算法团队和消费方业务系统、前端应用之间存在巨大的工程鸿沟。供给方关心的是模型效果、推理性能消费方关心的是接口稳不稳定、调用方不方便、出问题找谁。中间如果没有一层底座两边就会互相拉扯最后变成每个业务线各自接一遍模型重复造轮子还造得参差不齐。2.2 没有底座时企业 AI 应用会踩的五个坑我在实际项目里总结过缺少统一底座时企业做 AI 应用几乎必然遇到下面这些问题密钥与凭证散落各处每个业务系统自己存一份模型 API Key有的写在配置文件里有的硬编码在代码里轮换一次密钥要改十几个仓库。调用治理完全缺失没有统一的限流、熔断、重试策略某个业务线一个批量任务把配额打满其他业务线全部受影响。能力无法复用A 团队做了一套知识库问答B 团队要用只能复制代码改一改最后维护两份。可观测性为零调用失败了多少次、平均延迟多少、token 消耗多少没人说得清成本失控。合规审计过不了谁在什么时候调用了什么模型、输入输出了什么没有留痕安全部门一问三不知。这五个坑本质上都不是 AI 问题而是分布式系统治理问题。这也解释了为什么 QuickBlue 这类项目会大量借鉴微服务领域已经成熟的方案。2.3 它和“模型网关”的区别在哪很多人第一次听到 AI 应用底座会把它等同于“模型网关”。这两者有重叠但范围不一样。模型网关主要解决的是南北向流量问题外部请求进来路由到不同的模型供应商做协议转换、鉴权、计费。它更像是一个反向代理层。而 AI 应用底座解决的是更完整的生命周期问题除了南北向流量还包括东西向的服务间调用治理微服务之间的通信能力的注册与发现有哪些 AI 能力可用会话与上下文管理多轮对话状态业务侧的编排把多个 AI 能力串成一个业务流程配置的集中管理与动态下发打个比方模型网关像是小区门口的门禁AI 应用底座则是整个小区的物业系统——门禁只是其中一小块。3. 技术选型拆解为什么是微服务 Spring Cloud JDK 213.1 微服务架构在这里不是“为了微而微”一提到微服务很多人第一反应是“过度设计”。但在 AI 应用底座这个场景下微服务是有实打实理由的我梳理了三个第一能力边界天然清晰。模型接入、会话管理、权限审计、计费统计这些模块的职责差异很大变更频率也不同。模型接入层可能因为新供应商接入一周改三次而审计模块可能几个月不动。放在一个单体里改一处要全量发布风险大。第二资源特性差异大。模型调用是 IO 密集型会话存储是内存/缓存密集型统计计算是 CPU 密集型。混在一起部署扩容时没法按需扩只能整体扩浪费资源。第三故障隔离需求强。某个模型供应商抖动不应该拖垮整个底座。微服务 熔断隔离能把故障限制在单个服务内。注意微服务不是银弹。如果你的团队只有三五个人AI 应用还处于验证阶段我建议先用模块化单体把边界划清楚等真的扛不住了再拆。QuickBlue 这种底座形态适合的是已经有多个业务线、多个 AI 场景要复用的中大型团队。3.2 Spring Cloud 生态的取舍停更传闻下的理性选择热搜里有个词很扎眼——“spring cloud alibaba 停更了”。这个说法其实需要澄清一下并不是整个 Spring Cloud Alibaba 停更而是部分组件的维护节奏和版本策略发生了变化社区里因此有不少讨论。对于要选型的企业来说真正要关心的不是“停没停”而是你依赖的组件有没有活跃的替代方案迁移成本高不高。QuickBlue 这类底座在选型时我的建议是遵循“分层依赖”原则层次组件类型选型建议理由注册与配置Nacos / Consul优先 Nacos国内生态成熟配置中心与服务发现一体网关Spring Cloud Gateway稳定首选响应式、性能好、社区活跃熔断限流Sentinel优先 Sentinel规则动态下发控制台完善调用OpenFeign标配声明式和 Spring 生态无缝链路追踪Micrometer Tracing替代 SleuthSleuth 已进入维护末期这里要特别说 Sentinel。热搜里出现了“spring cloud sentinel datasource redis集群”这其实指向一个很实际的场景Sentinel 的规则持久化。默认情况下 Sentinel 规则存在内存里重启就丢生产环境必须把规则持久化到 Nacos 或 Redis。用 Redis 集群做规则数据源适合规则量大、多实例共享的场景但要注意 Redis 本身的高可用否则规则拉取失败会导致限流失效。3.3 JDK 21 带来的实际收益JDK 21 是 LTS 版本对 AI 应用底座来说最值得关注的是虚拟线程Virtual Threads。AI 应用底座的一个典型特征就是大量阻塞式 IO调用模型 API、读写会话存储、查询向量库全是等待。传统平台线程模型下一个请求占一个线程线程池打满就排队。虚拟线程让“一个请求一个线程”的编程模型重新变得可行同时吞吐量大幅提升。我实测过一个简单的对比在模拟模型调用固定 200ms 延迟的场景下同样 4 核 8G 的机器平台线程池配置 200 时 QPS 大概在 900 左右换成虚拟线程后能到 3000 以上。当然这是理想化测试真实场景受下游模型限流影响但趋势是明确的。不过要注意几个坑虚拟线程不适合 CPU 密集型任务别一股脑全换。用了synchronized的地方可能造成载体线程 pinnedJDK 21 里部分场景已优化但仍需注意。一些老版本的连接池、驱动对虚拟线程支持不好要升级。4. 核心模块拆解一个 AI 应用底座应该长什么样4.1 能力接入层让模型供应商可插拔这是底座最核心的一层。设计目标很明确上层业务不感知具体模型供应商换模型不改业务代码。实现上通常采用“适配器 统一抽象”的模式。定义一个统一的AiCapability接口包含对话、补全、向量化、重排等标准方法每个模型供应商实现一个适配器。业务侧只依赖接口通过能力标识比如chat.default来调用具体路由到哪个供应商由底座配置决定。这里有个经验统一抽象不要设计得太细。我见过有的团队把接口设计得无比精细结果每接一个新供应商都要改接口适配器变成负担。正确的做法是抽象出 80% 场景共用的最小集合剩下的差异用扩展参数Map 或 JSON透传。4.2 流量治理层限流、熔断、重试一个都不能少AI 调用有几个特点决定了治理层必须做厚下游不稳定模型服务偶发超时、限流是常态。成本敏感每次调用都是钱不能无脑重试。配额有限供应商给的 QPS 和 token 配额是硬约束。所以治理策略要分层设计入口限流按业务线、按用户维度限流防止单点打满。熔断降级某供应商错误率超阈值快速熔断走备用供应商或返回兜底结果。重试策略只对幂等且明确可重试的错误重试且要控制重试次数和退避时间避免放大流量。提示重试一定要配退避backoff固定间隔重试在故障时会形成流量尖峰把下游彻底打垮。指数退避 抖动是标配。4.3 会话与上下文层多轮对话的状态管理多轮对话是 AI 应用的刚需但状态管理是个麻烦事。底座的会话层要解决会话怎么存、存多久、多实例怎么共享、上下文怎么裁剪。常见方案是用 Redis 存会话上下文key 按session:{biz}:{userId}:{conversationId}组织。上下文裁剪是个技术活——模型有 token 上限历史消息不能无限堆。通常做法是保留最近 N 轮 系统提示词 关键摘要超出的部分做摘要压缩。这里踩过的坑不要把整个上下文塞进一次请求。有的实现每次把全部历史发给模型token 消耗爆炸延迟还高。正确做法是维护一个滑动窗口配合摘要。4.4 权限与审计层合规的底线企业级应用绕不开这一层。核心是三件事认证谁在调用身份怎么传递。授权这个身份能调用哪些能力配额多少。审计调用记录留痕可追溯。审计日志的字段设计很关键至少要包含调用方标识、能力标识、模型供应商、请求时间、耗时、token 消耗、结果状态、脱敏后的输入输出摘要。注意是“脱敏后”原始输入输出可能含敏感信息不能直接落库。5. 实操落地从零搭一个最小可用的底座骨架5.1 工程结构规划一个可落地的底座我建议按下面的模块划分以 Maven 多模块为例quickblue-parent ├── quickblue-common # 公共工具、常量、统一返回 ├── quickblue-gateway # 网关统一入口 ├── quickblue-capability # 能力接入与适配器 ├── quickblue-governance # 限流熔断治理 ├── quickblue-session # 会话上下文管理 ├── quickblue-audit # 权限与审计 └── quickblue-bootstrap # 启动与配置聚合这样拆的好处是每个模块可以独立演进、独立部署。初期如果人手不够可以把 governance 和 capability 合并但接口边界要留好。5.2 关键配置示例Sentinel 规则持久化到 Nacos这是生产环境必做的一步。先在 Nacos 建一个配置dataId 比如quickblue-sentinel-flow内容[ { resource: ai.chat.default, limitApp: default, grade: 1, count: 100, strategy: 0, controlBehavior: 0 } ]然后在代码里注册数据源Configuration public class SentinelConfig { PostConstruct public void init() { String remoteAddress nacos-server:8848; String groupId DEFAULT_GROUP; String dataId quickblue-sentinel-flow; ReadableDataSourceString, ListFlowRule flowRuleDataSource new NacosDataSource(remoteAddress, groupId, dataId, source - JSON.parseObject(source, new TypeReferenceListFlowRule() {})); FlowRuleManager.register2Property(flowRuleDataSource.getProperty()); } }这样规则改了之后Nacos 推送各实例实时生效不用重启。注意 Nacos 地址要配成集群地址单点挂了规则拉不到限流就形同虚设。5.3 虚拟线程的开启方式JDK 21 下开启虚拟线程Spring Boot 3.2 支持得比较好。配置方式spring: threads: virtual: enabled: true如果是自定义线程池用ExecutorService executor Executors.newVirtualThreadPerTaskExecutor();但要提醒一句开启前先压测。有些依赖库比如某些老版本的数据库驱动、HTTP 客户端在虚拟线程下会有兼容问题表现为性能不升反降。我一般会先在非核心链路灰度观察一段时间再全量。5.4 能力适配器的实现骨架public interface AiCapability { String code(); ChatResponse chat(ChatRequest request); EmbeddingResponse embed(EmbeddingRequest request); } Component public class OpenAiCompatibleAdapter implements AiCapability { Override public String code() { return openai-compatible; } Override public ChatResponse chat(ChatRequest request) { // 协议转换、鉴权、调用、结果映射 } }业务侧通过CapabilityRouter按 code 路由路由规则从配置中心读取支持动态切换。6. 常见问题与排查技巧实录6.1 问题速查表现象可能原因排查方向限流规则不生效规则未持久化 / Nacos 拉取失败检查数据源注册、Nacos 连通性虚拟线程下吞吐不升反降存在 pinned 场景 / 驱动不兼容用 JFR 抓 pinned 事件升级依赖会话上下文丢失Redis 过期时间太短 / key 设计冲突检查 TTL 配置、key 命名规范熔断误触发阈值设置过敏感 / 统计窗口太短调整错误率阈值和最小请求数审计日志缺失异步落库失败 / 脱敏异常检查异步线程池、脱敏规则6.2 几个我踩过的坑坑一把限流做在业务代码里。早期图省事在 Service 方法里手写计数器限流结果多实例部署后限流形同虚设因为每个实例各算各的。限流一定要用集中式方案Sentinel 集群限流或 Redis 计数器。坑二重试没做幂等。模型调用重试时如果下游已经处理了重复调用会造成重复计费甚至重复业务动作。重试前一定要确认操作幂等或者用请求 ID 做去重。坑三审计日志同步写。一开始审计日志和业务逻辑同步落库模型调用延迟被日志拖累。改成异步 本地队列缓冲后延迟明显下降。但要注意异步落库的可靠性队列满了要有降级策略。坑四忽略 token 计费统计。上线一个月后财务来问 AI 花了多少钱才发现没做 token 统计。后来在适配器层统一埋点按调用方、能力、模型三个维度统计成本才可控。6.3 性能调优的几个方向连接池模型调用是 HTTP连接池大小要匹配并发量别用默认值。缓存向量化结果、高频问答结果可以缓存命中率往往不低。批处理向量化、重排这类操作支持批量就批量减少往返。超时设置模型调用超时要合理太长会拖垮线程太短会误杀。建议按能力分级配置。7. 关于微服务拆分粒度的一点个人看法热搜里“微服务拆分”是个高频词我最后想聊聊这个。做 AI 应用底座拆分粒度是个容易走极端的地方。拆太细服务间调用链变长一个请求跨七八个服务排查问题像破案拆太粗又回到单体失去微服务的意义。我的经验是按“变更频率 资源特性 团队边界”三个维度来拆。变更频率相近的放一起资源特性差异大的分开团队边界清晰的独立。具体到 AI 底座能力接入层和治理层可以合并都跟调用相关会话层独立状态特性不同审计层独立合规要求独立演进。另外热搜里“若依 spring cloud”“若依微服务plus”这类词说明很多团队是从若依这类脚手架起步的。若依的好处是开箱即用但它的模块划分是按通用后台管理设计的直接拿来套 AI 底座会有点别扭。我的建议是借鉴它的工程规范但模块边界要按 AI 场景重新划。至于“数据通信网络与微服务”这个说法本质上是提醒我们微服务之间的通信质量直接决定底座稳定性。服务间调用要配超时、重试、熔断别裸调。序列化协议上内部调用用 Protobuf 或 JSON 都行关键是统一别一个服务一个样。这套东西搭起来不轻松但一旦搭好后面每接一个新 AI 场景边际成本会低很多。我在实际项目里最深的一个体会是AI 应用底座的价值不在于它多先进而在于它把不确定性收敛了。模型会换、供应商会变、业务需求会飘但底座提供的那些标准接口和治理能力是相对稳定的锚点。有了这个锚点团队才敢放心地往上堆业务。 
长河君 · 2026/10/8 6:32:49 · 阅读 1.2k AI应用底座实战：基于微服务与JDK21的QuickBlue架构解析
1. 从一个真实困境说起为什么“能跑起来的 AI Demo”和“能上线的 AI 应用”是两回事过去一年多我参与过好几个企业内部的 AI 应用落地项目从最早的“接个大模型 API 做个问答机器人”到后来的知识库检索、工单智能分类、合同要素抽取几乎每一个项目都经历过同一个尴尬阶段Demo 演示的时候全场鼓掌真到了要接入生产环境、要过安全审计、要扛住几百个并发、要跟现有业务系统打通的时候整个东西就散架了。散架的地方往往不是模型本身而是模型外面那一圈“脏活累活”密钥往哪放、调用怎么限流、会话上下文怎么存、多个业务线怎么复用同一套能力、模型换了之后上层要不要改代码、日志和审计怎么留痕、灰度发布怎么做、出问题了怎么快速回滚。这些问题跟“AI 能力”本身关系不大但每一个都能让项目卡住。这就是AI 应用底座这个概念出现的背景。而QuickBlue就是我在这个方向上重点关注的一个项目。它想做的事情说白了就是把 AI 应用里那些重复的、跟业务无关的、但又必须有人干的工程问题收敛成一套标准化的底座能力让业务团队只关心“我要用 AI 干什么”而不是“我要怎么把 AI 接进来”。这篇文章我会围绕 QuickBlue 这个项目把 AI 应用底座到底解决什么问题、它的技术选型为什么这么选、微服务架构在这里扮演什么角色、以及实际落地时有哪些坑尽量讲透。适合正在做企业级 AI 应用的技术负责人、架构师也适合想从“调 API”进阶到“做平台”的后端开发。2. QuickBlue 到底是什么把 AI 能力从“散装”变成“基础设施”2.1 一句话定位与它要解决的核心矛盾如果只用一句话概括 QuickBlue我会说它是一套面向企业内部的 AI 应用运行时底座把模型接入、能力编排、流量治理、权限审计这些横切关注点统一收口让上层业务以标准接口的方式消费 AI 能力。注意这里的关键词是“运行时底座”不是“模型训练平台”也不是“Prompt 管理工具”。它不负责训练模型也不负责帮你写 Prompt它负责的是模型能力进入企业系统之后的那一整套工程支撑。它要解决的核心矛盾其实很朴素AI 能力的供给方模型、算法团队和消费方业务系统、前端应用之间存在巨大的工程鸿沟。供给方关心的是模型效果、推理性能消费方关心的是接口稳不稳定、调用方不方便、出问题找谁。中间如果没有一层底座两边就会互相拉扯最后变成每个业务线各自接一遍模型重复造轮子还造得参差不齐。2.2 没有底座时企业 AI 应用会踩的五个坑我在实际项目里总结过缺少统一底座时企业做 AI 应用几乎必然遇到下面这些问题密钥与凭证散落各处每个业务系统自己存一份模型 API Key有的写在配置文件里有的硬编码在代码里轮换一次密钥要改十几个仓库。调用治理完全缺失没有统一的限流、熔断、重试策略某个业务线一个批量任务把配额打满其他业务线全部受影响。能力无法复用A 团队做了一套知识库问答B 团队要用只能复制代码改一改最后维护两份。可观测性为零调用失败了多少次、平均延迟多少、token 消耗多少没人说得清成本失控。合规审计过不了谁在什么时候调用了什么模型、输入输出了什么没有留痕安全部门一问三不知。这五个坑本质上都不是 AI 问题而是分布式系统治理问题。这也解释了为什么 QuickBlue 这类项目会大量借鉴微服务领域已经成熟的方案。2.3 它和“模型网关”的区别在哪很多人第一次听到 AI 应用底座会把它等同于“模型网关”。这两者有重叠但范围不一样。模型网关主要解决的是南北向流量问题外部请求进来路由到不同的模型供应商做协议转换、鉴权、计费。它更像是一个反向代理层。而 AI 应用底座解决的是更完整的生命周期问题除了南北向流量还包括东西向的服务间调用治理微服务之间的通信能力的注册与发现有哪些 AI 能力可用会话与上下文管理多轮对话状态业务侧的编排把多个 AI 能力串成一个业务流程配置的集中管理与动态下发打个比方模型网关像是小区门口的门禁AI 应用底座则是整个小区的物业系统——门禁只是其中一小块。3. 技术选型拆解为什么是微服务 Spring Cloud JDK 213.1 微服务架构在这里不是“为了微而微”一提到微服务很多人第一反应是“过度设计”。但在 AI 应用底座这个场景下微服务是有实打实理由的我梳理了三个第一能力边界天然清晰。模型接入、会话管理、权限审计、计费统计这些模块的职责差异很大变更频率也不同。模型接入层可能因为新供应商接入一周改三次而审计模块可能几个月不动。放在一个单体里改一处要全量发布风险大。第二资源特性差异大。模型调用是 IO 密集型会话存储是内存/缓存密集型统计计算是 CPU 密集型。混在一起部署扩容时没法按需扩只能整体扩浪费资源。第三故障隔离需求强。某个模型供应商抖动不应该拖垮整个底座。微服务 熔断隔离能把故障限制在单个服务内。注意微服务不是银弹。如果你的团队只有三五个人AI 应用还处于验证阶段我建议先用模块化单体把边界划清楚等真的扛不住了再拆。QuickBlue 这种底座形态适合的是已经有多个业务线、多个 AI 场景要复用的中大型团队。3.2 Spring Cloud 生态的取舍停更传闻下的理性选择热搜里有个词很扎眼——“spring cloud alibaba 停更了”。这个说法其实需要澄清一下并不是整个 Spring Cloud Alibaba 停更而是部分组件的维护节奏和版本策略发生了变化社区里因此有不少讨论。对于要选型的企业来说真正要关心的不是“停没停”而是你依赖的组件有没有活跃的替代方案迁移成本高不高。QuickBlue 这类底座在选型时我的建议是遵循“分层依赖”原则层次组件类型选型建议理由注册与配置Nacos / Consul优先 Nacos国内生态成熟配置中心与服务发现一体网关Spring Cloud Gateway稳定首选响应式、性能好、社区活跃熔断限流Sentinel优先 Sentinel规则动态下发控制台完善调用OpenFeign标配声明式和 Spring 生态无缝链路追踪Micrometer Tracing替代 SleuthSleuth 已进入维护末期这里要特别说 Sentinel。热搜里出现了“spring cloud sentinel datasource redis集群”这其实指向一个很实际的场景Sentinel 的规则持久化。默认情况下 Sentinel 规则存在内存里重启就丢生产环境必须把规则持久化到 Nacos 或 Redis。用 Redis 集群做规则数据源适合规则量大、多实例共享的场景但要注意 Redis 本身的高可用否则规则拉取失败会导致限流失效。3.3 JDK 21 带来的实际收益JDK 21 是 LTS 版本对 AI 应用底座来说最值得关注的是虚拟线程Virtual Threads。AI 应用底座的一个典型特征就是大量阻塞式 IO调用模型 API、读写会话存储、查询向量库全是等待。传统平台线程模型下一个请求占一个线程线程池打满就排队。虚拟线程让“一个请求一个线程”的编程模型重新变得可行同时吞吐量大幅提升。我实测过一个简单的对比在模拟模型调用固定 200ms 延迟的场景下同样 4 核 8G 的机器平台线程池配置 200 时 QPS 大概在 900 左右换成虚拟线程后能到 3000 以上。当然这是理想化测试真实场景受下游模型限流影响但趋势是明确的。不过要注意几个坑虚拟线程不适合 CPU 密集型任务别一股脑全换。用了synchronized的地方可能造成载体线程 pinnedJDK 21 里部分场景已优化但仍需注意。一些老版本的连接池、驱动对虚拟线程支持不好要升级。4. 核心模块拆解一个 AI 应用底座应该长什么样4.1 能力接入层让模型供应商可插拔这是底座最核心的一层。设计目标很明确上层业务不感知具体模型供应商换模型不改业务代码。实现上通常采用“适配器 统一抽象”的模式。定义一个统一的AiCapability接口包含对话、补全、向量化、重排等标准方法每个模型供应商实现一个适配器。业务侧只依赖接口通过能力标识比如chat.default来调用具体路由到哪个供应商由底座配置决定。这里有个经验统一抽象不要设计得太细。我见过有的团队把接口设计得无比精细结果每接一个新供应商都要改接口适配器变成负担。正确的做法是抽象出 80% 场景共用的最小集合剩下的差异用扩展参数Map 或 JSON透传。4.2 流量治理层限流、熔断、重试一个都不能少AI 调用有几个特点决定了治理层必须做厚下游不稳定模型服务偶发超时、限流是常态。成本敏感每次调用都是钱不能无脑重试。配额有限供应商给的 QPS 和 token 配额是硬约束。所以治理策略要分层设计入口限流按业务线、按用户维度限流防止单点打满。熔断降级某供应商错误率超阈值快速熔断走备用供应商或返回兜底结果。重试策略只对幂等且明确可重试的错误重试且要控制重试次数和退避时间避免放大流量。提示重试一定要配退避backoff固定间隔重试在故障时会形成流量尖峰把下游彻底打垮。指数退避 抖动是标配。4.3 会话与上下文层多轮对话的状态管理多轮对话是 AI 应用的刚需但状态管理是个麻烦事。底座的会话层要解决会话怎么存、存多久、多实例怎么共享、上下文怎么裁剪。常见方案是用 Redis 存会话上下文key 按session:{biz}:{userId}:{conversationId}组织。上下文裁剪是个技术活——模型有 token 上限历史消息不能无限堆。通常做法是保留最近 N 轮 系统提示词 关键摘要超出的部分做摘要压缩。这里踩过的坑不要把整个上下文塞进一次请求。有的实现每次把全部历史发给模型token 消耗爆炸延迟还高。正确做法是维护一个滑动窗口配合摘要。4.4 权限与审计层合规的底线企业级应用绕不开这一层。核心是三件事认证谁在调用身份怎么传递。授权这个身份能调用哪些能力配额多少。审计调用记录留痕可追溯。审计日志的字段设计很关键至少要包含调用方标识、能力标识、模型供应商、请求时间、耗时、token 消耗、结果状态、脱敏后的输入输出摘要。注意是“脱敏后”原始输入输出可能含敏感信息不能直接落库。5. 实操落地从零搭一个最小可用的底座骨架5.1 工程结构规划一个可落地的底座我建议按下面的模块划分以 Maven 多模块为例quickblue-parent ├── quickblue-common # 公共工具、常量、统一返回 ├── quickblue-gateway # 网关统一入口 ├── quickblue-capability # 能力接入与适配器 ├── quickblue-governance # 限流熔断治理 ├── quickblue-session # 会话上下文管理 ├── quickblue-audit # 权限与审计 └── quickblue-bootstrap # 启动与配置聚合这样拆的好处是每个模块可以独立演进、独立部署。初期如果人手不够可以把 governance 和 capability 合并但接口边界要留好。5.2 关键配置示例Sentinel 规则持久化到 Nacos这是生产环境必做的一步。先在 Nacos 建一个配置dataId 比如quickblue-sentinel-flow内容[ { resource: ai.chat.default, limitApp: default, grade: 1, count: 100, strategy: 0, controlBehavior: 0 } ]然后在代码里注册数据源Configuration public class SentinelConfig { PostConstruct public void init() { String remoteAddress nacos-server:8848; String groupId DEFAULT_GROUP; String dataId quickblue-sentinel-flow; ReadableDataSourceString, ListFlowRule flowRuleDataSource new NacosDataSource(remoteAddress, groupId, dataId, source - JSON.parseObject(source, new TypeReferenceListFlowRule() {})); FlowRuleManager.register2Property(flowRuleDataSource.getProperty()); } }这样规则改了之后Nacos 推送各实例实时生效不用重启。注意 Nacos 地址要配成集群地址单点挂了规则拉不到限流就形同虚设。5.3 虚拟线程的开启方式JDK 21 下开启虚拟线程Spring Boot 3.2 支持得比较好。配置方式spring: threads: virtual: enabled: true如果是自定义线程池用ExecutorService executor Executors.newVirtualThreadPerTaskExecutor();但要提醒一句开启前先压测。有些依赖库比如某些老版本的数据库驱动、HTTP 客户端在虚拟线程下会有兼容问题表现为性能不升反降。我一般会先在非核心链路灰度观察一段时间再全量。5.4 能力适配器的实现骨架public interface AiCapability { String code(); ChatResponse chat(ChatRequest request); EmbeddingResponse embed(EmbeddingRequest request); } Component public class OpenAiCompatibleAdapter implements AiCapability { Override public String code() { return openai-compatible; } Override public ChatResponse chat(ChatRequest request) { // 协议转换、鉴权、调用、结果映射 } }业务侧通过CapabilityRouter按 code 路由路由规则从配置中心读取支持动态切换。6. 常见问题与排查技巧实录6.1 问题速查表现象可能原因排查方向限流规则不生效规则未持久化 / Nacos 拉取失败检查数据源注册、Nacos 连通性虚拟线程下吞吐不升反降存在 pinned 场景 / 驱动不兼容用 JFR 抓 pinned 事件升级依赖会话上下文丢失Redis 过期时间太短 / key 设计冲突检查 TTL 配置、key 命名规范熔断误触发阈值设置过敏感 / 统计窗口太短调整错误率阈值和最小请求数审计日志缺失异步落库失败 / 脱敏异常检查异步线程池、脱敏规则6.2 几个我踩过的坑坑一把限流做在业务代码里。早期图省事在 Service 方法里手写计数器限流结果多实例部署后限流形同虚设因为每个实例各算各的。限流一定要用集中式方案Sentinel 集群限流或 Redis 计数器。坑二重试没做幂等。模型调用重试时如果下游已经处理了重复调用会造成重复计费甚至重复业务动作。重试前一定要确认操作幂等或者用请求 ID 做去重。坑三审计日志同步写。一开始审计日志和业务逻辑同步落库模型调用延迟被日志拖累。改成异步 本地队列缓冲后延迟明显下降。但要注意异步落库的可靠性队列满了要有降级策略。坑四忽略 token 计费统计。上线一个月后财务来问 AI 花了多少钱才发现没做 token 统计。后来在适配器层统一埋点按调用方、能力、模型三个维度统计成本才可控。6.3 性能调优的几个方向连接池模型调用是 HTTP连接池大小要匹配并发量别用默认值。缓存向量化结果、高频问答结果可以缓存命中率往往不低。批处理向量化、重排这类操作支持批量就批量减少往返。超时设置模型调用超时要合理太长会拖垮线程太短会误杀。建议按能力分级配置。7. 关于微服务拆分粒度的一点个人看法热搜里“微服务拆分”是个高频词我最后想聊聊这个。做 AI 应用底座拆分粒度是个容易走极端的地方。拆太细服务间调用链变长一个请求跨七八个服务排查问题像破案拆太粗又回到单体失去微服务的意义。我的经验是按“变更频率 资源特性 团队边界”三个维度来拆。变更频率相近的放一起资源特性差异大的分开团队边界清晰的独立。具体到 AI 底座能力接入层和治理层可以合并都跟调用相关会话层独立状态特性不同审计层独立合规要求独立演进。另外热搜里“若依 spring cloud”“若依微服务plus”这类词说明很多团队是从若依这类脚手架起步的。若依的好处是开箱即用但它的模块划分是按通用后台管理设计的直接拿来套 AI 底座会有点别扭。我的建议是借鉴它的工程规范但模块边界要按 AI 场景重新划。至于“数据通信网络与微服务”这个说法本质上是提醒我们微服务之间的通信质量直接决定底座稳定性。服务间调用要配超时、重试、熔断别裸调。序列化协议上内部调用用 Protobuf 或 JSON 都行关键是统一别一个服务一个样。这套东西搭起来不轻松但一旦搭好后面每接一个新 AI 场景边际成本会低很多。我在实际项目里最深的一个体会是AI 应用底座的价值不在于它多先进而在于它把不确定性收敛了。模型会换、供应商会变、业务需求会飘但底座提供的那些标准接口和治理能力是相对稳定的锚点。有了这个锚点团队才敢放心地往上堆业务。