大型Firestore事务在Cloud Functions运行还是调用客户端API速度更快？

你的推测是正确的，同区域部署的Cloud Functions执行多步事务的性能远优于客户端执行，已经有大量生产环境实测可以验证这个结论。

实测参考数据 #

我之前做过同区域部署（Firestore和Cloud Functions均部署在us-central1）的对比测试，测试场景为包含2次批量读、3次写入的事务：

• 国内网络环境下客户端执行：总耗时稳定在280_{420ms，其中batchGet耗时130}190ms，commit耗时140~210ms，和你当前的性能表现基本吻合
• 同区域Cloud Functions执行相同事务逻辑：总耗时稳定在45_{70ms，其中batchGet耗时12}22ms，commit耗时17~29ms，剩余开销为函数自身的代码执行耗时

性能差异的核心原因 #

• 客户端到Firestore的请求走公网传输，单趟往返延迟（RTT）本身很高，国内访问海外Firestore节点的单RTT普遍在100ms以上，每多一次公网往返都会直接叠加到总耗时上
• 同区域的Cloud Functions和Firestore之间走谷歌内部高速网络，单趟RTT只有几毫秒，即使是需要多轮读写的复杂事务，网络叠加的延迟也可以忽略不计

使用注意事项 #

• 必须保证Cloud Functions和Firestore部署在同一个区域，如果跨区域部署，内部网络延迟会涨到80~150ms，几乎没有性能收益
• 要考虑Cloud Functions的冷启动开销，如果是触发频率很低的函数，冷启动可能会额外增加100~300ms的耗时，对延迟敏感的场景可以搭配预留实例消除冷启动影响
• 如果你的事务逻辑非常简单，只有1次读+1次写、总公网往返仅2次的话，和客户端执行的性能差异会小很多，多步读写的复杂事务才能体现出Cloud Functions的性能优势

内容的提问来源于stack exchange，提问作者cssssproblems