1. 项目概述当老系统遇上新AI最近在跟一个金融行业的老项目打交道核心系统还是基于Java 8构建的架构稳定业务跑了好几年都没出过大问题。但业务部门的需求已经变了他们希望能在现有的客户服务流程里快速集成智能问答、文档摘要、风险提示生成这些AI能力。一提到AI大家第一反应可能就是Spring AI或者直接调用各大模型的SDK但这些新玩意儿对JDK版本都有要求动不动就要求JDK 17甚至21。对于这个核心的Java 8老系统来说升级JDK无异于一场心脏外科手术风险高、周期长、成本巨大任何一个环节出问题都可能影响线上稳定服务。所以我们面临一个非常现实的矛盾既不能动核心系统的根基Java 8和现有架构又要让它能快速、安全地用上最新的AI能力。“旁路接入”就成了我们技术选型的核心思路。这就像给一栋老房子安装一套全新的智能家居系统我们不拆承重墙不改造主电路而是通过新增一条独立的线路和网关来控制所有新设备。在这个场景里这个“智能家居网关”就是AI Gateway。AI Gateway本质上是一个独立的、专门用于处理AI模型请求的中间层服务。它扮演着“翻译官”和“调度员”的角色对上游的老Java 8应用它提供简单、稳定的接口通常是HTTP/RESTful对下游各式各样的AI模型服务可能是OpenAI、国内大模型、或自研模型它负责协议转换、请求路由、负载均衡、鉴权、限流、监控和降级。我们的老系统完全不需要知道背后是GPT-4还是文心一言它只需要像调用一个普通内部接口一样把问题抛给AI Gateway然后等待结果就行。这个方案最大的吸引力在于解耦和非侵入。老系统继续跑在它熟悉的Java 8环境里所有与AI相关的复杂性、版本依赖、网络策略、密钥管理都被隔离到了AI Gateway这一层。这不仅保护了核心业务的稳定性也为未来AI能力的迭代和切换留下了巨大的灵活性。今天用A模型明天换B模型对老系统来说可能就是改一个配置项或者完全无感。2. 核心架构设计与选型考量2.1 为什么是“旁路接入”而非“直接集成”在深入技术细节前我们必须先厘清架构选择的根本原因。对于Java 8老系统直接集成AI SDK的路基本被堵死了。以Spring AI为例它最低要求Spring Boot 3.x而Spring Boot 3.x又强制要求JDK 17。这不仅仅是一个版本号的问题背后涉及的是整个生态链的断裂依赖库冲突、框架行为变更、甚至底层API的差异。强行升级带来的测试和验证工作量是灾难性的。因此“旁路接入”不是一种妥协而是针对这种特定约束的最优解。它的核心思想是将变化封装在边界之外。我们通过引入一个独立的服务AI Gateway在系统边界处建立一道“防火墙”所有新的、变化快的、依赖复杂的技术栈都被限制在这道防火墙之后。老系统与AI Gateway之间的交互采用最保守、最稳定的协议和格式比如HTTP/1.1和JSON。这种架构带来了几个关键优势技术栈隔离AI Gateway可以用任何合适的语言和框架开发如Go、Python、Java 17享受最新的生态红利而老系统安然无恙。风险可控AI Gateway的发布、回滚、扩容都与核心业务系统分离即使Gateway出问题也有熔断机制保证不影响主流程。能力聚合与优化Gateway可以统一对接多个AI服务商实现负载均衡和故障转移可以集成提示词工程、上下文管理、结果后处理等通用能力避免每个应用重复造轮子。安全与治理所有对外的AI API调用收敛到Gateway便于统一做权限校验、访问审计、流量控制和成本核算。2.2 AI Gateway的核心功能组件设计一个能满足生产级要求的AI Gateway绝不是简单的HTTP代理。我们需要为其设计清晰的功能模块。下图勾勒了其核心组件与数据流注此处用文字描述架构图实际部署时可使用绘图工具1. 接入层 (API Gateway Core)这是对老系统暴露的界面。我们选择RESTful API因为它对Java 8的HttpClient或RestTemplate支持最为成熟。需要设计清晰、版本化的API路径例如/v1/chat/completions。这一层负责基础的HTTP协议处理、请求/响应序列化与反序列化。2. 管控层 (Control Plane)这是Gateway的大脑负责所有控制逻辑。认证鉴权 (AuthN/AuthZ)验证来自老系统的请求是否合法。通常采用API Key或JWT令牌的方式。Gateway维护一个白名单或与公司的统一权限中心同步。限流熔断 (Rate Limiting Circuit Breaker)防止某个应用或用户过度消耗AI资源。需要针对不同模型、不同API设置不同的限流规则。熔断机制在检测到下游AI服务不稳定时快速失败避免线程池被拖垮。路由与负载均衡 (Router LB)根据配置将请求分发到不同的AI服务提供商如公司内首选模型A备选模型B或同一提供商的不同端点。支持基于内容、权重或哈希的路由策略。提示词管理 (Prompt Management)将业务参数如“生成一段风险说明”与具体的、优化过的提示词模板结合。模板可以存储在数据库或配置中心支持动态更新避免将提示词硬编码在老系统或Gateway代码中。3. 执行层 (Execution Plane)这是Gateway的双手负责与下游AI服务交互。模型适配器 (Model Adapter)这是最关键的部分。每个支持的AI服务OpenAI API、Azure OpenAI、Anthropic Claude、国内大模型API等都需要一个适配器将Gateway内部统一的请求格式转换为对应服务商要求的特定格式包括HTTP头、JSON结构、甚至SSE流式响应处理。HTTP客户端池 (Http Client Pool)配置高性能、带连接池的HTTP客户端如Java的AsyncHttpClient或OkHttpGo的net/http包优化设置合理的超时时间、重试策略对于可重试的错误码如429、502。流式响应处理 (Streaming Response Handling)对于需要实时逐字返回的聊天场景Gateway需要正确处理Server-Sent Events (SSE)或类似流式协议并将数据流透明地转发给老系统。这对Java 8客户端可能是个挑战需要确保客户端库支持分块传输编码。4. 可观测层 (Observability)没有监控线上系统就是盲人骑瞎马。日志 (Logging)结构化记录每个请求的元数据请求ID、用户、模型、token用量、耗时、状态码便于问题追踪和审计。指标 (Metrics)暴露关键指标如请求量、成功率、平均响应时间、token消耗速率并集成到PrometheusGrafana中。分布式追踪 (Tracing)将请求的Trace ID从老系统传递到Gateway再传递到下游AI服务实现全链路追踪方便定位性能瓶颈。2.3 技术选型自研 vs 开源 vs 云服务明确了架构接下来就是技术实现路径的选择。1. 自研Gateway这是最灵活、最能贴合自身业务需求的方案。你可以用Spring Boot 3JDK 17或更轻量的Micronaut、Quarkus来构建也可以用Go高性能、部署简单或Python快速原型来写。优势完全自主可控深度定制能与现有基础设施无缝集成。劣势需要投入开发和运维成本需要自行实现上述所有核心组件有一定技术门槛。适合场景AI能力是核心业务组成部分有较强的研发团队对定制化、安全性和成本控制要求极高。2. 采用开源AI Gateway社区有一些现成的项目如AI Gateway by Portkey、OpenAI Proxy的各种变种等。它们通常已经实现了多模型路由、密钥管理、缓存等基础功能。优势开箱即用快速启动社区支持。劣势功能可能不符合所有需求定制化修改需要理解其代码性能和稳定性需要自行验证。适合场景希望快速搭建原型或团队资源有限且开源项目的功能基本满足需求。3. 使用云服务商的API Gateway产品像AWS API Gateway、Azure API Management等它们本身是成熟的API网关可以通过编写Lambda函数或插件来实现AI模型路由的逻辑。优势免运维高可用弹性伸缩自带强大的监控、安全和限流能力。劣势成本较高按调用次数和流量计费 vendor lock-in供应商锁定对于复杂AI逻辑如提示词工程的实现可能不够灵活。适合场景业务主要在单一云平台上且希望最大化减少运维负担。对于我们这个Java 8老系统场景我个人的建议是如果团队有足够的后端开发能力优先考虑自研。因为“旁路接入”的核心诉求就是深度可控和灵活集成自研能最好地满足这一点。开源方案可以作为参考或初期原型但生产环境可能需要大量改造。云服务方案则引入了新的依赖可能把“Java 8升级问题”转化成了“云服务依赖问题”需要谨慎评估。3. 老系统侧最小化集成改造实操现在我们把视角切回老Java 8系统。我们的目标是用最小的改动安全可靠地调用AI Gateway。3.1 客户端库选择与封装Java 8环境下我们通常使用HttpURLConnection、Apache HttpClient或OkHttp。综合性能和易用性OkHttp 3.x是一个优秀的选择它对Java 8有良好支持且API现代、功能强大。但是我们不建议在业务代码中直接散布OkHttp的调用逻辑。最佳实践是封装一个专用的AI客户端SDK。这个SDK内部依赖OkHttp但对上层业务暴露简洁的、领域相关的接口。// 示例一个极简的AIGatewayClient封装 public class AIGatewayClient { private final OkHttpClient httpClient; private final String gatewayBaseUrl; private final String apiKey; public AIGatewayClient(String gatewayBaseUrl, String apiKey) { this.gatewayBaseUrl gatewayBaseUrl; this.apiKey apiKey; this.httpClient new OkHttpClient.Builder() .connectTimeout(10, TimeUnit.SECONDS) // 连接超时 .writeTimeout(30, TimeUnit.SECONDS) // 写超时发送请求体 .readTimeout(60, TimeUnit.SECONDS) // 读超时等待响应AI请求可能较长 .retryOnConnectionFailure(true) // 连接失败重试 .build(); } public String chatCompletion(ChatRequest request) throws IOException { // 1. 构建JSON请求体 MediaType JSON MediaType.parse(application/json; charsetutf-8); String jsonBody new Gson().toJson(request); // 使用Gson或Jackson RequestBody body RequestBody.create(jsonBody, JSON); // 2. 构建HTTP请求 Request httpRequest new Request.Builder() .url(gatewayBaseUrl /v1/chat/completions) .addHeader(Authorization, Bearer apiKey) // 传递API Key .addHeader(Content-Type, application/json) .post(body) .build(); // 3. 同步执行请求异步示例见下文 try (Response response httpClient.newCall(httpRequest).execute()) { if (!response.isSuccessful()) { throw new IOException(Unexpected code response , body: response.body().string()); } // 4. 解析响应 String responseBody response.body().string(); ChatResponse chatResponse new Gson().fromJson(responseBody, ChatResponse.class); return chatResponse.getChoices().get(0).getMessage().getContent(); } } }注意超时设置是关键AI模型生成响应的时间波动很大readTimeout必须设置得足够长比如60-120秒但同时也要在Gateway和客户端设置总体超时防止线程被永远阻塞。更健壮的做法是使用异步调用。3.2 异步调用与线程池隔离同步调用会阻塞业务线程。如果AI服务响应慢大量并发请求可能耗尽Web容器如Tomcat的线程池导致整个应用瘫痪。因此必须采用异步调用并进行线程池隔离。我们可以利用Java 8的CompletableFuture来封装异步操作并使用一个独立的、有界队列的线程池来执行这些IO密集型的AI调用。public class AsyncAIGatewayClient { private final AIGatewayClient syncClient; private final ExecutorService aiExecutorService; public AsyncAIGatewayClient(String gatewayBaseUrl, String apiKey) { this.syncClient new AIGatewayClient(gatewayBaseUrl, apiKey); // 创建一个专用的、资源受限的线程池 this.aiExecutorService new ThreadPoolExecutor( 5, // 核心线程数 20, // 最大线程数 60L, TimeUnit.SECONDS, // 空闲线程存活时间 new LinkedBlockingQueue(100), // 有界队列防止内存溢出 new ThreadFactoryBuilder().setNameFormat(ai-call-%d).build(), new ThreadPoolExecutor.CallerRunsPolicy() // 拒绝策略由调用者线程执行 ); } public CompletableFutureString chatCompletionAsync(ChatRequest request) { return CompletableFuture.supplyAsync(() - { try { return syncClient.chatCompletion(request); } catch (IOException e) { throw new CompletionException(e); // 将受检异常包装为非受检异常 } }, aiExecutorService); } }在业务服务中你可以这样使用public class CustomerService { private AsyncAIGatewayClient aiClient; public void handleCustomerInquiry(String question) { ChatRequest req new ChatRequest(你是一个客服助手..., question); aiClient.chatCompletionAsync(req) .thenAccept(answer - { // 成功回调将AI回答存入数据库或发送给用户 log.info(AI回复: {}, answer); // 注意这里可能不在原始请求线程上下文中涉及事务、会话等需小心处理 }) .exceptionally(ex - { // 失败回调记录日志返回兜底话术 log.error(调用AI服务失败, ex); return null; }); // 主线程立即返回不会被阻塞 } }线程池参数调优心得corePoolSize和maximumPoolSize取决于你的AI Gateway和下游服务的QPS容量。从小开始如5/20根据监控指标逐步调整。workQueue一定要用有界队列如LinkedBlockingQueue(100)无界队列在突发流量下可能导致内存溢出。RejectedExecutionHandler推荐用CallerRunsPolicy当队列满时让调用者线程自己执行任务这是一种平滑的降级虽然会拖慢调用者但保证了任务不丢失不会抛出令人措手不及的异常。3.3 配置外部化与启动初始化API Key、Gateway地址等配置信息绝对不要硬编码。应该放在应用外部的配置文件中如application.properties或application.yml或更专业的配置中心如Apollo、Nacos里。# application.yml ai: gateway: base-url: ${AI_GATEWAY_URL:http://localhost:8080} # 支持环境变量覆盖 api-key: ${AI_GATEWAY_API_KEY} timeout: connect: 10000 read: 60000在Spring Boot或传统Spring项目中使用ConfigurationProperties或Value注入这些配置并在配置类中初始化Bean。Configuration ConfigurationProperties(prefix ai.gateway) Data // Lombok注解 public class AIGatewayConfig { private String baseUrl; private String apiKey; private int connectTimeout; private int readTimeout; } Configuration public class AIClientConfiguration { Bean ConditionalOnMissingBean public AIGatewayClient aiGatewayClient(AIGatewayConfig config) { // 使用配置初始化同步客户端 return new AIGatewayClient(config.getBaseUrl(), config.getApiKey()); } Bean ConditionalOnMissingBean public AsyncAIGatewayClient asyncAIGatewayClient(AIGatewayClient aiGatewayClient) { // 初始化异步客户端 return new AsyncAIGatewayClient(aiGatewayClient); } }这样业务代码中只需要Autowired注入AsyncAIGatewayClient即可使用所有复杂的配置和初始化都被隔离在配置层。4. AI Gateway服务侧实现详解现在我们来构建这个关键的中间层。假设我们选择使用Spring Boot 3JDK 17自研因为它生态丰富与我们老系统的技术栈如果是Spring有概念上的延续性。4.1 基础框架搭建与依赖首先创建一个新的Spring Boot 3项目。在pom.xml中我们需要以下核心依赖dependencies !-- Web -- dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency !-- 用于流式响应 -- dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-webflux/artifactId /dependency !-- 参数校验 -- dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-validation/artifactId /dependency !-- 监控 -- dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-actuator/artifactId /dependency dependency groupIdio.micrometer/groupId artifactIdmicrometer-registry-prometheus/artifactId /dependency !-- 高性能HTTP客户端 -- dependency groupIdorg.asynchttpclient/groupId artifactIdasync-http-client/artifactId version2.12.3/version /dependency !-- 配置管理可选如使用Nacos -- !-- dependency ... /dependency -- !-- 工具 -- dependency groupIdorg.projectlombok/groupId artifactIdlombok/artifactId optionaltrue/optional /dependency /dependencies4.2 统一请求/响应体与路由设计定义Gateway内部通用的数据模型这有助于解耦上游请求和下游模型。// 统一聊天请求 Data public class UnifiedChatRequest { NotBlank private String model; // 模型标识如 gpt-3.5-turbo, claude-3-haiku private ListUnifiedMessage messages; private Double temperature; private Integer maxTokens; // ... 其他通用参数 } // 统一消息 Data public class UnifiedMessage { private String role; // system, user, assistant private String content; } // 统一聊天响应 Data public class UnifiedChatResponse { private String id; private String model; private ListUnifiedChoice choices; private UnifiedUsage usage; } Data public class UnifiedChoice { private UnifiedMessage message; private Integer index; private String finishReason; } Data public class UnifiedUsage { private Integer promptTokens; private Integer completionTokens; private Integer totalTokens; }设计清晰的控制器对外提供API。RestController RequestMapping(/v1) Slf4j public class ChatController { Autowired private ChatService chatService; PostMapping(/chat/completions) public UnifiedChatResponse createChatCompletion(Valid RequestBody UnifiedChatRequest request, RequestHeader(Authorization) String authHeader) { // 1. 认证鉴权 (在Filter或Interceptor中完成更佳) // 2. 调用核心服务 return chatService.createCompletion(request); } // 流式响应端点 PostMapping(value /chat/completions/stream, produces MediaType.TEXT_EVENT_STREAM_VALUE) public FluxServerSentEventString streamChatCompletion(Valid RequestBody UnifiedChatRequest request, RequestHeader(Authorization) String authHeader) { return chatService.createCompletionStream(request) .map(content - ServerSentEvent.builder(content).build()); } }4.3 核心服务层路由与适配器模式ChatService是核心它负责路由决策和调用具体的模型适配器。这里使用策略模式或适配器模式来管理不同的AI提供商。Service Slf4j public class ChatService { Autowired private ModelAdapterFactory adapterFactory; // 适配器工厂 Autowired private RateLimiterService rateLimiterService; // 限流服务 Autowired private MetricsService metricsService; // 指标服务 public UnifiedChatResponse createCompletion(UnifiedChatRequest request) { // 1. 限流检查 if (!rateLimiterService.tryAcquire(request.getModel())) { throw new RateLimitExceededException(Rate limit exceeded for model: request.getModel()); } // 2. 根据模型标识获取对应的适配器 ModelAdapter adapter adapterFactory.getAdapter(request.getModel()); if (adapter null) { throw new ModelNotSupportedException(Model not supported: request.getModel()); } long startTime System.currentTimeMillis(); try { // 3. 调用适配器执行请求 UnifiedChatResponse response adapter.chat(request); // 4. 记录成功指标 metricsService.recordSuccess(request.getModel(), response.getUsage(), System.currentTimeMillis() - startTime); return response; } catch (Exception e) { // 5. 记录失败指标 metricsService.recordFailure(request.getModel(), e.getClass().getSimpleName()); log.error(Chat completion failed for model: {}, request.getModel(), e); throw new GatewayInternalException(AI service call failed, e); } } // 流式处理类似但返回FluxString public FluxString createCompletionStream(UnifiedChatRequest request) { // ... 实现逻辑通常涉及将下游的SSE流转换为Flux } }ModelAdapterFactory负责管理和提供适配器实例。适配器接口定义public interface ModelAdapter { boolean supports(String model); UnifiedChatResponse chat(UnifiedChatRequest request) throws IOException; FluxString chatStream(UnifiedChatRequest request); }一个具体的OpenAI适配器示例Component Slf4j public class OpenAIModelAdapter implements ModelAdapter { private final AsyncHttpClient asyncHttpClient; private final String apiBaseUrl; private final String apiKey; public OpenAIModelAdapter(Value(${ai.provider.openai.base-url}) String baseUrl, Value(${ai.provider.openai.api-key}) String apiKey) { this.apiBaseUrl baseUrl; this.apiKey apiKey; this.asyncHttpClient Dsl.asyncHttpClient(); } Override public boolean supports(String model) { return model.startsWith(gpt-); // 支持所有GPT模型 } Override public UnifiedChatResponse chat(UnifiedChatRequest unifiedRequest) throws IOException { // 1. 转换请求格式 UnifiedChatRequest - OpenAI格式的请求体 OpenAIChatRequest openaiRequest convertToOpenAIRequest(unifiedRequest); // 2. 构建AsyncHttpClient请求 Request request Dsl.post(apiBaseUrl /v1/chat/completions) .addHeader(Authorization, Bearer apiKey) .addHeader(Content-Type, application/json) .setBody(new Gson().toJson(openaiRequest)) .build(); // 3. 执行同步调用也可用异步 ListenableFutureResponse future asyncHttpClient.executeRequest(request); try { Response response future.get(60, TimeUnit.SECONDS); // 设置超时 if (response.getStatusCode() ! 200) { throw new IOException(OpenAI API error: response.getResponseBody()); } // 4. 转换响应格式 OpenAI响应 - UnifiedChatResponse OpenAIChatResponse openaiResponse new Gson().fromJson(response.getResponseBody(), OpenAIChatResponse.class); return convertToUnifiedResponse(openaiResponse, unifiedRequest.getModel()); } catch (InterruptedException | ExecutionException | TimeoutException e) { throw new IOException(Failed to call OpenAI API, e); } } // convertToOpenAIRequest, convertToUnifiedResponse 等方法省略... // 流式处理chatStream方法实现类似但需要处理SSE流 }4.4 关键生产特性实现1. 认证与鉴权在WebMvcConfigurer或使用Filter实现。通常校验请求头中的Authorization: Bearer api_key并与预配置的密钥或从配置中心获取的密钥列表进行比对。更复杂的可以集成OAuth2或公司统一SSO。Component public class ApiKeyAuthFilter extends OncePerRequestFilter { Override protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain chain) throws ServletException, IOException { String apiKey extractApiKey(request); if (!isValidApiKey(apiKey)) { response.setStatus(HttpStatus.UNAUTHORIZED.value()); response.getWriter().write(Invalid or missing API Key); return; } // 可以将用户/应用信息存入SecurityContext或请求属性供后续使用 chain.doFilter(request, response); } // ... extractApiKey, isValidApiKey 实现 }2. 限流与熔断使用Resilience4j或Sentinel库。可以为不同模型或不同客户端设置不同的限流规则。// 使用Resilience4j RateLimiter Bean public RateLimiterRegistry rateLimiterRegistry() { RateLimiterConfig config RateLimiterConfig.custom() .limitForPeriod(100) // 每秒100个请求 .limitRefreshPeriod(Duration.ofSeconds(1)) .timeoutDuration(Duration.ofMillis(100)) // 等待令牌的超时时间 .build(); return RateLimiterRegistry.of(config); } // 在Service中使用 private final RateLimiter rateLimiter; public ChatService(RateLimiterRegistry registry) { this.rateLimiter registry.rateLimiter(openai-gpt4); } public UnifiedChatResponse createCompletion(...) { // 在调用适配器前 boolean permission rateLimiter.acquirePermission(1); if (!permission) { throw new RateLimitExceededException(...); } // ... }熔断器CircuitBreaker配置类似当下游服务失败率达到阈值时快速失败直接返回兜底响应或错误给下游服务恢复的时间。3. 监控与日志利用Spring Boot Actuator暴露/actuator/prometheus端点在MetricsService中记录自定义指标。Service public class MetricsService { private final MeterRegistry meterRegistry; private final Counter successCounter; private final Counter failureCounter; private final Timer requestTimer; public MetricsService(MeterRegistry meterRegistry) { this.meterRegistry meterRegistry; this.successCounter Counter.builder(ai.gateway.requests) .tag(status, success) .register(meterRegistry); this.failureCounter Counter.builder(ai.gateway.requests) .tag(status, failure) .register(meterRegistry); this.requestTimer Timer.builder(ai.gateway.latency) .register(meterRegistry); } public void recordSuccess(String model, UnifiedUsage usage, long durationMs) { successCounter.increment(); requestTimer.record(durationMs, TimeUnit.MILLISECONDS); // 记录token用量 meterRegistry.counter(ai.gateway.tokens, model, model, type, prompt).increment(usage.getPromptTokens()); meterRegistry.counter(ai.gateway.tokens, model, model, type, completion).increment(usage.getCompletionTokens()); } }日志方面使用MDCMapped Diagnostic Context记录请求ID确保同一个请求在Gateway内部所有日志中的关联性。5. 部署、测试与运维避坑指南5.1 部署架构与配置AI Gateway作为独立服务建议部署在Kubernetes或Docker Swarm等容器化平台上便于弹性伸缩。高可用至少部署2个实例前面通过负载均衡器如Nginx, Kubernetes Service分发流量。配置分离所有敏感信息API Keys、模型端点URL和动态配置限流阈值、路由规则必须从代码中分离使用配置中心或Kubernetes ConfigMap/Secret管理。健康检查暴露/actuator/health端点配置就绪性和存活探针确保负载均衡器只会将流量导到健康的实例。资源限制为容器设置合理的CPU和内存限制。AI Gateway是IO密集型网络请求而非CPU密集型但需要预留足够内存处理JSON和并发请求。5.2 全链路测试要点测试必须覆盖从老系统到AI Gateway再到下游AI服务的完整链条。单元测试针对适配器、服务类、工具类进行测试使用Mockito等工具模拟HTTP客户端。集成测试Gateway API测试使用TestRestTemplate或RestAssured测试Controller层验证认证、参数校验、基本路由功能。适配器集成测试针对每个ModelAdapter可以连接一个测试用的Mock AI服务比如用WireMock模拟OpenAI API的响应验证请求转换和响应解析逻辑是否正确。切记不要直接调用真实付费API进行自动化测试端到端E2E测试在预发布环境部署完整的Gateway让老系统的测试用例真实调用Gateway验证整个流程。重点测试超时与重试模拟下游服务响应慢或网络抖动看Gateway的超时和重试机制是否生效。熔断与降级模拟下游服务持续失败看熔断器是否会打开以及是否有合理的降级响应如返回一个默认的提示语。流式传输测试SSE流式接口是否能稳定、完整地传输数据。压力测试使用JMeter或Gatling对Gateway进行压测找出其性能瓶颈是线程池是下游服务还是网络带宽并确定其最大稳定QPS为限流配置提供依据。5.3 常见问题与排查实录在实际落地过程中我们踩过不少坑这里分享几个典型的问题一老系统调用Gateway超时但Gateway日志显示成功。排查这是最经典的问题。首先检查老系统客户端的readTimeout设置是否小于Gateway处理请求的总时间包括下游AI模型生成时间。然后检查网络链路是否存在防火墙、代理或负载均衡器有更短的超时设置。最后在Gateway侧增加请求生命周期日志收到请求、开始处理、转发下游、收到下游响应、返回客户端精确计算每个阶段耗时。解决调整客户端和中间网络设备的超时。更重要的是在Gateway实现异步响应。对于长耗时的AI请求Gateway可以先返回一个202 Accepted和一个任务ID然后通过WebSocket或让客户端轮询另一个接口来获取结果。这能彻底解决HTTP超时问题。问题二下游AI服务返回429Rate Limit错误导致客户端请求失败。排查检查是否为所有客户端共享了同一个下游API Key导致总额度迅速耗尽。解决在Gateway层面实现更精细化的限流和队列管理。例如为每个下游API Key设置独立的限流器并将超出速率的请求放入一个延迟队列稍后重试而不是直接向客户端返回错误。同时考虑接入多个AI服务商作为备选当一个触发限流时自动切换。问题三流式响应SSE中途断开客户端收不到完整回复。排查可能是Gateway与下游AI服务之间的连接不稳定也可能是Gateway在转发流数据时缓冲区处理不当还可能是客户端在处理流时提前关闭了连接。解决确保Gateway使用的HTTP客户端如AsyncHttpClient, WebClient正确配置了SSE支持并且响应体是以流的方式处理而不是一次性加载到内存。在Gateway增加心跳机制在流式传输间歇发送“: ping”注释行保持连接活跃。客户端需要实现断线重连和续传逻辑例如携带上一个收到的消息ID重新请求。问题四Token消耗费用飙升成本失控。排查缺乏监控和预警。某些提示词可能意外生成了极长的内容或者被恶意调用。解决在Gateway的UnifiedUsage中记录每次请求的token消耗并实时上报到监控系统。设置成本告警规则例如“每分钟总消耗token数超过X”或“单个应用日均消耗超过Y”。在Gateway层面对请求的max_tokens参数设置上限防止单次请求消耗过多token。实现基于预算的配额管理为每个应用或团队分配月度token预算接近时告警耗尽时拒绝服务。问题五提示词Prompt管理混乱修改需要重启服务。解决切勿将提示词模板硬编码在代码或Gateway的配置文件中。应该建立一个简单的提示词管理服务可以是一个独立的微服务或者就利用现有的配置中心将提示词模板存储为可版本化的内容如数据库、Git仓库。Gateway在启动时加载并监听变更事件。业务请求中只需传递一个“提示词模板ID”和对应的参数由Gateway动态获取并渲染模板。这极大提升了运营效率。通过这套“旁路接入AI Gateway”的方案我们成功让那个坚如磐石的Java 8老系统在几乎零风险的情况下接入了最前沿的AI能力。整个过程中老系统就像只是多调用了一个普通的内部REST服务而所有的复杂性、可变性和技术债都被牢牢地封装在了那个用JDK 17编写的、可独立演进和部署的AI Gateway之后。这种架构上的清晰隔离不仅解决了眼前的问题也为未来更多异构技术的集成提供了一个可复用的范式。