PHP SaaS AI 异步架构：事件驱动落地实战

Tinywan

发布于 2026-09-15 14:45:54

330

事件驱动架构——异步 SaaS AI 的核心

想象一下你正在使用一款 AI 聊天应用，发送了一个稍复杂的问题后，界面直接卡住 15 秒，只有一个加载圈在转，没有任何进度提示。你甚至会开始怀疑：程序到底是在处理，还是已经崩了？

如果在构建 SaaS AI 产品时，默认把调用 AI 服务当成普通 HTTP 请求，就会出现这种糟糕的体验。现实中，一次大模型调用的耗时从 2 秒到 30 秒不等，取决于提示词长度和服务端负载。如果全程保持 HTTP 连接等待，Web 服务器、负载均衡器甚至浏览器本身都会触发超时。

在本系列已经介绍的五种架构模式中，事件驱动架构（EDA） 最直接地解决了 SaaS AI 产品的核心痛点：如何让一个缓慢、耗时不可控的流程，不至于让用户对着空白屏幕干等。

什么是事件驱动架构

在看代码之前，我们先用一个简单的类比理清概念。

想象你在餐厅用餐：你向服务员下单（这就像一次 HTTP 请求），服务员不会站在你面前等 20 分钟直到菜做好。他们会把订单写在小票上，传到后厨，然后去服务其他桌。后厨根据小票做菜，做好之后通知服务员取餐，最后服务员才把菜送到你桌上。

这就是事件驱动架构的核心逻辑：系统各组件之间不是同步等待对方完成，而是通过「消息」——在 Laravel 中我们称之为事件（Event）——在状态变化时互相通知。监听该消息的组件（称为监听器 Listener）会在消息到达后执行对应逻辑，发起请求的一方全程不需要阻塞等待。

三个核心组件

● 事件（Event）：对「某件事已经发生」的通知。例如：PromptSubmitted（用户提交了新提示词）、AiResponseGenerated（AI 已生成回复）。

● 监听器（Listener）：监听特定事件并在触发时执行逻辑的代码。一个事件可以对应多个监听器，分别执行不同操作。

● 队列任务（Queue Job）：在后台运行的任务，与当前 HTTP 请求完全解耦。正是它让调用 AI 这类慢操作不会拖慢用户界面。

和本系列之前讲的 Action、Service、Repository、DTO、值对象不同，那些模式关注的是代码的组织方式；而事件驱动架构关注的是系统内各组件随时间推进的通信方式——也正因如此，它才能让后端调用耗时几十秒的 SaaS AI 产品，在用户感知上依然流畅响应。

两条并行的执行流

还记得系列第一篇里的架构图吗？现在我们来拆解最核心的部分：同步流（快速响应，立刻给用户反馈）与异步流（后台运行，处理重逻辑） 并行工作。

同步流 —— 立即响应用户

HTTP 请求 ↓SubmitPromptAction（提交提示词动作） ↓将用户提交的消息写入数据库 ↓触发事件：PromptSubmitted ↓立即返回 HTTP 201 响应（用户无需等待 AI 处理）

异步流 —— 后台静默执行

PromptSubmitted 事件（由同步流触发） ↓监听器：DispatchAiProviderJob（分发 AI 调用任务） ↓队列：CallAiProviderJob（执行 AI 调用任务） ↓调用 AI 服务商接口（耗时 2~30 秒） ↓触发事件：AiResponseGenerated ↓监听器 1：将回复存入数据库监听器 2：通过 WebSocket 推送到前端监听器 3：记录 Token 用量用于计费

用户在毫秒级就能收到 HTTP 201 响应，而不是等到 AI 回复完成。无论 AI 实际耗时 3 秒还是 25 秒，前端都会通过 WebSocket 收到推送更新，无需轮询，也不用在同一个请求里阻塞等待。

代码实现：从事件到广播

第一步：定义事件

namespace App\Domain\Chat\Events; use App\Domain\Chat\Models\Conversation;use App\Domain\Chat\Models\Message; class PromptSubmitted{ public function __construct( public readonly Conversation $conversation, public readonly Message $message, ) {}}

第二步：监听器分发队列任务

监听器捕获事件后，将 AI 调用任务投递到队列：

namespace App\Domain\Chat\Listeners; use App\Domain\Chat\Events\PromptSubmitted;use App\Domain\Chat\Jobs\CallAiProviderJob; class DispatchAiProviderJob{ public function handle(PromptSubmitted $event): void { CallAiProviderJob::dispatch( $event->conversation, $event->message, ); }}

第三步：实际调用 AI 的队列任务

这个任务在后台独立运行，与 HTTP 请求完全解耦：

