在单个硬件服务器上进行负载平衡是否有意义？

Question

这可能是一种情况，它实际上并未真正理解负载平衡的工作原理，但请耐心等待……我目前正在设计一个Web应用程序，并且只有一台硬件服务器可供我使用。我遇到的大多数体系结构都将Nginx用作多个服务器前面的负载平衡器（Nginx代理到不同的端口）。

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

我认为混乱的部分原因是“服务器”既可以指硬件也可以指软件。如果有一个更好的了解的人可以为我解决这个问题，那就太好了！

非常感谢

Answer 1

从性能角度来看，通过实验确定哪种方法更好的方法。我想不出任何原因，尽管多个应用程序实例的性能要优于单个实例，因为您打算将其与已经处理并发请求的Nginx一起使用。确实，由于集装箱运输的开销，我预计情况会更糟。

如果您担心应用程序或其基础结构的稳定性，那么多个实例将为您提供一些冗余。如果一个新实例失败，则可以自动启动。您也可以使用blue-green deployments或类似方法将这种设置用于零停机时间部署。

Answer 2

在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集群中与另一服务进行对话的最佳方式。