关于LT分发系统的设计构想

时间:2022-05-01 18:26:56

git地址



背景

对tomcat做集群,在多机多tomcat的情况下,如果要更新代码,只能手动的将代码复制,粘贴,然后下一个服务器,复制,粘贴,然后下一个服务器,复制,粘贴。

    LT分发系统(因为我女朋友叫兰亭)可以做到,自动化更新代码,只要把最新的代码更新到一台服务器上,LT会自动把最新的代码分发到它所管理的多台服务器的tomcat里。

宏观的处理逻辑

系统整体分为两个模块,Mather与Son,我们把最新的代码上传到Mother的代码库里,需要更新的时候,Mather会把代码主动push给son(具体的说,不是只有mather能push代码,如上图,son_1获得代码后,它也可以把代码push到son_2)

大体流程如下图

关于LT分发系统的设计构想

Mather模块的逻辑结构

list<File> files 存放之前的war文件

    list<Address> allSons 存放这所有son的地址 包括ip地址,端口号,tomcat的文件地址

    list<Address> notGetFilesSon 初始时,与allsons一致,表示还没有获得最新文件的son的地址

list<Address> getFilesSon 初始时为空,表示已经获得最新文件的son的地址

Map<String,integer> versions 保存了所有son的ip与版本号

Son模块的逻辑结构

一个java类,用来接收文件,并且重启tomcat

    list<Address> nextSons 自己还需要传递文件的son的地址集合 

    参考资料http://blog.knowsky.com/223533.htm

具体的处理逻辑

1 我们上传最新的代码文件(.war文件)及版本介绍信息到Mather,mather更新自己的version.txt文件,这里保存着最新的文件版本号

    2 mather从配置文件里加载数据并初始化allSons,在页面上显示所有的son的信息

3 用户选择一个版本文件给部分/全部son发送文件

3.0 在versions里获得需要push代码的son的版本号,例如之前的版本是451,先把451变成-451,

3.1 将notGetFilesSon随机分为n组,再从每一组里随机挑选一个son(我们记为son_trunk),以mather为源头,向他发送war文件,同时发送的还有这个组里别的son的地址信息

参考资料

http://blog.****.net/yarshray/article/details/211324

http://www.blogjava.net/sterning/archive/2007/10/13/152508.html

      3.2 每个组收到mather信息的son(son_trunk),如果完整的接受到所有文件与地址信息,就向mather反馈一条序列化message

      3.3 每个son_trunk把自己收到的文件,按照nextSons的地址发送出去

3.4 每个son收到信息后(不管是是来自mather还是来自son_trunk),首先删除原有的war文件,并且把新的war完整的保存后,都要向mather汇报

参考资料

http://www.dedecms.com/knowledge/program/jsp-java/2012/1107/16321.html

http://blog.chinaunix.net/uid-14767524-id-3399136.html

3.5 mather收到某个son的消息后,就把它从notGetFilesSon里移除并添加到getFilesSon里,同时更新versions到最新的version.txt里面的版本号

具体的说,就是mather内部有一个hashmap,key是各个son的ip,value是对应的版本号,每次mather收到底下son的反馈消息后,就更新对应key的版本号

系统只有访问mather的hashmap就知道当前所有son的版本信息了

4 son的java类中保存完文件后,重启tomcat(tomcat的地址可xml配置,也可在java文件中写死),在重启中要删除原有的文件夹

    6 mather的监控程序会一直监控自己的getFilesSon情况与version的版本号,并显示到浏览器页面上如果value 是负数,说明正在更新,是正数且小于最新的版本号,显示分发按钮,如果等于最新版本号,就显示已经是最新版本

    7 对于一直没有成功获得文件的son,目前只能手动更新文件,并在浏览器页面上手动更新

这一版本的问题及解决方案

1 没有错误重传机制

      错误重传机制,再议

    2 son接收到消息后,确认机制不够优雅,目前等于所有的son都得"知道"mather的地址,这个设计不好

       son_trunk给普通的son发消息的时候,就把mather的ip也发过去就OK了

4 每次mother重启后,就丢失了所有son的版本信息

每次mather收到son的反馈消息后,先更新hashmap,然后吧hashmap持久化的文件里,每次tomcat启动的时候,就去读那个文件,来恢复版本信息

另外,这个系统是我之前自己闭门造车的结果,贻笑大方了

各位高手如果觉得我的设计哪里有不合适的地方,请一定告诉我,大家共同进步