Java 8老系统旁路接入AI Gateway：不升级JDK也能用AI

为什么要写这个系列做Java后端十年我接触过不少企业的核心系统。金融、电商、政务——行业不同但底层的现状惊人地相似生产系统还在Java 8框架停在Spring Boot 2.x甚至更早代码跑了很多年没人敢轻易动。去年开始几乎每个项目都在谈接AI。但真正动手的时候团队就卡住了。不是因为不懂大模型而是老系统本身接不住。JDK版本不够Spring AI引不进来依赖树牵一发动全身升级一个包怕带崩一片生产流量压着不敢拿主流程赌一个AI试点。更危险的是硬塞。我见过团队在老系统的Service层直接new一个HttpClient调模型APIPrompt拼在业务代码里超时没配、降级没有。模型响应慢的时候老系统的订单查询线程池被占满主流程跟着卡住。还有团队把用户手机号、身份证原样送进Prompt过了两个月才被安全审计发现。这种事见多了我就开始想一个问题老系统不具备直接接入AI的条件这是不是大多数企业的常态答案是肯定的。而且这不应该成为接不了AI的理由。核心思路其实就三条老系统少改 —— 不升级 JDK不引入 Spring AI 依赖 AI 能力旁路 —— 独立部署老系统通过 HTTP 或 MQ 调用 企业边界先行 —— 脱敏、审计、降级、幂等比模型调用更重要这个系列就是把这三条线展开成10讲。从AI Gateway到MCP工具中心从SQL Agent到RAG知识库从工单Agent到多Agent研发团队——每一讲都围绕同一个前提你的老系统还在跑Java 8你不能为了AI去赌它的稳定性。每讲配套一个可运行的Maven Lab不讲空架构不写Hello World。你跑得通Demo看得到边界拿得到代码。这就是我做这个系列的原因。这个系列帮你建立企业 AI 接入的架构意识。每个 Demo 都可独立运行每讲都配有边界设计和企业避坑。但意识不等于系统。当你真正要在自己的项目里落地时会发现10 个独立 Lab 的组件需要整合成一个完整的 AI 能力中心Stub 模型需要替换成真实模型调用权限、审计、脱敏需要从 Demo 级别升级到生产级别先把架构意识打好落地时才能走得更稳。Java 8老系统旁路接入AI Gateway不升级JDK也能用AI很多企业接AI的真实起点不是从0写一个新应用。更常见的情况是生产系统还在 Java 8 框架还是 Spring Boot 2.x 甚至更老 代码跑了很多年不敢轻易升级 业务已经开始要求接 AI这时候最危险的做法是把Spring AI或大模型SDK直接塞进老系统。不是因为Spring AI不好而是老系统本身承担着生产流量、历史业务和稳定性风险。为了一个AI能力去升级JDK、升级Spring Boot、调整依赖树很容易把AI试点变成老系统改造项目。所以第一讲先回答一个更朴素的问题Java 8老系统不升级怎么接入AI我的答案是旁路接入。先别急着接模型很多人一听老系统接AI脑子里会先出现模型API拿 API Key 拼 Prompt 调用模型 解析结果但对老系统来说第一步不是模型而是接入边界。你要先想清楚4个问题老系统要不要升级 AI 调用失败会不会影响主流程 敏感数据能不能直接进模型 AI 输出能不能直接改业务状态如果这些问题没想清楚模型调通也只是一个脆弱Demo。本讲的代码就是围绕这4个问题设计的。本讲能学到什么本讲配套代码是一个Maven可运行的基础Lab。代码目录code/spring-ai-enterprise-lab/labs/chapter01-ai-gateway运行.\compile-and-run.ps1运行后会看到4个场景老系统通过AiGatewayClient旁路调用AI Gateway。手机号、身份证、邮箱先脱敏再进入模型调用。相同订单重复请求命中幂等缓存。模型不可用或参数非法时老系统仍然拿到可控降级结果。最重要的是AI只生成处理建议不自动修改老系统订单状态。推荐的接入方式第1讲采用的是旁路架构Java 8 老订单系统 ↓ AiGatewayClient ↓ AI Gateway ↓ 模型调用、脱敏、审计、降级等能力在Demo里AiGatewayClient为了方便演示直接Java调用OrderSummaryService。在真实项目里它应该变成HTTP调用老系统 ↓ HTTP AI 能力中心这里的重点不是HTTP代码怎么写而是依赖方向老系统依赖一个稳定的 Gateway 接口 老系统不直接依赖 Spring AI 老系统不感知模型供应商这样以后模型从A换到B或者AI能力中心从单模型变成多模型路由老系统都不需要跟着改。旁路失败时怎么办旁路不是把风险丢给另一个服务。老系统接AI时要先定义失败策略。本讲建议的同步调用策略是连接超时短比如 3-5 秒 读取超时可稍长比如 10-30 秒 老系统侧不做多次重试 AI Gateway 侧负责重试、熔断和降级 老系统拿不到 AI 结果时继续走人工处理流程也就是说AI Gateway是增强能力不是老系统主流程的单点依赖。在本讲Demo中模型不可用时会返回{fallback:true,summary:AI 模型服务暂时不可用请稍后重试。}老系统依旧能拿到一个固定建议而不是直接抛异常把页面或业务流程打断。如果是更高风险的业务比如支付、审批、退款就不建议同步等待AI结果。更稳的方式是异步老系统写入业务结果 ↓ 发送事件 ↓ AI 能力中心异步分析 ↓ 生成建议或待办 ↓ 人工确认后处理本讲先讲同步旁路因为它最容易理解后面的工单、工作流、多Agent会继续扩展异步和人工确认。端到端走一遍现在把整条链路串起来看。老系统收到一个订单处理请求订单 O202606050001 延迟发货 客户希望今天给处理方案 文本中包含手机号、身份证、邮箱第一步老系统调用自己的业务服务legacyOrderService.assistOrder(orderId,orderText);第二步LegacyOrderService组装一个请求对象newOrderSummaryRequest(demo,u1001,orderId,orderText);这里的tenantId和operatorId很重要。企业系统里的AI调用不能只有一段文本还要知道哪个租户 哪个操作人 哪个业务对象 哪一次请求第三步老系统通过AiGatewayClient调用AI GatewaypublicOrderSummaryResultsummarizeOrder(OrderSummaryRequestrequest){returnorderSummaryService.summarize(request);}当前是Demo直接调用生产环境可以替换成HTTP Client。第四步AI Gateway执行治理流程校验请求 检查重复请求 检查调用频率 脱敏订单文本 记录请求审计 判断模型是否可用 调用模型或返回降级 整理结构化响应 记录响应审计第五步老系统拿到结构化建议{summary:客户反馈订单延迟发货需要尽快给出处理方案。,riskLevel:MEDIUM,suggestedActions:[查询物流状态,联系仓库确认发货时间,向客户同步预计处理时间]}注意这里只是建议。Demo里还会输出legacyOrderStatusBeforeDELAYED, legacyOrderStatusAfterDELAYED boundaryAI 只生成处理建议不自动修改老系统订单状态。这就是老系统接AI的第一条底线AI可以辅助判断但不能默认替你改业务状态。代码应该看哪些类这篇文章不需要你一次看完所有Filter。第一讲真正建议先看的类只有5个legacy/LegacyOrderService.java legacy/AiGatewayClient.java common/OrderSummaryRequest.java common/OrderSummaryResult.java gateway/OrderSummaryService.java它们对应的是老系统接入AI的主线老系统业务服务 ↓ AI Gateway 客户端 ↓ 请求/响应 DTO ↓ AI Gateway 总入口理解这条线以后再去看Gateway内部治理。Gateway内部不要平铺理解本讲代码里有一条Pipeline但不要把9个Filter当成同等重要的知识点硬背。可以分成三层第一层接入必需ValidationFilter MaskingFilter AuditRequestFilter ModelCallFilter AuditResponseFilter这一层解决的是请求是否合法 敏感数据有没有进模型 谁调用了 AI 模型结果怎么回来 响应有没有审计如果只做最小可用AI Gateway至少要有这一层。第二层企业稳态IdempotencyFilter RateLimitFilter CircuitBreakerFilter这一层解决的是重复请求怎么办 调用太频繁怎么办 模型不可用怎么办这些不是炫技而是老系统接外部能力时经常会遇到的问题。第三层输出整理ParseResponseFilter FallbackAnswerFactory这一层解决的是模型结果怎么变成业务系统能理解的结构 失败时怎么给出固定可控结果这样分层以后Pipeline就不再是一串吓人的类名而是一套接入思路。脱敏要看输入和输出正常请求里包含手机号 13800000000 身份证 110101199001011234 邮箱 vipexample.com审计日志会记录maskedFields[idCard, mobile, email]返回结果里也会带上{maskedFields:[idCard,mobile,email]}这让读者能直接把输入和输出对应起来原始订单文本里有敏感信息 ↓ Gateway 脱敏 ↓ 审计记录脱敏字段 ↓ 响应告诉老系统处理过哪些字段企业里做AI接入不是相信我们已经脱敏了而是要让脱敏行为可观察。为什么要做幂等很多AI Demo不讲幂等。但在企业里重复请求很常见用户重复点击 网关超时重试 MQ 重复投递 前端刷新页面如果每次都重新调用模型就会带来两个问题重复成本。重复处理风险。本讲里相同订单重复请求会命中幂等缓存不再穿透后续AI调用链路。这不是复杂功能但很贴近企业真实需求。企业避坑这篇文章的避坑点其实可以归成4句话。第一老系统不要为了接AI贸然升级。先旁路接入降低试点风险。第二AI调用失败不能拖垮老系统。同步调用要有超时和降级高风险业务优先考虑异步。第三敏感数据不要裸奔进模型。手机号、身份证、邮箱至少要先脱敏而且脱敏行为要可观察。第四AI输出默认只是建议。除非经过明确审批和授权否则不要让AI自动修改订单、退款、审批、支付等业务状态。从 Demo 到落地还差什么本讲帮你跑通了旁路接入 AI 的核心链路但从一个可运行 Demo 到真正在企业落地还差几步模型替换当前 Demo 用 Stub 模拟模型调用。真实项目需要接入大模型 API、管理 Prompt 模板、处理模型返回格式的稳定性。多模型路由企业不会只用一个模型。不同场景需要按成本、精度、速度选择不同模型还要支持模型切换时老系统无感知。运维可观测生产环境需要调用看板——调用量、延迟分布、降级触发次数、各 Filter 耗时。Demo 里没有这些。动态配置限流阈值、熔断参数、脱敏规则不能写死在代码里。生产级 Gateway 需要配置中心按租户动态调整。如果你正在推进企业 AI 接入落地后续会有一个完整的 AI 能力中心工程把这些组件整合起来届时会单独介绍。和后续9讲的关系第1讲是整个公开系列的总纲。后面的内容都会复用这条主线老系统少改 ↓ AI 能力旁路 ↓ 企业边界先行第2讲会讲MCP Tool Center老系统能力如何包装成受控工具。第3讲会讲SQL AgentAI查库为什么必须只读、白名单和LIMIT。第6讲会讲RAG企业知识库为什么必须有权限和引用。第9、10讲会把AI放进工作流和多Agent研发流程。小结Java 8老系统接AI不应该从怎么调大模型API开始。更稳的第一步是老系统不升级 AI Gateway 旁路部署 同步调用有超时和降级 敏感数据先脱敏 调用过程可审计 AI 只给建议不直接改业务状态这篇文章真正想讲的不是一个Gateway Demo而是一种思维方式先保护老系统再引入AI能力。