微服务架构中使用的分布式调度器

  • Andrew Morgan
  • Rays

2017 年 8 月 22 日

话题:DevOps语言 & 开发架构文化 & 方法Kubernetes

在 MicroXchg 2017 柏林大会上,DigitalOcean 的微服务可扩展性专家 Martin Campbell 针对如何使用分布式调度器运行基于微服务的架构做了一个演讲。在演讲中,Campbell 着重介绍了在他们在部署过程中遇上的一些问题,以及在他们是如何权衡选用 Kubernetes、Nomad 和 Mesos 等产品的。

演讲的关键要点包括:

  • 分布式调度器使得用户可将集群理解为单一的物理机。
  • 分布式调度器简化了 DevOps,大大降低了普遍存在于基于微服务架构中的操作复杂性。
  • 没有任何现有产品可以完美地运行有状态服务,因此最好不要使用现有产品去运行这类服务。
  • 在网络分区的情况下,即便有些过程所在的主机节点不能与主服务器通信,容错的分布式调度器也应该保持所有进程的运行。

Campbell 首先指出,操作系统内核就是一种集中式调度器,因为它在单一计算机上实现了对多个进程的管理。他进而阐述了分布式调度在概念上与集中式调度器是类似的,差别在于它是跨集群中各机器工作的,而非工作于单一机器上。“我们可以与整个数据中心通信,就像是面对单台物理机一样。”

分布式调度器尤其适用于微服务架构。Cambell 认为这是考虑到那些额外的操作开销,这些操作开销是由不断得以扩展和部署的多个服务所导致的。

对于如何选择多种分布式调度器的问题,Campbell 首先介绍了他在 Mesos 上的实战经验。当使用 Mesos 时,用户不需操心进程所在的实际物理机,因为 Mesos 是基于对 CPU 和 RAM 等资源的限额处理做部署的。Mesos 还提供了一个仪表盘,可像查看单一物理机那样方便地实现数据中心的可视化。

Campbell 指出,Mesos 的主要问题在于它对网络分区的处理方式。如果一个进程不能与 Mesos 的主服务器通信,那么该进程就会被杀掉。在 Campbell 看来,这并非是一种好的设计方式,事实上,因为网络分区普遍存在于分布式系统中,在这种情况下应该继续保持应用的运行。他以 Kafka 为例说明了这种行为会导致数据的丢失。虽然 Kafka 是一种分布式消息总线,在设计上考虑了弹性问题,但是分区还是可以导致丢失几乎全部的单一节点及数据。

Campbell 最终弃用了 Mesos,他先是转向 Nomad 作为替代。Nomad 的优点在于,它具有自身的 Gossip 协议,允许服务器在同一数据中心中及跨数据中心间的相互通信。在网络分区的情况下,同一分区中的服务会保持功能及通信,并在分区识别时成为最终一致的。但是由于 Campbell 并不了解有任何在生产环境中运行 Nomad 的应用,因而不想冒险迁移到 Nomad 上。

他最终选定了 Kubernetes。尽管 Kubernetes 类似于 Mesos,Campbell 还是从中发现一些独到之处。最主要是,Kubernetes 对网络分区处理机制不同,并不会在上述情况下杀死实例。它也提供了仪表盘,让用户易于了解集群的状态,减少了处理应用中的抽象层级。

该演讲的视频可以在线完整观看,其中详细地介绍了 Campbell 正在处理的应用架构及各种调度器。

查看英文原文: Distributed Schedulers with Microservice Architectures

DevOps语言 & 开发架构文化 & 方法Kubernetes