负载平衡在单个硬件服务器上有意义吗？

Question

这可能是一个实际不了解负载平衡如何工作的情况，但请耐心等待...我目前正在设计一个 Web 应用程序，并且有一个可用的硬件服务器。我遇到的大多数架构都使用 Nginx 作为多台服务器前面的负载均衡器（使用 Nginx 代理到不同的端口）。

我的问题是：我很想使用 Docker 来容器化 Nginx 和一些我将要运行的 Django 应用程序实例（以及数据库），但是是否值得拥有多个在单个硬件服务器上运行的应用程序？服务器可以在不同的端口上运行几个 Django 应用程序实例，但负载均衡肯定是为了在硬件之间分配压力，在这种情况下就没有意义了吗？

我认为部分混淆是“服务器”可以指硬件或软件这一事实。如果有更好的理解的人可以为我解决这个问题，那将是非常棒的！

非常感谢

Answer 1

在 Docker（和公共云）领域，有几种情况将负载均衡器放在单个实例前面实际上是有用的。基本前提是负载均衡器的配置相当稳定，即使您会定期重启底层应用程序，所以您可以将客户端指向负载均衡器，而不必担心连接细节发生变化。

@CalumHalpin 的回答暗示了零停机升级，这是一个很好的用例。仅使用普通 Docker，它可能会像这样工作：

1. 在单个应用程序容器前启动负载平衡器。
2. docker build 和 docker run 应用程序容器的新版本（旧版本仍在运行）。
3. 将新容器附加到负载平衡器。现在负载平衡器将为两者之间的流量提供服务。
4. 分离旧容器。 docker stop 和 docker rm 它。

现在客户端总是连接到负载平衡器，没有任何时候没有一些支持服务。在升级期间，负载均衡器有两个实例，而不仅仅是一个。

在各种集群环境中，负载平衡器还为您提供了一种访问可能在不同节点上运行的服务的方法。 Kubernetes Service 是具有内部可见 DNS 名称的负载均衡器，并与 Deployment 结合实现了上述零停机升级路径。在 Amazon ECS 中，您可以attach load balancers to services，这曾经是一个服务与另一个服务通信的最佳方式，即使在 ECS 集群内也是如此。

Answer 2

从性能的角度来看，通过实验确定哪种方法更好。我想不出多个应用程序实例比单个应用程序实例性能更好的任何原因，因为您打算使用 Nginx 来提供它，它已经可以处理并发请求。事实上，由于容器化开销，我预计情况会更糟。

如果您担心应用程序或其基础架构的稳定性，那么多个实例会给您带来一些冗余。如果一个实例失败，您可以让一个新实例自动启动。您还可以使用 blue-green deployments 或类似的设置来实现零停机部署。