原文地址：http://www.firmament.io/blog/...Hybrid架构是最近出现的，致力于结合单一或共享状态的设计，解决其缺点全分布式架构。这通常没问题-例如，在Tarcil(http://dl.acm.org/citation.cf...)、Mercury(https://www.usenix.org/confer...)和Hawk(https://www.usenix.org/confer...)-有两种调度路径：一种是分布式处理工作负载（例如，非常短的任务，或低优先级的批处理任务），另一种是中央处理其他任务.图1e演示了此设计。每个混合调度器的行为方式与上述架构相同。在实际实践中，据我所知，目前还没有在生产中部署混合调度器。这在实践中意味着什么？上面讨论的不同调度架构并不完全是一个学术话题，尽管它们确实出现在研究论文中。有关从行业角度对Borg、Mesos和Omega论文的扩展的讨论，请参阅AndrewWang的优秀博文(http://umbrant.com/blog/2015/...)。此外，所讨论的许多系统都部署在大型企业的生产环境中（Microsoft的Apollo、Google的Borg、Apple的Mesos），它们启发了其他可用的开源项目。最近很多集群开始运行容器，于是出现了很多以容器为中心的“编排框架”。这些类似于谷歌和其他人所说的“集群管理器”。然而，关于调度器讨论的一些细节已经融入到这些框架及其设计规范中，通常它们的重点是面向用户的调度API（由ArmandGrillet报道http://armand.gr/static/files...，它比较了DockerSwarm、Mesos/Marathon、Kubernetes默认调度程序）。此外，许多用户没有意识到调度器架构之间的差异以及哪一种架构适合他们的应用程序。图2显示了开源编排框架、它们的调度程序架构和支持的功能的概览。在表格的底部，我们还包括来自谷歌和微软的闭源系统。资源粒度一栏表示调度器是将任务分配到一个固定大小的slot，还是按照多个维度（CPU、内存、磁盘I/O借贷、网络带宽等）分配资源。确定合适的调度架构的一个关键点是您的集群是否正在运行混合工作负载。比如这个案例，就是同时有在线服务（原：前端服务）（web负载均衡服务和memcached）和批量数据分析（MapReduce或Spark）的时候。这种类型对提高利用率很有意义，但不同的应用程序有不同的调度需求。在混合设置中，单片调度器只能产生次优解决方案，因为无法在每个应用程序的基础上调整单个逻辑，而两层或共享状态调度器可以提供更好的产量。大多数面向用户的在线工作负载旨在使用所有资源来满足每个容器的峰值需求，但这导致它们的利用率低于分配的资源。在这种情况下，优化具有低优先级工作负载（保证QoS）的超额资源成为优化高效集群的关键。Mesos是目前唯一支持超额订阅的开源系统，而Kubernetes也有提案（http://kubernetes.io/v1.1/doc...）加入这个功能。我们预计未来该领域会有更多活动，因为目前许多集群的使用率实际上低于GoogleBorg集群报告的60-70%(http://dl.acm.org/citation.cf...)%。未来我们会陆续发布容量规划、超额认购、机器高效利用等方面的内容。最后，某些分析和OLAP类型的应用程序（例如，Dremel或SparkSQL查询）可以受益于完全分布式的调度程序。然而，全分布式调度器（如Sparrow）有非常严格的特征集限制，当任务负载是相同类型时（例如，所有任务大约同时运行），它具有良好的性能，设置时间低（例如，任务被调度到长时间运行的worker，像YARN中的MapReduce应用级任务），任务会大量产生（例如短时间内会产生很多调度判断）。我们将在本系列的下一篇博文中更详细地讨论为什么完全分布式调度程序-混合调度程序的分布式组件仅在这些应用程序中有意义。现在，分布式调度器比其他调度器更简单，并且不支持多资源维度、超额订阅或重新调度。总的来说，图2表明开源框架在支持闭源系统的上述高级功能之前还有一段路要走，这是一个号召性用语：由于功能缺失、使用不当、任务性能不可靠、邻居嘈杂导致半夜被吵醒，针对某些用户需求定制的黑科技。然而，有一些好消息：今天的许多框架仍然是单一的调度器，它们开始转向更灵活的设计。Kubernetes已经开始支持插件式调度器（kube-schedulerpod可以换成另一个兼容API的调度器pod），很多调度器在V1.2（https://github.com/kubernetes...）之后，开始支持自定义策略（https://github.com/kubernetes...）。DockerSwarm也可能——据我所知——添加对可插拔调度程序的支持。最后推荐一本书，内容是第一手的阿里工程师在线问题处理案例，值得一读。欢迎与我交流关于阿里VIPServer的软负载。发布会详情及目录请见：《逆流而上：阿里巴巴技术成长之路》大甩卖长按图片识别二维码关注。通讯邮箱：zhukunrong@yeah.net
