目前，我有3个Firebase项目用于一个应用程序：实时，测试版，开发
这些可以处理各自的环境，并且都在美国区域内。
如果将来在全球范围内使用应用，那么在欧盟/亚洲+美国扩展的推荐方式是什么？我最初的意图是创建其他livebase项目，例如live-eu，live-asia，但我在这里看到一个问题：
这些项目可以使用与我当前在美国使用的相同应用程序ID吗？我无法从美国项目中导入数据，因为那里有uid's，这些数据肯定不能与其他项目的auth一起使用吗？但是我需要允许用户过渡到其他区域。
我无法在一个地方收集来自所有地区的分析数据吗？
因此，有一个方法可以在firebase项目中扩展/添加多区域支持吗？对Firestore和云功能特别感兴趣，因为这些功能可以减少延迟。
答案 0 :(得分：3)
我在评论中提出了问题，但没有得到答复，因此我假设您的应用程序具有读取密集型工作负载。对于这些情况，为了减少来自世界各地的请求的延迟，您应该使用CDN来缓存静态文件和响应（即，利用边缘位置和边缘计算）。您甚至不需要为此坚持使用Firebase（有些解决方案可以满足您的需求，并且可以轻松地插入Firebase解决方案，例如Akamai和CloudFront），但是如果需要，请查看Firebase Hosting。
如果您的工作量是WRITE密集型，请尝试使用异步机制（例如消息队列）来确保您更快地向用户提供反馈。通常，写操作不需要立即/同步执行，但是再次理解，最好了解您的工作量以给出更准确的答案。
编辑：Google最近宣布了Firestore －它们提供了多区域支持以提高可用性：
多区域位置是一般地理区域，例如美国。多区域位置中的数据将在多个区域中复制。在一个区域内，数据跨区域复制。
关于可伸缩性，这是他们在their blog中给出的声明：
Cloud Firestore [...]建立在支持一些非常流行的应用程序的相同Google Cloud基础架构之上。因此，与实时数据库相比，它可以更轻松地进行扩展，并具有更大的容量。
使用新的查询结构，所有Cloud Firestore查询都将缩放到结果集的大小-而不是数据的大小。这意味着，无论您的数据库中有300家餐厅，30万家餐馆还是3000万家餐馆，使用饭店评论应用程序搜索芝加哥排名前10的饭店将花费相同的时间。正如一位工程师喜欢这样说：“在Cloud Firestore中创建缓慢的查询基本上是不可能的。”
请注意，Firestore中的写入具有很强的一致性（这意味着与最终的一致性解决方案相比，它们具有更高的延迟）。