1

我正在尝试使用 Cloud Run 运行连接到 Firestore 的微服务。微服务基于s2geometry创建对象以创建具有特定属性的多个地理区域，从而帮助本地化用户根据我所在的区域向他们发送信息。

我使用 Python 3.7 和FastAPI来创建微服务以及与之通信的路由。

微服务在我的本地机器和 Compute Engines 上运行顺利，因为当我测试它们时，我的大多数路由都需要不到 150 毫秒的时间来回答。但是，当我使用 Cloud Run 部署它时，我遇到了延迟问题。有时，微服务需要很长时间才能回答（最多 15 分钟），我无法确定究竟是什么原因造成的。

这是一个屏幕截图，我们可以在其中看到请求计数和请求延迟：

请求计数和请求延迟

请求延迟和请求数量之间没有真正的关联，或者至少没有微不足道的关联。我还查看了服务的内存使用情况，内存使用情况最多为 30%。然而，CPU 使用率有时会达到 100%，但在请求缓慢时不一定如此。

最后，当我探索跟踪列表并比较具有高延迟的请求时，我注意到以下差异

慢请求
跟踪 快速请求跟踪

快速请求似乎会调用自己，而慢速请求则不会，我不知道为什么。

目前我们的用户并不多，所以我认为这可能是一个冷启动问题，但缓慢的请求不一定是第一个问题。

现在，老实说，我不知道这里发生了什么以及 Cloud Run 做了什么（或者我做错了什么），而且我还发现很难找到关于 Cloud Run 实际工作原理的详尽解释，所以如果你有一个（除了谷歌之外）我很乐意深入研究它。

非常感谢您的帮助

4

1 回答 1

1

经过几次测试，这似乎是一个冷启动问题。Cloud Run 容器会在一段时间后停止，如果它们没有被使用，并且由于我们没有大量流量，每次用户想要访问应用程序时容器都必须重新启动。

解决方案 ：

我创建了一个Cloud Function，它在触发时向容器发送请求，然后创建了一个Cloud Scheduler作业，该作业每分钟运行一次。

笔记 ：

如果不同的修订被路由到您的服务，您需要为每个修订创建一个 Cloud Scheduler 作业。为此，您必须为每个路由修订（当前为 beta）创建一个修订 URL（标签）。

编辑 ：

现在正如@Jofre 提到的，您可以通过将“最小实例数”设置为 1 来选择始终运行服务实例。如果您使用控制台，GCP 甚至会告诉您“设置为 1 以减少冷启动” .

于 2020-09-25T07:27:15.677 回答