之前写了一篇关于云渲染集群监控与任务调度设计的文章，里面涉及到一部分任务调度，今天主要是对之前任务调度做一些可扩展性的优化，公司最近又打算采购30台服务器，之前那种单层应用的调度方式已经满足不了目前的集群规模以及吞吐量，因此必须对之前的任务调度重构和优化，以提高整个集群的吞吐量以及可靠性和高可用。
随着集群规模不停地壮大，单层应用调度迟早会达到瓶颈，所以想法就是把大集群拆分成若干个小集群，这样将压力分摊下来，提高整个集群调度的可扩展性，具体设计如下：
a. IrayProphet: 任务管理应用，管理不同类型的任务出队，以及对外提供任务更新接口。
b. IraySchedule: 任务调度应用，分组管理渲染引擎和构建应用，负责任务的分发以及调度。
c. Construct: 任务构建服务，主要负责场景转换以及任务提交。
d. ConstructAgent：构建服务代理，主要接受任务并提交给构建服务进行场景转换，并上报任务构建状态。
e. IrayServer：渲染引擎，主要进行图片渲染工作。
f. IrayAgent：渲染引擎代理，主要负责监控任务渲染进度以及上报进度。
任务管理应用(IrayProphet)根据各调度节点(IraySchedule)上报的任务情况以及配置的阈值动态计算出相应出队任务数，并将出队的任务存入redis队列中，各调度应用节点(IraySchedule)根据集群内的空闲构建数取相应任务，并推送给相应构建代理(ConstructAgent)，构建代理经过初始化工作之后，将任务推送给相应构建(Construct)进行场景转换，场景转换完成之后通知调度任务服务(IraySchedule)，任务调度服务根据渲染引擎代理(IrayAgent)上报的空闲节点，分发场景转换后的任务给渲染引擎(IrayServer)进行渲染工作。
目前我们单个集群中，渲染引擎(IrayServer)20个节点，构建服务(Construct)15个节点，这样分配的原因在于单个任务构建时长比渲染时长要小，构建服务处理能力比渲染引擎强，因此这样分配达到一个平衡目的。
