如何更好地扩展服务：Docker swarm服务复制或使用uvicorn工人

Question

各位同事，大家好！

我有一个基于微服务架构的大型 Web 应用程序。整个基础设施都在 Docker Swarm 中运行。

所有微服务都使用 Python 并在 uvicorn 服务器上运行。

Uwsgi 有自己的可以扩展的工作人员。

在 Docker Swarm 中，您还可以通过增加服务的副本来扩展应用程序。

问题是如何更好地扩展服务：

1) 1 个 docker swarm 复制器 - 100（任何其他数量）uvicorn 工人

2) 100 个（任何其他数量）docker swarm 副本 - 1 个 uvicorn 工人

3) 10 个 docker swarm 副本 - 10 个 uvicorn 工人

Answer 1

这取决于您的应用程序和您的要求/能力，因此很难说出确切的答案。 Docker 副本和 Uvicorn 工作线程在微服务架构中处于不同的级别。

Docker 处理副本之间以及副本（容器）内部的流量（负载），Uvicorn 处理工作人员之间的进程/请求。

复制品和独角兽架构（非常高水平）：

1. 1 个 docker swarm 复制器 - 100 个（任何其他数量）uvicorn 工人

• 在这种情况下，Docker（容器）可能会过载，因为所有流量均由一个副本（容器）处理。这可能会导致资源争用，特别是如果工作人员是资源密集型的，因为他们共享相同的容器资源。

2. 100 个（任何其他数量）docker swarm 副本 - 1 个 uvicorn 工人

• 如果系统没有负载，这个解决方案可能会被过度杀死。此外，默认的 Docker 覆盖子网限制了网络中可以启动的容器数量（256），并且停止的容器也被计算在内。此外，Unicorn 可以处理更多的工人，因此仅限制 1 名工人是不合逻辑的。但每个实例都是独立运行的，这在一个实例可能变得无响应或遇到问题而不影响其他实例的情况下会有所帮助。这可以提高容错性和稳定性。

3. 10 个 docker swarm 副本 - 10 个 uvicorn 工人

• 我认为这是最有效的配置。在这种情况下，Docker 部分不会过载，也不会在低负载的情况下过度终止。 Unicorn 还可以通过此配置处理更多进程/请求。我计算了一下：

  10 replicas * 10 Unicorn = 100 parallel request

  ，所以对于并行请求处理来说这是一个相当不错的数字。这种方法可能适用于受益于并行处理和独立实例组合的应用程序。