Tomcat集群应用部署的实现机制

集群应用部署是一个很重要的应用场景，设想一下如果没有集群应用部署功能，每当我们发布应用时都要登陆每台机器对每个tomcat实例进行部署，这些工作量都是繁杂且重复的，而对于进步青年的程序员来说是不能容忍重复的事情发生的。于是需要一种功能可以在集群中某实例部署后，集群中的其他tomcat实例会自动完成部署。

集群部署主要分两部分内容。

• 第一部分是关于应用传输问题，主要是关于在tomcat中如何一个web应用传输到其它tomcat实例上；
• 第二部分是应用部署方式及应用更新方式，主要关于在tomcat中如何以集群同步方式部署一个web应用，以及集群实例在接收到新版本web应用时如何进行更新。

tomcat的集群是基于tribes网络框架的。

关于第一部分传输的问题，其主要是使用tribes进行数据传输，但它有一个地方需要考虑，常见的小数据都可以一次性直接发送，但web应用一般都是比较大，不可能一次性将其全部读到内存再直接写入到套接字中，所以需要分开多次传输。

部署的几个主要组件如图，tomcat集群中每个实例都会包含Cluster组件，它包含了专门用于集群部署的ClusterDeployer集群部署器，而且ClusterDeployer组件也是建立在tribes之上。假如将web应用部署到中间的tomcat实例上，它的ClusterDeployer组件则会读取该web应用war包文件，然后通过tribes向集群的其他两个tomcat实例发送，前面也说到不可能一次性全部读取，所以读取时使用了一个缓冲区，它默认是10k字节大小的，所以一次最多能传输10k字节数据，这些数据会被封装成FileMessage对象进行传递。集群其他tomcat实例的ClusterDeployer将所有FileMessage接收后组成一个完整的war包文件。

另外，从发送端到接收端存在多个缓冲队列并且可能还有多线程操作，所以说在发送端的应用层按顺序将文件数据一份一份发送，在接收端的应用层并不能保证按顺序接收到。为了解决乱序的问题，需要在传输的消息中引入消息编号，即对每个FileMessage进行累加编号，例如发送时每个FileMessage对象按顺序编码从1开始累加，在接收端就可以从编码为1的FileMessage对象开始处理，接着处理编码为2的FileMessage，以此类推，这样就保证了数据的顺序性了，保证了拼凑的数据最终的准确性。这样就解决了web应用传输的问题了，往下看第二部分。

集群中应用如何部署及如何更新的？如下图，每个tomcat实例的集群部署器ClusterDeployer都包含了一个WarWatcher组件，这个组件主要用于监听某个目录下是否有新的应用包或某个应用包是否被有更新，一旦监听到这些事件则把新的应用同步到集群中其他实例上。这个过程大致如下：

①集群中某实例的WarWatcher监听watchDir目录下部署了新应用xx.war包。

②将新应用xx.war包先复制到本实例的deployDir部署目录下。

③集群部署器ClusterDeployer将xx.war包传递到另外一个tomcat实例。

④另外一个tomcat实例的ClusterDeployer将xx.war包暂时存放到tempDir目录。

⑤xx.war包完整接收后重新命名到deployDir目录下。

关于那三个目录，watchDir目录属于监听目录，一旦有war包部署或更新就会被检测到；tempDir目录用于存放临时接收到的war包数据，不能直接保存到deployDir目录，异常情况下可能把原来的war包覆盖了且又没能接收完整的新war包，所以需要临时目录；deployDir目录是真正的部署目录，war包从tempDir目录转移到deployDir目录一般使用renameTo操作，它不用真正地进行文件copy操作，不管文件多大都可以在瞬间完成操作。

至此，tomcat集群如何进行集群应用部署的整个工作过程及其机制已经全部完毕，总的来说就是通过监听实例的某个目录，一旦发现新应用就同步到集群其他实例上，传输时引入缓冲机制避免文件过大，而且通过对消息编号避免消息乱序，接收时先暂存应用到某目录，避免网络异常发生文件覆盖情况。