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

架构&设计 微服务

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

作者： Andrew Morgan

正文：

在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