1. 项目缘起当老系统遇上新AI最近在做一个老项目的技术升级客户的核心诉求很有意思他们有一套运行了快十年的Java 8老系统业务逻辑复杂牵一发动全身短期内完全没有升级JDK版本的计划。但现在业务部门又提出了新需求希望能在系统里集成一些AI能力比如智能客服问答、文档内容摘要、风险信息识别等等。这听起来就像让一个还在用功能机的老用户突然要用上最新的5G和智能应用中间的代沟不是一般的大。最直接的想法当然是升级JDK。现在Spring AI、LangChain4j这些框架对Java 17的支持最好新特性用起来也顺手。但现实很骨感这套老系统依赖了大量陈旧的第三方库有些甚至已经找不到源码了线上服务器环境复杂升级JDK意味着所有依赖、部署脚本、监控配置可能都要动更别提全面回归测试的成本和不可预知的风险了。客户给的底线很明确核心业务代码和运行环境JDK 8绝对不能动。那怎么办难道要自己从头去封装各大AI平台的HTTP API光是处理不同模型的请求格式、响应解析、错误重试、流式输出、令牌计算这些事就够写一个中型项目了而且后续的维护成本会是个无底洞。正是在这种“既要又要”的困境下AI Gateway这个概念进入了我们的视野。它本质上是一个智能路由和统一适配层对外提供一套标准的API对内帮你对接OpenAI、Anthropic、国内各大模型厂商等不同的AI服务。我们的思路是既然不能动老系统那就走旁路接入。在老系统之外独立部署一个AI Gateway服务让老系统通过最传统的HTTP/RPC方式去调用这个网关由网关来搞定所有与AI模型交互的脏活累活。这样一来老系统继续安稳地跑在Java 8上而AI能力则由一个独立的、可以用任何新版本JDK甚至其他语言实现的服务来提供两者通过清晰的接口契约进行通信。这个方案的精髓在于“桥接”与“解耦”。老系统不需要理解什么是Function Calling也不需要处理SSEServer-Sent Events流式响应它只需要像调用一个普通的外部数据接口一样向AI Gateway发起请求并等待结果。所有的复杂性都被隔离在了网关内部。接下来我就详细拆解一下如何在不升级老系统一行业务代码的情况下为它装上AI的“翅膀”。2. 技术选型为什么是Spring AI 独立服务明确了旁路接入的思路后下一个问题就是这个独立的AI Gateway服务用什么技术栈来构建虽然老系统是Java 8但网关服务我们完全可以从零开始选择最合适、最高效的技术。经过一番调研和对比我们最终选择了Spring AI作为网关的核心框架。2.1 主流Java AI框架横向对比在Java生态里除了Spring AI你可能还听说过LangChain4j。这里简单做个对比就能明白我们的选择理由LangChain4j灵感来源于Python的LangChain概念抽象程度高提供了Chain、Agent、Memory等丰富的编排能力。如果你要构建非常复杂的、有状态的AI应用流水线它是个强大的工具。但它的学习曲线相对陡峭且对于“将多个AI模型统一成简单API”这个网关核心诉求来说显得有些“重”了。Spring AISpring官方出品秉承了Spring框架一贯的理念简化常见任务。它的抽象层次恰到好处核心概念就是ChatClient、EmbeddingClient和ImageClient等直接对应AI的聊天、嵌入、绘图等能力。对于构建一个AI Gateway我们需要的就是这种直接、稳定的抽象。更重要的是它与Spring Boot生态无缝集成配置管理、健康检查、监控指标Micrometer都能轻松搞定这对于一个需要高可用、易运维的网关服务至关重要。2.2 Spring AI的核心优势与网关的契合度Spring AI的几个特点让它成为我们网关的理想选择模型无关的API这是最关键的一点。无论后端对接的是OpenAI的GPT-4还是Anthropic的Claude或是国内的通义千问、文心一言Spring AI都通过统一的ChatClient接口来提供服务。这意味着网关的业务代码只需要写一套通过配置就能切换或路由到不同的模型。老系统调用网关时完全感知不到后端的模型是谁。强大的连接器ConnectorsSpring AI社区提供了大量预置的连接器涵盖了几乎所有主流的AI提供商。我们只需要引入对应的Spring Boot Starter如spring-ai-openai-spring-boot-starter在application.yml里配置好API Key和Base URL就能立刻拥有一个可用的客户端。这极大地减少了集成工作量。开箱即用的功能比如它内置了对流式响应Streaming Response的支持返回的是一个FluxChatResponse响应式编程模型这对于需要实时显示AI生成结果的场景非常友好。虽然我们的老系统可能暂时用不到流式但网关保留这个能力可以为未来预留空间。便捷的Prompt管理可以将复杂的Prompt模板化并存储在外部文件或数据库中方便进行A/B测试和动态调整而不需要修改代码。2.3 网关服务的独立性与技术栈我们决定将AI Gateway构建为一个全新的Spring Boot 3.x应用基于JDK 17或21。这样做的好处非常明显技术栈自由我们可以尽情使用Records、Text Blocks、新的HTTP Client等现代Java特性提升开发效率和运行时性能。独立部署与伸缩网关服务可以独立于老系统进行部署、扩容、升级和重启不会影响核心业务的稳定性。专注单一职责这个服务只负责AI能力聚合与适配代码结构清晰易于维护。统一管控点可以在网关层统一实现限流、降级、鉴权、审计、费用监控等跨领域关切这些是直接在每个业务系统里调用AI API难以做到的。3. 架构设计与老系统对接方案确定了核心技术和独立服务的方向后我们需要设计一个清晰的架构来确保老系统能安全、高效、稳定地使用这个新的AI能力。整个架构的核心思想是“前后端分离”和“契约先行”。3.1 整体架构视图我们可以用以下逻辑视图来理解这个旁路接入方案[Java 8 老系统] ---(HTTP/REST or RPC)--- [AI Gateway (Spring Boot on JDK 17)] | |--- (适配与路由) --- [OpenAI API] |--- (适配与路由) --- [Anthropic Claude API] |--- (适配与路由) --- [国内大模型A API] |--- (适配与路由) --- [国内大模型B API]老系统和AI Gateway是两个独立的进程通常部署在不同的服务器或容器中。它们之间的通信方式是整个方案成败的关键。3.2 对接协议选型REST API vs RPC对于老系统来说调用外部服务最常见的方式就是HTTP。我们需要为AI Gateway设计一套对老系统友好的API。RESTful API这是最通用、最容易被各种语言和框架理解的方式。我们可以在AI Gateway里定义几个清晰的端点例如POST /api/ai/chat/completion用于聊天补全。POST /api/ai/embedding用于获取文本向量。请求体和响应体使用JSON格式结构尽量简单、稳定。优点兼容性极强老系统里用HttpURLConnection、Apache HttpClient、甚至RestTemplate都能调用。调试也方便用Postman或curl即可。缺点相对于RPC性能有轻微开销需要自己处理序列化/反序列化。RPC (如 gRPC)如果老系统所在的技术栈支持例如使用了Dubbo并且对性能有极致要求可以考虑gRPC。gRPC基于HTTP/2和Protocol Buffers传输效率高接口通过.proto文件严格定义。优点性能好接口强类型编译时就能发现错误。缺点对老系统侵入性稍强需要引入gRPC客户端依赖调试不如REST直观。考虑到我们场景的初衷是“最小化老系统改动”和“最大化兼容性”我们首选RESTful API。它的普适性使得集成成本最低。接下来我们就以REST为例设计具体的接口。3.3 API接口设计示例我们的目标是让老系统像调用一个普通数据接口一样调用AI。下面是一个聊天接口的设计请求端点POST /v1/chat/completions请求头需要包含鉴权信息如X-API-Key和老系统传递的一些上下文如X-User-Id,X-Request-Id用于链路追踪。请求体 (JSON){ model: gpt-3.5-turbo, // 指定模型网关可根据此路由 messages: [ {role: system, content: 你是一个专业的客服助手。}, {role: user, content: 请问你们的产品保修期是多久} ], stream: false, // 老系统暂不支持流式设为false max_tokens: 500 }响应体 (JSON){ success: true, code: 200, message: 成功, data: { id: chatcmpl-xxx, choices: [ { message: { role: assistant, content: 我们产品的标准保修期为一年从购买之日算起。在此期间..., reasoning: null // 某些模型如Claude的思考过程可选择性返回 }, finish_reason: stop } ], usage: { prompt_tokens: 25, completion_tokens: 42, total_tokens: 67 }, model: gpt-3.5-turbo, provider: openai // 新增字段告知老系统实际调用的供应商 }, requestId: 老的系统传递的请求ID }错误响应{ success: false, code: RATE_LIMIT, message: 请求频率超限请稍后重试, data: null, requestId: ... }这个设计的关键在于包装响应没有直接返回AI厂商的原生响应而是套了一层success/code/message/data的标准业务格式。这让老系统的错误处理逻辑可以统一。简化字段只保留了老系统可能关心的核心字段去掉了AI原生响应中很多复杂的元数据。透传信息requestId用于全链路追踪provider和model帮助后续问题定位和成本分析。3.4 老系统侧的集成代码示例Java 8在老系统里调用这个网关接口的代码可以非常简洁。假设我们使用Spring Framework 4.x老系统常见配置和RestTemplateimport org.springframework.http.*; import org.springframework.web.client.RestTemplate; import java.util.HashMap; import java.util.Map; public class AIGatewayClient { private String gatewayUrl http://ai-gateway-service:8080; private String apiKey your-gateway-api-key; // 网关的鉴权key非AI平台key private RestTemplate restTemplate; // 需要自行配置Bean public String chatCompletion(String userMessage) { String url gatewayUrl /v1/chat/completions; // 构建请求体 MapString, Object requestMap new HashMap(); requestMap.put(model, gpt-3.5-turbo); MapString, String systemMsg new HashMap(); systemMsg.put(role, system); systemMsg.put(content, 你是一个简洁的助手。); MapString, String userMsg new HashMap(); userMsg.put(role, user); userMsg.put(content, userMessage); requestMap.put(messages, Arrays.asList(systemMsg, userMsg)); requestMap.put(stream, false); requestMap.put(max_tokens, 200); // 设置请求头 HttpHeaders headers new HttpHeaders(); headers.setContentType(MediaType.APPLICATION_JSON); headers.set(X-API-Key, apiKey); headers.set(X-Request-Id, generateRequestId()); // 生成唯一ID HttpEntityMapString, Object requestEntity new HttpEntity(requestMap, headers); try { ResponseEntityMap responseEntity restTemplate.postForEntity(url, requestEntity, Map.class); MapString, Object responseBody responseEntity.getBody(); if (responseBody ! null Boolean.TRUE.equals(responseBody.get(success))) { MapString, Object data (MapString, Object) responseBody.get(data); ListMap choices (ListMap) data.get(choices); Map firstChoice choices.get(0); Map message (Map) firstChoice.get(message); return (String) message.get(content); } else { // 处理网关返回的业务错误 String errorMsg (String) responseBody.get(message); throw new RuntimeException(AI Gateway调用失败: errorMsg); } } catch (Exception e) { // 处理网络超时、连接异常等 throw new RuntimeException(调用AI Gateway服务异常, e); } } private String generateRequestId() { // 简单的ID生成逻辑 return java.util.UUID.randomUUID().toString(); } }可以看到老系统的代码完全不需要知道任何关于Spring AI、OpenAI SDK的事情。它只是在调用一个普通的HTTP接口处理标准的JSON数据。这就是旁路接入的魅力所在。4. AI Gateway服务核心实现详解现在我们把目光聚焦到AI Gateway服务本身。这是一个全新的Spring Boot 3应用我们将基于JDK 21和Spring AI来构建。我会分步骤拆解核心实现并穿插实际编码中遇到的坑和解决方案。4.1 项目初始化与依赖配置首先使用Spring Initializr创建一个新项目选择Project: MavenLanguage: JavaSpring Boot: 3.2.x (建议选择当前稳定版)Dependencies:Spring Web,Spring AI,Spring Configuration Processor(辅助配置提示) 以及你计划对接的AI提供商starter比如Spring AI OpenAI。pom.xml的关键依赖部分如下properties java.version21/java.version spring-ai.version0.8.1/spring-ai.version !-- 使用当时最新稳定版 -- /properties dependencies !-- Spring Boot 基础 -- dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency !-- Spring AI 核心 -- dependency groupIdorg.springframework.ai/groupId artifactIdspring-ai-core/artifactId version${spring-ai.version}/version /dependency !-- Spring AI OpenAI 连接器 -- dependency groupIdorg.springframework.ai/groupId artifactIdspring-ai-openai-spring-boot-starter/artifactId version${spring-ai.version}/version /dependency !-- 如果需要对接其他模型如Azure OpenAI -- !-- dependency groupIdorg.springframework.ai/groupId artifactIdspring-ai-azure-openai-spring-boot-starter/artifactId version${spring-ai.version}/version /dependency -- !-- 工具类 -- dependency groupIdorg.projectlombok/groupId artifactIdlombok/artifactId optionaltrue/optional /dependency /dependencies注意Spring AI版本迭代较快务必查看官方文档使用匹配的版本。不同版本间API可能有细微调整。4.2 应用配置与多模型路由接下来是核心的application.yml配置。这里我们要实现一个关键功能根据请求中的model字段动态路由到不同的AI服务提供商。server: port: 8080 spring: application: name: ai-gateway ai: openai: api-key: ${OPENAI_API_KEY:sk-your-key-here} # 从环境变量读取安全 base-url: https://api.openai.com/v1 # 如果是Azure或代理需修改 chat: options: model: gpt-3.5-turbo # 默认模型 temperature: 0.7 # 假设我们还要配置一个国内模型例如通过OpenAI兼容的API # 这里以某个提供兼容接口的国产模型为例配置另一个连接 openai-compatible: api-key: ${DOMESTIC_API_KEY:key-here} base-url: https://api.domestic-ai.com/v1 chat: options: model: domestic-large-model temperature: 0.8 # 自定义配置用于模型路由映射 ai: gateway: model-provider-map: gpt-3.5-turbo: openai gpt-4: openai domestic-large-model: openai-compatible claude-3-haiku: anthropic # 需要对应的starter和配置这里我们配置了两个ChatClientBean一个叫openai对应Spring AI的默认Bean名另一个叫openai-compatible。我们通过自定义的model-provider-map将模型名称映射到具体的Bean名称。这样在代码中我们就可以根据请求的模型名从Spring容器中取出对应的ChatClient来使用。4.3 核心服务层路由与适配逻辑我们创建一个ChatService它负责接收标准化请求根据模型路由到正确的ChatClient并处理响应。import lombok.RequiredArgsConstructor; import lombok.extern.slf4j.Slf4j; import org.springframework.ai.chat.client.ChatClient; import org.springframework.ai.chat.model.ChatResponse; import org.springframework.ai.chat.prompt.Prompt; import org.springframework.ai.chat.messages.Message; import org.springframework.ai.chat.messages.UserMessage; import org.springframework.ai.chat.messages.SystemMessage; import org.springframework.beans.factory.annotation.Qualifier; import org.springframework.stereotype.Service; import java.util.List; import java.util.Map; import java.util.stream.Collectors; Service Slf4j RequiredArgsConstructor public class ChatService { // 注入默认的OpenAI ChatClient (Bean name: openaiChatClient) private final ChatClient defaultChatClient; // 注入另一个兼容接口的ChatClient使用Qualifier指定Bean名 private final ChatClient openaiCompatibleChatClient; // 从配置中读取模型-提供者映射 private final MapString, String modelProviderMap; public GatewayChatResponse getCompletion(GatewayChatRequest request) { String model request.getModel(); String providerKey modelProviderMap.get(model); if (providerKey null) { throw new IllegalArgumentException(不支持的模型: model); } // 根据提供者Key选择正确的ChatClient ChatClient targetChatClient switch (providerKey) { case openai - defaultChatClient; case openai-compatible - openaiCompatibleChatClient; // 可以继续扩展 case anthropic - anthropicChatClient; default - throw new IllegalArgumentException(未知的提供者: providerKey); }; // 构建Prompt ListMessage messages request.getMessages().stream() .map(m - { switch (m.getRole()) { case user: return new UserMessage(m.getContent()); case system: return new SystemMessage(m.getContent()); case assistant: return new AssistantMessage(m.getContent()); // 假设有此类 default: return new UserMessage(m.getContent()); // 默认 } }) .collect(Collectors.toList()); Prompt prompt new Prompt(messages); // 调用AI服务 ChatResponse response targetChatClient.call(prompt); // 转换为网关统一响应格式 return convertToGatewayResponse(response, model, providerKey); } private GatewayChatResponse convertToGatewayResponse(ChatResponse aiResponse, String model, String provider) { GatewayChatResponse gatewayResponse new GatewayChatResponse(); // ... 详细的字段映射逻辑将Spring AI的ChatResponse转换为我们自定义的GatewayChatResponse // 包括提取content, usage等信息 gatewayResponse.setModel(model); gatewayResponse.setProvider(provider); return gatewayResponse; } }踩坑记录1ChatClient的注入。Spring AI会根据配置自动创建名为openaiChatClient的Bean如果用了OpenAI Starter。如果你配置了多个同类型的连接比如两个OpenAI兼容端点需要自己通过Bean方法显式定义并使用Qualifier区分。否则Spring会因找到多个同类型Bean而报错。4.4 控制层对外暴露REST API最后我们创建Controller来接收老系统的请求。import jakarta.validation.Valid; import lombok.RequiredArgsConstructor; import org.springframework.http.ResponseEntity; import org.springframework.web.bind.annotation.*; RestController RequestMapping(/api/ai) RequiredArgsConstructor public class AIController { private final ChatService chatService; PostMapping(/chat/completions) public ResponseEntityApiResponseGatewayChatResponse chatCompletion( RequestHeader(value X-API-Key, required true) String apiKey, RequestHeader(value X-Request-Id, required false) String requestId, Valid RequestBody GatewayChatRequest request) { // 1. 网关自身鉴权 (验证apiKey是否有效) if (!isValidApiKey(apiKey)) { return ResponseEntity.status(401) .body(ApiResponse.fail(UNAUTHORIZED, 无效的API Key, requestId)); } // 2. 可选请求参数校验与增强 (如注入默认system message) enhanceRequest(request); // 3. 调用服务层 try { GatewayChatResponse data chatService.getCompletion(request); return ResponseEntity.ok(ApiResponse.success(data, requestId)); } catch (IllegalArgumentException e) { return ResponseEntity.badRequest() .body(ApiResponse.fail(BAD_MODEL, e.getMessage(), requestId)); } catch (Exception e) { log.error(AI服务调用异常, requestId: {}, requestId, e); // 这里可以根据e的具体类型如OpenAI的RateLimitError细化错误码 return ResponseEntity.status(500) .body(ApiResponse.fail(INTERNAL_ERROR, AI服务暂时不可用, requestId)); } } private boolean isValidApiKey(String apiKey) { // 实现你的鉴权逻辑例如核对预配置的Key列表或调用外部鉴权服务 // 这里简单示例 return your-pre-shared-secret-key.equals(apiKey); } private void enhanceRequest(GatewayChatRequest request) { // 例如如果请求中没有system message可以默认注入一个 if (request.getMessages().stream().noneMatch(m - system.equals(m.getRole()))) { GatewayChatRequest.Message defaultSystemMsg new GatewayChatRequest.Message(); defaultSystemMsg.setRole(system); defaultSystemMsg.setContent(你是一个有帮助的助手。回答请简洁专业。); request.getMessages().add(0, defaultSystemMsg); // 添加到开头 } } }这个Controller做了几件重要的事网关鉴权保护网关自身防止被未授权调用。请求增强可以在网关层统一添加一些默认参数比如System Prompt确保所有从老系统来的请求都符合一定的质量要求。统一异常处理将底层AI服务提供商的各种异常如额度不足、模型不存在、网络超时转换为老系统能理解的统一错误码和格式。链路追踪将X-Request-Id贯穿整个调用链方便日志排查。至此一个具备基本路由、鉴权、适配能力的AI Gateway服务核心就完成了。老系统通过HTTP调用这个网关的/api/ai/chat/completions接口就能获得AI能力而完全无需关心背后的技术细节。5. 生产环境关键考量与进阶优化一个能上生产环境的AI Gateway远不止一个能调通的API。它必须稳定、可靠、可观测、可运维。以下是我们在实际部署中必须考虑的几个关键点。5.1 稳定性基石熔断、降级与重试AI服务的API调用是典型的外部依赖网络波动、服务方限流或临时故障都可能导致调用失败。我们必须为ChatClient的调用加上 resilience 防护。重试Retry对于网络瞬断、服务方返回5xx错误等暂时性故障应该自动重试。可以使用Spring Retry或Resilience4j实现。Service public class ChatService { Retryable(value {ResourceAccessException.class, HttpClientErrorException.TooManyRequests.class}, maxAttempts 3, backoff Backoff(delay 1000, multiplier 2)) public GatewayChatResponse getCompletionWithRetry(GatewayChatRequest request) { // ... 调用逻辑 } }注意并非所有错误都应重试。例如400 Bad Request请求参数错误或401 Unauthorized密钥错误就不应该重试重试只会浪费资源。熔断Circuit Breaker当AI服务持续不可用或异常率过高时应快速失败避免线程池被拖垮。熔断器可以在故障时直接返回一个预设的降级响应如“服务繁忙请稍后再试”并定期探测服务是否恢复。Resilience4j是很好的选择。降级Fallback当熔断触发或调用失败时可以提供降级策略。例如对于智能客服场景降级策略可以是返回一个预设的常见问题答案列表或者将问题记录到队列稍后由人工处理。CircuitBreaker(name aiChatService, fallbackMethod fallbackCompletion) public GatewayChatResponse getCompletion(GatewayChatRequest request) { // ... } public GatewayChatResponse fallbackCompletion(GatewayChatRequest request, Exception e) { log.warn(AI服务降级触发请求ID: {}, 原因: {}, request.getRequestId(), e.getMessage()); // 返回一个友好的降级响应 GatewayChatResponse fallback new GatewayChatResponse(); fallback.setContent(当前AI服务暂时不可用您的问题已被记录我们会尽快处理。); fallback.setFromFallback(true); return fallback; }5.2 可观测性监控、日志与链路追踪“出了事能快速定位”是运维的黄金法则。监控指标Metrics利用Spring Boot Actuator和Micrometer暴露关键指标。请求量/成功率ai.gateway.requests.total,ai.gateway.requests.errors响应耗时ai.gateway.request.duration区分不同模型和接口。Token消耗ai.gateway.tokens.prompt,ai.gateway.tokens.completion这是成本控制的核心。需要在convertToGatewayResponse方法中提取usage信息并记录。这些指标可以推送到Prometheus Grafana形成监控大盘。结构化日志Logging日志中必须包含唯一请求IDX-Request-Id这样才能串联起从老系统到网关再到AI服务的完整调用链。使用MDCMapped Diagnostic Context来实现。PostMapping(/chat/completions) public ResponseEntity... chatCompletion(..., RequestHeader(value X-Request-Id, required false) String requestId) { String traceId requestId ! null ? requestId : UUID.randomUUID().toString(); MDC.put(requestId, traceId); // 放入MDC log.info(收到聊天请求模型: {}, request.getModel()); try { // ... 业务逻辑 } finally { MDC.clear(); } }在logback-spring.xml中配置日志格式包含%X{requestId}。分布式链路追踪如果公司已有Jaeger、SkyWalking等系统可以将网关接入。Spring Cloud Sleuth现为Micrometer Tracing可以自动为请求生成Trace ID和Span ID并注入到HTTP调用中调用AI服务时实现端到端的追踪。5.3 成本与权限管控AI调用是按Token计费的必须加以管控。限流Rate Limiting防止某个用户或应用异常调用导致账单爆炸。可以在网关入口实现基于API Key或用户ID的限流。Spring Cloud Gateway的过滤器或直接使用Resilience4j的RateLimiter都可以。预算与告警每日/每月为每个API Key或部门设置Token消耗预算。在网关层累计算消耗接近阈值时发出告警如发送到钉钉/企业微信甚至自动阻断后续请求。审计日志所有AI请求和响应可脱敏都应记录到数据库或ES中用于后续的用量分析、问题复盘和合规审计。5.4 配置热更新与模型管理模型列表和密钥不可能每次都重启服务来更新。配置外化将model-provider-map和API Keys放到Nacos、Apollo或Consul等配置中心。Spring Cloud Config支持动态刷新RefreshScope的Bean。模型管理端点可以暴露一个管理API需高级别鉴权用于动态添加、禁用或更新模型配置。这样运营人员可以在不重启服务的情况下上线一个新模型或切换某个模型的API端点。6. 老系统集成实战与避坑指南理论说完了最后聊聊把这块“拼图”真正接入老系统时会遇到哪些具体问题以及我们的解决办法。6.1 网络与部署拓扑老系统和AI Gateway如何通信这取决于你的网络环境。场景一同机房/同VPC内这是最简单的情况。将AI Gateway部署为内部服务老系统通过内网域名如http://ai-gateway.internal:8080或Kubernetes Service名直接调用。延迟低安全性也相对可控通过内网防火墙策略。场景二跨公网调用如果老系统在IDC网关部署在云上或者反之。这时必须使用HTTPS并在网关上配置严格的IP白名单或双向TLS认证mTLS。强烈建议不要将AI Gateway直接暴露在公网前面一定要有API Gateway如Kong, APISIX或负载均衡器做一层防护和路由。踩坑记录2超时设置。老系统的HTTP客户端如HttpURLConnection默认超时时间可能很短几秒而AI生成一段长文本可能需要十几秒甚至更久。务必在老系统调用侧和网关的RestTemplate/WebClient配置合理的连接、读取超时时间如30秒。同时网关调用AI服务时也要设置超时并做好超时后的熔断降级。6.2 老系统HTTP客户端改造很多Java 8老系统可能还在用最基础的HttpURLConnection或者Apache HttpClient 4.x。我们需要封装一个健壮的客户端。连接池管理务必使用连接池避免每次请求都建立新的TCP连接。Apache HttpClient或OkHttp都有成熟的连接池管理。JSON处理老系统可能用org.json或Jackson 2.8Spring Boot 1.x自带。确保序列化/反序列化我们的请求响应体时没有问题。建议在网关和老系统都维护一份API的DTO类定义保持一致性。异常处理网络超时、服务不可用502/503、网关返回的业务错误如code: RATE_LIMIT都需要有不同的处理逻辑。不能一概当成系统错误。6.3 灰度发布与回滚策略如何安全地将新功能上线网关自身灰度先部署新版本的AI Gateway到小部分实例用少量流量测试。老系统调用灰度这是关键。不要一下子让所有老系统的服务实例都切换调用网关。可以通过配置中心先让1-2台老系统机器启用新的AI调用代码观察日志和效果。确认无误后再逐步扩大范围。回滚方案必须准备一键回滚。回滚操作包括两部分一是将老系统的配置切回旧的调用方式如果之前有直接调用AI的残存代码或一个稳定的旧版网关地址二是将网关服务本身回退到上一个稳定版本。6.4 一个真实的“坑”上下文长度与Token计算这是我们上线后遇到的一个典型问题。老系统传来的对话历史可能非常长直接发给AI会导致context length exceeded错误。解决方案在AI Gateway里实现一个上下文管理模块。它的职责是计算请求消息的Token数可以近似按字符数/4估算或调用模型的tokenize接口。如果总Token数超过模型上限如GPT-3.5-turbo的16K则进行裁剪。裁剪策略可以是保留最新的N条消息或保留System Prompt和最新的几条User/Assistant对话。在响应中返回一个警告信息告知老系统上下文已被裁剪。进阶对于需要长上下文记忆的场景如多轮对话可以在网关层引入简单的会话缓存如Redis将历史对话存储起来每次只取最近的有效部分发送。但这会引入状态增加网关的复杂性需要权衡。6.5 效果评估与迭代接入后如何知道AI的效果好不好在网关层埋点除了记录Token消耗还可以记录一些业务指标。例如对于客服场景可以记录“用户是否在得到AI回答后结束了会话”作为解决率的代理指标。这些数据可以和人工客服的日志进行对比分析。A/B测试通过网关的路由能力可以轻松实现A/B测试。例如将10%的流量导向一个新的、调优了Prompt的模型配置对比其与原有配置的指标差异。反馈收集在老系统的界面上增加“回答是否有用”的反馈按钮。将反馈结果传递回网关并记录下来作为持续优化Prompt和模型选择的依据。通过以上这些步骤我们成功地将一个运行在Java 8上的“老古董”系统平滑地接入了现代AI能力。整个过程中老系统就像只是多调用了一个普通的外部数据接口技术债务被牢牢锁定在了边界之外。而AI Gateway则作为一个独立的、现代化的服务可以自由地迭代、扩展和运维为未来接入更多AI能力打下了坚实的基础。这个模式的核心价值不在于用了多炫酷的技术而在于用最小的改造代价解决了最实际的业务问题。