动态可扩展和自适应架构

时间:2015-11-05 23:21:28

标签: docker zeromq microservices consul

我是云计算的博士生,我计划在我的研究项目中使用基于微服务的架构与consul和zeromq。我几乎没有发现我难以理解的问题。有人可以帮助我分享他们的经验。

  1. 我们有基于码头工人的微服务,我们有zeromq,我们有领事。您能否提及我们如何将所有三者结合在一起以形成动态自适应环境?
  2. 虽然我理解zeromq,docker和consul是单独的,我仍然无法清楚地了解它们如何作为一个整体运行。我们有一个docker容器,在主机上运行微服务。我们使用zeromq在docker容器之间传输消息(Pub-sub / pipeline)。容器可以在同一主机/数据中心上运行,也可以在不同的主机/数据中心上运行。然后我们使用consul进行服务发现。我的理解是正确的吗?

    1. 架构如何根据工作负载动态扩展/缩小?
    2. 说,我有一种情况,我需要更多的工作节点来进行特定的计算。谁旋转了更多的工作节点。哪个组件决定/做出此决定?

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

      1. 那么,领事的主要作用是什么?它是否仅用于服务发现?它是否也可用于配置。如果是这样,它的局限性是什么?
      2. 我看到即使是zeromq也有服务发现机制,为什么我们需要领事?

        1. 如何在架构中传播节点信息的失败?哪个组件负责?这只是领事吗?还是零甚至?
        2. 请建议。

2 个答案:

答案 0 :(得分:3)

我参与了一个使用基于Docker的微服务和Consul的大型项目。 (我们正在使用不同的排队服务 - RabbitMQ,所以我不能详细谈论这个方面,但一般来说,队列就是队列。)

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

要添加自动缩放功能,您需要查看类似Kubernetes的内容。

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

我建议您查看Amazon Web Services,而不是走这条路。使用AWS,您可以轻松运行docker容器并根据CPU负载,队列中的消息,一天中的时间(或一周中的某天)等设置自动缩放。我知道使用AWS带有价格标签,但设计和管理得当,它的成本远远低于尝试设计,实施和维护自己的成本。您还可以使用最小(即免费)的机器和/或实例来最小化成本。

答案 1 :(得分:2)

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

  1. Docker:管理各个服务的包装并交付到基础架构上 ZeroMQ:管理服务之间的有效点对点或代理通信 领事:服务发现(例如,找出用户服务的位置)

  2. Docker不执行自动缩放。您可以使用自己的微服务来检查负载指标(例如,负载平均值,物理/交换内存使用情况等)并旋转复制副本并更新Consul。

    或者,您可以依靠@drhender详细说明的自动缩放解决方案:Kubernetes,Mesosphere DCOS或AWS Autoscaling Groups。但请注意,使用AWS Autoscaling Groups会显着限制解决方案的可移植性。

    无论您选择何种自动调节机制,请确保您的ZeroMQ消息模式支持添加或删除服务。 ZeroMQ Guide对此主题有很好的建议。

  3. Consul可以提供服务发现和服务配置需求。如果要存储PHI或PII等敏感数据,请记住存储安全问题。这些可以更好地存储在静态保护中,例如Vault供应。

    The Consul agent collects telemetry您可以监控问题。您还可以使用相当简单的Consul KV benchmarking suite来测试配置存储。

    ZeroMQ不是直接用于服务发现的。您可以选择集中式代理架构,无需单独进行服务发现,但这具有不同的可扩展性和容错能力。假设您在绑定SUB套接字时使用多部分消息和主题订阅,则它具有每消息有效负载开销。有很多方法可以单独使用ZeroMQ进行服务发现,但是在考虑到faukt容忍度和共识时,这将是非常重要的。

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

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

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