首版架构的取舍

首版架构的取舍

说明：本文把微前端中的容量与权限问题抽象为示例。具体隔离策略、时延目标和成本预算需要按宿主及子应用契约验证。

在微前端架构（Micro-frontends）下接入大模型能力时，技术团队极易忽视一个致命隐患：大模型 upstream API 的超时与报错，会顺着微应用之间的事件总线（Event Bus）蔓延至整个基座应用。

某次线上大促期间，第三方 LLM 供应商因流量激增出现了长达 15 分钟的 API 504 Gateway Timeout。由于子应用 A 在请求 AI 生成时没有设置离线熔断与超时下发，导致主线程一直挂起等待。

进而，基座应用的全局 Event Loop 队列堆积，其余未接入 AI 的子应用 B（订单）和子应用 C（支付）也出现了无法响应点击的假死状态。

“一个智能化小功能故障，挂掉整个微前端大盘”——这是极度不合格的工程落地。模型出错是确定会发生的事实，如何在 100 毫秒内完成快速优雅降级，是微前端工程化应封死的铁门。

1. 灾难传播链：从 upstream 504 到主线程全局假死

我们拉出了当天的微前端基座日志与微应用运行埋点，还原了这场连锁事故的全过程。

# 提取微前端基座中未捕获的子应用 Promise 挂起状态 cat /var/log/micro-frontend/base-app.log | grep -E "MicroAppError|UnhandledRejection|Timeout" | tail -n 15

控制台捕获到的错误轨迹展示了隔离机制的缺失：

[14:32:05] [SubApp: AI-Assistant] Requesting /api/v1/chat/completions (Pending...) [14:32:35] [SubApp: AI-Assistant] Request standard timeout (30s) exceeded. No fallback provided. [14:32:35] [BaseApp: EventBridge] Uncaught PromiseRejection in SubApp AI-Assistant. Main thread blocked. [14:32:40] [SubApp: OrderCenter] Event 'USER_CHECKOUT' handler failed to execute within Frame Budget.

问题症结在于：

1. 缺乏微应用维度的熔断孤立（Circuit Breaker）：将 AI 请求的生命周期与子应用的 DOM 生命周期绑定，导致请求挂起时，子应用卸载逻辑被阻塞。
2. 缺乏静态规则降级底座（Fallback Standard Component）：大模型出错时，前端抛出裸露的 500 错误弹窗，而不是瞬间切换回标准的规则配置界面。
3. 缺少统一的 SDK 降级网关：每个微应用各自用fetch直接请求 AI 接口，降级逻辑五花八门。

2. 隔离与三级降级架构：基座侧代理拦截

为了确保“AI 模块可以崩，微前端大盘不宜挂”，我们在微前端基座侧设计了统一的 AI 状态隔离与三级自动降级网关。

降级体系明确划分了三级确定性防御：

• Level 1 语义缓存降级：若模型超时，优先提取本地 IndexedDB 存储的历史相似请求成功响应。
• Level 2 确定性规则降级：若无缓存，直接跳过模型，由前端确定性 JSON Schema 静态表单引擎渲染标准交互组件。
• Level 3 隔离性组件降级：若发生致命崩溃，微前端基座直接卸载 AI 子应用 DOM 节点，降级为微弱图标提示“AI 服务维护中，已切换为经典模式”。

3. 示例性代码：微前端基座的高可用 AI 降级代理 SDK

我们使用 TypeScript 在微前端基座层实现了一套具有状态隔离与智能降级的 Fetch 代理拦截器：

export interface AiRequestOptions { subAppId: string; endpoint: string; payload: any; timeoutMs?: number; staticFallbackData: any; } export interface CircuitBreakerState { failures: number; lastFailureTime: number; isOpen: boolean; } export class MicroAppAiGateway { private static instance: MicroAppAiGateway; private breakerMap: Map<string, CircuitBreakerState> = new Map(); private maxFailures = 3; private coolDownMs = 30000; // 熔断冷却时间 30 秒 public static getInstance(): MicroAppAiGateway { if (!MicroAppAiGateway.instance) { MicroAppAiGateway.instance = new MicroAppAiGateway(); } return MicroAppAiGateway.instance; } /** * 微前端子应用统一 AI 请求入口（带强隔离与自动降级） */ public async requestAiService<T>(options: AiRequestOptions): Promise<{ data: T; isDegraded: boolean; reason?: string }> { const { subAppId, endpoint, payload, timeoutMs = 3000, staticFallbackData } = options; const breaker = this.getBreakerState(subAppId); // 1. 判断熔断器状态 if (breaker.isOpen) { if (Date.now() - breaker.lastFailureTime > this.coolDownMs) { // 半开状态尝试恢复 breaker.isOpen = false; breaker.failures = 0; } else { console.warn(`[AI 隔离网关] 子应用 ${subAppId} 的 AI 服务已处于熔断状态，直接触发 Level 3 静态降级`); return { data: staticFallbackData, isDegraded: true, reason: 'CircuitBreakerOpen' }; } } // 2. 带硬性 Timeout 的 Fetch 请求 const controller = new AbortController(); const timer = setTimeout(() => controller.abort(), timeoutMs); try { const response = await fetch(endpoint, { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify(payload), signal: controller.signal, }); clearTimeout(timer); if (!response.ok) { throw new Error(`Upstream HTTP Error: ${response.status}`); } const json = await response.json(); // 成功：重置熔断计数 breaker.failures = 0; return { data: json as T, isDegraded: false }; } catch (err) { clearTimeout(timer); // 记录失败并更新熔断状态 breaker.failures += 1; breaker.lastFailureTime = Date.now(); if (breaker.failures >= this.maxFailures) { breaker.isOpen = true; console.error(`[AI 隔离网关] 子应用 ${subAppId} 连续失败 ${breaker.failures} 次，激活熔断器`); } const errorMsg = (err as Error).name === 'AbortError' ? `请求超时 (${timeoutMs}ms)` : (err as Error).message; console.warn(`[AI 隔离网关] 触发降级机制. 原因: ${errorMsg}`); // 返回确定性静态降级数据 return { data: staticFallbackData, isDegraded: true, reason: errorMsg, }; } } private getBreakerState(subAppId: string): CircuitBreakerState { if (!this.breakerMap.has(subAppId)) { this.breakerMap.set(subAppId, { failures: 0, lastFailureTime: 0, isOpen: false }); } return this.breakerMap.get(subAppId)!; } }

4. 故障演练与实战指标复盘

在将这套微前端基座 AI 隔离网关部署完毕后，我们在预发环境进行了一场“ upstream 模型断网注入测试”。

# 使用 Chaos Mesh 模拟 /api/v1/chat 接口 100% 丢包与 504 响应 curl -X POST http://localhost:9090/inject-fault --data '{"target": "ai-service", "latency": "10s", "status": 504}'

监控告警面板拉出的演练对比数据如下：

在微前端与 AI 大模型结合的工程实践中，应时刻保持“防御性编程”的清醒。

不要信任第三方 AI API 的稳定性，更不要把模型的生命周期直接暴露给全局微前端基座。用统一代理网关做硬隔离，用三级确定性 Fallback 做护城河，即使 upstream 崩塌成一片漆黑，微前端的大盘依然固若金汤。