1. 从一次技术选型争论说起为什么“AI 应用底座”突然成了刚需前阵子跟几个做企业级系统的老朋友吃饭席间聊到一个很有意思的现象。两年前大家讨论的还是“要不要上微服务”“Spring Cloud 和 Dubbo 怎么选”现在话题直接跳到了“我们那套 AI 能力怎么沉淀成公司级资产”。有个做供应链 SaaS 的架构师说得很直白他们公司去年一口气接了四个 AI 项目——智能客服、合同审查、库存预测、单据 OCR每个项目组各自拉了一套 Python 服务、各自封装模型调用、各自管理密钥和限流结果半年下来运维那边快疯了光模型版本就有十几个在跑谁也说不清哪个接口对应哪个模型。这就是“AI 应用底座”要解决的核心问题。QuickBlue 这个项目从名字和关键词来看定位就是给企业提供一层统一的 AI 应用基础设施——它不是一个具体的 AI 应用而是让所有 AI 应用都能跑在上面的那层“地基”。你可以把它理解成以前每个业务系统都要自己接数据库、自己写鉴权、自己搞配置中心后来有了 Spring Cloud 这套微服务底座大家统一在这上面开发现在 AI 应用也到了这个阶段需要一层专门为 AI 场景设计的底座。关键词里出现的微服务、JDK 21、Spring Cloud基本勾勒出了 QuickBlue 的技术底色——它是用现代 Java 技术栈构建的、面向 AI 应用场景的微服务基础设施。而热搜词里那一串“微服务架构图”“微服务拆分”“spring cloud alibaba 停更了”“若依 spring cloud”则暴露了大家真正的焦虑微服务这套东西大家已经用了好几年但怎么把它和 AI 应用结合起来怎么在 Alibaba 组件维护节奏变化的背景下选型怎么把 AI 能力做成可复用、可治理、可观测的服务这些才是真问题。这篇文章我打算把 QuickBlue 这类“AI 应用底座”拆开讲透。不是念产品文档而是从一线架构和落地角度说清楚它到底是什么、为什么企业需要它、它内部大概怎么组织、用起来要注意什么。如果你正在负责公司 AI 能力的平台化建设或者你是个后端工程师想搞清楚 AI 时代微服务该怎么演进这篇应该能给你一些能直接参考的东西。2. QuickBlue 到底是不是又一个“套壳平台”2.1 先厘清概念底座和应用的区别很多人第一次听到“AI 应用底座”会本能地警惕——是不是又搞个门户把几个模型 API 包一层就叫平台了这个怀疑很合理市面上确实有不少这样的东西。但要判断 QuickBlue 这类项目的价值得先分清两个层次。AI 应用是面向最终用户的比如一个智能问答机器人、一个文档摘要工具、一个代码补全插件。AI 应用底座是面向开发者和运维的它不直接产生业务价值但它决定了你开发第十个 AI 应用时成本是第一个的十分之一还是三倍。底座的本质是把重复的、跨应用的能力抽出来做成公共服务让上层应用只关注自己的业务逻辑。打个比方开餐厅每家店都要有厨房、水电、排烟、收银。如果每开一家店都从头搞一遍成本极高。美食城做的就是底座——统一提供水电、排烟、公共收银你租个档口专心做菜就行。QuickBlue 在 AI 领域扮演的就是美食城角色它提供的是模型接入、提示词管理、向量检索、调用配额、审计日志这些“公共设施”。2.2 从关键词反推 QuickBlue 的能力边界结合关键词和热搜词我推断 QuickBlue 的能力边界大致覆盖这么几块能力域具体内容对应热搜词线索服务治理服务注册发现、配置中心、熔断限流微服务架构、spring cloud sentinelAI 能力接入多模型统一接入、路由、降级AI 应用底座数据层向量库、缓存集群、关系库redis 集群、datasource运行时现代 JDK 特性、虚拟线程JDK 21开发框架微服务开发脚手架若依 spring cloud、微服务拆分这里有个关键点值得展开JDK 21 出现在关键词里不是偶然。JDK 21 是 LTS 版本最大的亮点是虚拟线程正式转正。AI 应用有个典型特征——大量时间花在等待上等模型返回、等向量检索、等外部 API。传统平台线程模型下一个请求占一个线程高并发时线程池瞬间打满CPU 却在空转。虚拟线程让“一个请求一个线程”的写法重新变得可行吞吐量能上去代码还不用改成响应式那种反人类风格。QuickBlue 选 JDK 21 作为基线说明它是奔着高并发 AI 调用场景去的这个选型我认为是对的。2.3 它和“若依 spring cloud”这类脚手架的关系热搜里“若依 spring cloud”“若依微服务plus”出现频率很高说明很多团队在找现成的微服务脚手架。这里要区分清楚若依这类项目是通用业务脚手架帮你快速搭起用户管理、权限、菜单这些后台功能QuickBlue 是AI 场景底座重点在 AI 能力的接入和治理。两者不是替代关系理论上你可以用若依做业务后台用 QuickBlue 做 AI 能力层中间通过服务调用打通。但我不建议无脑叠加。如果你的团队规模不大硬把两套东西拼一起配置复杂度会指数上升。更务实的做法是先想清楚你到底需要底座解决什么问题是模型接入混乱还是调用没有配额控制还是缺少统一审计。只解决真问题别为了“架构完整”而堆组件。3. 企业为什么非要在 AI 项目上做“底座”这件事3.1 没有底座时AI 项目会烂成什么样我见过太多没有底座的 AI 项目现场总结下来有四个典型病症而且几乎每个团队都会中招。第一是密钥和模型配置散落各处。每个项目组在自己的配置文件里写模型地址、API Key、超时时间。某天模型供应商换了域名或者密钥要轮换你得挨个找、挨个改、挨个发版。更可怕的是密钥进了 Git 仓库安全审计直接亮红灯。第二是调用没有统一配额和限流。市场部搞了个活动某个 AI 接口被刷爆把整个模型配额吃光导致客服系统也跟着挂。因为大家共用同一个上游账号却没有统一的流量管控。第三是效果无法横向对比。客服组说 A 模型好合同组说 B 模型准但没人能拿出统一口径的数据。因为没有统一的调用日志和评测机制选型全靠拍脑袋。第四是重复造轮子。向量检索、提示词模板、结果缓存每个组都写一遍代码质量参差不齐出了问题各修各的。3.2 底座带来的三个可量化收益把上面这些病症反过来看就是底座的价值。我尽量说得具体点方便你拿去跟老板汇报。成本收益统一接入后模型调用可以按业务线做配额闲时配额可以调剂给忙时。实测中通过统一缓存和请求合并重复问题的模型调用量能降 30% 到 50%。这不是理论值是很多团队做语义缓存后的真实数据。效率收益新 AI 应用接入底座通常一两天就能跑通因为鉴权、日志、限流、模型调用都是现成的。没有底座时光是把这些基础设施搭起来就得一两周。风险收益统一审计日志意味着每次 AI 调用都可追溯——谁调的、调了什么模型、输入输出是什么、耗时多少。这在合规要求越来越严的今天价值不用我多说。3.3 什么阶段的企业最该上底座不是所有团队都需要底座。我的判断标准很简单如果你公司只有一个AI 应用别搞底座直接写怎么快怎么来。如果有两到三个AI 应用且分属不同团队可以开始考虑轻量底座重点是统一模型接入和日志。如果有三个以上AI 应用或者 AI 能力要作为公司级资产对外输出那底座就是必需品QuickBlue 这类项目值得认真评估。提示底座建设最大的坑是“过度设计”。我见过团队在只有一个 AI 应用时就上了完整的服务网格、多级缓存、灰度发布结果维护成本比业务代码还高。底座要跟着应用数量走别一步到位。4. QuickBlue 的技术骨架微服务怎么和 AI 场景咬合4.1 服务拆分AI 底座该切成几块微服务拆分是个老话题但 AI 场景有它的特殊性。热搜里“微服务拆分”“微服务架构图”热度高说明大家都在纠结怎么切。我结合 QuickBlue 的定位给一个我认为合理的拆分思路。AI 应用底座的拆分原则和普通业务系统不太一样。普通业务按领域切订单、库存、用户AI 底座更适合按能力类型切因为不同能力的技术栈和伸缩特性差异很大。一个典型的拆分方案是这样的网关层统一入口负责鉴权、路由、限流。AI 请求往往体量大长文本、图片网关要特别注意请求体大小限制和超时配置。模型接入服务封装各家模型的调用差异对外暴露统一接口。这是底座的核心也是最容易变成瓶颈的地方。提示词管理服务管理提示词模板、版本、变量。别小看这个提示词是 AI 应用的“业务逻辑”必须版本化。向量检索服务封装向量库操作提供语义检索能力。配额与计费服务按租户、按应用统计调用量做配额控制。审计日志服务异步记录所有调用供追溯和分析。这里我要强调一个反直觉的点模型接入服务不要拆得太细。有些团队按模型供应商拆成 OpenAI 服务、Claude 服务、国产模型服务结果每接一个新模型就要加一个服务。更好的做法是一个模型接入服务内部用策略模式适配不同供应商对外统一。拆分的粒度应该按“变更频率”和“伸缩需求”来定而不是按供应商。4.2 JDK 21 虚拟线程在 AI 调用链里的实际收益前面提了 JDK 21这里展开说说为什么它对 AI 底座特别重要。AI 调用的特点是IO 密集且延迟高。一次模型调用动辄几百毫秒到几秒向量检索也要几十毫秒。传统平台线程模型下假设你有 200 个线程每个请求平均耗时 2 秒那理论吞吐就是 100 QPS再多请求就得排队。想提高吞吐只能加线程但线程多了上下文切换开销大内存也扛不住每个平台线程默认 1MB 栈。虚拟线程改变了这个等式。虚拟线程由 JVM 调度栈内存按需增长可以轻松创建几十万个。同样是 2 秒的模型调用用虚拟线程你可以让每个请求独占一个虚拟线程JVM 在等待 IO 时自动挂起它不占 OS 线程。实测中同样的硬件虚拟线程能把 IO 密集型服务的吞吐提升数倍。但这里有个坑必须提醒虚拟线程不是银弹遇到 synchronized 块会“钉住”载体线程。JDK 21 里这个问题已经大幅缓解但如果你用的第三方库内部大量用 synchronized虚拟线程的优势会打折。上生产前一定要做压测别只看 demo 数据。// 虚拟线程处理 AI 调用的典型写法 try (var executor Executors.newVirtualThreadPerTaskExecutor()) { ListFutureModelResponse futures requests.stream() .map(req - executor.submit(() - modelClient.call(req))) .toList(); // 收集结果 for (var future : futures) { results.add(future.get()); } }这段代码的意图很明确每个模型调用跑在独立虚拟线程里主线程等待汇总。写法跟传统线程池几乎一样但底层调度完全不同。这就是虚拟线程的价值——不改变编程模型只提升吞吐。4.3 Spring Cloud 组件选型Alibaba 停更背景下的取舍热搜里“spring cloud alibaba 停更了”是个敏感话题很多团队在担心。我的看法是别慌但要清醒。首先要澄清所谓“停更”更多是指某些组件的维护节奏放缓不是整个生态消失。Spring Cloud Alibaba 里的 Nacos、Sentinel 这些核心组件依然在广泛使用社区也还在运转。但作为架构决策者你确实需要评估长期维护风险。对于 QuickBlue 这类新项目我的选型建议是能力保守选择激进选择我的倾向注册配置NacosConsul / K8s Service已有 Nacos 经验就继续用熔断限流SentinelResilience4j新项目优先 Resilience4j网关Spring Cloud Gateway同上无争议服务调用OpenFeignSpring Interface Client看团队习惯Resilience4j 相比 Sentinel 更轻量和 Spring Boot 集成更自然不依赖控制台。Sentinel 的优势是规则动态推送和可视化做得好。如果你的团队没有强运维诉求Resilience4j 是更省心的选择。注意无论选哪个都要把熔断降级规则配置化、可动态调整。AI 模型服务不稳定是常态硬编码的超时和阈值迟早会坑你。5. 把 QuickBlue 跑起来从环境到第一个 AI 服务5.1 环境准备里最容易被忽略的三件事假设你要基于 QuickBlue 搭一套环境我按实际踩坑经验给你排一下优先级。很多人上来就 clone 代码、改配置、启动结果卡在一些莫名其妙的地方。第一件是 JDK 版本和启动参数。JDK 21 是硬要求但光装了还不够。虚拟线程相关的一些行为受启动参数影响建议加上--enable-preview如果你用了预览特性和合理的内存参数。AI 服务内存占用波动大堆内存别设太死留出余量。第二件是向量库和缓存的网络连通性。底座依赖 Redis 集群做缓存和配额计数依赖向量库做检索。这两个如果网络不通或者认证配置错服务启动时不一定报错但第一次调用就挂。建议在启动脚本里加健康检查把依赖连通性作为启动前置条件。第三件是模型密钥的管理方式。千万别把密钥写进配置文件提交到仓库。用环境变量或者配置中心加密存储。QuickBlue 这类底座通常支持密钥的动态刷新配好之后轮换密钥不用重启服务。5.2 一个最小可用的 AI 服务接入流程下面是我梳理的接入步骤你可以照着走一遍感受一下底座的价值。在底座注册应用拿到应用 ID 和访问凭证。这一步相当于给你的 AI 应用上户口。配置模型路由指定你的应用可以用哪些模型优先级如何超时多少。比如主用模型 A降级用模型 B。定义提示词模板把提示词从代码里抽出来放到提示词管理服务用变量占位。调用统一接口你的业务代码只调底座的统一接口不直接调模型供应商。配置配额和告警设置每日调用上限超过阈值告警。# 调用底座统一接口的示例curl curl -X POST https://quickblue-gateway/api/v1/ai/invoke \ -H Authorization: Bearer ${APP_TOKEN} \ -H Content-Type: application/json \ -d { appId: supply-chain-assistant, promptTemplate: contract-review-v2, variables: {contractText: ...}, modelPolicy: primary-with-fallback }注意modelPolicy这个字段它让业务方不用关心具体用哪个模型只声明策略底座负责路由和降级。这是底座最核心的价值之一——把模型选择从业务代码里解耦出去。5.3 跑通之后必须做的压测和观测配置Demo 跑通只是开始。上线前有两件事必须做。压测要模拟真实场景并发数、请求体大小、模型响应延迟都要贴近生产。重点观察虚拟线程在高并发下的表现以及模型接入服务会不会成为瓶颈。我建议至少压到预期峰值的 1.5 倍。观测要配齐三样指标、日志、链路追踪。指标关注 QPS、延迟分布、错误率、模型调用量日志要结构化方便检索链路追踪要能串起“网关到模型接入到向量检索”的完整路径。AI 调用链路长没有追踪出问题就是盲人摸象。6. 落地过程中那些文档不会告诉你的坑6.1 模型降级策略写错比不降级还糟降级逻辑看起来简单主模型挂了切备用。但实际落地时我见过太多翻车案例。有个团队配置了主备模型主模型超时 3 秒切备用。结果主模型只是偶尔慢大部分请求在 2.9 秒返回降级逻辑频繁触发备用模型被大量本不该来的请求打爆最后两个模型一起挂。问题出在降级阈值和超时设置没有联动而且没有做降级的“冷静期”。正确的做法是降级触发后给主模型一个恢复探测窗口别一有超时就永久切走。同时降级要有熔断器的半开状态让少量请求去试探主模型是否恢复。这些细节QuickBlue 这类底座如果做得好应该内置如果没内置你得自己补。6.2 向量检索的“召回率陷阱”做 RAG检索增强生成的团队几乎都会踩这个坑向量检索返回的 Top-K 结果看起来相关但模型生成时还是答非所问。原因往往不在模型而在检索。常见问题有三个一是分块策略不合理把一段完整语义切碎了检索出来的是碎片二是没有做混合检索纯向量检索对关键词匹配不敏感用户问“2024 年 Q3 财报”向量检索可能返回一堆泛泛的财务内容三是没有重排序Top-K 里混进了不相关的结果干扰了模型。我的经验是向量检索一定要配关键词检索做混合再用重排序模型精排。这套组合拳下来召回质量能上一个台阶。QuickBlue 如果提供向量检索服务最好把这套流程封装好别让每个业务方自己拼。6.3 配额统计的并发一致性配额控制听起来简单做起来容易出并发问题。多个实例同时扣减配额如果用的是“先查后扣”的写法高并发下必然超扣。正确做法是用 Redis 的原子操作比如INCR配合过期时间或者用 Lua 脚本保证“检查加扣减”的原子性。这里有个细节配额的时间窗口怎么算是按自然日还是滚动窗口自然日实现简单但会有“零点突刺”滚动窗口更平滑但实现复杂。我建议按业务特点选别盲目追求平滑。-- Redis Lua 脚本原子扣减配额 local key KEYS[1] local limit tonumber(ARGV[1]) local cost tonumber(ARGV[2]) local current tonumber(redis.call(GET, key) or 0) if current cost limit then return -1 -- 超配额 end redis.call(INCRBY, key, cost) redis.call(EXPIRE, key, 86400) return current cost这段脚本的意图是保证“检查加扣减”在 Redis 里原子执行避免并发超扣。注意过期时间设成一天对应自然日窗口。6.4 审计日志别写成性能瓶颈审计日志要求记录每次调用的输入输出但 AI 调用的输入输出可能很大长文本、图片 base64。如果同步写日志会拖慢主流程如果全量存存储成本爆炸。我的做法是异步写、分级存。日志通过消息队列异步落库不阻塞主流程。存储上完整输入输出存对象存储数据库只存元数据和摘要。敏感信息要做脱敏别把用户隐私原样记下来。这些策略最好在底座层面统一别让业务方各自发挥。7. 我对 AI 应用底座这件事的真实判断聊了这么多技术细节最后说点掏心窝的判断。AI 应用底座这个方向我认为是对的但它的形态还在快速演化。QuickBlue 这类项目现在做的事情很多在两年后可能会被更上层的框架或者云厂商的原生能力吸收掉。所以选型时别把底座当成不可替换的资产要保证业务代码和底座之间的耦合足够松。你的业务逻辑应该只依赖底座的抽象接口而不是具体实现。这样将来底座换了迁移成本才可控。另外底座的价值高度依赖“规模”。一个只有两个 AI 应用的团队上底座大概率是负收益。底座是为“多应用、多团队、多模型”场景准备的规模不到它就是负担。我见过太多团队被“平台化”这个词忽悠提前建了一堆用不上的基础设施。如果你现在正评估 QuickBlue 或者类似的底座方案我的建议是先做一个小范围试点挑一个真实的 AI 应用把它接到底座上跑一个月看运维成本、开发效率、调用治理这几个维度到底有没有改善。数据说话比任何架构评审都管用。底座这东西用对了是杠杆用错了是枷锁区别就在于你有没有想清楚自己到底要解决什么问题。
