H.E.'s Blog

我们知道 Google 多数都是采用廉价的机器来构建这样的全球化大型系统，里面肯定少不了分布式和集群计算的方式，如果要更新其中的某一套系统，那么就需要更新很多集群节点中的计算机，Google是如何做到在最短时间做出最快响应的喃? 也许我们暂时不知道Google是怎么对大规模生产环境进行发布的，但是至少有一点我敢肯定，那一定是采用自动化和半自动化的方式进行批量部署。

现在我们生成环境的机器和测试环境的机器越来越多，导致我们的重复劳动就越来越多，隐含发生错误的机率也越来越多。我们希望有一个工具输入一个命令就可以关闭 每台机器或者每个分组机器上的应用，再输入一下就可以全部启动，当我们需要部署不同应用到不同的到大量的计算机上时可以全自动的也可以是人工输入命令半自动去完成。 对于这样具体的要求我们想自己开发一套适合我们使用的工具。

有人肯定会说为什么这样折腾？不去使用 hudson 这样专业的持续集成工具，而要自己去创造轮子？以下是我们给出的观点；

第一我们认为hudson那样的工具虽然全面，但针对性不强，如果为了满足我们一些具体的功能需要进行量身改造的话可能需要投入的成本非常大。就好比有一个造零件的机器什么零件都能造，这样的机器设备针对某种产品生产起来还是用一定的局限性，相对我们自己先造一个机器设备，这个设备专门制造我们需要的零件，那么这样的机器工作效率肯定快，而且好用，造出来的零件也肯定很适用。

第二谁都无法保证在一些繁杂的编译、打包、发布过程中不会出错，加上很多台服务器的生产环境需要发布不同的应用程序和不同的版本，遇到问题又要能快速回退，回退到某个稳定的版本，这样工作需要99.9%的保证不出问题，而且完全依靠人工手动是不现实的。

第三为了提高生产力，节约人力成本，繁杂的工作交给一个人在短时间完成不出错要求未免有点苛刻了，我们希望任何一个懂点liunx知识的人都能完成这个复杂又重复的工作，在短时间内能发布完成在不同服务器上的不同应用程序。

为了实现这个目标我们才产生了这样的想法，再加上我这个人天生就喜欢没事折腾，就去实现了这个想法。

ps：这个玩意只能适合内部使用，但不会只适合我们某一个项目，而不能适应其他项目，设计工具的时候我们还考虑到了这个工具在公司内部的一些通用性。我们需要的是一个可插拔、灵活性强的工具，需要对整个打包，发布的过程做到 可选项和必选项，输入不同的命令产生不同的结果，并且可以做到单元功能扩展。

整体架构 / 过程如下：
    1、从snv服务器下载源码到发布的机器上 ，
    2、通过mvn、ant 工具在发布机器上进行打包，
    3、对当前版本进行备份，
    4、开发环境上传远程生产服务器，
    5、分发到每个集群的应用服务器上，
    6、开始部署应用程序，
    7、重启应用、应用服务器 (可选)

系统架构 如图所示1：

大致流程 如图所示2：

我的废话：
目前我们正在对这个工具进行不断的完善，并且希望将来可以在整个公司推广，给更多的项目使用，得到更多的需求，扩充工具的功能，逐步实现通用化。

–end–