江苏龙网

  1. 首页 > 人文 > >

阿里经济体核心调度系统Fuxi( 四 )


2.1 单调度器的局限性
2.1.1 线上的规模与压力
大数据计算的场景与需求正在快速增长（下图是过去几年MaxComputer平台计算和数据的增长趋势） 。 单集群早已突破万台规模 ， 急需提供十万台规模的能力 。
阿里经济体核心调度系统Fuxi
本文插图
图. MaxCompute 2015 ~ 2018线上作业情况
但规模的增长将带来复杂度的极速上升 ， 机器规模扩大一倍 ， 资源请求并发度也会翻一番 。 在保持既有性能、稳定性、调度效果等核心能力不下降的前提下 ， 可以通过对调度器持续性能优化来扩展集群规模（这也是伏羲资源调度1.0方向） ， 但受限于单机的物理限制 ， 这种优化总会存在天花板 ， 因此需要从架构上优化来彻底规模和性能的可扩展性问题 。
2.1.2 调度需求的多样性
伏羲支持了各种各样的大数据计算引擎 ， 除了离线计算（SQL、MR) ， 还包括实时计算、图计算 ， 以及近几年迅速发展面向人工智能领域的机器学习引擎 。
阿里经济体核心调度系统Fuxi
本文插图
图. 资源调度器的架构类型
场景的不同对资源调度的需求也不相同 ， 比如 ， SQL类型的作业通常体积小、运行时间短 ， 对资源匹配的要求低 ， 但对调度延时要求高 ， 而机器学习的作业一般体积大、运行时间长 ， 调度结果的好坏可能对运行时间产生直接影响 ， 因此也能容忍通过较长的调度延时换取更优的调度结果 。 资源调度需求这种多样性 ， 决定了单一调度器很难做到“面面俱到” ， 需要各个场景能定制各自的调度策略 ， 并进行独立优化 。
2.1.3 灰度发布与工程效率
资源调度系统是分布式系统中最复杂最重要的的模块之一 ， 需要有严苛的生产发布流程来保证其线上稳定运行 。 单一的调度器对开发人员要求高 ， 出问题之后影响范围大 ， 测试发布周期长 ， 严重影响了调度策略迭代的效率 ， 在快速改进各种场景调度效果的过程中 ， 这些弊端逐渐显现 ， 因此急需从架构上改进 ， 让资源调度具备线上的灰度能力 ， 从而幅提升工程效率 。
2.2 去中心化的多调度器架构
为了解决上述规模和扩展性问题 ， 更好地满足多种场景的调度需求 ， 同时从架构上支持灰度能力 ， 伏羲资源调度2.0在1.0的基础上对调度架构做了大规模的重构 ， 引入了去中心化的多调度器架构 。
阿里经济体核心调度系统Fuxi
本文插图
图. 资源调度的架构类型
我们将系统中最核心的资源管理和资源调度逻辑进行了拆分解耦 ， 使两者同时具备了多partition的可扩展能力（如下图所示） ， 其中：? 资源调度器（Scheduler）：负责核心的机器资源和作业资源需求匹配的调度逻辑 ， 可以横向扩展 。 ? 资源管理和仲裁服务（ResourceManagerService ， 简称RMS）：负责机器资源和状态管理 ， 对各个Scheduler的调度结果进行仲裁 ， 可以横向扩展 。 ? 调度协调服务（Coordinator）：管理资源调度系统的配置信息 ， Meta信息 ， 以及对机器资源、Scheduler、RMS的可用性和服务角色间的可见性做仲裁 。 不可横向扩展 ， 但有秒级多机主备切换能力 。 ? 调度信息收集监控服务（FuxiEye）：统计集群中每台机的运行状态信息 ， 给Scheduler提供调度决策支持 ， 可以横向扩展 。 ? 用户接口服务（ApiServer）：为资源调度系统提供外部调用的总入口 ， 会根据Coordinator提供的Meta信息将用户请求路由到资源调度系统具体的某一个服务上 ， 可以横向扩展 。
阿里经济体核心调度系统Fuxi
本文插图
图. 伏羲多调度器新架构


推荐阅读


上一篇：『美军』美国欠中国的钱可造一万架歼-20，如果不还怎么办？专家称美国不敢

下一篇：那个年薪3亿的“打工皇帝” 终究是雷军得不到的男人