实例分析分布式系统设计的一般性原则

　　本文涉及阿里云分布式调度团队在分布式调度系统的设计、实现、优化等方面的实践以及由此总结的分布式系统设计的一般性原则，具体包括分布式调度的任务调度、资源调度、容错机制、规模挑战、安全与性能隔离以及未来发展方向六部分。

　　云计算并不是无中生有的概念，它将普通的单台PC计算能力通过分布式调度软件连接起来。其最核心的问题是如何把一百台、一千台、一万台机器高效地组织起来，灵活进行任务调度和管理，从而可以像使用台式机一样使用云计算。在云计算中，最核心的模块是分布式调度，它好比云计算的中央处理器。目前，业界已存在多种分布式调度实现方案，如伏羲、Hadoop MapReduce、YARN、Mesos等系统。

　　阿里云伏羲

　　伏羲系统在前人的基础上进行了一系列改造，首先与YARN和Mesos系统类似，将资源的调度和任务调度分离，形成两层架构，使其具备以下优势：

　　规模：两层架构易于横向扩展，资源管理和调度模块仅负责资源的整体分配，不负责具体任务调度，可以轻松扩展集群节点规模；

　　容错：当某个任务运行失败不会影响其他任务的执行；同时资源调度失败也不影响任务调度；

　　扩展性：不同的计算任务可以采用不同的参数配置和调度策略，同时支持资源抢占；

　　调度效率：计算framework决定资源的生命周期，可以复用资源，提高资源交互效率。

　　这套系统目前已经在阿里集团进行了大范围的应用，能支持单集群5000节点、并发运行10000作业、30分钟完成100T数据terasort，性能是Yahoo在Sort Benchmark的世界纪录的两倍。

　　伏羲的系统架构

　　伏羲的系统架构如图1所示，整个集群包括一台Fuxi Master以及多台Tubo。其中Fuxi Master是集群的中控角色，负责资源的管理和调度；Tubo是每台机器上都有的一个Agent，负责管理本台机器上的用户进程；同时集群中还有一个叫Package Manager的角色，因为用户的可执行程序以及一些配置需要事先打成一个压缩包并上传到Package Manager上，Package Manager专门负责集群中包的分发。

　　图1 伏羲的系统架构

　　集群部署完后，用户通过Client端的工具向Fuxi Master提交计算任务；Fuxi Master接收到任务后首先通知某一个Tubo启动这个计算任务所对应的APP Master；APP Master启动之后，它获知了自己的计算任务，包括数据分布在哪里、有多少的任务需要计算等等信息；接着APP Master会向Fuxi Master提交资源申请，表明它需要多少计算资源；Fuxi Master经过资源调度以后，将资源的分配结果下发给APP Master；APP Master在这个资源的基础之上进行它的任务调度，来决定哪些机器上运行哪些计算任务，并且将这个计算任务发送给对应机器上的Tubo进程；Tubo接受到命令之后就会从Package Manager中下载对应的可执行程序并解压；然后启动用户的可执行程序，加载用户的配置（图1中的APP Worker）；APP Worker根据配置中的信息读取文件存储系统中的数据，然后进行计算并且将计算结果发往下一个APP Worker。其中，数据的切片称之为Instance或者叫计算实例。

　　Fuxi Master与Tubo这套结构解决了分布式调度中的资源调度，每个计算任务的APP Master以及一组APP Worker组合起来解决任务调度的问题。

　　任务调度

　　伏羲在进行任务调度时，主要涉及两个角色：计算框架所需的APP Master以及若干个APP Worker。