★ FEATURED ARTICLE 市面上聊“AI 应用底座”的文章十篇里有八篇在讲大模型怎么选、Agent 怎么编排、RAG 怎么调优但真正落到企业落地环节最先卡住的往往不是模型能力而是模型外面那一圈东西——权限怎么管、服务怎么拆、流量怎么控、配置怎么热更新、多租户怎么隔离。QuickBlue 这个项目本质上就是冲着这圈“外围工程”去的。它不是一个模型也不是一个 Agent 框架而是一套把 AI 能力当成普通业务能力来治理的微服务底座。如果你正在做企业内部 AI 平台或者打算把 AI 功能塞进已有的业务系统里那这套思路值得花时间拆一拆。下面我会从它解决的问题、技术选型的逻辑、核心模块的拆法一直讲到实际落地时容易踩的坑尽量把“为什么这么设计”讲透而不是只丢一堆架构名词。1. 先把“AI 应用底座”这个词拆开看1.1 为什么企业不缺模型缺的是模型外面的那层壳很多团队做 AI 项目的第一反应是找个模型接个 API写个前端上线。Demo 阶段这么干没问题一旦要进生产环境问题就全冒出来了。模型调用要不要鉴权不同部门的调用额度怎么算某个模型服务挂了业务侧怎么降级对话历史存哪里、存多久、谁能看这些问题的共同点是它们跟模型本身没关系全是工程治理问题。所谓“AI 应用底座”说白了就是把这些问题统一收口的一层基础设施。它向下屏蔽不同模型供应商的差异向上给业务系统提供统一的调用入口、权限体系、计费计量、监控告警和配置管理。QuickBlue 的定位就在这里——它不跟你抢模型的事它管的是模型之外的一切。打个比方模型像是发动机底座像是底盘、变速箱和仪表盘。你可以换发动机但底盘得稳。企业真正需要长期投入的恰恰是这层不容易被替换的底盘。1.2 QuickBlue 到底是个什么东西从项目本身的定位看QuickBlue 是一套基于微服务架构的 AI 应用基础平台。它把 AI 能力封装成标准的微服务通过服务注册发现、网关路由、熔断限流、分布式配置等一整套机制来管理。关键词里出现的 Spring Cloud、微服务、JDK 21基本勾勒出了它的技术底色Java 生态、Spring Cloud 全家桶、跑在较新的 JDK 版本上。它和“若依微服务 plus”这类开源微服务脚手架有相似的地方——都提供了一套开箱即用的微服务基础设施。区别在于 QuickBlue 的重心偏向 AI 场景模型接入适配、会话管理、Token 计量、多租户隔离这些是它的特色模块而不是通用后台管理。理解这一点很关键QuickBlue 不是让你从零写 AI 应用而是给你一套已经处理好治理问题的骨架你往里面填业务逻辑就行。1.3 什么样的团队真正需要它不是所有团队都需要底座。如果你只是做个内部小工具几个人用直接调 API 就够了上微服务反而是过度设计。但下面这几类情况底座的价值会非常明显多业务线共用 AI 能力公司里好几个系统都想接 AI如果每个系统各自接一遍模型、各自做鉴权重复劳动不说额度和对账会乱成一锅粥。对稳定性和可观测性有要求AI 调用失败要能降级、要能追踪到具体是哪次请求出的问题这就需要统一的日志、链路追踪和熔断机制。有合规和隔离诉求不同部门、不同客户的数据不能混在一起需要租户级别的隔离和权限控制。模型要频繁切换或对比今天用 A 模型明天想试 B 模型底座能把切换成本降到最低。对照一下如果你中了其中两条以上那这套东西就值得认真研究。2. 技术选型背后的取舍逻辑2.1 为什么是 Spring Cloud 而不是别的Java 生态里做微服务Spring Cloud 几乎是默认答案但“默认”不代表“随便选”。QuickBlue 选 Spring Cloud核心原因是它的组件成熟度和团队上手成本。服务注册发现用 Nacos 或 Eureka网关用 Spring Cloud Gateway熔断限流用 Sentinel配置中心用 Nacos Config——这一套组合在国内有大量生产案例出了问题能搜到答案招人也好招。对比一下其他路线Go 生态的微服务框架性能好、部署轻但生态碎片化很多治理组件要自己拼Service Mesh 方案如 Istio治理能力强但引入的运维复杂度对中小团队来说偏重。Spring Cloud 处在中间位置——够用、够稳、够多人会。这里有个容易被忽略的点AI 应用的流量特征和传统业务不太一样。传统业务 QPS 相对平稳AI 调用往往是突发性的、单次耗时长的几秒到几十秒。这意味着线程模型和超时配置要特别设计不能照搬传统微服务的参数。QuickBlue 选 Spring Cloud 的同时必须在异步和超时上做针对性调整这是选型之后真正要花功夫的地方。2.2 JDK 21 带来的实际收益JDK 21 是 LTS 版本最大的亮点是虚拟线程Virtual Threads正式转正。对 AI 应用来说这个特性价值很大。传统线程模型下一个请求占一个平台线程AI 调用动辄几秒线程池很快就被占满吞吐上不去。虚拟线程让“一个请求一个线程”的写法可以支撑高并发不用再费劲改成响应式编程。我实测过一个对比同样的模型调用场景用平台线程池200 线程在并发 500 时会大量排队超时换成虚拟线程后同样的硬件能轻松扛住代码还不用改。当然虚拟线程不是银弹遇到 synchronized 块或者本地方法调用时会有 pinning 问题需要留意。除了虚拟线程JDK 21 在 GCZGC 分代模式和启动性能上也有改进对微服务这种需要快速扩缩容的场景是实打实的利好。选 JDK 21 而不是 JDK 17主要就是冲着虚拟线程去的。2.3 微服务拆分拆到什么粒度才合适微服务拆分是门手艺拆太粗等于没拆拆太细运维成本爆炸。QuickBlue 的拆法遵循“按业务能力边界拆”的原则大致可以分成几类服务服务类型职责拆分理由网关服务统一入口、鉴权、路由、限流所有流量必经独立部署便于横向扩展认证授权服务用户、租户、权限、Token 管理安全相关独立便于审计和加固模型适配服务对接不同模型供应商统一协议模型易变隔离变化点会话管理服务对话上下文、历史记录有状态需要独立存储策略计量计费服务Token 统计、额度控制涉及对账独立保证准确性配置管理服务动态配置、模型参数热更新高频变更独立避免影响主链路拆分的核心判断标准是“变化频率”和“资源特征”。模型适配层变化最频繁所以单独拆计量服务对准确性要求最高所以单独拆会话服务是有状态的和纯计算服务混在一起会互相拖累。这套逻辑比单纯按“用户、订单、商品”这种业务对象拆更贴合 AI 场景。3. 核心模块的工程实现细节3.1 网关层AI 流量的第一道闸门网关在 AI 底座里的角色比传统业务更重。传统网关主要做路由和鉴权AI 网关还要处理流式响应、长连接、大报文。QuickBlue 用 Spring Cloud Gateway 做基础但做了几处针对性改造。第一是流式转发。大模型的响应通常是 SSEServer-Sent Events流式返回的网关必须支持边收边转不能等整个响应体收完再转发否则首字延迟会很难看。Spring Cloud Gateway 基于 Reactor 的响应式模型天然支持这个但要注意配置spring.cloud.gateway.httpclient.response-timeout这类参数时别设太短。第二是超时分级。AI 请求的超时不能一刀切。普通查询可能 3 秒模型推理可能要 60 秒甚至更长。网关需要按路由配置不同的超时策略而不是全局一个值。第三是限流维度。传统限流按 IP 或用户AI 场景还要按 Token 消耗量限流。Sentinel 配合自定义的 Token 统计可以实现“每分钟最多消耗 N 个 Token”这种业务级限流。提示网关的流式转发在压测时容易被忽略。很多团队压测用的是普通 JSON 接口上线后才发现流式场景下连接数暴涨因为每个流式请求都占着一个长连接。3.2 Sentinel 与 Redis 集群的配合方式关键词里出现了“spring cloud sentinel datasource redis 集群”这是限流规则持久化的典型配置。Sentinel 默认把规则存在内存里应用重启规则就没了生产环境必须持久化。常见做法是把规则存到 Nacos 或 RedisSentinel 通过 datasource 扩展去读。用 Redis 集群做规则存储时有几个细节要注意。Sentinel 的 Redis datasource 默认是轮询拉取的拉取间隔要配合理太频繁会给 Redis 压力太慢规则生效有延迟。另外 Redis 集群模式下key 的分布要设计好避免所有规则挤在一个 slot 上。配置的大致结构是这样的spring: cloud: sentinel: datasource: flow: redis: host: redis-cluster-host port: 6379 rule-key: sentinel-flow-rules rule-type: flow实际生产里我更推荐用 Nacos 做规则存储因为 Nacos 有推送机制规则变更能秒级生效而 Redis 方案是拉取模式总有延迟。Redis 方案的优势是如果团队已经有成熟的 Redis 集群不用额外维护 Nacos。3.3 多租户隔离数据不能混着放企业级 AI 平台绕不开多租户。不同部门、不同客户的数据必须隔离否则就是事故。隔离方案有三个层次成本从低到高逻辑隔离所有租户共用一套表靠 tenant_id 字段区分。成本最低但一个租户的慢查询可能拖垮所有人。Schema 隔离每个租户一个数据库 schema。隔离性好一些但租户多了管理麻烦。物理隔离每个租户独立数据库实例。隔离性最好成本最高。QuickBlue 这类底座通常默认走逻辑隔离通过 MyBatis 拦截器自动给 SQL 加上 tenant_id 条件。这里有个坑拦截器要处理好“哪些表需要加租户条件、哪些不需要”。像字典表、系统配置表这种全局表加了租户条件反而查不到数据。所以拦截器需要维护一个白名单明确哪些表跳过租户过滤。会话数据尤其要注意隔离。对话历史里可能包含敏感信息如果租户 A 能通过某种方式读到租户 B 的会话那就是严重的安全问题。会话服务的每个查询都必须带租户上下文不能有例外。3.4 配置热更新模型参数不能靠重启AI 应用有个特点模型参数、提示词模板、限流阈值这些东西变更非常频繁。如果每次改个提示词都要重启服务运维会疯掉。所以配置中心是刚需。Nacos Config 支持配置变更推送配合 Spring Cloud 的RefreshScope注解可以实现不重启就生效。但RefreshScope有个已知问题它创建的是代理对象如果配置类被频繁刷新会产生大量代理实例有内存泄漏风险。更稳妥的做法是把易变的配置抽到一个专门的配置 Bean 里控制刷新范围。提示词模板的管理也值得单独说。好的做法是把提示词当成配置而不是代码存在配置中心或数据库里支持版本管理和灰度发布。这样运营人员改提示词不用找开发开发也不用为了改一句话走一遍发版流程。4. 落地时真正会卡住你的几个问题4.1 模型适配层的抽象怎么做才不别扭模型适配层最容易犯的错是“抽象过度”。一开始想设计一个万能接口把 OpenAI、各家国产模型、本地模型全兼容结果发现每家的参数、返回格式、流式协议都有细微差别抽象层越写越厚最后变成一堆 if-else。我的经验是抽象要抓“稳定不变的部分”把“易变的部分”留给配置。稳定的部分是输入消息列表、参数、输出文本、Token 用量、调用方式同步、流式。易变的部分是具体的参数名、鉴权方式、返回字段路径。前者定义成统一接口后者用适配器 配置映射来解决。具体做法是定义一个ModelProvider接口每个供应商一个实现类实现类里做参数转换。新增一个模型供应商只需要加一个实现类加一份配置不动核心代码。这比追求“一套代码适配所有模型”务实得多。4.2 流式响应下的错误处理流式响应最麻烦的是错误处理。普通请求失败了返回一个错误码就行流式请求可能已经推了一半数据才出错这时候 HTTP 状态码早就发出去了200没法再改。客户端看到的是“数据推了一半突然断了”。处理这个问题的标准做法是在流式协议里定义错误事件。比如 SSE 里除了正常的 data 事件再定义一个 event: error 的事件类型出错时推一个错误事件客户端识别到就中断并提示。同时服务端要保证连接被正确关闭避免连接泄漏。还有一个细节流式场景下的超时要分“首字超时”和“整体超时”。首字超时通常设短一点比如 10 秒因为模型如果 10 秒还没吐第一个字大概率是卡住了整体超时设长一点比如 120 秒给长回答留空间。这两个超时要分开配置。4.3 计量计费的准确性怎么保证Token 计量看着简单实际很容易出错。问题出在几个地方流式响应下 Token 数是最后才统计出来的如果中途断了这次调用的 Token 怎么算并发调用下同一个用户的额度扣减怎么保证不超扣第一个问题的解法是“预扣 结算”。请求发起时先按预估 Token 预扣额度响应结束后按实际用量结算多退少补。中途断了就按已产生的部分结算。第二个问题要靠原子操作。额度扣减必须用 Redis 的原子命令如DECRBY或者数据库的行锁不能用“先查后改”的方式否则并发下必然超扣。如果对准确性要求极高可以考虑把计量做成异步的先放行请求事后对账但这样有超支风险要权衡。注意计量数据建议双写——一份写 Redis 做实时扣减一份写数据库做持久化对账。Redis 挂了不能导致计量数据全丢。4.4 服务拆多了之后的联调噩梦微服务拆得越细本地联调越痛苦。你改一个服务要启动五六个依赖服务才能跑通开发机内存直接爆掉。这是微服务架构的固有代价QuickBlue 这类项目也躲不开。缓解办法有几个。一是用 Docker Compose 把依赖服务容器化本地只跑正在开发的那个服务其他用容器。二是用服务 Mock把不关心的下游服务 mock 掉。三是把一些强关联的服务合并部署别为了“微”而“微”。我个人的判断标准是如果一个服务离开另一个服务就完全没法独立测试那它们可能不该拆开。拆分的目的是独立演进和独立扩展如果达不到这个目的拆了就是纯负担。5. 从零搭一套类似底座的实操路径5.1 环境准备与依赖版本锁定如果你打算照着 QuickBlue 的思路自己搭一套第一步是把版本锁死。Spring Cloud 和 Spring Boot 的版本对应关系非常严格选错版本会有一堆莫名其妙的兼容问题。JDK 21 对应的 Spring Boot 建议用 3.2 及以上Spring Cloud 用 2023.0.x 系列。依赖管理上用 Spring Cloud 的 BOMBill of Materials统一管理版本不要在子模块里各自指定版本号。Nacos、Sentinel 这些组件的版本也要和 Spring Cloud 版本对齐官方文档里有对应表照着选就行。一个容易忽略的点是JDK 21 下有些老版本的字节码增强库比如某些版本的 CGLIB会有兼容问题如果启动时报Unsupported class file major version之类的错多半是依赖库太老升级即可。5.2 服务注册与配置中心的最小可用配置最小可用的底座至少要有服务注册和配置中心。用 Nacos 同时承担这两个角色是最省事的方案。启动一个 Nacos 单机实例然后每个微服务引入spring-cloud-starter-alibaba-nacos-discovery和spring-cloud-starter-alibaba-nacos-config。配置上bootstrap.yml里指定 Nacos 地址和命名空间application.yml里写业务配置。命名空间用来隔离环境开发、测试、生产不同环境用不同的 namespace避免配置串环境。服务注册有个细节健康检查。Nacos 默认用心跳检测如果服务是临时实例心跳断了会被自动摘除如果是持久化实例需要主动注销。AI 服务通常用临时实例就行配合 K8s 的存活探针能快速摘除不健康的实例。5.3 网关路由与鉴权的串联网关是流量的入口路由配置和鉴权逻辑要在这里串起来。路由配置建议用配置中心动态管理而不是写死在代码里这样加一条路由不用发版。鉴权通常分两步先验 Token 有效性再查权限。Token 校验可以在网关做比如校验 JWT 签名权限校验建议下沉到具体服务因为网关不一定知道每个接口的细粒度权限。网关只做“粗筛”把明显没登录的请求挡掉细粒度权限交给业务服务。这里有个性能考量如果每个请求网关都要调一次认证服务验 Token认证服务会成为瓶颈。优化办法是网关本地缓存 Token 校验结果注意设置合理的过期时间或者用 JWT 这种自包含的 Token网关本地就能验签不用远程调用。5.4 上线前的压测重点AI 底座的压测和普通微服务不一样重点要放在几个特殊场景上。第一是流式接口的并发能力要测长连接数能撑到多少。第二是模型调用超时后的降级路径要确认降级逻辑真的生效。第三是限流规则在高并发下是否准确会不会误伤。压测工具上普通接口用 JMeter 或 wrk 都行流式接口建议用能处理 SSE 的工具或者自己写脚本。压测时要注意观察的不只是 QPS还有连接数、线程数、GC 频率这些指标。虚拟线程场景下线程数不再是瓶颈指标要转而关注下游模型服务的承载能力。6. 我对这套架构的一点个人判断搭了几年微服务也踩过不少坑我对“AI 应用底座”这类项目的看法是它的价值不在于技术多先进而在于把一堆琐碎的治理问题标准化了。QuickBlue 用的技术栈——Spring Cloud、Sentinel、Nacos、JDK 21——没有一个是新东西但把它们组合起来解决 AI 场景的具体问题这个组合本身就是价值。真正决定这类项目成败的往往不是架构设计得多漂亮而是细节处理得到不到位。比如流式响应的错误处理、Token 计量的并发准确性、多租户隔离的彻底性这些地方出问题再漂亮的架构也白搭。所以如果你要落地类似的东西我的建议是架构可以简单点但边界情况一定要想全。最后分享一个我自己的习惯每引入一个中间件或组件都问自己一句“它挂了会怎样”。Sentinel 挂了限流失效、Nacos 挂了配置拉不到、Redis 挂了计量不准——把这些降级路径提前想清楚比事后救火强得多。底座这东西平时不出彩出事的时候才知道它值不值。
阅读完成 · 觉得有帮助？
