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

在 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