1. 从一个真实困境说起为什么“能跑起来的 AI Demo”和“能上线的 AI 应用”之间隔着一整条鸿沟过去一年多我参与过好几个企业内部的 AI 应用落地项目从最开始的智能问答助手到后来的文档解析、工单自动分类、知识库检索增强几乎每一个项目都经历过同样的剧本第一周搭出一个 Demo效果惊艳老板看完拍板“就按这个方向做”第二周开始接入真实业务系统问题像潮水一样涌出来——模型调用超时怎么重试、多租户的会话上下文怎么隔离、Prompt 模板改了要不要重新发版、向量库和业务库的数据一致性怎么保证、某个模型服务挂了怎么自动降级到备用模型。等到第三周团队里已经有人在问一个灵魂问题我们到底是在做 AI 应用还是在重新造一个后端中间件这就是QuickBlue这类“AI 应用底座”要解决的核心问题。它不是又一个模型也不是又一个聊天界面而是一层位于业务应用和底层大模型之间的工程化基础设施。你可以把它理解成 AI 时代的 Spring Cloud——当年微服务兴起时大家发现光有业务代码不够还需要服务注册、配置中心、熔断限流、网关路由这一整套东西于是有了 Spring Cloud 生态现在 AI 应用兴起同样的问题换了个马甲又出现了只不过这次要管的不只是微服务还有模型、Prompt、向量、会话、Token 配额这些新角色。这篇文章我想聊的不是 QuickBlue 的官方文档复述而是从一个一线落地者的角度把“AI 应用底座”这件事拆开讲清楚它到底包含哪些能力、为什么企业绕不开它、用 Spring Cloud 这套成熟体系去承载它有哪些坑和技巧、JDK 21 在这里面扮演什么角色。如果你正在做企业级 AI 应用或者正在评估要不要引入一个底座这篇应该能帮你少走几个月的弯路。2. 先把概念掰开AI 应用底座到底“底座”了什么2.1 从微服务架构图看 AI 应用的分层逻辑传统微服务架构图里我们习惯画这么几层接入层网关、应用层业务微服务、中间件层注册中心、配置中心、消息队列、数据层数据库、缓存。这套分层之所以经典是因为它把“变化频率不同的东西”分开了——网关很少改业务服务经常改中间件几乎不改。AI 应用底座本质上是在这套分层里插入了一个新的中间层我习惯叫它“AI 能力层”。这一层往上对业务服务暴露统一的 AI 能力接口比如chat、embedding、rerank、agent往下对接各种异构的模型提供方自研模型、第三方 API、本地推理服务。中间它要负责的事情包括模型路由、Prompt 版本管理、会话状态管理、Token 计量与配额、内容安全过滤、调用链路追踪。为什么这一层必须独立出来因为它的变化频率和业务层完全不同。业务逻辑可能一周改一次但模型供应商可能一个月换一次Prompt 可能一天调十次。如果把这些逻辑散落在各个业务微服务里每次换模型都要改十几个服务这是灾难。把它收敛成一层业务服务只依赖抽象接口底层怎么换都不影响上层这才是微服务拆分思想在 AI 场景下的正确应用。2.2 为什么不是“直接调 API”就完事很多人第一反应是我业务代码里直接httpClient.post(modelUrl, prompt)不就行了为什么要多一层小规模确实可以但一旦满足下面任意两个条件直接调 API 就会开始反噬你有多个业务线共用同一个模型需要统一计量和限流需要在多个模型之间做灰度或降级Prompt 需要非开发人员比如运营、产品参与调整需要记录完整的调用审计日志用于合规会话上下文需要跨请求、跨实例保持我见过一个团队三个业务线各自直连模型 API结果某天一个业务线写了个死循环把整个账号的 Token 配额刷爆另外两个业务线当天全部不可用。如果中间有一层底座做配额隔离和熔断这个事故根本不会发生。这就是“底座”的价值——它把横切关注点从业务代码里抽出来集中治理。2.3 QuickBlue 的定位不是框架是“可运行的底座”需要澄清一点QuickBlue 这类产品和 Spring Cloud 这种纯框架不太一样。Spring Cloud 给你一堆库你自己组装而 AI 应用底座通常是开箱可运行的一套服务集合包含网关、AI 能力服务、管理后台、配置存储等你部署起来就能用业务服务通过 SDK 或 HTTP 接入。这个定位差异很重要因为它决定了你的接入成本。纯框架方案灵活但工作量大可运行底座上手快但需要接受它的约定。我的建议是如果你的团队 AI 工程经验不足优先选可运行底座先把业务跑起来等摸清了自己的真实需求再考虑深度定制如果团队本身就有很强的中间件能力那用框架自建也未尝不可但要预留至少两个人力专门维护这层。3. 核心技术点拆解Spring Cloud 生态如何承载 AI 能力层3.1 服务注册与发现AI 能力服务怎么被业务找到AI 能力层本身也是微服务所以服务注册发现这套东西直接复用就好。用 Nacos 或 Consul 做注册中心AI 能力服务启动时注册自己业务服务通过服务名调用。这里有个细节值得说AI 能力服务通常是长耗时调用一次 chat 请求可能几秒到几十秒这和传统微服务的毫秒级响应完全不同。这意味着健康检查的策略要调整。默认的心跳间隔和超时时间往往不适合长耗时服务容易误判。我的做法是把 AI 能力服务的健康检查拆成两个端点一个轻量的/health/liveness只检查进程存活一个较重的/health/readiness检查模型连接是否正常。注册中心只依赖 livenessreadiness 交给网关做流量摘除判断。这样即使模型临时不可用服务也不会被注册中心踢掉导致雪崩。3.2 配置中心Prompt 和模型参数为什么必须外置这是 AI 应用底座和传统微服务最大的差异点之一。传统微服务的配置主要是数据库连接、超时时间这类改一次很久不动AI 应用的配置里Prompt 模板、模型温度、Top-P、最大 Token 数这些参数是高频变化的。把这些配置放在 Nacos 配置中心里配合RefreshScope实现热更新能让运营同学改完 Prompt 后秒级生效不用重启服务。我实测下来这个能力对迭代速度的提升是数量级的——以前改个 Prompt 要走发版流程现在改完点保存就行。但要注意一个坑配置热更新和会话状态的一致性。如果一次多轮对话进行到一半Prompt 模板被改了后续轮次用的是新模板可能导致上下文错乱。我的处理方式是给每个会话绑定一个 Prompt 版本号会话开始时锁定版本中途不切换新会话才用新版本。这个逻辑要写在底座里不能让业务方自己处理。3.3 网关与限流Sentinel 在 AI 场景下的特殊配置限流这块Spring Cloud Sentinel 是绕不开的组件。但 AI 场景的限流维度和传统接口不一样不能只按 QPS 限。我总结下来至少要三个维度限流维度说明典型配置QPS 限流控制请求频率单业务线 50 QPSToken 限流控制 Token 消耗速率单租户 10000 Token/分钟并发限流控制同时进行的请求数单模型 20 并发Token 限流是 AI 场景特有的因为一次请求消耗的资源差异极大——同样一次调用可能消耗 100 Token也可能消耗 10000 Token。只按 QPS 限流会出现“请求数没超但成本爆了”的情况。Sentinel 本身不直接支持 Token 维度需要自定义Slot或者在业务层做二次校验这块我在后面实操部分会详细讲。3.4 数据通信微服务之间传什么、怎么传AI 应用里服务间通信有个特殊点大对象传输。向量数据动辄几百上千维一次批量 embedding 可能返回几 MB 的数据。用默认的 JSON 序列化 HTTP 传输性能会很差。我的经验是分场景处理控制类请求比如查询配置、提交任务走标准 REST数据类请求比如批量向量写入、大文档解析结果回传走 gRPC 或者消息队列异步处理。特别是向量写入强烈建议异步化——业务服务把待向量化的文本丢进消息队列AI 能力服务消费后写入向量库这样业务服务不用等用户体验也好。4. 实操落地从零搭一个最小可用的 AI 应用底座4.1 环境准备与 JDK 21 的取舍先说 JDK 版本。JDK 21 是 LTS 版本最大的亮点是虚拟线程Virtual Threads这对 AI 应用底座来说简直是量身定做。为什么因为 AI 调用是典型的 IO 密集型场景——大部分时间在等模型返回线程都在阻塞。传统线程池模式下为了支撑高并发你得开几百上千个平台线程内存开销大上下文切换也贵。虚拟线程让每个请求用一个虚拟线程阻塞时自动让出载体线程同样的硬件能支撑的并发数提升一个数量级。我实测过一个对比同样的模型调用代理服务JDK 17 线程池200 线程和 JDK 21 虚拟线程在 500 并发下的表现后者吞吐量高约 40%P99 延迟低约 30%。所以如果条件允许AI 应用底座直接上 JDK 21收益很直接。但要注意兼容性Spring Boot 3.2 才正式支持虚拟线程Spring Cloud 2023.x 才对齐。如果你的依赖里有老版本的库可能不兼容。我的建议是先在非核心服务上试点跑稳了再全量切。# application.yml 开启虚拟线程 spring: threads: virtual: enabled: true4.2 服务拆分AI 能力层应该拆成几个服务这是很多人纠结的问题。拆太细运维成本高拆太粗又失去了微服务的意义。我推荐的最小拆分方案是三个服务ai-gateway统一入口负责鉴权、限流、路由、日志ai-core核心能力服务负责模型调用、Prompt 渲染、会话管理ai-admin管理后台负责配置管理、配额管理、监控看板向量检索如果量大可以单独拆一个ai-vector服务如果量小先放在 ai-core 里等压力上来了再拆。这个“先合后拆”的策略比一开始就拆五个服务要务实得多我见过太多团队一开始拆太细结果光服务间调用链路就够喝一壶。4.3 核心配置Sentinel 数据源接 Redis 集群限流规则如果只存在内存里多实例部署时每个实例各限各的总量就失控了。所以 Sentinel 的规则数据源必须外置接 Redis 集群是常见做法。配置大概长这样spring: cloud: sentinel: datasource: flow: redis: host: redis-cluster.example.com port: 6379 rule-type: flow degrade: redis: host: redis-cluster.example.com port: 6379 rule-type: degrade这里有个坑Redis 集群模式下 Sentinel 数据源对 pipeline 的支持有限如果规则很多拉取规则可能变慢。我的做法是把规则按应用分组每个应用只拉自己相关的规则减少单次拉取量。另外规则变更后要主动推送不能只靠定时拉取否则限流规则生效有延迟。4.4 模型调用的重试与降级策略模型调用失败是常态不是异常。网络抖动、模型服务过载、Token 超限都会导致失败。底座必须内置重试和降级业务方不该关心这些。我的策略是三级处理同模型重试网络类错误重试 2 次间隔 200ms 指数退避同供应商换实例如果配置了多个实例换一个实例重试跨供应商降级主模型不可用时降级到备用模型比如从大模型降级到小模型降级要谨慎因为不同模型的输出格式可能不同。我的做法是在底座里做输出归一化把不同模型的返回统一成标准结构业务方拿到的永远是一致的格式。这样降级对业务方透明。// 简化的降级逻辑示意 public ChatResponse chat(ChatRequest request) { try { return primaryModel.chat(request); } catch (ModelUnavailableException e) { log.warn(主模型不可用降级到备用模型, e); return fallbackModel.chat(request); } }4.5 会话状态管理别把上下文塞进数据库多轮对话的上下文管理是个容易踩坑的地方。我见过有团队把每轮对话都写进 MySQL结果对话一长查询慢得离谱。正确的做法是热数据放 Redis冷数据异步落库。具体来说会话的最近 N 轮上下文放 Redis设置合理的过期时间比如 30 分钟无活动过期超过 N 轮的历史异步写入对象存储或宽表用于后续分析。Redis 里存的时候要注意序列化方式用 JSON 还是二进制取决于你的上下文大小。如果上下文里包含向量建议用二进制序列化体积能小一半以上。5. 常见问题与排查技巧实录5.1 模型调用超时但日志里看不到任何错误这是最让人抓狂的问题之一。现象是业务方报超时但底座日志干干净净。排查下来通常是这几个原因连接池耗尽HTTP 客户端连接池太小请求排队等待还没发出去就超时了。检查连接池配置AI 场景下maxConnections建议设大一些。DNS 解析慢如果模型地址是域名DNS 解析可能成为瓶颈。可以配置本地 DNS 缓存或者直接用 IP。虚拟线程 同步锁用了虚拟线程但代码里有synchronized块会导致载体线程被 pin 住性能反而下降。JDK 21 里要尽量用ReentrantLock替代synchronized。5.2 Token 计量不准账单对不上Token 计量不准通常有两个来源一是流式响应的 Token 统计很多模型在流式模式下不返回准确的 Token 数需要自己估算二是重试导致的重复计量一次请求重试了三次如果每次都计量就会多算。我的处理方式是流式响应按字符数估算 Token中文约 1.5 字符/Token英文约 4 字符/Token并在响应结束后用模型返回的准确值校正重试只在最终成功的那次计量中间失败的不计。这个逻辑要写在底座里统一处理不能让每个业务方自己算。5.3 常见问题速查表问题现象可能原因排查方向请求超时无日志连接池耗尽/DNS 慢查连接池指标、DNS 解析耗时Token 账单偏高重试重复计量/流式估算偏差查重试次数、对比估算与准确值限流不生效规则未推送/Redis 连接异常查 Sentinel 规则拉取日志会话上下文错乱Prompt 版本不一致/并发写查会话版本号、加分布式锁降级后格式错乱未做输出归一化检查归一化逻辑覆盖度5.4 几个我踩过的坑第一个坑是配置中心的命名空间隔离。开发、测试、生产的配置如果放在同一个命名空间很容易误改。一定要按环境隔离命名空间并且生产环境的配置修改要加审批。第二个坑是向量库的维度一致性。换 embedding 模型时如果新旧模型维度不同向量库里的数据就废了。我的做法是向量库按模型版本分 collection切换模型时新建 collection旧数据异步重建避免直接覆盖。第三个坑是日志脱敏。AI 应用的日志里很容易包含用户输入的敏感信息如果直接打日志合规上过不去。底座要内置脱敏规则对手机号、身份证号这类模式自动打码。6. 关于“要不要自建底座”的一些个人判断聊了这么多技术细节最后说点务实的。不是所有团队都需要自建 AI 应用底座。我的判断标准是如果你的 AI 应用只有一两个调用量不大业务方也不多那直接调 API 加一层薄封装就够了没必要上完整的底座。但如果你满足下面任意一条就该认真考虑底座了有三个以上业务线要用 AI 能力月 Token 消耗超过一定量级成本需要精细管控有合规审计要求需要完整的调用记录需要在多个模型之间灵活切换自建还是选现成的取决于团队基因。有中间件团队的自建可控性高没有的选 QuickBlue 这类可运行底座把精力放在业务上更划算。我个人的体会是底座这东西的价值不在于技术多先进而在于它把那些“每个 AI 应用都会遇到但每个团队都重复踩一遍”的坑提前填好了。省下来的时间才是真正能投入到业务创新的时间。后续如果要做扩展我建议优先在可观测性上投入——把模型调用的延迟、成功率、Token 消耗、成本这些指标做成看板让每一次调用都可追溯、可分析。AI 应用的优化很大程度上就是基于这些数据做出来的。