在 Google Cloud Run（Docker 映像）上运行 FastAPI

Question

我正在寻找构建一个 Docker 映像以在 Google Cloud Run 上运行 FastAPI。 FastAPI 使用 Uvicorn 作为 ASGI 服务器，Uvicorn recommend using Gunicorn with the Uvicorn worker class 用于生产部署。 FastAPI 本身在using Gunicorn with Uvicorn 上也有一些出色的文档。我什至看到 FastAPI 提供了一个结合两者的官方图像（ uvicorn-gunicorn-fastapi-docker) 但这带有 warning:

您可能正在使用 Kubernetes 或类似工具。在这种情况下，你 可能不需要此图像（或任何其他类似的基本图像）。你 从头开始构建 Docker 映像可能会更好

此警告基本上说明复制将在集群级别处理，而无需在进程级别处理。这是有道理的。但是我不太确定 Cloud Run 是否属于这一类？本质上，它是一个抽象和托管的 Knative 服务，因此运行在 Kubernetes 上。

我的问题是，我应该在我的 Dockerfile 中安装 Gunicorn 和 Uvicorn 并在进程级别处理复制吗？大致如下：

CMD ["gunicorn", "app.main:app", "-w", "4", "-k", "uvicorn.workers.UvicornWorker", "--bind", "0.0.0.0:80"]

或者我应该坚持使用 Uvicorn，一个单一的进程，让 Cloud Run (Kubernetes) 在集群级别处理复制？例如

CMD ["uvicorn", "app.main:app", "--host", "0.0.0.0", "--port", "80"]

Answer 1

A.让我们先去大规模。

在撰写本文时，Cloud Run 实例最多可设置为 1000 个concurrency requests。 CPU 可以设置为 4 个 vCPU。

回到基础一点。 Cloud Run 将跨越多个实例，每个实例都将单独工作，每个实例都可以处理允许的最大并发数，因此每个实例可以处理 1000 个请求。如果设置多个 CPU，则需要处理多个进程。

当我们谈论如此大的数字时，我们需要谨慎。如果您的容器在 CPU/内存方面足够大以处理此流量，您可能希望使用进程管理器 (gunicorn) 来启动多个 Uvicorn 线程 (worker)，就像您引用的图像一样。这样就可以使用docker容器了。

B.规模小。

另一方面，如果您设置了 1 个 vCPU 并且是单线程的，则您不需要 gunicorn 用于进程管理器。您仍然可以启用并发，但不能在顶层启用，可能在较低级别，适合您的 1 个 vCPU 模型，例如 80 个并发请求。在这种情况下，您将拥有大量流量，许多实例由 Cloud Run 启动，并且您依靠 Cloud Run 根据需要生成尽可能多的实例，这非常好。它就像您的简单容器之上的 Kubernetes。

我建议从单个进程开始，构建一个不使用引用容器的容器，并且仅在您知道拥有更大实例有好处（成本明智）时将 B 交换到版本 A。