Google cloud platform 每小时调用一次外部API并分别执行约10000行任务的作业

我目前正在设计一个系统，它基本上每小时运行一个作业，但大约需要10000行。然后，这些行中的每一行都需要调用一个外部api，并在分析方面执行其他一些操作

我目前正在努力找出实现这一目标的最佳方法，但我以前从未做过类似的事情，因此我将感谢任何人提供的建议或指导。我主要习惯于GCP，因此我将我的想法集中在那里可用的工具上（这也很可能在JS/Node环境中完成）

我对设计的初步想法如下

• 使用云计划程序创建每小时运行一次的作业
• 云调度器触发一个云函数
• 云函数检索所有必要的行，并在主题中为每一行创建发布/订阅消息
• 然后，Cloud pub sub触发另一个云函数，该函数调用外部API并对该行执行其他任务，并将数据写回需要返回的位置
• 鳍

我让第一个函数向队列添加项的理由显然是云函数受执行时间和内存的限制，因此我认为让一个函数自己尝试处理所有行并不明智。我的假设是，pub/sub每次都会触发函数的一个新实例，而不是覆盖第一个实例

我认为理论上我可以批处理一些外部API调用，可能一次最多20个，所以我不知道这是否会/应该对上述设计产生影响

很明显，我也希望这样做的成本尽可能低，所以我不知道让应用程序引擎实例这样做是否会更好？但我也不知道我是否会遇到内存和超时问题

我在写这篇文章时想到的一个想法是，我是否可以按原样批处理这些批次。来自JS后台，我可以创建所有批处理API调用，并在Promise.all（）调用中执行它们。同样，我也不确定它对内存和性能的影响，所以我想我需要对它进行测试

有没有人注意到上面的漏洞，或者有更好的解决方法

---

谢谢

您的设计的第一部分是正确的（云调度器->云功能->PubSub中的消息）

在这里，对每条消息调用一个云函数。在我看来，这不是最好的选择，因为您一次只能处理一个云函数实例上的请求。如果您执行一个外部API调用，您将白白浪费时间（您将等待答案，什么也不做）

更好的解决方案是使用管理并发请求的产品，例如或。使用Cloud Run，您最多可以有250个并发请求，但使用App Engine时只有80个

通过使用这种解决方案，您将节省大量资金，从而节省时间

---

关于批处理，我不太明白

• 如果您可以在一个请求中向外部API发送包含在20条消息中的20个值，那么最好批处理该请求（在第一个云函数中创建包含20条消息的区块）
• 如果您继续一个接一个地发送请求，但使用了该语言的并发能力（Node或Go在这方面非常有限），那么与逐个处理消息相比，没有什么真正的优势

事实上，您将减少调用的数量（但它确实非常便宜），相反，会增加代码的复杂性。我不确定那值不值得

---

编辑1

事实上，PubSub不会生成任何云运行实例。PubSub订阅仅将消息推送到URL。PubSub的工作到此结束

现在，在云运行端，服务根据HTTP流量进行扩展。因此，平台选择创建1个、2个或更多实例来吸收流量。在您的情况下，平台将创建大量实例（我认为大约100个），但您只需使用实例处理流量。没有请求处理，没有账单

您还可以使用max instance参数限制Cloud Run上并行实例的数量。有了它，您不仅可以限制成本，还可以限制处理能力

现在，关于延迟，当然有不同的来源

在PubSub中发布消息时，在第一次创建到第10次之间存在“延迟”

每次云运行平台创建一个新实例时，该实例都需要启动并初始化其运行时环境（称为冷启动）；根据您的开发语言和设计，可能需要几毫秒（大约200-500）或几秒钟（例如，使用Spring引导）。您可以想象使用min instance功能来预热多个实例，从而限制clod start的数量。但是，对于每小时运行1次，此功能对您来说可能太贵了（在我看来，我不推荐使用此功能）

在同一个实例上，如果您同时处理250个请求，它们必须共享相同的CPU资源，并且一些请求将等待获得处理它们的CPU时间。您可以增加CPU数量以减少延迟（例如SET4VCPU），但这是任何多线程系统的正常行为

---

设计的第一部分是正确的（云调度器->云功能->PubSub中的消息）

在这里，对每条消息调用一个云函数。在我看来，这不是最好的选择，因为您一次只能处理一个云函数实例上的请求。如果您执行一个外部API调用，您将白白浪费时间（您将等待答案，什么也不做）

更好的解决方案是使用管理并发请求的产品，例如或。使用Cloud Run，您最多可以有250个并发请求，但使用App Engine时只有80个

通过使用这种解决方案，您将节省大量资金，从而节省时间

---

关于批处理，我不太清楚