3

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

  1. 我们有基于 docker 的微服务，我们有 zeromq，我们有 consul。你能提到我们如何将这三者结合在一起以形成一个动态的自适应环境吗？

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

  1. 架构如何根据工作负载动态扩展/缩减？

比如说，我有一段时间需要更多工作节点来进行特定计算。谁启动了更多数量的工作节点。哪个组件决定/做出这个决定？

有调度组件吗？如果是这样，有人可以简要解释它是如何发生的或哪个组件执行该功能吗？

  1. 那么，领事的主要作用是什么？它仅用于服务发现吗？它也可以用于配置。如果是这样，它的局限性是什么？

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

  1. 节点信息的故障如何在架构中传播？哪个组件负责？只是领事吗？还是 zeroMq 也是？

请指教。

4

2 回答 2

3

我参与了一个使用基于 Docker 的微服务和 Consul 的大型项目。（我们使用的是不同的队列服务——RabbitMQ，所以我不能详细说明这方面，但总的来说，队列就是队列。）

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

要添加自动缩放功能，您需要查看 Kubernetes 之类的东西。

你可以看看像 CloudFoundry 或 Mesos 这样的东西。但是，这两者都需要一个虚拟化层，例如 OpenStack 或 VMWare vSphere。这些产品带来了巨大的价值，但也带来了价格和复杂性。

与其走那条路，我建议你研究一下亚马逊网络服务。使用 AWS，您可以轻松运行 docker 容器并根据 CPU 负载、队列中的消息、一天中的时间（或一周中的一天）等设置自动缩放。我知道使用 AWS 是有代价的，但如果设计和管理得当，它的成本远远低于尝试自己设计、实施和维护的成本。您还可以使用最小（即免费）的机器和/或 Spot 实例来最小化成本。

于 2015-11-07T03:45:32.083 回答
2

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

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

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

    或者，您可以依靠@drhender 详述的自动扩展解决方案：Kubernetes、Mesosphere DCOS 或 AWS Autoscaling Groups。但是请注意，使用 AWS Autoscaling Groups 会显着限制您的解决方案的可移植性。

    无论您选择何种自动缩放机制，请确保您的 ZeroMQ 消息模式支持添加或删除的服务。ZeroMQ 指南对这个主题有很好的建议。

  3. Consul 可以同时提供服务发现和服务配置需求。如果您要存储 PHI 或 PII 等敏感数据，请记住存储安全问题。使用 Vault 用品等静态保护措施可以更好地存储它们。

    Consul 代理收集遥测数据，您可以监控这些遥测数据。还有一个相当简单的Consul KV 基准测试套件，您可以使用它来测试配置存储。

    ZeroMQ 并不是直接为服务发现而设计的。您可以选择一个中央代理架构，该架构不需要单独的服务发现，但具有不同的可伸缩性和容错含义。假设您在绑定 SUB 套接字时使用多部分消息和主题订阅，则它具有每条消息的有效负载开销。有很多方法可以单独使用 ZeroMQ 进行服务发现，但在考虑容错和共识时，这将是非常重要的。

  4. 节点故障是一个有趣的挑战。Consul 可以通过健康检查知道，但 ZeroMQ 会根据消息传递模式产生一些挑战。例如，如果发送请求并且响应者在交付后死亡，则使用 REQ-REP 对，根据我的经验，REQ 套接字将永远阻塞。有一些方法可以解决这个问题。

    我会为此依靠 Consul，并准备在失败时中断或重新生成 REQ 套接字。通过使用分阶段事件驱动架构 (SEDA) 完全避免 RPC 样式交互，其中输入的生产者不是输出的消费者，几乎完全避开了这一点。您总是面临在失败时丢失排队输入或输出的挑战，因此如果丢失工作是致命的，您需要系统级监控和重试机制。

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

于 2015-12-24T16:10:57.430 回答