Google Cloud Function的配额页面:https://cloud.google.com/functions/quotas表示HTTP函数在HTTP响应中发送的最大数据量为10 MB。我在Google存储桶中有100 MB的文件,要从Cloud Function流到我的应用程序。由于我们架构的安全性,我的应用程序无法直接从存储桶中读取。
云功能中的示例Go代码为:
func MyFn(w http.ResponseWriter, r *http.Request) {
var appendedBytes []byte
for {
decryptedFileBuffer, err := fh.GetNextDecryptedPage()
if err != nil {
break
}
appendedBytes = append(appendedBytes, decryptedFileBuffer...)
}
w.Write(appendedBytes)
}
如果我尝试使用Cloud Function获取超过10 MB的文件,则会出现以下错误:
错误:函数响应不正确。函数调用原为 中断。
错误:无法处理请求
如何从Cloud Function中获取10 MB以上的文件?
答案 0 :(得分:2)
当我们查看配额页面时,会看到一个 no ,关于是否可以增加配额。小镇上的一个新玩家是Google Cloud Run ...请参阅here。这提供了与Cloud Functions非常相似的功能,但使用Kubernetes作为功能托管环境。 quota的配额为32MB ... ...但这也少于您的需要,并且还标记为 no 可以增加。
我立即想到的是,为了方便而交易便利性(一个简单的云功能)并在GCP上运行您自己的计算资源。例如,运行Compute Engine,App Engine或Kubernetes群集(其中所包含的应用程序通过Web服务器提供响应)是一个很好的主张,并且不受吞吐量的限制。由于度量标准会有所不同,因此您必须对计费进行数学运算才能确定成本差异,但是从技术角度来看,游戏会发生巨大变化。云功能/云运行功能主要是为了支持非常短性质的微服务,我想直接将100MB的传输视为微服务是不可行的。它也可能不像人们想象的那样具有成本效益。据我了解,Cloud Functions按使用的单位时间计费。传输100MB可能是延迟时间较慢的提议,并且与我们一直认为的始终运行的计算相比,成本效益不高。