一个网格计算的构想

    今天看到了Google实验室的一篇学术论文：MapReduce: Simpli ed Data Processing on Large Clusters。刚看到时很兴奋，感觉其中的网格计算的思想很是优秀。但兴奋过后，发现其原理其实比较简单，而且好像只适合用于一些需要进行非实时的大规模计算的场合，如搜索引擎的统计工作，对大部分开发任务来说，并无多大借鉴意义。
    但MapReduce的这种思想，倒与我之前曾经的一个想法，有些不谋而合：）
    我目前参与的一个项目，会在每晚进行整个系统的每日构建，现在由于现在代码量过大，而且由于部分工程组织不合理，导致编译时间过长，每次完整构建的时间超过了12小时。所以一般两天才完成一次构建，而工作中按需要随时构建简直就是一场灾难。为解决这个问题，曾构想过如下一个网格计算环境（受Google File System的启发）：

网格计算框架：
    一个网格管理节点，提供如下服务：
        接收网格计算任务（包含一个工作者程序和一个管理者程序，以及相关数据）
        将计算任务的工作者程序分发给多个网格节点
        启动计算任务的管理者程序
        维护网格节点的加入和退出，将退出节点上的任务重新分配到其他节点上

    多个网格节点，每个网格节点，提供如下服务：
        接收节点管理器分发的工作者程序
        接收节点管理器的调度，并调用工作者程序进行工作
        监视并报告工作者程序的工作情况

    那么，针对这个每日编译的任务，除了以上框架外，还需要如下两个处理程序。

    工作者程序：
        下载源代码包
        向管理者获取需要编译的模块（源代码包中的路径）
        解压、进入指定模块所在目录、make
        打包编译结果（一些obj文件）
        上传编译结果

管理者程序：
        从CVS中下载源代码并打包，以供工作者下载
        将整个系统按模块划分的方式分配给多个工作者
        接收和合并各工作者编译的结果
        链接各工作者编译的结果
        再次编译并链接整个系统（增量方式）
        打包最终编译结果，发布

    在这里记下来，也许哪天可以实现一个看看。