dynamic可扩展和自适应架构

我是一名云计算博士生，我计划使用基于微服务的架构与consul和zeromq进行我的研究项目。 我有几个难以理解的问题。 有人能帮我分享他们的经验。

1. 我们有基于docker的微服务，我们有zeromq，我们有领事。 你能否提一下我们如何将这三者结合起来，形成一个dynamic的适应性环境？

虽然我了解zeromq，docker和consul是个别的，但是我仍然无法清楚地了解它们是如何作为一个整体来运行的。我们有一个在主机上运行微服务的docker容器。 我们使用zeromq在Docker容器之间传输消息（Pub-sub / pipeline）。 这些容器可能运行在相同的主机/数据中心或不同的主机/数据中心上。 然后，我们使用领事进行服务发现。这里我的理解是否正确？

2. 架构如何根据工作负载dynamic扩展/缩小？

说，我有一个情况，我需要更多的工人节点进行特定的计算。 谁旋转了更多的工人节点。 哪个组件决定/做出这个决定？

是否有调度组件？ 如果是这样，有人可以简单地解释它是如何发生的或哪个组件执行该function？

3. 那么，领事的主要angular色是什么？ 是否仅用于服务发现？是否也可用于configuration。 如果是这样，它的局限性是什么？

我看到，即使是zeromq也有服务发现机制，那么为什么我们需要领事呢？

4. 如何在架构中传播节点信息的失败？ 哪个组件负责？ 这只是领事吗？ 还是zeroMq呢？

请指教。

Answer 1

我参与了一个使用基于Docker的微服务和Consul的大型项目。 （我们正在使用不同的排队服务–RabbitMQ，所以我不能详细讲述这个方面，但一般来说，一个队列是一个队列。）

Docker，Consul和我知道的任何队列技术都不​​提供自动调节function。 Docker提供了一个简单的方法来启动服务的多个实例，Consul提供服务发现（如您所说）和一个键/值持久性存储。 队列只是在服务实例之间传递消息的一种方式。 没有提到处理自动缩放的问题。

要添加自动缩放function，您需要查看类似Kubernetes的内容。

你可以看看CloudFoundry或Mesos。 但是，这两者都需要虚拟化层，例如OpenStack或VMWare vSphere。 用这些产品，具有重要的价值，而且价格和复杂性。

我build议您不要走这条路线，而要考虑Amazon Web Services。 使用AWS，您可以轻松地运行Docker容器，并根据CPU负载，队列中的消息，一天中的时间（或一周中的某天）等设置自动调节。我知道使用AWS带有价格标签，但是如果devise良好， ，它会花费你远远低于试图devise，实施和维护自己。 您也可以使用最小的（即免费的）机器和/或现场实例来降低成本。

Answer 2

这是个有趣的问题。 你提到的所有组件都是独立的，在微服务架构中有明确的独立优势和作用。 不寻常的部分是使用消息而不是HTTP。 我认为这是一个有价值的出发点，因为它可以实现更灵活的计算模式（工作生产者不需要成为产品消费者，甚至不需要通知）。 跳过HTTP的特别之处在于避免了成本（OPEX和服务延迟），复杂性以及负载均衡器的增加的故障模式。

1. Docker：pipe理单个服务的打包和交付到基础设施ZeroMQ：pipe理服务之间高效的点对点或代理通信Consul：服务发现（例如，找出用户服务的位置）

2. 自动缩放不是由Docker执行的。 您可以使用您自己的微服务来检查负载指标（例如负载平均值，物理/交换内存使用情况等），并调整副本并更新Consul。

   或者，您可以依靠@drhender：Kubernetes，Mesosphere DCOS或AWS Autoscaling Groups详述的自动调节解​​决scheme。 但请注意，使用AWS Autoscaling组显着限制了解决scheme的可移植性。

   无论您select哪种自动缩放机制，都要确保您的ZeroMQ消息模式支持添加或删除的服务。 ZeroMQ指南在这个话题上有很好的build议。

3. 领事可以提供服务发现和服务configuration需求。 记住存储安全问题，如果您正在存储敏感数据，如PHI或PII。 这些更好地存储与rest保护，如保险柜供应。

   Consul代理收集您可以监视问题的遥测 。 还有一个相当简单的Consul KV基准testing套件 ，您可以使用它来testingconfiguration存储。

   ZeroMQ不是直接为服务发现而devise的。 您可以select一个集中代理的架构，使得单独的服务发现变得不必要，但这具有不同的可伸缩性和容错性。 它具有每个消息的有效载荷开销，假设在绑定SUB套接字时使用多部分消息和主题订阅。 有很多方法可以单独使用ZeroMQ来进行服务发现，但是考虑到容忍性和共识性的情况下，这将是非常重要的。

4. 节点故障是一个有趣的挑战。 领事可以通过健康检查知道，但是ZeroMQ根据消息模式创造了一些挑战。 例如，如果发送请求并且响应者在传送后死亡，则使用REQ-REP对，根据我的经验，REQ套接字将永远阻塞。 有超时的方法。

   我会依赖Consul来做这个事情，并准备在失败时中断或重新生成REQ套接字。 几乎完全通过使用分步事件驱动架构（SEDA）完全避免RPC风格的交互，其中inputd的生产者不是输出的消费者。 你总是有失败的排队input或输出失败的挑战，所以你需要系统级别的监测和重试机制，如果失去工作是致命的。

ContainerBuddy允许您将任何可启动的应用程序放在Docker容器中，并将其注册到Consul。 它可以为你简化的事情。