领导基于Docker的微服务架构

时间:2017-08-28 22:38:38

标签: networking amazon-ec2 architecture microservices consul

我们正致力于从单一应用程序切换到微服务。 每个微服务都将通过Amazon ECS在Docker上运行。

我们决定使用Consul进行服务发现。我们在VPC内的EC2实例上运行了3台服务器。

我的问题如下:

如何/在哪里为每个微服务启动Consul代理?我是否在每个实例上运行另一个容器(通过Docker-Compose)和Consul里面?或者以某种方式在每个微服务的现有Docker容器中运行Consul代理?

enter image description here

附件是我的情况的粗略表示。 Consul客户端(黄色)应该在自己的Docker容器中还是在Node.js容器内?

1 个答案:

答案 0 :(得分:1)

Consul是另一项服务,我不会将其部署在我的微服务的容器中。在大型场景中,我将部署几个Consul容器:一些将在服务器模式下运行代理(将它们视为Masters),一些将在客户端模式下运行(将它们视为Slaves)。

我不会将在客户端模式下运行的代理部署为应用程序容器的一部分,因为:

  1. 隔离它们意味着它们会被单独停止。将它们组合在一起意味着每当我因版本升级或故障而停止我的应用程序容器时,我就会不必要地停止在其中运行的Consul代理。反过来也是这样:停止Consul代理将停止我正在运行的应用程序。这种不必要的耦合是没有用的。
  2. 隔离它们意味着它们可以单独缩放。我可能需要扩展我的微服务并部署更多的实例。如果容器还包含Consul客户端代理,那么扩展我的微服务也会最终缩放Consul。或者相反:我可能需要在不缩放微服务的情况下缩放Consul。
  3. 就Docker容器图像而言,隔离它们更容易。我可以继续使用官方的Consul图像并毫不费力地升级。将Consul和我的微服务放在一起意味着升级Consul需要我自己修改容器图像。
相关问题