Level2调度架构通过资源获取和任务隔离来解决这个问题。这样任务调度逻辑就可以针对特定的应用，同时也保持了跨集群共享的能力。Mesos的集群管理是这方面的先行者，而YARN支持部分功能。在Mesos中，资源由应用级调度器提供（挑选和选择），而YARN允许应用级调度器请求资源（获得配额作为回报）。图1b显示了基本思想：负责负载的调度程序(S0-S2)与资源管理器交互，资源管理器为集群资源的每个负载动态分区。这种方法可以支持定制的、负载特定的调度策略。现在，关注点分离的两级架构带来了一些缺点：应用级调度器丢失了一些知识，例如，他们看不到所有可能的资源点，而且他们基本上看不到这些和资源管理器组件提供的选项相关资源获取(Mesos)或分配(YARN)。这有一些缺点：优先级抢占变得困难（高优先级任务踢出低优先级任务）：在provision-based模型中，运行任务的资源对于上层调度器是不可见的；在基于请求的模型中，低级资源管理器必须了解抢占策略（可能依赖于应用程序）。调度程序无法解释在负载下运行的降级资源（例如，“吵闹的邻居”抢夺IO资源），因为他们看不到他。应用级调度器关心下游资源的许多不同方面，但它们只有资源管理器的提供/请求接口。这个界面很容易变得复杂。SharedStateArchitecture将此问题转化为分布式模型，其中集群状态的多个副本由应用程序级调度程序单独更新，如图1c所示。本地更改后，调度程序启动乐观更新事务以更新共享集群状态。很明显，事务可能会失败：不同的调度程序可能同时进行了冲突的更改。最著名的使用共享状态的设计是谷歌的Omega、微软的Apollo和Hashicorp的Nomad容器调度程序。上面的豆浆共享集群状态现在是一个单点：Omega的“cellstate”，Apollo的“resourcemonitor”，Nomad的“planqueue”。Apollo与其他两者的不同之处在于它的共享状态是只读的，预定的事务直接提交给集群机器。机器本身会检查冲突并选择接受或拒绝更改。这允许Apollo在共享状态暂时不可用时进行调度。可以在不实现整个集群状态的情况下记录“逻辑”共享状态设计。通过这种方式（类似于Apollo所做的），每台机器都维护自己的状态并将更新发送到不同的代理，例如调度程序、机器健康监视器和资源监视系统。每台机器自己的本地状态视图现在形成了全局共享状态的碎片。当然，共享状态架构也有一些缺点：它们必须使用状态信息（与集中式调度程序不同），并且在遇到高层竞争时会降低调度性能（尽管其他架构也会受到影响）。本文来自微信公众号《麦芽面包》，id“darkjune_think”转载请注明。微信扫一扫关注公众号。交流邮箱：zhukunrong@yeah.net
