本节重点

任何项目都是先完成再完⁡美，经过的学习，我们的 AI 零代码应用生成‍平台已经具备了完整的功能。但是，作为一个有追‍求的程序员，怎么能满足于 “能跑就行” 呢？⁡这一节咱们就从多个维度对系统进行全面优化，让‏它从玩具项目真正蜕变为生产级别的应用。

本节将从以下几个方面进行系统优化：

• 性能优化：
  • AI 并发调用：解决目前只能同时处理一个 AI 请求的瓶颈问题
  • Redis 缓存：通过缓存主页精选内容提升响应速度
• 实时性优化：
  • 实时浏览：确保用户生成网站后能立刻看到最新效果
• 安全性优化：
  • 流量保护：为 AI 对话接口实现限流限频机制
  • Prompt 审查：防范恶意输入和注入攻击
• 稳定性优化：
  • 重试策略：通过护轨机制提升系统容错能力
  • 工具调用优化：解决 AI 工具调用的无限循环问题
• 成本优化：
  • AI 大模型成本控制：根据不同场景选择合适的模型

一、性能优化

AI 并发调用问题

问题分析

在实际使用过程中，⁡我们发现了一个严重的性能瓶颈：当多‍个用户同时使用平台时，只有第一个用‍户的 AI 请求能够正常处理，后续⁡的请求都会被阻塞，需要等待前面的请‏求完全处理完毕后才能开始执行。

用户量较少时可能不⁡太明显，但随着平台用户的增长，这个问‍题会变得越发严重。想象一下，如果有 ‍10 个用户同时想要生成网站，第 1⁡0 个用户可能需要等待几分钟以上才能‏看到 AI 开始响应，肯定不行。

那么，这个问题的根源在哪里呢？

经过分析，发现问题出在 AI 大模型的 ChatModel 采用了单例模式。虽然 StreamingChatModel 返回的是 Flux 响应式流，表面上看起来是异步的，但其底层的 SpringRestClient.execute() 方法内部实际上是同步解析数据流的，导致了串行执行问题。

完整调用链如图：

为了验证这个分析，我写了个单元测试，发现即使是不同的 AI Service 实例，只要使用的是同一个 ChatModel，依然会出现阻塞现象。

解决方案 - 多例模式

寻找解决方案的过程中，我发现 LangChain4j 官方提到，使用不同的对话记忆 id 就能解决并发问题（参考 GitHub Issue #2755）。但其实这只是一个敷衍的回答，经过实际测试，我们发现使用不同的 id 虽然能够区分不同用户的对话，但并没有解决并发阻塞的核心问题。