微服务实战：负载均衡所有实例的请求

在研究负载均衡之前，有些事情需要权衡下。我们需要一个服务的多个实例，由于已经在第2章中讨论过扩展，所以下面的命令应该不会让你意外：

很快就会有go-demo服务的5个实例在运行，如图3-5所示。

图3-5　使用go-demo服务扩展的Docker Swarm集群

应该怎么做才能让代理在所有实例之间对请求进行负载均衡呢？答案是什么都不需要做。我们不需要采取任何措施。其实，这个问题本身就是错的，代理根本不会对请求进行负载均衡，而是Docker Swarm会进行负载均衡。所以，让我们重新提出这个问题。我们应该怎么做才能让Docker Swarm网络在所有实例之间对请求进行负载均衡呢？答案依然是什么都不需要做。我们不需要采取任何措施。

为了理解负载均衡，我们可能需要回到过去并讨论Docker网络诞生之前的负载均衡。

通常情况下，如果没有使用Docker Swarm的功能，则会有类似于下面的代理配置模型：

每次添加新实例时，我们都需要将其添加到配置中。如果一个实例被删除，那么需要将它从配置中删除。如果一个实例失败……好吧，你应该明白了：我们需要监控集群的状态，并在发生变化时更新代理配置。

如果你读过《微服务运维实战（第一卷）》，那么你可能会记得我建议使用Registrator（https：//github．com/gliderlabs/registrator）、Consul（https：//www.consul.io/）和Consul模板（https：//github．com/hashicorp/consul-template）的组合。

一旦容器被创建或销毁，Registrator将会监控到Docker事件并更新Consul。利用Consul中存储的信息，我们可以使用Consul模板来更新nginx或HAProxy配置。现在不再需要这样的组合了。尽管在特殊情况下这些工具仍然有价值，但现在没有使用它们的必要了。

我们不会在每次集群内发生变化时去更新代理，例如缩放事件。相反，我们会在每次创建新服务时更新代理。请注意，服务的更新（部署新版本）不算是服务创建。我们只创建服务一次并用每个新版本进行更新（除其他原因外）。因此，只有创建新服务，才需要更改代理配置。(www.xing528.com)

上面推理背后的原因在于负载均衡现在是Docker Swarm网络的一部分。让我们用util服务做另外一个练习：

以上命令的输出如下：

IP 10.0.0.8代表go-demo服务，而不是一个单独的实例。当我们发送练习请求时，Swarm网络在该服务的所有实例中执行负载均衡（LB）。更确切地说，它执行了时间片轮转LB。

除了为每个服务创建一个虚拟IP之外，每个实例也都有自己的IP。大多数情况下，不需要知道这些IP（或任何Docker网络的端点IP），因为我们只需要一个服务名称，该服务名称将被转换为IP并在后台进行负载均衡。