Firebase Admin Node SDK 从sendAll迁移到sendEach的性能优化实践

背景介绍

Firebase Admin Node SDK在12.0.0版本中引入了一个重要的变更：废弃了原有的sendAll方法，转而推荐使用sendEach方法来发送批量消息。这一变更源于Firebase后端API的调整，原有的批量发送端点已被弃用。

问题现象

开发者在升级到12.0.0版本后，按照官方建议将sendAll替换为sendEach时，遇到了以下典型问题：

1. 认证错误：出现"Failed to determine project ID"的错误提示
2. 性能下降：发送速度比原来慢2-2.5倍
3. 资源消耗增加：需要更多线程来完成相同的工作量

解决方案

认证问题解决

认证错误的主要原因是缺少项目ID配置。在初始化应用时，需要显式指定projectId参数：

initializeApp({
  credential: fcm.credential.cert(credentials),
  projectId: "your-project-id"  // 必须添加这一行
}, credentials.credentialsId);

性能优化方案

Firebase团队在12.3.0版本中针对性能问题做了以下改进：

1. 默认启用HTTP/2连接：提高了网络传输效率
2. 优化内部实现：虽然仍需要为每条消息发送独立请求，但通过连接复用等技术减少了开销

技术原理

新旧方法差异

• sendAll：使用已弃用的批量API端点，单次请求可发送多条消息
• sendEach：基于新的单条消息API，需要为每条消息发送独立请求

性能差异原因

由于后端API的变更，sendEach无法再使用批量发送机制，这是性能下降的根本原因。每条消息都需要：

1. 建立独立的HTTP请求
2. 处理独立的响应
3. 维护连接状态

最佳实践建议

1. 升级到最新版本：确保使用12.3.0或更高版本以获得HTTP/2支持
2. 合理设置并发：根据服务器资源调整并发发送数量
3. 监控性能指标：建立基准测试以评估实际影响
4. 考虑分批处理：对于超大消息量，可考虑手动分批发送

未来展望

Firebase团队正在持续优化消息发送性能，开发者可以关注以下可能的改进方向：

1. 更高效的连接池管理
2. 智能批处理策略
3. 异步发送模式的支持

虽然当前方案相比原生的批量API有一定性能差距，但通过合理配置和最新版本的特性，可以在大多数场景下获得可接受的性能表现。