namespace App\Domain\Chat\Jobs; use Illuminate\Bus\Queueable;use Illuminate\Contracts\Queue\ShouldQueue;use Illuminate\Queue\InteractsWithQueue;use App\Domain\Chat\Models\Conversation;use App\Domain\Chat\Models\Message;use App\Domain\Chat\Events\AiResponseGenerated;use App\Domain\Chat\DataTransferObjects\AiResponseDTO; class CallAiProviderJob implements ShouldQueue{ use Queueable, InteractsWithQueue; // 最多重试 3 次，每次退避 5 秒 public int $tries = 3; public int $backoff = 5; public function __construct( public Conversation $conversation, public Message $message, ) {} public function handle(AiProviderRouterService $router): void { // 根据租户解析对应的 AI 服务商 $provider = $router->resolveFor($this->conversation->tenant); $response = $provider->complete( conversation: $this->conversation, prompt: $this->message, ); // AI 回复生成完成，触发事件 event(new AiResponseGenerated($this->conversation, $response)); }}

第四步：多个监听器响应 AI 回复事件

注意这里的设计：一个事件可以触发多个完全独立的监听器，彼此之间无需感知：

namespace App\Domain\Chat\Listeners; use App\Domain\Chat\Events\AiResponseGenerated; // 监听器 1：将 AI 回复存入数据库class SaveAiResponseToDatabase{ public function handle(AiResponseGenerated $event): void { $event->conversation->messages()->create([ 'role' => 'assistant', 'content' => $event->response->content, ]); }} // 监听器 2：将 AI 回复广播到前端class BroadcastAiResponseToFrontend{ public function handle(AiResponseGenerated $event): void { broadcast(new AiResponseReady( $event->conversation->id, $event->response->content, ))->toOthers(); }} // 监听器 3：记录 Token 用量用于计费class RecordTokenUsageForBilling{ public function handle(AiResponseGenerated $event): void { RecordUsageAction::run( $event->conversation->tenant, $event->response->tokenUsage, ); }}

前端只需通过 Laravel Echo 订阅广播频道（底层可使用 Laravel Reverb 或 Pusher），一旦 AiResponseReady 这个广播事件被推送到频道，界面就会实时更新——无需反复轮询服务器询问「处理完了吗」。

故障处理：AI 调用也会失败

用队列任务处理 AI 调用的一大优势：Laravel 原生自带重试机制。但并非所有失败都值得重试——网络超时和 API 密钥错误，显然是两种完全不同的故障。

较新版本的 Laravel 支持将某些异常标记为不可重试，在这个场景下非常实用：如果 AI 服务商因为内容合规拒绝了请求，反复重试只会浪费配额和时间。

use Throwable; public function handle(AiProviderRouterService $router): void{ $provider = $router->resolveFor($this->conversation->tenant); try { $response = $provider->complete($this->conversation, $this->message); event(new AiResponseGenerated($this->conversation, $response)); } catch (ContentPolicyViolationException $e) { // 内容违规：直接标记失败，不再重试 $this->fail($e); } catch (ProviderTimeoutException $e) { // 超时异常：抛出后由队列自动重试 throw $e; }} public function failed(Throwable $exception): void{ // 重试全部耗尽后，触发失败事件通知用户 event(new AiResponseFailed($this->conversation, $exception->getMessage()));}

failed() 方法对 SaaS AI 产品至关重要：当任务彻底失败后，我们依然可以通过事件通知用户，而不是让他们永远等下去。

无需真实等待的异步测试

事件驱动架构还有一个容易被忽略的优势：测试效率会大幅提升——我们完全不需要真实调用 AI，也不用等待队列 Worker 运行。

// 测试：提交提示词后会正确分发 AI 调用任务it('dispatches the AI call job after a prompt is submitted', function () { Event::fake([PromptSubmitted::class]); Bus::fake(); $action = app(SubmitPromptAction::class); $conversation = Conversation::factory()->create(); $action->handle($conversation, new PromptDTO(content: 'Hello')); Event::assertDispatched(PromptSubmitted::class); Bus::assertDispatched(fn (CallAiProviderJob $job) => $job->conversation->is($conversation) && $job->message->content === 'Hello' );}); // 测试：AI 回复事件携带了正确的 Token 用量信息it('carries correct token usage in the AI response event', function () { Event::fake([AiResponseGenerated::class]); $conversation = Conversation::factory()->create(); $response = AiResponseDTO::fromOpenAi($fakePayload, 'gpt-4'); event(new AiResponseGenerated($conversation, $response)); Event::assertDispatched(AiResponseGenerated::class, function ($event) use ($response) { return $event->response->tokenUsage->total() === $response->tokenUsage->total(); });});

Event::fake() 和 Bus::fake() 会阻止监听器和任务的真实执行，我们只需要断言「正确的事件/任务被分发、携带了正确的数据」即可，全程不需要联网，也不需要真实的 AI 接口密钥。

需要避开的常见误区

1. 单个事件挂载过多监听器，导致链路难以追踪 如果一个事件有 8 个监听器，且彼此的执行顺序互相依赖，说明部分逻辑应该合并到同一个监听器，或者下沉到 Service 中。

2. 重试任务忽略幂等性 如果任务执行到一半失败、已经写入了部分数据，重试就可能产生重复数据。务必保证任务可安全地重复执行（例如用 updateOrCreate 替代 create）。

3. 任务彻底失败后不给用户反馈 这是最容易引发用户不满的问题：用户发了消息，后台任务静默失败，没有任何提示，用户只能一直空等。

4. 用事件处理强顺序依赖的流程 事件驱动架构非常适合互相独立的操作（广播、计费、日志可以按任意顺序执行）。但如果流程有严格的先后依赖、后一步依赖前一步的结果，直接放在 Action 里顺序执行会更合适，不要拆成多个事件。

代码目录结构参考

app/ Domain/ Chat/ Events/ PromptSubmitted.php AiResponseGenerated.php AiResponseFailed.php Listeners/ DispatchAiProviderJob.php SaveAiResponseToDatabase.php BroadcastAiResponseToFrontend.php RecordTokenUsageForBilling.php Jobs/ CallAiProviderJob.php

本篇小结

如果整个系列里你只能先落地一种架构模式，首推就是事件驱动架构。

Action、Service、Repository、DTO、值对象能让代码更整洁、更易测试；但事件驱动架构才是让 SaaS AI 产品真正可用的核心——它不会让用户盯着加载圈胡思乱想。

现在我们已经有了清晰的流程：请求快速响应、重逻辑后台处理、完成后实时推送。

本文参与腾讯云自媒体同步曝光计划，分享自微信公众号。

原始发表：2026-08-24，如有侵权请联系 cloudcommunity@tencent.com 删除

异步