事件驱动架构——异步 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 ↓ 立即返回 HTTP201 响应（用户无需等待 AI 处理） |
异步流 —— 后台静默执行
PromptSubmitted 事件（由同步流触发） ↓ 监听器：DispatchAiProviderJob（分发 AI 调用任务） ↓ 队列：CallAiProviderJob（执行 AI 调用任务） ↓ 调用 AI 服务商接口（耗时 2~30 秒） ↓ 触发事件：AiResponseGenerated ↓ 监听器 1：将回复存入数据库 监听器 2：通过 WebSocket 推送到前端 监听器 3：记录 Token 用量用于计费 |
用户在毫秒级就能收到 HTTP 201 响应，而不是等到 AI 回复完成。无论 AI 实际耗时 3 秒还是 25 秒，前端都会通过 WebSocket 收到推送更新，无需轮询，也不用在同一个请求里阻塞等待。
代码实现：从事件到广播
第一步：定义事件
namespaceApp\Domain\Chat\Events; useApp\Domain\Chat\Models\Conversation; useApp\Domain\Chat\Models\Message; classPromptSubmitted { publicfunction__construct( publicreadonly Conversation $conversation, publicreadonly Message $message, ) {} } |
第二步：监听器分发队列任务
监听器捕获事件后，将 AI 调用任务投递到队列：
namespaceApp\Domain\Chat\Listeners; useApp\Domain\Chat\Events\PromptSubmitted; useApp\Domain\Chat\Jobs\CallAiProviderJob; classDispatchAiProviderJob { publicfunctionhandle(PromptSubmitted $event): void { CallAiProviderJob::dispatch( $event->conversation, $event->message, ); } } |
第三步：实际调用 AI 的队列任务
这个任务在后台独立运行，与 HTTP 请求完全解耦：
namespaceApp\Domain\Chat\Jobs; useIlluminate\Bus\Queueable; useIlluminate\Contracts\Queue\ShouldQueue; useIlluminate\Queue\InteractsWithQueue; useApp\Domain\Chat\Models\Conversation; useApp\Domain\Chat\Models\Message; useApp\Domain\Chat\Events\AiResponseGenerated; useApp\Domain\Chat\DataTransferObjects\AiResponseDTO; classCallAiProviderJobimplementsShouldQueue { useQueueable, InteractsWithQueue; // 最多重试 3 次，每次退避 5 秒 publicint$tries = 3; publicint$backoff = 5; publicfunction__construct( public Conversation $conversation, public Message $message, ) {} publicfunctionhandle(AiProviderRouterService $router): void { // 根据租户解析对应的 AI 服务商 $provider = $router->resolveFor($this->conversation->tenant); $response = $provider->complete( conversation: $this->conversation, prompt: $this->message, ); // AI 回复生成完成，触发事件 event(newAiResponseGenerated($this->conversation, $response)); } } |
第四步：多个监听器响应 AI 回复事件
注意这里的设计：一个事件可以触发多个完全独立的监听器，彼此之间无需感知：
namespaceApp\Domain\Chat\Listeners; useApp\Domain\Chat\Events\AiResponseGenerated; // 监听器 1：将 AI 回复存入数据库 classSaveAiResponseToDatabase { publicfunctionhandle(AiResponseGenerated $event): void { $event->conversation->messages()->create([ 'role' => 'assistant', 'content' => $event->response->content, ]); } } // 监听器 2：将 AI 回复广播到前端 classBroadcastAiResponseToFrontend { publicfunctionhandle(AiResponseGenerated $event): void { broadcast(newAiResponseReady( $event->conversation->id, $event->response->content, ))->toOthers(); } } // 监听器 3：记录 Token 用量用于计费 classRecordTokenUsageForBilling { publicfunctionhandle(AiResponseGenerated $event): void { RecordUsageAction::run( $event->conversation->tenant, $event->response->tokenUsage, ); } } |
前端只需通过 Laravel Echo 订阅广播频道（底层可使用 Laravel Reverb 或 Pusher），一旦 AiResponseReady 这个广播事件被推送到频道，界面就会实时更新——无需反复轮询服务器询问「处理完了吗」。
故障处理：AI 调用也会失败
用队列任务处理 AI 调用的一大优势：Laravel 原生自带重试机制。但并非所有失败都值得重试——网络超时和 API 密钥错误，显然是两种完全不同的故障。
较新版本的 Laravel 支持将某些异常标记为不可重试，在这个场景下非常实用：如果 AI 服务商因为内容合规拒绝了请求，反复重试只会浪费配额和时间。
useThrowable; publicfunctionhandle(AiProviderRouterService $router): void { $provider = $router->resolveFor($this->conversation->tenant); try { $response = $provider->complete($this->conversation, $this->message); event(newAiResponseGenerated($this->conversation, $response)); } catch (ContentPolicyViolationException $e) { // 内容违规：直接标记失败，不再重试 $this->fail($e); } catch (ProviderTimeoutException $e) { // 超时异常：抛出后由队列自动重试 throw$e; } } publicfunctionfailed(Throwable$exception): void { // 重试全部耗尽后，触发失败事件通知用户 event(newAiResponseFailed($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, newPromptDTO(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(newAiResponseGenerated($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 产品真正可用的核心——它不会让用户盯着加载圈胡思乱想。
现在我们已经有了清晰的流程：请求快速响应、重逻辑后台处理、完成后实时推送。
