1. 从一次技术选型聊起为什么“AI 应用底座”突然成了刚需去年下半年我参与了一个中型企业的内部平台改造项目。项目背景很典型公司内部已经有三四个业务系统每个系统都在尝试接入大模型能力有的做智能客服有的做文档摘要有的做知识库问答。结果半年下来技术栈五花八门Python 脚本满天飞模型调用密钥散落在各个项目里运维同事每次排查问题都要先问一圈“这个服务是谁写的、部署在哪”。这个场景我相信很多同行都不陌生——AI 能力确实好用但一旦从“demo”走向“生产”工程化的问题就会集中爆发。QuickBlue 就是在这个背景下进入我视野的。简单说它是一个面向企业的AI 应用底座基于JDK 21和Spring Cloud微服务体系构建目标是把 AI 应用的通用能力——模型接入、会话管理、知识库、权限、监控、网关——沉淀成一套可复用的基础平台。你可以把它理解成“AI 应用的操作系统层”上层业务只管写自己的业务逻辑底层的模型调度、流量治理、服务注册、配置管理这些脏活累活全部由底座兜住。这篇文章适合谁看如果你是企业的技术负责人正在纠结“AI 项目怎么从散兵游勇变成正规军”如果你是后端工程师想了解一套 AI 底座到底该怎么搭、微服务在这类场景里怎么落地或者你只是听说过 QuickBlue 这个名字想知道它和普通的 Spring Cloud 项目有什么区别——那这篇内容应该能给你一些实在的参考。我会尽量把“为什么这么设计”讲透而不是只罗列功能清单。2. QuickBlue 到底是什么拆开“AI 应用底座”这个概念2.1 底座不是框架是“能力集合 约束规范”很多人第一次听到“AI 应用底座”会误以为它是一个开发框架类似 Spring Boot 那种“引入依赖就能跑”的东西。实际上底座的定位更重它既提供能力也制定规范。QuickBlue 做的事情可以拆成三层来看。最底层是基础设施层负责服务注册发现、配置中心、网关路由、链路追踪。这一层用的是 Spring Cloud 生态里比较成熟的组件组合但因为 Spring Cloud Alibaba 部分组件已经停止更新维护QuickBlue 在选型上做了取舍尽量用社区活跃、长期可维护的方案避免踩到“用着用着没人管了”的坑。中间层是AI 能力层这是底座区别于普通微服务框架的核心。它把大模型调用抽象成统一接口不管你后面接的是哪家模型服务上层业务代码都不用改。同时它还管会话上下文、提示词模板、向量检索、知识库索引这些 AI 应用特有的东西。最上层是应用支撑层包括统一认证、租户隔离、配额限流、审计日志。这一层解决的是“多个 AI 应用如何共存于一个平台”的问题。没有这层每个业务团队各搞一套登录、各搞一套计费平台方根本管不过来。提示底座的价值不在于“功能多”而在于“边界清晰”。哪些事底座做、哪些事业务做必须在项目初期就定死否则底座会越做越臃肿最后变成一个谁都不敢动的巨石应用。2.2 和普通 Spring Cloud 项目的本质区别我见过不少团队把“用了 Spring Cloud”等同于“有了微服务底座”这其实是两码事。普通 Spring Cloud 项目解决的是“服务怎么拆、怎么调”的问题而 QuickBlue 这类 AI 应用底座额外要解决三个问题。第一是模型调用的不确定性。传统接口的响应时间基本可控但大模型调用可能 2 秒返回也可能 30 秒超时还可能因为限流直接失败。底座必须内置重试、降级、熔断策略并且这些策略要能按模型、按租户动态调整。第二是上下文的状态管理。AI 应用天然是有状态的——多轮对话要记住历史知识库问答要带上检索结果。在微服务架构里状态放哪、怎么共享、怎么清理都是需要底座统一规范的。第三是成本可见性。模型调用是按 token 计费的如果平台方不知道每个业务、每个用户花了多少钱月底账单出来就是一笔糊涂账。底座需要在网关层就把 token 消耗统计做掉而不是等业务方自己上报。2.3 JDK 21 在这里不是噱头QuickBlue 选择 JDK 21 作为基础运行时这个决定我觉得挺务实。JDK 21 是 LTS 版本虚拟线程Virtual Threads已经正式转正。AI 应用的一个典型特征是高并发、长等待——大量请求卡在等模型返回上。用传统线程模型每个请求占一个平台线程几千并发就能把线程池打满。虚拟线程在这种 IO 密集型场景下优势明显同样的硬件能扛住更高的并发量。另外 JDK 21 的模式匹配、记录类Record这些特性在写 DTO 和配置类的时候确实能少写不少样板代码。当然升级 JDK 版本本身有成本如果团队还在 JDK 8 或 11 上迁移前要做好依赖兼容性排查尤其是那些用了反射和字节码增强的老库。3. 核心架构拆解微服务在 AI 底座里怎么落地3.1 服务拆分按“能力域”而不是“技术层”微服务拆分最容易犯的错误是按技术分层拆——controller 一个服务、service 一个服务、dao 一个服务。这种拆法在 AI 底座场景下是灾难因为一次对话请求可能要横跨好几个服务网络开销直接吃掉性能。QuickBlue 的拆分思路是按能力域来。我梳理了一下它主要的核心服务服务名称职责拆分理由网关服务统一入口、鉴权、限流、token 统计所有流量必经独立部署便于横向扩展模型路由服务模型选择、参数适配、重试降级模型接入变化频繁独立迭代不影响其他服务会话服务多轮对话上下文存储与检索有状态服务需要独立的存储和扩缩容策略知识库服务文档解析、向量化、检索计算密集资源需求与其他服务差异大用户与租户服务认证、授权、配额管理数据敏感安全边界独立审计与监控服务日志、指标、告警写多读少独立存储避免影响主链路这个拆法的好处是每个服务的资源画像清晰。知识库服务吃 CPU 和内存可以单独部署到高配节点网关服务吃网络 IO可以多实例负载均衡。如果全揉在一起扩缩容就是一笔糊涂账。3.2 服务间通信同步还是异步得看场景微服务架构图里那些箭头画起来好看但真到落地通信方式选错会让系统稳定性大打折扣。QuickBlue 在这块的处理我觉得比较克制。同步调用主要用在强依赖路径上比如网关到模型路由、模型路由到具体模型适配器。这些环节必须拿到结果才能继续用 OpenFeign 或 RestClient 直接调配合超时和熔断。异步消息用在非关键路径上比如审计日志写入、token 消耗统计、知识库索引更新。这些操作不影响用户拿到回答走消息队列削峰填谷避免因为统计服务抖动拖垮主链路。注意异步化不是银弹。我见过团队把模型调用也做成异步结果用户等半天拿不到结果体验极差。判断标准很简单——用户是否在等这个结果。等就同步不等才异步。3.3 配置管理别把配置散落在各个服务里AI 应用有个特点配置变化特别频繁。模型版本要换、提示词要调、限流阈值要改如果每个服务各自维护配置文件改一次要发一次版运维会疯掉。QuickBlue 用统一的配置中心管理这些动态配置服务启动时拉取运行时监听变更。这里有个实操细节配置中心里的敏感信息比如模型服务的访问凭证必须加密存储不能明文放。我见过有团队图省事直接写明文结果配置仓库权限没管好凭证泄露被人刷了一堆调用量。配置的粒度也要设计好。全局配置比如默认超时时间放公共命名空间服务级配置放各自命名空间租户级配置再单独一层。层级太多会增加理解成本太少又不够灵活三层基本够用。4. 实操落地从零搭一个最小可用的 AI 底座4.1 环境准备与依赖选型假设你现在要基于 QuickBlue 的思路搭一套最小可用底座我建议从这几个基础组件开始。JDK 21 装好Maven 或 Gradle 选一个顺手的。Spring Cloud 版本要和 Spring Boot 版本对齐这个在官方文档里有对应关系表别自己瞎配版本不匹配的报错能让你查一整天。服务注册发现我推荐用 Nacos它同时能做配置中心一套组件解决两个问题运维成本低。网关用 Spring Cloud Gateway响应式模型在高并发下表现比传统的 Zuul 好很多。熔断限流用 Sentinel规则可以动态推送到客户端不用重启服务。数据库方面业务数据用 MySQL会话上下文和向量数据分开存。会话上下文如果并发高可以考虑 Redis向量检索用专门的向量数据库别硬塞进关系型数据库性能差距不是一点半点。# 以 Nacos 配置为例服务注册的最小配置 spring: application: name: quickblue-model-router cloud: nacos: discovery: server-addr: ${NACOS_ADDR:127.0.0.1:8848} namespace: ${NACOS_NAMESPACE:public} config: server-addr: ${NACOS_ADDR:127.0.0.1:8848} file-extension: yaml这段配置里namespace用来做环境隔离开发、测试、生产各用一个命名空间避免测试环境的服务注册到生产里。这个坑我踩过测试服务把生产流量分走了一部分排查了半天才发现是命名空间没隔离。4.2 模型路由服务的核心实现模型路由是底座里最值得花心思的部分。它的核心职责是接收上层请求根据策略选择模型适配参数调用处理异常返回结果。策略选择可以很简单也可以很复杂。最简单的就是按模型名称直接路由。复杂一点的要考虑租户优先级、模型健康度、成本预算、响应时间。我建议初期别做太复杂先把“能调通、能降级、能统计”这三件事做好。// 模型路由的简化示意重点看降级逻辑 public class ModelRouter { private final ListModelProvider providers; private final CircuitBreaker circuitBreaker; public ModelResponse route(ModelRequest request) { // 按优先级排序优先选健康且成本低的 ListModelProvider candidates providers.stream() .filter(p - p.supports(request.getModelType())) .filter(p - circuitBreaker.isAvailable(p.getName())) .sorted(Comparator.comparing(ModelProvider::getPriority)) .toList(); for (ModelProvider provider : candidates) { try { return provider.invoke(request); } catch (Exception e) { // 记录失败继续尝试下一个 circuitBreaker.recordFailure(provider.getName()); log.warn(模型 {} 调用失败尝试降级, provider.getName(), e); } } throw new NoAvailableModelException(所有模型均不可用); } }这段代码的关键在于降级链。当主模型不可用时自动切到备用模型而不是直接给用户报错。备用模型可以是同厂商的不同版本也可以是不同厂商的同类模型。降级策略要可配置因为不同业务对降级的容忍度不一样——智能客服可以降级到小模型但合同审核这种场景可能宁可报错也不能用低质量模型。4.3 会话上下文的管理细节多轮对话的上下文管理说起来简单做起来全是细节。首先是存储结构我建议按租户ID 会话ID做分片键这样同一会话的数据落在同一个分片上读取快。其次是过期策略会话不能无限期保留既占存储又涉及隐私一般设 24 到 72 小时比较合理。上下文长度也要控制。模型有 token 上限历史对话不能无限往里塞。常见的做法是滑动窗口加摘要保留最近 N 轮完整对话更早的内容用模型生成摘要。这个摘要生成本身也要消耗 token所以要权衡——摘要频率太高浪费钱太低又丢信息。实操心得会话上下文里千万别存敏感信息原文。用户可能在里面输入身份证号、手机号这些要么脱敏后再存要么干脆不存。合规这事出事之前都觉得是小题大做出事之后才知道代价。4.4 网关层的限流与 token 统计网关是所有流量的入口限流和统计放这里最合适。限流维度至少要有三个按租户、按接口、按用户。租户级限流防止某个客户把平台打满接口级限流保护后端服务用户级限流防止单账号异常刷量。Sentinel 的规则配置可以持久化到 Nacos这样重启不丢规则。规则变更通过 Nacos 推送到网关实例秒级生效。这里有个细节限流阈值别设太死要留缓冲。我见过把阈值设成和容量一模一样的结果正常流量波动就触发限流用户投诉不断。token 统计要在请求和响应两个方向都做。请求方向统计输入 token响应方向统计输出 token加起来才是这次调用的总消耗。统计结果异步写到消息队列由专门的统计服务聚合。别在网关里直接写数据库网关的性能很宝贵不能被统计拖慢。5. 踩坑记录那些文档里不会写的问题5.1 服务拆分过细导致的“分布式单体”刚接触微服务的人容易上头恨不得每个功能都拆一个服务。我早期参与的一个项目拆了二十多个服务结果一次业务请求要跨十几个服务链路追踪图长得像蜘蛛网。更麻烦的是任何一个小服务出问题整个链路就断了。这种架构表面上是微服务实际上是“分布式单体”——部署单元多了但耦合度一点没降。QuickBlue 的拆分粒度我觉得比较合理核心服务控制在十个以内。判断拆分是否过细有个简单标准如果两个服务之间几乎每次调用都是一起出现而且数据强一致那它们可能就不该拆开。微服务的收益来自独立部署和独立扩展如果这两个收益不明显拆开就是纯增加复杂度。5.2 Spring Cloud Alibaba 停更带来的选型焦虑Spring Cloud Alibaba 部分组件停更这件事确实让不少团队紧张。我的建议是分情况处理如果现有系统跑得稳不用急着换但要做好技术债记录规划迁移路径如果是新项目选型时优先考虑社区活跃度Nacos、Sentinel 这些核心组件目前还在维护可以继续用但要有备选方案。迁移最怕的是“边跑边换轮子”。我见过团队在业务迭代最忙的时候搞组件替换结果新老组件行为不一致线上出了一堆诡异问题。正确做法是先在非核心业务上试点跑稳了再逐步推广。技术选型这事稳比新重要。5.3 模型调用的超时设置是个技术活超时设太短模型还没返回就断了用户看到报错设太长请求堆积线程池打满整个服务雪崩。我的经验是分模型设置小模型比如摘要、分类设 10 到 15 秒大模型比如长文生成设 60 到 120 秒。同时要配合熔断连续超时达到阈值就暂时摘掉这个模型过一段时间再试探性恢复。还有一个容易忽略的点连接超时和读取超时要分开设。连接超时通常很短几秒就够读取超时才是等模型返回的时间。很多人只设一个总超时结果连接阶段就把时间耗光了。5.4 常见问题速查表现象可能原因排查方向解决思路服务注册不上网络不通或命名空间错误检查 Nacos 地址和命名空间配置确认网络策略核对命名空间配置不生效配置未发布或监听未生效查看配置中心发布状态和客户端日志手动刷新或重启服务验证模型调用频繁超时模型服务限流或网络抖动查看模型服务监控和网络延迟增加重试、切换备用模型会话上下文丢失Redis 过期或分片键设计问题检查过期时间和分片配置调整过期策略核对分片键token 统计不准异步写入丢失或重复消费检查消息队列消费位点和幂等增加幂等校验核对消费日志网关限流误伤阈值设置过低或规则冲突查看限流规则和实际 QPS调整阈值梳理规则优先级这张表里的每一条基本都是我在实际项目里真实遇到过的。尤其是“配置不生效”和“限流误伤”出现频率最高排查起来也最耗时间。建议在平台建设初期就把配置变更审计和限流规则可视化做进去后面能省很多事。6. 这套底座适合什么样的团队不是所有团队都需要一上来就搞 AI 应用底座。如果你只有一个 AI 应用用户量也不大直接写个 Spring Boot 单体应用把模型调用封装成一个 Service 类完全够用。过早引入微服务和底座只会增加开发和运维负担。但如果出现下面这些信号就该考虑底座了多个业务团队都在接模型重复造轮子模型调用成本开始失控没人说得清钱花在哪运维排查问题要跨好几个系统效率极低安全合规要求提高需要统一的鉴权和审计。这些信号出现两个以上底座的投入产出比就划算了。QuickBlue 这套思路的价值不在于它用了多新的技术而在于它把 AI 应用工程化过程中那些“迟早要面对”的问题提前用一套结构化的方案兜住了。JDK 21 和 Spring Cloud 是手段微服务拆分是手段真正的核心是把不确定性关进笼子里——模型会变、流量会变、需求会变但底座的边界和规范不变上层业务才能安心迭代。我在实际搭建过程中最大的体会是底座这东西前期设计多花一周后期能省一个月。尤其是服务边界和配置规范一旦定下来就别轻易改改一次全平台都要跟着动。宁可初期保守一点留好扩展点也别为了“看起来先进”而过度设计。