【问题标题】：Consul in a Docker-based Microservices architecture基于 Docker 的微服务架构中的 Consul
【发布时间】：2017-08-28 22:38:38
【问题描述】：
我们正在努力从单一应用程序切换到微服务。
每个微服务都将通过 Amazon ECS 在 Docker 上运行。
我们决定使用 Consul 进行服务发现。我们有 3 台服务器在 VPC 内的 EC2 实例上运行。
我的问题如下：
如何/在哪里为每个微服务启动 Consul 代理？我是否在每个实例上运行另一个容器（通过 Docker-Compose），里面有 Consul？或者我是否以某种方式在每个微服务的现有 Docker 容器中运行 Consul 代理？
附件是我的情况的粗略表示。
Consul 客户端（黄色）应该在它自己的 Docker 容器中还是在 Node.js 容器中？
【问题讨论】：
标签：
networking
amazon-ec2
architecture
microservices
consul
【解决方案1】：
Consul 是另一个服务，我不会将它部署在我的微服务容器中。在大规模场景中，我会部署几个 Consul 容器：一些会在 Server 模式下运行代理（将它们视为 Master），而另一些会在 Client 模式下运行（将它们视为 Slave）。
我不会将在客户端模式下运行的代理部署为我的应用程序容器的一部分，因为：
- 隔离它们意味着它们被单独停止。将它们放在一起意味着每当我由于版本升级或故障而停止应用程序的容器时，我都会不必要地停止在其中运行的 Consul 代理。反过来也是一样：停止 Consul 代理会停止我正在运行的应用程序。这种不必要的耦合没有好处。
- 隔离它们意味着它们可以单独缩放。我可能需要扩展我的微服务并部署更多实例。如果容器还包含 Consul 客户端代理，那么扩展我的微服务最终也会扩展 Consul。或者反过来：我可能需要在不扩展我的微服务的情况下扩展 Consul。
- 就 Docker 容器映像而言，隔离它们更容易。我可以继续使用官方的 Consul 镜像并毫不费力地升级。把 Consul 和我的微服务放在一起就意味着升级 Consul 需要我自己修改容器镜像。