做AI应用开发这几年我见到的第一个坎几乎都不是算法效果而是架构。很多团队把大模型API一接、Prompt一调、界面一拼就能跑出一个漂亮的Demo但真正放进业务里面对多客户、多租户、持续迭代单体架构很快就扛不住。这篇文章想聊的就是AI应用从单体架构走向SaaS化过程中我踩过的坑、拆过的服务、和最终沉淀下来的一套演进路径。如果你正在做企业级AI应用、智能体平台或者传统SaaS想要接入AI功能这篇文章应该对你有用。我不打算讲一堆高大上的微服务理论只会拿一个我做过的“制度条例学习助手”以及后来餐饮SaaS接入AI的案例把每一步怎么拆、为什么拆、拆完有什么好处说清楚。1. 为什么AI应用最后都绕不开架构演进1.1 单体架构很爽但爽不过一年一个典型的单体AI应用技术栈一般就是FastAPI、Flask或者Spring Boot配上PostgreSQL、Redis然后直连大模型API。所有逻辑放在同一个进程里用户管理、会话管理、Prompt组装、模型调用、向量检索、计费埋点全部挤在一个工程目录下。前期开发过程确实舒服没有网络开销没有服务间联调日志打在一起随便查部署就一个进程完事。Demo阶段、内部工具阶段这种单体架构完全够用甚至可以说是最佳选择。但“爽不过一年”的原因往往不是代码本身出了问题而是业务变化了。当这个AI应用从一个内部工具变成一个对外售卖的产品当客户从1个变成30个当每个客户有不同的知识库、不同的模型偏好、不同的调用量单体的麻烦会集中爆发。我见过一个很典型的场景原本一个制度条例学习助手给公司内部30个人用每天几百次调用一切正常。后来产品化之后要给几十家外部企业做私有部署和数据隔离还没有真正做多租户设计结果客户的文档和检索结果混在一起运营同学每天都要手动处理数据串线问题。用生活类比来说单体架构就像街边一家小店后厨和前台是一体的。客人少的时候老板兼厨师兼服务员效率很高口味稳定。可一旦店里排起长队后厨出菜慢前台催单门口等位的客人开始不耐烦小店立刻就乱成一团。这时候你不是缺一个好厨师而是缺一套把“接单、做菜、送菜”分开的流程。SaaS化要解决的就是这个流程问题只是AI应用里的“做菜”变成了模型调用、知识库检索、向量化这些更重的活儿。1.2 SaaS化到底改变了什么很多人会把SaaS简单理解为“做成网页版给别人用”其实完全不是。SaaS化的核心是四件事多租户隔离、自助开通、弹性扩缩、按量计费。它意味着你的系统不再是为一个客户定制而是同一套代码同时服务很多客户每个客户的数据和配置互相隔离并能够根据实际用量计费。对AI应用来说SaaS化还会多出几个传统SaaS没有的变量。第一模型成本是可变成本。传统SaaS的边际成本很低用户多了主要加服务器但AI应用每一次对话都在消耗Token这部分成本如果不在架构层面按租户记录清楚月底就只能对着供应商账单发愁。第二租户隔离的范围变大了。传统SaaS隔离数据库和文件就行AI应用还要隔离知识库、向量索引、Prompt模板、模型路由策略。第三模型供应商是不固定的。客户可能指定必须用某家国产模型或者某家大模型的私有化版本这要求架构不能和任何一家供应商绑死。所以我会把这件事概括成一句话单体架构解决的是“能不能跑”SaaS化解决的是“能不能卖”。你要把一个AI应用真正作为SaaS产品交付出去就必须让系统具备多租户、计量、配额、灰度这些能力。而这些能力几乎不可能靠给单体架构打补丁来实现一定要做架构演进。2. 单体阶段的AI应用是怎么搭起来的2.1 典型单体AI应用长什么样我之前做过一个“制度条例学习助手”这个项目特别适合用来还原单体AI应用的典型长相。它的业务流程并不复杂管理员上传企业制度文档系统解析文档内容切片后做向量化存入向量库普通用户提问系统先从向量库检索相关内容把命中的片段和大模型对话历史一起组装成Prompt让模型生成回答。从功能上讲这已经是一个完整的RAG应用了。当时的代码结构大概是这样的一个FastAPI后端服务包含了用户管理、文件上传、文档解析、文本切片、向量化写入、向量检索、Prompt组装、大模型调用、会话历史存储这些所有模块。前端是两个简单的页面一个是聊天窗口一个是管理后台。存储上PostgreSQL放用户、会话和文档元数据向量库单独部署了一个QdrantRedis做了缓存。但这里要注意虽然向量库是独立进程整个应用在架构上仍然是一个单体业务逻辑全部耦合在一个服务进程里文档解析和向量化任务也是同步执行的。我后来接触到的不少AI Agent智能体应用前期也是类似的形态。Agent的工作流编排、工具调用、会话管理、模型调用全部塞在一个Agent服务里。一个人开发、一个人维护功能演示非常顺利。这再次说明单体架构在早期完全不是错误而是一个必经阶段。只是你必须清楚地知道它会在什么条件下开始失灵。2.2 单体架构的隐性负债单体架构最大的问题是所有事情共享同一个进程的资源一旦某个环节变慢整个服务都会受影响。大模型接口本身就是一个高延迟外部依赖动辄两三秒甚至更长时间如果业务代码是同步等待的Tomcat或者Uvicorn的工作线程很快就会耗尽。这个时候用户打开聊天页面不只是提问没反应连登录接口和运维健康检查也会跟着超时负载均衡器会把实例从注册中心摘掉最终整个服务不可用。第二类问题是重型任务抢占了在线资源。文档解析、切片、向量化是典型的CPU密集和IO密集型任务。如果在Web进程里同步跑一个20MB的PDF解析上传可能就让几十个在线提问请求排队等候。第三类问题是租户隔离几乎没有。刚开始只给一个客户部署时向量库里的Collection随便建不需要考虑过滤条件。当客户变多不同客户的制度文档如果继续混在同一个Collection里检索时不做租户过滤就必然出现数据串线。这是SaaS产品绝对不能接受的问题。第四类问题是发布和回滚太重。单体时代改一个Prompt模板或者换一个模型版本整个服务都要重新构建、重新发布而且没有灰度能力。你想给一部分用户先试新模型另外一部分用户继续用旧模型单体架构里很难做到。最后成本核算也是糊涂账。模型供应商的账单只会告诉你这个月花了几万块但具体是哪个客户、哪个功能消耗了多少Token根本没有数据支撑。我印象很深的一次故障就是白天执行了一批制度文档的向量化任务切片和Embedding占满了CPU结果同一个进程里的聊天接口响应时间从300毫秒涨到30秒最后内存也撑不住实例OOM了。那次之后我下定决心要拆也才有了后面这一套演进思路。3. AI应用SaaS化的核心拆解边界到底划在哪里3.1 先划业务边界再谈技术拆分很多人一谈架构演进第一反应是上微服务、上服务网格然后被分布式事务和链路追踪折磨得痛不欲生。我的经验是拆分之前一定要先想清楚边界而边界不是按代码行数或者团队分工来划的应该按“变化频率”和“资源消耗特征”来划。一个典型的AI SaaS产品至少可以划出这几个子系统接入网关、会话业务服务、模型网关、知识库服务、计量计费服务。它们各自的变化频率很不一样。会话业务服务是变化最快的产品经理天天有新想法这里要频繁迭代。模型网关是中等频率变化的模型供应商的API格式、限流策略、价格体系经常变但对业务方来说变化应该被隔离在网关内部。计量计费服务变化频率低但一旦出错客户投诉和财务对账都会很麻烦。这张表可以比较直观地说明边界职责子系统核心职责变化频率接入网关认证、路由、限流低会话业务服务对话逻辑、业务编排、状态管理高模型网关模型路由、重试、成本计量中知识库服务文档解析、切片、向量化、检索中计量计费配额、用量统计、账单低但极其重要这里有一条我认为必须坚持的底线任何业务代码都不能直接依赖某个具体模型供应商的SDK所有模型调用必须走模型网关。哪怕最开始模型网关只是一个非常薄的代理也要先把这层边界立住。这样未来替换模型、做灰度、按租户计费都有一个统一的收口点。3.2 模型接入层为什么要单独成服务模型网关是AI应用SaaS化性价比最高的一步没有之一。它的核心价值不是“转发请求”这个动作而是把“模型供应商不稳定”这个事实隔离在业务之外。你想想看今天用GPT明天换国产模型后天客户要求私有化部署如果这些变化都要改业务代码那产品迭代的速度会被拖死。实际落地的时候模型网关一般做这几件事。第一统一接口协议最简单的方式是兼容/v1/chat/completions的格式业务方只认一套HTTP接口。第二多模型路由根据租户等级、请求类型、预算策略选择具体用哪个模型。第三统一超时、重试和熔断某个供应商限流了网关可以退避重试或者切到备用供应商业务侧无感。第四成本打点每个请求结束后记录Token消耗按租户维度写入计量系统。这里其实还有一个很现实的作用内容安全和合规。所有进出大模型的内容都在网关这一层做审计和过滤比在业务代码里到处埋点要干净得多。模型网关可以类比成公司前台来访的客人不需要知道他们要找的人具体坐在哪个工位前台会根据访客身份和事由分发到不同部门。业务系统只需要跟“前台”打交道不需要自己跑去对接每一个模型供应商。3.3 知识库与向量化服务独立的意义RAG类的AI应用知识库是最容易被低估的一块。模型网关解决的是“模型能力”问题但知识库解决的是“回答质量”问题。企业制度条例学习助手这类产品客户最在意的就是检索准不准、回答有没有依据、文档更新后能不能立即生效。这些能力如果还是一股脑塞在单体里很快会遇到两个问题。第一个问题是重计算阻塞在线请求。文档解析和向量化是非常重型的工作一次批量导入几百份制度文档Embedding要调用模型接口向量要写入数据库整个过程可能持续几分钟。如果放在Web进程同步执行在线聊天接口就只能干等着。第二个问题是知识库的租户隔离和版本管理。不同客户有不同的制度文档甚至同一个客户在不同时期有不同的制度版本向量索引不能把所有数据揉在一起必须有清晰的租户和文档级隔离。所以知识库服务应该独立出来通常采用“任务队列 Worker”的模式。用户上传文档后业务服务只负责把文件存到对象存储并发送一条消息到队列后台Worker负责解析、切片、向量化、写入向量库。向量库本身的连接池、检索逻辑也收敛到RAG服务里业务方通过HTTP接口做检索不需要自己直连向量库。对于智能体应用也是一样的道理Agent的工作流编排、工具执行引擎如果足够复杂同样适合独立成服务。核心思路始终不变把有状态的、重计算的、慢的部分和请求入口分离。4. 从单体到SaaS的一次典型演进实录4.1 第一阶段抽出模型网关我的建议是把演进分成几个小阶段每个阶段都保证系统处于可交付状态不要憋大招。第一阶段只做一件事所有模型调用收口到独立的模型网关。具体操作并不复杂。先新起一个服务用FastAPI、Go或者你顺手的技术栈都行先实现一个/v1/chat/completions接口内部转发给真实模型供应商。然后把业务代码里所有直接调用大模型SDK的地方替换成调用这个网关。替换过程中顺手做一件事在网关里强制拿到tenant_id、request_id和usage信息并写入日志和计量表。代码结构上核心逻辑大概长这样# 简化版模型网关核心逻辑 app.post(/v1/chat/completions) async def chat_completions(req: ChatRequest, tenant: Tenant Depends(get_tenant)): # 1. 根据租户配置解析出要使用的模型路由 route model_router.resolve(tenant.tenant_id, req.model) # 2. 检查租户配额超限直接返回 429 quota quota_checker.check(tenant.tenant_id) if not quota.allowed: raise HTTPException(status_code429, detailquota exceeded) # 3. 转发给真实模型供应商 resp await route.forward(req) # 4. 记录 usage 和费用归属 usage resp.get(usage, {}) billing_recorder.record(tenant.tenant_id, route.model_name, usage) return resp这里要提醒一个很容易踩的坑流式输出。如果业务侧用的是SSE流式响应模型网关就不能等完整响应再转发必须透传流。而SSE流的超时和客户端断连特别难排查网关层要做好读写超时控制避免连接被一直挂着。第一阶段不要急着做多供应商适配器先统一协议选一个主供应商跑通等网关稳定了再扩展。做完这一步最直接的效果是业务代码里几十处模型调用被统一成了一个client以后不管模型供应商怎么换业务服务代码一行都不用动。同时成本和配额的数据从此有了唯一的采集点这是后面所有SaaS计费功能的地基。4.2 第二阶段让应用服务变成无状态模型网关落地之后第二步是把原来的单体业务服务改造为无状态。为什么必须做这一步因为无状态是水平扩展的前提。你不可能让多个副本同时跑一个有状态的服务会话数据放在本地内存负载均衡把请求分到不同实例用户上一秒的对话内容可能就丢了。这个阶段需要动三块东西。第一会话历史从内存或本地文件挪到Redis或数据库。第二上传的文件从服务本地磁盘挪到对象存储这样多副本可以共享访问。第三耗时的后台任务从Web进程剥离即使暂时不独立部署至少用Celery、RQ这类任务队列把异步任务拆出来别让文档解析继续占着在线进程。无状态化之后的单体在物理上仍然是一个部署单元但逻辑上已经具备水平扩展的能力。前面加一层负载均衡流量大了就多开几个副本哪个实例挂了也能被自动摘除。我曾经在这个阶段犯过一个典型错误为了追求“架构先进”过早引入了配置中心、服务注册发现、全链路监控结果业务没起来光运维就给团队增加了大量负担。无状态化真正的收益是“多副本安全”而不是“拆分微服务”你要始终记得当前阶段的目标。4.3 第三阶段多租户与配额控制多租户隔离是SaaS化的核心。这里我要强调一句多租户不是简单在表里加一个customer_id字段而是从业务流转到数据存储、从模型路由到成本归属全链路都要贯穿同一个租户标识。改造的时候有两块重点。一块是数据隔离所有业务表增加tenant_id查询强制带租户过滤向量库给每条向量打上租户元数据每次检索必须带租户过滤条件。这里最怕的是“只在Service层过滤SQL里忘了加条件”所以我的建议是早期宁可多写一点强制代码在数据访问层统一处理不要依赖每个开发人员的自觉。另一块是配额控制。SaaS产品的配额维度通常有每分钟请求数、每分钟Token消耗量、并发数、存储容量等。配额不单是为了防刷更是成本控制的一种手段。免费版用户每天只能提问50次企业版用户每月有100万Token额度这些都必须由系统强制执行。用中间件实现租户限流是比较常见的做法# 租户配额中间件伪代码 async def tenant_quota_middleware(request: Request, call_next): tenant request.state.tenant if not quota_manager.allow(tenant.tenant_id, rpm60, tpm10000): return JSONResponse( status_code429, headers{Retry-After: 60}, content{detail: quota exceeded, please upgrade plan} ) return await call_next(request)要注意的是限流的返回信息不要太生硬最好能告诉用户当前额度用到了多少、什么时候恢复、如何升级套餐。这既是技术设计也是产品设计。配额的数据来自哪里来自第一阶段模型网关记录的usage。所以再次强调成本打点一定要走网关否则配额和计费都是无源之水。4.4 第四阶段可观测性与按租户灰度很多团队把可观测性放在最后做我的建议恰恰相反从第一阶段就要开始打点。至少做到每个请求有request_id每个请求知道tenant_id所有日志、网关调用、向量库检索记录都带上这两个字段。没有这个基础等拆成多个服务之后再补排查线上问题的痛苦会成倍放大。到了多租户阶段可观测性的价值就更明显了。你需要能回答几个问题某个租户今天调用了多少次模型、消耗了多少Token、错误率是多少某个模型供应商的接口最近延迟是不是变高了某个Prompt模板修改后回答质量有没有下降。这些数据分别来自业务日志、模型网关日志和计量系统最好做成统一的看板。灰度发布也要按租户维度来做而不是简单按服务器比例分批。一个典型操作是先选几个内部租户和愿意尝鲜的Beta租户把他们的模型路由切到新模型版本观察错误率、延迟和单次成本。确认没问题再逐步扩大到更多租户。如果某个租户是新签的大客户还可以单独给他配置一个模型版本通过调整模型路由来实现定制化不需要改代码。整个演进过程可以用下面这张表概括阶段核心目标关键动作判断标准模型网关解耦模型供应商统一接口、成本计量换模型不碰业务代码无状态化支持水平扩展会话外置、异步任务多副本无共享状态多租户配额可售卖、成本可控tenant_id贯穿、限流中间件新租户5分钟完成开通可观测灰度稳定迭代traceId、按租户灰度能回答是哪个租户出错5. 从Spring Boot餐饮SaaS接入AI看老系统怎么走这条路5.1 传统SaaS里的AI集成不是把Java改成Python“Spring Boot餐饮SaaS AI集成”这个场景代表了一大类需求传统SaaS系统已经跑了好几年有完整的商户、门店、菜品、订单、会员数据现在想接入AI能力但不可能推倒重来。不少团队在这个地方很容易走偏为了调大模型方便直接在订单服务里引入Python SDK甚至额外起一个Python服务去直连业务数据库这样既破坏了原有系统的边界也把数据库耦合搞得一团糟。正确的做法其实和前面说的模型网关思路完全一致传统SaaS系统不需要关心AI具体怎么实现只需要定义一个内部的AI服务边界。Java侧通过HTTP调用一个AI网关AI网关后面才是模型网关、RAG服务、向量库。AI应用的逻辑可以用Python写也可以继续用Java写语言根本不是关键关键的是一层清晰的边界。餐饮SaaS里典型的AI集成点有这么几个。菜品推荐根据用户历史订单生成个性化推荐语差评自动回复调用大模型生成几个话术版本由商家确认后发布营业数据分析助手让老板用自然语言问“上周哪道菜销量最高”系统通过RAG或者NL2SQL返回答案。这些场景有一个共性它们都不是核心交易链路可以异步执行也可以失败降级。比如推荐服务挂了用户还能正常点餐只是不显示推荐而已。所以接入方式上优先走事件驱动订单创建成功后发一条消息到队列AI服务异步处理而不是在交易接口里同步等待大模型结果。5.2 中小自研公司怎么演进才不亏热搜里有个问题问“中小自研公司的AI应用开发岗位多吗”我的观察是岗位需求确实在涨但要求的通常是综合能力不是纯算法能力。能做模型训练的人很多能把AI能力稳定落地到业务系统里的人反而稀缺。尤其像我们现在聊的架构演进懂的人就更少了。中小公司预算有限最忌讳一上来就搞K8s、服务网格、多活容灾这一套。我的建议非常务实第一步把模型网关做出来第二步把租户隔离和计量埋点做扎实第三步如果业务真的发展到需要拆分的量级再考虑把知识库服务、会话业务服务独立出去。哪怕一开始代码还是有些“单体味道”只要边界清晰、数据隔离、计量准确你就已经具备了一个SaaS产品最核心的骨架。现在还有很多AI应用搭建平台比如AI Studio、扣子这类产品能帮你快速搭一个Agent智能体应用。我的态度是用它们做Demo、做MVP完全没有问题能极大缩短验证周期。但一旦要把应用商业化要卖给多个客户要处理私有化部署、数据权限、审计日志、按量计费这些平台帮不了你只能靠自己的架构设计。平台是加速器不是替代品。6. 常见问题与避坑清单6.1 常见问题速查表这里整理我实际遇到过的几个高频问题每个都让当时的团队折腾过不少时间。问题现象常见原因排查思路与解法会话数据串租户前端传了tenant_id后端直接信任或SQL漏加租户过滤条件统一从认证Token解析租户身份在数据访问层强制拼租户条件模型调用超时导致业务接口雪崩业务代码同步等待模型接口超时时间设置过长模型网关统一设置超时上限业务侧快速失败后台任务重试向量库连接数被打爆每个业务实例都直连向量库连接池不受控收敛到RAG服务统一管理连接池业务侧只走HTTP检索接口按量计费对不上账只统计了普通响应流式输出的Token用量没累计流式响应也要逐段累计usage定时写计量库对账以计量库为准知识库更新后检索结果还是旧的文档有新增或修改但向量库增量更新没做给文档建立版本号和脏标记增量任务只处理变更文档完成后清理脏标记这些问题共同指向一个根源没有在架构层面对租户、模型、知识库这些关键对象做统一收口。每个服务各管各的数据和连接全扩散排查时自然一团乱麻。演进的过程其实就是把散落在各处的关键能力逐步收口的过程。6.2 现在回头看我认为最值得提前做的几件事第一日志从第一天就带上trace_id和tenant_id。不要等到服务拆多了再补那时候你连一次完整请求的链路都拼不回来。第二成本打点越早越好。模型网关每记录一次usage未来定价和对账就有依据。SaaS产品最怕的就是月底拿着供应商账单却不知道哪个客户该收多少钱。第三Prompt模板也要版本化并且和模型版本关联。生产环境的Prompt被人在后台手动改乱导致回答质量波动但没人发现问题这种事发生过太多次了。第四至少保持两个模型供应商可用不要跟单一家绑死。AI模型这个领域变化太快供应商的服务稳定性、价格、政策随时会变你至少要保留快速切换的能力。第五最重要的一条架构演进不要一步到位。先做模型网关再做租户隔离再做计量计费每个阶段都要有明确的业务收益。为了架构而架构最后大概率是被复杂的基础设施拖垮。微服务不是目的SaaS化带来的多租户、成本可控、按量计费、持续交付才是目的。最后说一点个人体会。架构演进这件事最怕的不是技术难而是看不清边界。我也见过团队为了架构好看把一个单体硬拆成十几个服务结果链路排查、数据一致性、运维成本一起爆掉也见过业务已经多租户了代码还停留在单体里客户数据混在一个库中SLA不敢承诺。比较稳妥的路线始终是先把模型网关、租户隔离、计量埋点这三件基础做扎实让业务压力来告诉你下一步该拆什么。希望这篇从单体到SaaS的AI应用架构演进记录能帮正在做同类系统的你少走一些弯路。
做AI应用开发这几年我见到的第一个坎几乎都不是算法效果而是架构。很多团队把大模型API一接、Prompt一调、界面一拼就能跑出一个漂亮的Demo但真正放进业务里面对多客户、多租户、持续迭代单体架构很快就扛不住。这篇文章想聊的就是AI应用从单体架构走向SaaS化过程中我踩过的坑、拆过的服务、和最终沉淀下来的一套演进路径。如果你正在做企业级AI应用、智能体平台或者传统SaaS想要接入AI功能这篇文章应该对你有用。我不打算讲一堆高大上的微服务理论只会拿一个我做过的“制度条例学习助手”以及后来餐饮SaaS接入AI的案例把每一步怎么拆、为什么拆、拆完有什么好处说清楚。1. 为什么AI应用最后都绕不开架构演进1.1 单体架构很爽但爽不过一年一个典型的单体AI应用技术栈一般就是FastAPI、Flask或者Spring Boot配上PostgreSQL、Redis然后直连大模型API。所有逻辑放在同一个进程里用户管理、会话管理、Prompt组装、模型调用、向量检索、计费埋点全部挤在一个工程目录下。前期开发过程确实舒服没有网络开销没有服务间联调日志打在一起随便查部署就一个进程完事。Demo阶段、内部工具阶段这种单体架构完全够用甚至可以说是最佳选择。但“爽不过一年”的原因往往不是代码本身出了问题而是业务变化了。当这个AI应用从一个内部工具变成一个对外售卖的产品当客户从1个变成30个当每个客户有不同的知识库、不同的模型偏好、不同的调用量单体的麻烦会集中爆发。我见过一个很典型的场景原本一个制度条例学习助手给公司内部30个人用每天几百次调用一切正常。后来产品化之后要给几十家外部企业做私有部署和数据隔离还没有真正做多租户设计结果客户的文档和检索结果混在一起运营同学每天都要手动处理数据串线问题。用生活类比来说单体架构就像街边一家小店后厨和前台是一体的。客人少的时候老板兼厨师兼服务员效率很高口味稳定。可一旦店里排起长队后厨出菜慢前台催单门口等位的客人开始不耐烦小店立刻就乱成一团。这时候你不是缺一个好厨师而是缺一套把“接单、做菜、送菜”分开的流程。SaaS化要解决的就是这个流程问题只是AI应用里的“做菜”变成了模型调用、知识库检索、向量化这些更重的活儿。1.2 SaaS化到底改变了什么很多人会把SaaS简单理解为“做成网页版给别人用”其实完全不是。SaaS化的核心是四件事多租户隔离、自助开通、弹性扩缩、按量计费。它意味着你的系统不再是为一个客户定制而是同一套代码同时服务很多客户每个客户的数据和配置互相隔离并能够根据实际用量计费。对AI应用来说SaaS化还会多出几个传统SaaS没有的变量。第一模型成本是可变成本。传统SaaS的边际成本很低用户多了主要加服务器但AI应用每一次对话都在消耗Token这部分成本如果不在架构层面按租户记录清楚月底就只能对着供应商账单发愁。第二租户隔离的范围变大了。传统SaaS隔离数据库和文件就行AI应用还要隔离知识库、向量索引、Prompt模板、模型路由策略。第三模型供应商是不固定的。客户可能指定必须用某家国产模型或者某家大模型的私有化版本这要求架构不能和任何一家供应商绑死。所以我会把这件事概括成一句话单体架构解决的是“能不能跑”SaaS化解决的是“能不能卖”。你要把一个AI应用真正作为SaaS产品交付出去就必须让系统具备多租户、计量、配额、灰度这些能力。而这些能力几乎不可能靠给单体架构打补丁来实现一定要做架构演进。2. 单体阶段的AI应用是怎么搭起来的2.1 典型单体AI应用长什么样我之前做过一个“制度条例学习助手”这个项目特别适合用来还原单体AI应用的典型长相。它的业务流程并不复杂管理员上传企业制度文档系统解析文档内容切片后做向量化存入向量库普通用户提问系统先从向量库检索相关内容把命中的片段和大模型对话历史一起组装成Prompt让模型生成回答。从功能上讲这已经是一个完整的RAG应用了。当时的代码结构大概是这样的一个FastAPI后端服务包含了用户管理、文件上传、文档解析、文本切片、向量化写入、向量检索、Prompt组装、大模型调用、会话历史存储这些所有模块。前端是两个简单的页面一个是聊天窗口一个是管理后台。存储上PostgreSQL放用户、会话和文档元数据向量库单独部署了一个QdrantRedis做了缓存。但这里要注意虽然向量库是独立进程整个应用在架构上仍然是一个单体业务逻辑全部耦合在一个服务进程里文档解析和向量化任务也是同步执行的。我后来接触到的不少AI Agent智能体应用前期也是类似的形态。Agent的工作流编排、工具调用、会话管理、模型调用全部塞在一个Agent服务里。一个人开发、一个人维护功能演示非常顺利。这再次说明单体架构在早期完全不是错误而是一个必经阶段。只是你必须清楚地知道它会在什么条件下开始失灵。2.2 单体架构的隐性负债单体架构最大的问题是所有事情共享同一个进程的资源一旦某个环节变慢整个服务都会受影响。大模型接口本身就是一个高延迟外部依赖动辄两三秒甚至更长时间如果业务代码是同步等待的Tomcat或者Uvicorn的工作线程很快就会耗尽。这个时候用户打开聊天页面不只是提问没反应连登录接口和运维健康检查也会跟着超时负载均衡器会把实例从注册中心摘掉最终整个服务不可用。第二类问题是重型任务抢占了在线资源。文档解析、切片、向量化是典型的CPU密集和IO密集型任务。如果在Web进程里同步跑一个20MB的PDF解析上传可能就让几十个在线提问请求排队等候。第三类问题是租户隔离几乎没有。刚开始只给一个客户部署时向量库里的Collection随便建不需要考虑过滤条件。当客户变多不同客户的制度文档如果继续混在同一个Collection里检索时不做租户过滤就必然出现数据串线。这是SaaS产品绝对不能接受的问题。第四类问题是发布和回滚太重。单体时代改一个Prompt模板或者换一个模型版本整个服务都要重新构建、重新发布而且没有灰度能力。你想给一部分用户先试新模型另外一部分用户继续用旧模型单体架构里很难做到。最后成本核算也是糊涂账。模型供应商的账单只会告诉你这个月花了几万块但具体是哪个客户、哪个功能消耗了多少Token根本没有数据支撑。我印象很深的一次故障就是白天执行了一批制度文档的向量化任务切片和Embedding占满了CPU结果同一个进程里的聊天接口响应时间从300毫秒涨到30秒最后内存也撑不住实例OOM了。那次之后我下定决心要拆也才有了后面这一套演进思路。3. AI应用SaaS化的核心拆解边界到底划在哪里3.1 先划业务边界再谈技术拆分很多人一谈架构演进第一反应是上微服务、上服务网格然后被分布式事务和链路追踪折磨得痛不欲生。我的经验是拆分之前一定要先想清楚边界而边界不是按代码行数或者团队分工来划的应该按“变化频率”和“资源消耗特征”来划。一个典型的AI SaaS产品至少可以划出这几个子系统接入网关、会话业务服务、模型网关、知识库服务、计量计费服务。它们各自的变化频率很不一样。会话业务服务是变化最快的产品经理天天有新想法这里要频繁迭代。模型网关是中等频率变化的模型供应商的API格式、限流策略、价格体系经常变但对业务方来说变化应该被隔离在网关内部。计量计费服务变化频率低但一旦出错客户投诉和财务对账都会很麻烦。这张表可以比较直观地说明边界职责子系统核心职责变化频率接入网关认证、路由、限流低会话业务服务对话逻辑、业务编排、状态管理高模型网关模型路由、重试、成本计量中知识库服务文档解析、切片、向量化、检索中计量计费配额、用量统计、账单低但极其重要这里有一条我认为必须坚持的底线任何业务代码都不能直接依赖某个具体模型供应商的SDK所有模型调用必须走模型网关。哪怕最开始模型网关只是一个非常薄的代理也要先把这层边界立住。这样未来替换模型、做灰度、按租户计费都有一个统一的收口点。3.2 模型接入层为什么要单独成服务模型网关是AI应用SaaS化性价比最高的一步没有之一。它的核心价值不是“转发请求”这个动作而是把“模型供应商不稳定”这个事实隔离在业务之外。你想想看今天用GPT明天换国产模型后天客户要求私有化部署如果这些变化都要改业务代码那产品迭代的速度会被拖死。实际落地的时候模型网关一般做这几件事。第一统一接口协议最简单的方式是兼容/v1/chat/completions的格式业务方只认一套HTTP接口。第二多模型路由根据租户等级、请求类型、预算策略选择具体用哪个模型。第三统一超时、重试和熔断某个供应商限流了网关可以退避重试或者切到备用供应商业务侧无感。第四成本打点每个请求结束后记录Token消耗按租户维度写入计量系统。这里其实还有一个很现实的作用内容安全和合规。所有进出大模型的内容都在网关这一层做审计和过滤比在业务代码里到处埋点要干净得多。模型网关可以类比成公司前台来访的客人不需要知道他们要找的人具体坐在哪个工位前台会根据访客身份和事由分发到不同部门。业务系统只需要跟“前台”打交道不需要自己跑去对接每一个模型供应商。3.3 知识库与向量化服务独立的意义RAG类的AI应用知识库是最容易被低估的一块。模型网关解决的是“模型能力”问题但知识库解决的是“回答质量”问题。企业制度条例学习助手这类产品客户最在意的就是检索准不准、回答有没有依据、文档更新后能不能立即生效。这些能力如果还是一股脑塞在单体里很快会遇到两个问题。第一个问题是重计算阻塞在线请求。文档解析和向量化是非常重型的工作一次批量导入几百份制度文档Embedding要调用模型接口向量要写入数据库整个过程可能持续几分钟。如果放在Web进程同步执行在线聊天接口就只能干等着。第二个问题是知识库的租户隔离和版本管理。不同客户有不同的制度文档甚至同一个客户在不同时期有不同的制度版本向量索引不能把所有数据揉在一起必须有清晰的租户和文档级隔离。所以知识库服务应该独立出来通常采用“任务队列 Worker”的模式。用户上传文档后业务服务只负责把文件存到对象存储并发送一条消息到队列后台Worker负责解析、切片、向量化、写入向量库。向量库本身的连接池、检索逻辑也收敛到RAG服务里业务方通过HTTP接口做检索不需要自己直连向量库。对于智能体应用也是一样的道理Agent的工作流编排、工具执行引擎如果足够复杂同样适合独立成服务。核心思路始终不变把有状态的、重计算的、慢的部分和请求入口分离。4. 从单体到SaaS的一次典型演进实录4.1 第一阶段抽出模型网关我的建议是把演进分成几个小阶段每个阶段都保证系统处于可交付状态不要憋大招。第一阶段只做一件事所有模型调用收口到独立的模型网关。具体操作并不复杂。先新起一个服务用FastAPI、Go或者你顺手的技术栈都行先实现一个/v1/chat/completions接口内部转发给真实模型供应商。然后把业务代码里所有直接调用大模型SDK的地方替换成调用这个网关。替换过程中顺手做一件事在网关里强制拿到tenant_id、request_id和usage信息并写入日志和计量表。代码结构上核心逻辑大概长这样# 简化版模型网关核心逻辑 app.post(/v1/chat/completions) async def chat_completions(req: ChatRequest, tenant: Tenant Depends(get_tenant)): # 1. 根据租户配置解析出要使用的模型路由 route model_router.resolve(tenant.tenant_id, req.model) # 2. 检查租户配额超限直接返回 429 quota quota_checker.check(tenant.tenant_id) if not quota.allowed: raise HTTPException(status_code429, detailquota exceeded) # 3. 转发给真实模型供应商 resp await route.forward(req) # 4. 记录 usage 和费用归属 usage resp.get(usage, {}) billing_recorder.record(tenant.tenant_id, route.model_name, usage) return resp这里要提醒一个很容易踩的坑流式输出。如果业务侧用的是SSE流式响应模型网关就不能等完整响应再转发必须透传流。而SSE流的超时和客户端断连特别难排查网关层要做好读写超时控制避免连接被一直挂着。第一阶段不要急着做多供应商适配器先统一协议选一个主供应商跑通等网关稳定了再扩展。做完这一步最直接的效果是业务代码里几十处模型调用被统一成了一个client以后不管模型供应商怎么换业务服务代码一行都不用动。同时成本和配额的数据从此有了唯一的采集点这是后面所有SaaS计费功能的地基。4.2 第二阶段让应用服务变成无状态模型网关落地之后第二步是把原来的单体业务服务改造为无状态。为什么必须做这一步因为无状态是水平扩展的前提。你不可能让多个副本同时跑一个有状态的服务会话数据放在本地内存负载均衡把请求分到不同实例用户上一秒的对话内容可能就丢了。这个阶段需要动三块东西。第一会话历史从内存或本地文件挪到Redis或数据库。第二上传的文件从服务本地磁盘挪到对象存储这样多副本可以共享访问。第三耗时的后台任务从Web进程剥离即使暂时不独立部署至少用Celery、RQ这类任务队列把异步任务拆出来别让文档解析继续占着在线进程。无状态化之后的单体在物理上仍然是一个部署单元但逻辑上已经具备水平扩展的能力。前面加一层负载均衡流量大了就多开几个副本哪个实例挂了也能被自动摘除。我曾经在这个阶段犯过一个典型错误为了追求“架构先进”过早引入了配置中心、服务注册发现、全链路监控结果业务没起来光运维就给团队增加了大量负担。无状态化真正的收益是“多副本安全”而不是“拆分微服务”你要始终记得当前阶段的目标。4.3 第三阶段多租户与配额控制多租户隔离是SaaS化的核心。这里我要强调一句多租户不是简单在表里加一个customer_id字段而是从业务流转到数据存储、从模型路由到成本归属全链路都要贯穿同一个租户标识。改造的时候有两块重点。一块是数据隔离所有业务表增加tenant_id查询强制带租户过滤向量库给每条向量打上租户元数据每次检索必须带租户过滤条件。这里最怕的是“只在Service层过滤SQL里忘了加条件”所以我的建议是早期宁可多写一点强制代码在数据访问层统一处理不要依赖每个开发人员的自觉。另一块是配额控制。SaaS产品的配额维度通常有每分钟请求数、每分钟Token消耗量、并发数、存储容量等。配额不单是为了防刷更是成本控制的一种手段。免费版用户每天只能提问50次企业版用户每月有100万Token额度这些都必须由系统强制执行。用中间件实现租户限流是比较常见的做法# 租户配额中间件伪代码 async def tenant_quota_middleware(request: Request, call_next): tenant request.state.tenant if not quota_manager.allow(tenant.tenant_id, rpm60, tpm10000): return JSONResponse( status_code429, headers{Retry-After: 60}, content{detail: quota exceeded, please upgrade plan} ) return await call_next(request)要注意的是限流的返回信息不要太生硬最好能告诉用户当前额度用到了多少、什么时候恢复、如何升级套餐。这既是技术设计也是产品设计。配额的数据来自哪里来自第一阶段模型网关记录的usage。所以再次强调成本打点一定要走网关否则配额和计费都是无源之水。4.4 第四阶段可观测性与按租户灰度很多团队把可观测性放在最后做我的建议恰恰相反从第一阶段就要开始打点。至少做到每个请求有request_id每个请求知道tenant_id所有日志、网关调用、向量库检索记录都带上这两个字段。没有这个基础等拆成多个服务之后再补排查线上问题的痛苦会成倍放大。到了多租户阶段可观测性的价值就更明显了。你需要能回答几个问题某个租户今天调用了多少次模型、消耗了多少Token、错误率是多少某个模型供应商的接口最近延迟是不是变高了某个Prompt模板修改后回答质量有没有下降。这些数据分别来自业务日志、模型网关日志和计量系统最好做成统一的看板。灰度发布也要按租户维度来做而不是简单按服务器比例分批。一个典型操作是先选几个内部租户和愿意尝鲜的Beta租户把他们的模型路由切到新模型版本观察错误率、延迟和单次成本。确认没问题再逐步扩大到更多租户。如果某个租户是新签的大客户还可以单独给他配置一个模型版本通过调整模型路由来实现定制化不需要改代码。整个演进过程可以用下面这张表概括阶段核心目标关键动作判断标准模型网关解耦模型供应商统一接口、成本计量换模型不碰业务代码无状态化支持水平扩展会话外置、异步任务多副本无共享状态多租户配额可售卖、成本可控tenant_id贯穿、限流中间件新租户5分钟完成开通可观测灰度稳定迭代traceId、按租户灰度能回答是哪个租户出错5. 从Spring Boot餐饮SaaS接入AI看老系统怎么走这条路5.1 传统SaaS里的AI集成不是把Java改成Python“Spring Boot餐饮SaaS AI集成”这个场景代表了一大类需求传统SaaS系统已经跑了好几年有完整的商户、门店、菜品、订单、会员数据现在想接入AI能力但不可能推倒重来。不少团队在这个地方很容易走偏为了调大模型方便直接在订单服务里引入Python SDK甚至额外起一个Python服务去直连业务数据库这样既破坏了原有系统的边界也把数据库耦合搞得一团糟。正确的做法其实和前面说的模型网关思路完全一致传统SaaS系统不需要关心AI具体怎么实现只需要定义一个内部的AI服务边界。Java侧通过HTTP调用一个AI网关AI网关后面才是模型网关、RAG服务、向量库。AI应用的逻辑可以用Python写也可以继续用Java写语言根本不是关键关键的是一层清晰的边界。餐饮SaaS里典型的AI集成点有这么几个。菜品推荐根据用户历史订单生成个性化推荐语差评自动回复调用大模型生成几个话术版本由商家确认后发布营业数据分析助手让老板用自然语言问“上周哪道菜销量最高”系统通过RAG或者NL2SQL返回答案。这些场景有一个共性它们都不是核心交易链路可以异步执行也可以失败降级。比如推荐服务挂了用户还能正常点餐只是不显示推荐而已。所以接入方式上优先走事件驱动订单创建成功后发一条消息到队列AI服务异步处理而不是在交易接口里同步等待大模型结果。5.2 中小自研公司怎么演进才不亏热搜里有个问题问“中小自研公司的AI应用开发岗位多吗”我的观察是岗位需求确实在涨但要求的通常是综合能力不是纯算法能力。能做模型训练的人很多能把AI能力稳定落地到业务系统里的人反而稀缺。尤其像我们现在聊的架构演进懂的人就更少了。中小公司预算有限最忌讳一上来就搞K8s、服务网格、多活容灾这一套。我的建议非常务实第一步把模型网关做出来第二步把租户隔离和计量埋点做扎实第三步如果业务真的发展到需要拆分的量级再考虑把知识库服务、会话业务服务独立出去。哪怕一开始代码还是有些“单体味道”只要边界清晰、数据隔离、计量准确你就已经具备了一个SaaS产品最核心的骨架。现在还有很多AI应用搭建平台比如AI Studio、扣子这类产品能帮你快速搭一个Agent智能体应用。我的态度是用它们做Demo、做MVP完全没有问题能极大缩短验证周期。但一旦要把应用商业化要卖给多个客户要处理私有化部署、数据权限、审计日志、按量计费这些平台帮不了你只能靠自己的架构设计。平台是加速器不是替代品。6. 常见问题与避坑清单6.1 常见问题速查表这里整理我实际遇到过的几个高频问题每个都让当时的团队折腾过不少时间。问题现象常见原因排查思路与解法会话数据串租户前端传了tenant_id后端直接信任或SQL漏加租户过滤条件统一从认证Token解析租户身份在数据访问层强制拼租户条件模型调用超时导致业务接口雪崩业务代码同步等待模型接口超时时间设置过长模型网关统一设置超时上限业务侧快速失败后台任务重试向量库连接数被打爆每个业务实例都直连向量库连接池不受控收敛到RAG服务统一管理连接池业务侧只走HTTP检索接口按量计费对不上账只统计了普通响应流式输出的Token用量没累计流式响应也要逐段累计usage定时写计量库对账以计量库为准知识库更新后检索结果还是旧的文档有新增或修改但向量库增量更新没做给文档建立版本号和脏标记增量任务只处理变更文档完成后清理脏标记这些问题共同指向一个根源没有在架构层面对租户、模型、知识库这些关键对象做统一收口。每个服务各管各的数据和连接全扩散排查时自然一团乱麻。演进的过程其实就是把散落在各处的关键能力逐步收口的过程。6.2 现在回头看我认为最值得提前做的几件事第一日志从第一天就带上trace_id和tenant_id。不要等到服务拆多了再补那时候你连一次完整请求的链路都拼不回来。第二成本打点越早越好。模型网关每记录一次usage未来定价和对账就有依据。SaaS产品最怕的就是月底拿着供应商账单却不知道哪个客户该收多少钱。第三Prompt模板也要版本化并且和模型版本关联。生产环境的Prompt被人在后台手动改乱导致回答质量波动但没人发现问题这种事发生过太多次了。第四至少保持两个模型供应商可用不要跟单一家绑死。AI模型这个领域变化太快供应商的服务稳定性、价格、政策随时会变你至少要保留快速切换的能力。第五最重要的一条架构演进不要一步到位。先做模型网关再做租户隔离再做计量计费每个阶段都要有明确的业务收益。为了架构而架构最后大概率是被复杂的基础设施拖垮。微服务不是目的SaaS化带来的多租户、成本可控、按量计费、持续交付才是目的。最后说一点个人体会。架构演进这件事最怕的不是技术难而是看不清边界。我也见过团队为了架构好看把一个单体硬拆成十几个服务结果链路排查、数据一致性、运维成本一起爆掉也见过业务已经多租户了代码还停留在单体里客户数据混在一个库中SLA不敢承诺。比较稳妥的路线始终是先把模型网关、租户隔离、计量埋点这三件基础做扎实让业务压力来告诉你下一步该拆什么。希望这篇从单体到SaaS的AI应用架构演进记录能帮正在做同类系统的你少走一些弯路。
