首次公开!菜鸟弹性调度系统的架构设计阅读心得

菜鸟方舟(ark)是面向菜鸟所有研发的资源管理和运维平台,负责对菜鸟的基础设施资源进行管控,以支撑日常和大促的资源需求。弹性调度是菜鸟方舟的一个重要组成部分,也是方舟的一个重要的功能特性。

通过弹性调度,能够使应用在业务压力上升时及时扩充资源,而在业务压力下降时对资源进行释放,从而实现在保证稳定性的前提下尽可能地提升资源使用效率。在未来引入离线任务进行混部,或者细粒度资源计价方式后,这种模式将会大幅度降低菜鸟整体IT成本。今天,我们来细细聊聊菜鸟方舟弹性调度系统背后的技术,希望对你有所启发。

为什么菜鸟更适合落地弹性调度?

弹性调度虽然能够带来较大的使用收益,但并不是适用于所有的公司或组织,而其之所以能够成功在菜鸟进行落地,主要取决于以下几点原因:

  • 菜鸟的业务特点决定系统是协调商家,cp,消费者之间的信息流转,而且物流订单流转的长链路多交互的特点也决定了信息流大于实操流即可,所以我们的系统面临导购秒杀型的脉冲峰值菜鸟方舟弹性调度系统场景微乎其微。 

  • 菜鸟在2017年年初全面实现容器化并且接入混合云架构体系后,已经完成了资源管理从“面向机器”到“面向应用”的转变,应用的部署、扩缩容等核心运维流程得到了极大的简化和提效。方舟平台作为容器资源管控平台,在经历了2017年618、双十一等大促活动的考验后,其稳定性已经得到了充分的验证,这就为弹性调度的落地创造了充分的技术基础。 

  • 菜鸟的核心应用绝大多数都属于无状态的在线计算应用,每天业务压力峰谷值差距明显,这就为弹性调度的落地提供了足够的业务场景基础。

  • 弹性调度并不是一项独立的工程,需要很多基础服务进行协助,并且依赖于统一、规范的系统环境。而菜鸟的应用遵从阿里集团规范,弹性调度可以直接读取alimonitor、鹰眼、alimetrics等工具提供的监控运维数据,并且核心应用所使用的技术栈基本上得到了收敛,这就位弹性调度的落地提供了充分的环境基础。

基于如上四点,菜鸟才能以较小的成本快速实现了弹性调度。

为什么采用三层决策的模式?

首先介绍一下方舟弹性调度的三层决策:

1.第一层是策略决策,策略决策层由多个不同的策略组成,并且支持快速扩展。策略之间逻辑完全隔离,每个策略计算完成后都会独立输出动作(扩容、缩容、不变)和数量。为了能够适应不同应用之间的异构,每个应用分组也可以根据实际情况启动或关闭不同的策略。

2.第二层是聚合决策,聚合决策收集第一层所有策略的决策结果,并依据聚合规则得到一个合并后的<动作,数量>组。这一层的规则十分简单:当同时存在扩容和缩容决策结果时,以扩容为准,忽视缩容结果;当存在多个扩容结果时,以扩容数量最多的结果作为最终结果;当存在多个缩容结果时,以缩容数量少的结果作为最终结果。

3.第三层是执行决策,这部分决策主要会考虑到一些规则,最终告诉扩缩容服务:要不要扩缩,要扩缩多少个容器,如果是缩容那么要缩容哪几个具体容器,如果是扩容那么具体的容器规格、扩容到的机房等。执行决策进行判断时需要考虑到的规则非常复杂,这里简单罗列一些相对重要的规则:

  • 机房均摊规则; 

  • 当前应用分组的扩缩容状态规则,例如如果本次为扩容:如果正在扩容,当本次扩容目标数量大于正在扩容的目标数量时,取差值再次发起一个扩容,由此实现并行扩容;当本次扩容目标数量小于正在扩容的目标数量时,忽略本次的扩容请求;若正在进行缩容,则立即停止缩容,并根据目标容器数和当前容器数发起扩容。 

  • 模式规则:弹性调度目前支持全自动扩缩模式、人工审批模式两种,如果当前分组为人工审批模式,那么本次决策会需要管理员进行审批。 

  • 最大值最小值保护规则:应用分组可以配置最大值最小值,执行决策会保证由弹性调度发起的扩缩任务,不会使最终容器数超过最大值或小于最小值。

此外,执行决策层对于单个分组来说是强一致的,并且第二层输出的决策结果,是集群需要达到的目标容器数量,这种设计是前两层能够做到完全无状态且幂等的重要因素。 

三层决策器使每一层只需要关注自己本身的决策逻辑,分离了“变与不变”的业务逻辑,对扩缩容的最终确定进行层层验证,是实现“覆盖菜鸟大多数应用”目标的基础。

如何做到计算的无状态、幂等和高可用?

1.方舟弹性调度深度依赖了ISS,ISS作为一款经历过大促考验,并且为菜鸟很多核心业务提供异步任务调度服务的高可用中间件,在功能、性能和稳定性上都非常可靠。方舟弹性调度对于在线数据的获取采用了“短频周期性主动拉取”的模式,通过ISS提供的周期性异步任务调用功能,为每个应用分组在接入弹性时自动注册一个独立的ISS周期任务。ISS在发起任务时,会在目标集群中随机进行选取,并且对任务执行时的生命周期进行管理,支持任务的重试。此外,ISS的客户端也提供资源保护能力,当集群中的某个进程压力过高时会更换目标机进行重试。

2.方舟弹性调度的在线计算数据源自于内嵌式监控系统alimetrics。alimetrics是伴随web容器的一种嵌入式metrics系统,包含非常丰富的监控项。当需要获取应用分组的细粒度监控数据时,这种数据查询、读取、传输压力是被分摊到每一个目标容器的,而非一个集中式的数据中心,这种设计使得数据源不存在单点,数据源的可靠性和压力容忍能力相比于依赖一个中心式的数据服务来说,要优越很多。

3.为了过滤毛刺,所有计算都基于或大或小的滑动时间窗口。通过alimetrics获取较短时间窗口(1小时以内)数据时能拥有非常高的性能,并且对应用的干扰非常小,这样就降低了计算的重试成本。基于这一能力,弹性调度的计算任务可以在每次执行时重新获取一个时间窗口内的全部监控数据,而不需要在自身内存中维护一个滑动窗口,这是弹性调度计算无状态的基础;

4.弹性调度三层决策器中,第三层与其他两层部署在不同的集群中。由于无论应用分组状态如何,第一层和第二层都要进行短频周期性计算,而只有在需要进行扩缩容时(只占一天中很小的一部分)才会将任务发往第三层,因此将强一致性的范围限定在第三层,在保证可靠性的同时,对性能影响最少。而第二层输出到第三层的决策数量,以“目标容器数”而非“扩缩容数量”的形式给出,这样一来,即使在同一时刻对于一个应用分组有多个弹性决策任务在执行,向第三层输出多个决策结果,也不会影响最终的扩缩容行为。

原文地址:https://www.cnblogs.com/andibier/p/11055187.html