Implementation mechanism of Tomcat cluster application deployment

Cluster application deployment is a very important application scenario, imagine that if there is no cluster application deployment capabilities, every time we publish an application to each machine to deploy each Tomcat instance, these workloads are cumbersome and repetitive, and for the progressive youth of programmers can not tolerate duplication of things happen. So you need a feature that will be deployed automatically after an instance of the cluster is deployable, and other Tomcat instances in the cluster.

Cluster deployment is divided into two main parts.

• The first part is about application transport issues, primarily about how a Web application is transmitted to other Tomcat instances in Tomcat;
• The second part is how to deploy the application and how to update it, mainly about how to deploy a Web application in Tomcat in a cluster, and how the cluster instance updates when it receives the new version of the Web App.

The tomcat cluster is based on the Tribes network framework.

About the first part of the transmission of the problem, it is mainly to use tribes for data transmission, but it has a place to consider, the common small data can be sent directly, but the Web application is generally relatively large, it is not possible to read it all in memory and then directly into the socket, so the need to separate multiple transmissions.

Several of the major components of the deployment, each of which includes the cluster component in the Tomcat cluster, contains the Clusterdeployer cluster Deployer dedicated to cluster deployment, and Clusterdeployer components are built on tribes. If a Web application is deployed to an intermediate tomcat instance, its Clusterdeployer component reads the Web App war package file and then sends it to the other two tomcat instances of the cluster via tribes, which is said to be impossible to read all at once. So a buffer is used for reading, which defaults to 10k byte size, so it can transmit up to 10k bytes of data at a time, which is encapsulated as a Filemessage object for delivery. The Clusterdeployer of other tomcat instances of the cluster will receive all filemessage and form a complete war package file.

In addition, there are multiple buffer queues from the sender to the receiver and possibly multi-threaded operations, so the application layer on the sending side sends the file data in order, and the application layer at the receiving end is not guaranteed to be received sequentially. In order to solve the problem of chaos, it is necessary to introduce the message number in the transmitted message, that is, to accumulate each filemessage, for example, each Filemessage object is sent in sequential encoding starting from 1, and at the receiving end can start processing from the Filemessage object encoded as 1 , then processing the filemessage encoded as 2, and so on, thus guaranteeing the order of the data, to ensure the ultimate accuracy of the piece of data. This solves the problem of Web application transmission, looking down to the second part.

How are applications deployed in the cluster and how are they updated? For example, the cluster deployer Clusterdeployer for each Tomcat instance contains a Warwatcher component that is primarily used to listen to whether a new app package or an app package is updated in a directory. Once these events are heard, the new application is synchronized to other instances in the cluster. The process is generally as follows:

A new application Xx.war package is deployed in the Warwatcher Listener Watchdir directory of an instance of the ① cluster.

② the new app Xx.war package is first copied to the Deploydir deployment directory for this instance.

The ③ cluster Deployer Clusterdeployer passes the Xx.war package to another Tomcat instance.

④ the Clusterdeployer of another Tomcat instance will temporarily store the Xx.war package in the TempDir directory.

The ⑤xx.war package is fully received and renamed to the Deploydir directory.

For those three directories, the Watchdir directory belongs to the listening directory, which is detected once a war package is deployed or updated, and the TempDir directory is used to hold temporary received war packet data and cannot be saved directly to the Deploydir directory. In exceptional cases, the original war package may have been overwritten and failed to receive the complete new war package, so a temporary directory is required; The Deploydir directory is a true deployment directory, and the war package is transferred from the TempDir directory to the Deploydir directory, which generally uses renameto operations. It does not really do file copy operations, no matter how many files can be completed in an instant operation.

At this point, how the Tomcat cluster to deploy the cluster application of the entire work process and its mechanism has been completed, in general, by listening to a directory of the instance, once the new application is found to synchronize to the other instances of the cluster, the transfer of the introduction of buffering mechanism to avoid the file is too large, and by the message number to avoid message chaos, When receiving, the first stage is applied to a directory to avoid the file coverage of network anomalies.

Implementation mechanism of Tomcat cluster application deployment