我想在欧洲使用Firebase Hosting&功能功能。
我确实从医生那里了解到：
如果您使用HTTP函数为Firebase提供动态内容主机，您必须使用us-central1
和
Firebase Hosting仅支持us-central1 中的云功能
很明显：您必须使用我们的中心。但我的主要目标是欧洲。。
我已经在云功能位置指南上阅读了以下内容：
对于HTTP和可调用函数，我们建议您首先设置功能到目的地区域，或最接近最期望的位置找到客户，然后将原来的功能更改为将其HTTP请求重定向到新函数(它们可以具有相同的名称(。
[Solution 1]如果您的HTTP功能的客户端支持重定向，您只需更改原始函数即可返回HTTP重定向状态(301(以及新函数的URL。[Solution 2]如果你的客户端不能很好地处理重定向，你可以通过以下方式将请求从原始函数代理到新函数启动从原始功能到新功能的新请求作用最后一步是确保所有客户端都在调用新功能。
我强调了我最初问题的两个解决方案：
解决方案1
- 有一个us-central1函数，它将301重定向发送到https://europe-west1-[myProject].cloudfunctions.net/[myEuropeanFunction]
- 有一个europe-west1函数来完成这项工作(在我的情况下，为Next.js应用程序服务(
- 愉快地使用位于欧洲西部的Firestore 1
只有当HTTP函数的客户端支持重定向时，这才会起作用。在我的情况下，这很好：所有浏览器都支持重定向。
exports.nextServer = functions
.https
.onRequest((req, res) => {
res.set('location', 'https://europe-west1-<my-project>.cloudfunctions.net/nextServerEurope');
res.status(301).send()
});
exports.nextServerEurope = functions
.region('europe-west1')
.https
.onRequest((req, res) => {
return server.prepare().then(() => nextjsHandle(req, res));
});
该解决方案的问题是浏览器中的URL更改为https://europe-west1-.cloudfunctions.net/nextServerEurope：-/
解决方案2
- 有一个us-central1函数，它向europe-west1函数发起一个新的/代理请求
- 拥有与此相同的europe-west1功能(在我的情况下，为Next.js应用程序服务(
- 仍然愉快地使用位于欧洲西部的Firestore 1
根据代理请求(如指南中所建议的(，我想这意味着使用类似于axios的lib。我知道有一些库可以执行节点的代理请求。
然而，有了这个解决方案，我能想到的第一个问题是通过美国终点带来的不必要的延迟
client -> us endpoint -> eu endpoint -> do stuff -> us endpoint -> client
计费方面，我想知道会有什么影响。。
我知道来自不同地区的两个服务相互调用会增加延迟和计费(出口(。
对于第一个解决方案，没有出口流量，因为它只是重定向到欧洲端点。但在我的情况下，重定向本身并不是一个有效的解决方案。
我不清楚第二种解决方案的额外计费成本(除了延迟成本(是多少：从我们到欧盟的代理请求的流量会很贵吗？
结束：
- 解决方案1很简单，但会导致不透明的重定向
- 解决方案2看起来还可以，但它需要额外的http请求，这会导致额外的延迟(以及潜在的额外计费(最后，这两种解决方案似乎都不太好
因此，我的问题是：
您如何使用Firebase主机和功能在欧洲提供动态内容
Firebase Hosting仅支持您提到的以及Firebase Hostting官方文档中所述的Us Central中的云功能。
我在Public Issue Tracker中创建了一个功能请求，以在使用带有云功能的Firebase主机时支持其他地区。请注意，这项计划何时实施还没有预计到达时间。
因此，正如@Doug Stevenson建议的那样，您可以使用Firebase Hosting with Cloud Run来为您的动态内容提供服务。
只是为了更新。截至2022年8月。
最后，现在可以很容易地解决延迟问题。
Firebase主机对CF3的重写可以对任何CF3进行区域，而不仅仅是以美国为中心1。
参考：功能请求票证