美团点评容器平台HULK的调度系统

《美团点评容器平台HULK的调度系统》要点：
本文介绍了美团点评容器平台HULK的调度系统，希望对您有用。如果有疑问，可以联系我们。

本文授权转载自微信公众号：美团点评技术团队

美团点评作为国内最大的O2O平台,业务热度的高峰低谷非常显著且规律,如果遇到节假日或促销活动,流量还会在短时间内出现成倍的增长.过去传统虚拟机的服务运行及部署机制在应对服务快速扩容、缩容需求中存在诸多不足：

• 资源实例创建慢,需要预先安装好运行所需的环境,比如JDK等.
• 扩容后的实例,需要经过代码部署流程,一些情况下还需要修改配置后才能承接流量.
• 资源申请容易回收难,促销活动后做相关资源的回收下线会比较漫长.
• 由于业务存在典型的高峰低谷,为保障业务稳定,资源实例数要保障能抗高峰期容量峰值的1-2倍,从而导致非高峰期资源大量闲置,整体利用效率低.

注意到上面这些问题后,我们经过调研与测试,结合业界的实践经验,决定基于Docker容器技术来实现服务的弹性伸缩,有效应对快速扩缩容需求、提升资源利用效率.

Docker容器技术也是一类虚拟化技术,不同于虚拟机的硬件虚拟化,容器是基于操作系统内核的隔离机制实现.容器省去了模拟底层硬件、指令等操作,直接基于宿主机内核,并隔离出独立的系统环境、加以资源限制,能有效提升启动速度和性能.

HULK容器平台简介

美团点评基础架构团队在2015年中旬启动了公司级的容器集群管理及弹性伸缩平台——HULK项目,目标是提供Docker容器平台,推动公司的服务容器化,实现自动的弹性扩容、缩容,提升资源利用率、业务运维效率并降低IT运维成本.

HULK是美国漫威漫画旗下超级英雄“绿巨人”,拥有强大的变身能.变身后的绿巨人对各类疾病、射线、毒药及物理攻击有很高的免疫力,加上超强的再生能力使得其非常强大.

我们选择HULK作为项目名,就是希望美团点评服务在接入HULK之后可以拥有绿巨人般强大的变身能力(弹性扩缩),进而在此基础上提升服务的健壮性、稳定性及资源利用率.

HULK容器平台系统层次图

在HULK所有模块中,调度系统负责对资源池进行统一的调度分配与管理.主要职责包括：

1. 接受上层弹性伸缩及集群管理模块的资源申请、回收请求,执行资源分配.
2. 综合多种资源利用、服务优化的调度算法,决策最优资源部署位置,提高资源利用率、节约成本并保障服务稳定性.
3. 对接云平台IaaS层.

本文将主要对HULK容器平台的调度系统进行介绍,包括当前调度系统的设计、考量指标、相关算法等.

HULK调度系统介绍

核心指标

从HULK弹性调度系统的设计以及后续的演进过程来看,一个完善的调度系统主要需要关注以下三个指标：

调度系统核心指标

• 资源利用率：即提高整体物理集群的资源利用率.一个优秀的调度系统可以把资源利用率提高到30%~70%,而简陋的调度系统甚至会使资源利用率降低到10%以下.
• 业务最优化：即保障运行业务的稳定高可用,以及服务相互调用的优化.比如,如果调度系统一味的追求资源利用率,将宿主机上堆砌超过其负载能力的实例,又或一台宿主机/机架的故障会影响到一个服务下所有实例的运行,都在业务稳定性上打了折扣.
• 并发调度能力：调度系统请求处理能力的体现.一个大规模的物理集群上,往往运行了数以千百计的业务,当出现调度请求高峰的场景下,调度系统要有能力在短时间内给出答案,即使这个答案可能只是全局近似最优解.

调度系统设计难题

调度系统设计的难题,在于几个调度核心指标在实现上存在的矛盾关系,类似于CAP理论中的三要素,无法同时满足.

在CAP理论中,Consistency(一致性)、Availability(可用性)与Partition Tolerance(分区容错性)无法同时满足.如果追求可用性与分区容错性,则需要牺牲强一致性,只能保证最终一致性；而如果要保障强一致性与可用性,如果出现网络故障将无法正常工作.

类似的,在调度系统中,如果要追求极限的资源利用率,则每一次调度的结果必须是基于当前资源池状态的最优解,因此不管调度队列还是调度处理计算只能是“单行道”,效率低下是毋庸置疑的,大批量伸缩调度场景下任务堆积严重.

如果追求高效的调度能力,则所有调度请求需要并发处理.但底层资源池只有一个,很容易出现多个调度请求争抢同一份资源的情况.这种情况下,就要采取措施来保障资源层数据一致性,且调度所得的结果不能保证是全局最优解(无法最大化资源利用率).

业界解决思路

Mesos

Mesos采用双层调度的理念,把应用相关的管理交由上层Framework来做,这也是Mesos与Kubernetes等系统最大的不同点.Mesos只是分布式系统内核,即管理分布式资源、对外暴露标准接口来操作集群资源(屏蔽资源层细节).在双层调度的模式下,Mesos只负责在不同的Framework之间分派资源,将资源作为Offer的形式提供给Framework.

这种做法把上述调度设计矛盾丢给了Framework,但如果只从提供资源Offer的角度来看,这是一种并发调度的形式(同一个Mesos资源池,资源要提供给上层多个Framework).Mesos解决并发调度、资源池数据一致性的方案是,资源Offer同时只会分派给一个Framework.这种资源分派方式是悲观的,资源被Framework独占,直到返回或超时.

显然,这种悲观锁导致了Mesos双层调度的并发粒度较小,但是在多数情况下,同个Mesos集群上层的Framework数量不会太多,有时只有一个Framework在独享资源,因此这种悲观锁的方案一般不会存在分配调度的瓶颈问题.

Omega

Omega同样采用了将资源分派给上层应用的调度方式,与Mesos的悲观锁不同,Omega采用了乐观锁(MVCC,基于多版本的并发访问控制)解决并发调度的问题,因此Omega也被称为共享状态调度器.

（编辑：ASP站长网）