感悟:菜鸟弹性调度系统的架构设计

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

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

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

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

  • 机房均摊规则;
  • 当前应用分组的扩缩容状态规则,例如如果本次为扩容:如果正在扩容,当本次扩容目标数量大于正在扩容的目标数量时,取差值再次发起一个扩容,由此实现并行扩容;当本次扩容目标数量小于正在扩容的目标数量时,忽略本次的扩容请求;若正在进行缩容,则立即停止缩容,并根据目标容器数和当前容器数发起扩容。
  • 模式规则:弹性调度目前支持全自动扩缩模式、人工审批模式两种,如果当前分组为人工审批模式,那么本次决策会需要管理员进行审批。
  • 最大值最小值保护规则:应用分组可以配置最大值最小值,执行决策会保证由弹性调度发起的扩缩任务,不会使最终容器数超过最大值或小于最小值。

目前,方舟的弹性调度还处于一个发展成长的过程中,对于一些应用的调度效果还要进行进一步的提升。

原文地址:https://www.cnblogs.com/xiaohaigege666/p/10811930.html

时间: 2024-11-04 08:35:50

感悟:菜鸟弹性调度系统的架构设计的相关文章

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

阿里妹导读:菜鸟方舟(ark)是面向菜鸟所有研发的资源管理和运维平台,负责对菜鸟的基础设施资源进行管控,以支撑日常和大促的资源需求.弹性调度是菜鸟方舟的一个重要组成部分,也是方舟的一个重要的功能特性. 通过弹性调度,能够使应用在业务压力上升时及时扩充资源,而在业务压力下降时对资源进行释放,从而实现在保证稳定性的前提下尽可能地提升资源使用效率.在未来引入离线任务进行混部,或者细粒度资源计价方式后,这种模式将会大幅度降低菜鸟整体IT成本.今天,我们来细细聊聊菜鸟方舟弹性调度系统背后的技术,希望对你有

分布式发布订阅消息系统 Kafka 架构设计[转]

分布式发布订阅消息系统 Kafka 架构设计 转自:http://www.oschina.net/translate/kafka-design 我们为什么要搭建该系统 Kafka是一个消息系统,原本开发自LinkedIn,用作LinkedIn的活动流(activity stream)和运营数据处理管道(pipeline)的基础.现在它已为多家不同类型的公司 作为多种类型的数据管道(data pipeline)和消息系统使用. 活动流数据是所有站点在对其网站使用情况做报表时要用到的数据中最常规的部

一个小型的网页抓取系统的架构设计

一个小型的网页抓取系统的架构设计 网页抓取服务是互联网中的常用服务,在搜索引擎中spider(网页抓取爬虫)是必需的核心服务.搜索引擎的衡量指标"多.快.准.新"四个指标中,多.快.新都是对spider的要求.搜索引擎公司比如google.baidu都维护者自己负责的spider系统.当然他们的系统很复杂,在这里我们介绍一个小型的网页抓取系统的架构,目标是快速的抓取某个或者几个指定的网站的数据,它的作用有很多,比如做竞品分析,还有其他不可告人的J. 下面这个小型的网页抓取系统,分成下面

中间件系统的架构设计

中间件系统的架构设计 Master-Slave架构   该系统的本质是希望能够用分布式的方式来处理一些数据,核心思想,就是把数据分发到很多台机器上来处理,然后需要有一台机器来控制N多台机器的分布式处理: 分布式的处理,就会肯定涉及到在Master中要维护这个集群的一些核心元数据.数据的分发处理的调度,处理的具体过程的进度,对集群里存放数据进行描述的一些核心元数据. 这些核心元数据会不断的频繁的修改,无论你是基于外部的文件还是数据库,或者是zookeeper来存放这些元数据的话,其实都会导致他的元

EasyScheduler调度系统的架构原理及实现思路

系统架构设计 在对调度系统架构说明之前,我们先来认识一下调度系统常用的名词 1.名词解释 DAG: 全称Directed Acyclic Graph,简称DAG.工作流中的Task任务以有向无环图的形式组装起来,从入度为零的节点进行拓扑遍历,直到无后继节点为止.举例如下图: 流程定义:通过拖拽任务节点并建立任务节点的关联所形成的可视化DAG 流程实例:流程实例是流程定义的实例化,可以通过手动启动或定时调度生成 任务实例:任务实例是流程定义中任务节点的实例化,标识着具体的任务执行状态 任务类型:

途牛原创|途牛无线权限系统的架构设计与实践

序 之前写过一篇大话权限中心的PHP架构之道,主要是从软件工程角度介绍,如何通过编码规范.依赖管理.数据源架构.事务处理.单元测试等技术,来保障权限系统的高可用,并未真正的涉及这套系统的架构. 今天准备从设计细节上分享一二. 望各位看官,心有“空杯”,带着“问题”一探究竟. 0. RBAC3 这里还是尤为的重要,因为他是整套系统设计的根基. 所以残忍的从上一篇中复制了一遍... RBAC认为权限授权实际上是Who.What.How的问题.在RBAC模型中,who.what.how构成了访问权限三

实时海量日志分析系统的架构设计、实现以及思考

1 序 对ETL系统中数据转换和存储操作的相关日志进行记录以及实时分析有助于我们更好的观察和监控ETL系统的相关指标(如单位时间某些操作的处理时间),发现系统中出现的缺陷和性能瓶颈. 由于需要对日志进行实时分析,所以Storm是我们想到的首个框架.Storm是一个分布式实时计算系统,它可以很好的处理流式数据.利用storm我们几乎可以直接实现一个日志分析系统,但是将日志分析系统进行模块化设计可以收到更好的效果.模块化的设计至少有两方面的优点: 模块化设计可以使功能更加清晰.整个日志分析系统可以分

分布式公布订阅消息系统 Kafka 架构设计

我们为什么要搭建该系统 Kafka是一个消息系统,原本开发自LinkedIn,用作LinkedIn的活动流(activity stream)和运营数据处理管道(pipeline)的基础. 如今它已为多家不同类型的公司 作为多种类型的数据管道(data pipeline)和消息系统使用. 活动流数据是全部站点在对其站点使用情况做报表时要用到的数据中最常规的部分.活动数据包含页面訪问量(page view).被查看内容方面的信息以及搜索情况等内容.这样的数据通常的处理方式是先把各种活动以日志的形式写

分布式发布订阅消息系统 Kafka 架构设计

我们为什么要搭建该系统 Kafka是一个消息系统,原本开发自LinkedIn,用作LinkedIn的活动流(activity stream)和运营数据处理管道(pipeline)的基础.现在它已为多家不同类型的公司 作为多种类型的数据管道(data pipeline)和消息系统使用. 活动流数据是所有站点在对其网站使用情况做报表时要用到的数据中最常规的部分.活动数据包括页面访问量(page view).被查看内容方面的信息以及搜索情况等内容.这种数据通常的处理方式是先把各种活动以日志的形式写入某