存在的挑战
v1.0 不是最好的⽅案，同时暴露出第⼀次构建慢、错误⽇志反馈不明确等问题，另外⼀点就是 job 维护困 难。要解决这些问题，就需要重新开始，重新设计。
⾸先就是 JOB 维护困难，v1.0 的任务模式是多个应⽤对应 1 个 job，这就导致⼏个问题，如果 job 发版 导致挂了，影响到全部。假如需要复⽤该 job，进⾏定制化开发也⽐较困难。
其次第⼀次构建慢的问题，更多在资源调度上和⽆法复⽤ Workspace，根据之前的资源调度模式，当我们 把任务分配到 A 机器，该任务被执⾏成功，那么下次的任务也会⾛⼊到这台 A 机器。以此观察，就会发 现⼤部分任务都会优先去抢占 A 机器。这家就导致了⼏个问题：
- 资源调度不均衡；
- npm 缓存越来越⼤；
最后是⽆法复⽤ Workspace 模式，在 v1.0 情况下，不复⽤ Workspace 模式是会带来以下优势：保证 node_module ⽆污染问题，同时也避免了 npm run build 的各种因为 node_module 包污染的问题，导 致的意外错误。所以在 v2.0 就需要应对污染的问题。同时也要考虑在复⽤ Workspace 后，如何最⼤化 的利⽤其特点，⽐如，从 node_module 缓存、npm install 跳过等。
⾸先需要对资源调度进⾏优化，那就需要重新设计，把⼀组机器分为多个切⽚组，每个切⽚组调度顺序不 同。当应⽤触发构建时，分配对应的 key值：
- 1 AppNodeKey = AppId%nodes
再根据划分的 key，寻找对应的机器组，如 [0,1,2,3,4]，构建任务去寻找 0 号机，寻找对应的 AppId 的 Workspace ⽬录地址去执⾏构建任务，假如任务被占⽤（默认是 2 个任务，这样可以优化资源不会被⼤ 量任务抢占），会再寻找下⼀台机器，这样机器资源调度就会均衡化。
