如何优化从 HTTP 触发函数并行调用“子”云函数答案

【问题标题】：How to optimise calling "sub" Cloud Functions in parallel from an HTTP triggered function如何优化从 HTTP 触发函数并行调用“子”云函数
【发布时间】：2019-09-23 11:59:59
【问题描述】：

我在云存储桶中有数千个日志文件，我需要使用 HTTP 触发的云函数来处理和聚合这些文件，并且正在寻找一种使用并行化以最快的方式计算任务的方法。

目前，我有两个云功能（nodejs 8）：

用户调用的“main”函数直接传递需要处理的日志文件列表；该函数为每个提供的日志文件调用“子”函数，我还通过使用 async.each 并行运行的 HTTP 请求触发这些日志文件。 “child”函数处理单个日志文件并将数据返回给“main”函数，该函数汇总结果，并在处理完所有文件后将结果发送回用户。

如果我直接调用子函数，完成一个文件大约需要1秒。我希望如果我调用 main 函数来并行处理 100 个文件，时间仍然或多或少 1 秒。批次中的第一个文件确实是1秒后返回，但是时间随着每个文件的增加而增加，第100个文件是7秒后返回。

最可能的罪魁祸首是我正在使用 HTTP 请求运行子函数，但我还没有找到“内部”调用它们的方法。是否有另一种特定于 Google Cloud Functions 的方法，或者我可以以某种方式优化 HTTP 请求的并行化？

【问题讨论】：

标签： google-cloud-functions google-cloud-storage

【解决方案1】：

最简单的方法是简单地共享执行子函数的代码，然后直接从主函数调用它。在某些情况下，由于函数调用更少，它更容易且成本更低。

另请参阅：Calling a Cloud Function from another Cloud Function

【讨论】：

但是，如果我理解正确，那么我将立即达到内存和 CPU 的限制，因为我将只运行一个实例，而不是并行运行数千个实例。
您需要数千个并行运行吗？您在这里的实际要求是什么？您的问题描述对于您实际希望完成的工作不是很具体，
我希望使用 Google 上的无服务器堆栈在最短的时间内根据用户的请求处理尽可能多的日志文件：Cloud Functions（而不是 Compute Engine）和 Storage（而不是 SSD 磁盘） )。 CF 和 Storage 都明显变慢，但我希望在 CF 限制内实现近线性并行化，并显着优于当前设置。
如果你没有具体的扩展需求，可以试试我的建议吗？
另外，我希望您无法在此处使用 Cloud Functions 优化速度和可扩展性。您将不得不选择一个，而您选择的一个将取决于您的预期负载。您可能还想考虑一下您的“子”功能是否可以异步发生，或者是否需要在主功能完成之前完成。