讯飞语音-架构选择

前端直连

1. 后端仅用于生成带签名的临时鉴权 URL。
2. 前端通过 Web API（WebSocket）直接与讯飞服务器通信，绕过后端音频转发。

优点

1. 快速开发：无需复杂的后端服务，后端仅生成临时鉴权 URL，前端可直接处理音频流和结果展示。
2. 低延迟：减少中间环节，语音识别响应速度快。

缺点

1. 安全风险存在：虽然前端不直接持有密钥，但鉴权 URL 本身包含签名授权信息，若在有效期内被截获，攻击者可模拟合法客户端行为（重放攻击）。
2. 业务控制弱：难以做复杂流量控制和日志管理。

适用场景

1. 小型应用、低并发
2. 快速原型或功能验证
3. 对安全性要求不高

后端中转

1. 双 WebSocket 架构：前端 ⇄ 后端 ⇄ 讯飞。
2. 前端采集音频并发送至后端，后端通过 Web API 或 SDK 转发至讯飞，并返回识别结果。

优点

1. 安全性高：前端仅访问自有业务服务器接口，由后端统一管理和使用讯飞鉴权信息，避免鉴权凭证在前端暴露。
2. 业务灵活：支持音频预处理、格式转换、重试策略、错误处理等。
3. 集中管理：统一日志、监控、性能优化与流量控制。
4. 扩展性好：可通过负载均衡和多实例扩展 TPS。

缺点

1. 延迟增加：整体延迟通常在 200ms ~ 1s。
2. 开发复杂度高：需要管理 WebSocket 连接、音频流、异常处理、认证等。
3. 后端负载大：需处理所有音频流及高并发请求。

适用场景

1. 中大型应用
2. 需要安全性、集中控制、流量管理

消息队列限流

1. 在后端中转基础上引入消息队列（RocketMQ/Kafka）。
2. 流程：前端采集音频 → 后端入队 → 消费端拉取 → 调用讯飞识别 → 结果返回前端。

优点

1. 高并发承载：消费者节点可横向扩展，支持大规模请求。
2. 流量削峰：精准限流，防止系统过载。
3. 系统解耦：前端、后端、识别服务独立，提高可维护性。
4. 高可用性：消息可靠传递、持久化、异常重试机制。

缺点

1. 系统复杂性增加：需额外配置和监控消息队列。
2. 延迟上升：整体延迟约 500ms ~ 2s。
3. 运维成本高：消息队列需管理和维护。

适用场景

1. 高并发、高流量企业级应用
2. 需要异步批量处理、限流、日志记录
3. 对系统容错性要求高

对比总结

特性/架构	前端直接连接讯飞	后端调用讯飞	RocketMQ 限流
实时性	✅ 较高	✅ 中等（增加延迟）	❌ 较低（队列和异步处理）
安全性	⚠️ 中等（存在 URL 短期重放风险）	✅ 高（后端控制鉴权）	✅ 高（后端控制鉴权）
开发复杂度	✅ 简单	❌ 较复杂	❌ 较高（消息队列管理）
扩展性	❌ 限制	✅ 较好（后端集中处理）	✅ 强（消费者横向扩展）
后端负载	❌ 较轻	✅ 较重（处理音频流）	✅ 高（需管理消息队列）
容错能力	❌ 低（连接断开会影响所有前端）	✅ 高（后端管理失败）	✅ 高（消息队列重试）
适用场景	小型应用、低并发	中大型应用、需安全性和控制	高并发、高流量、大规模系统