Building a server cluster-aware Java application

Today, many enterprise applications are delivered by a collaborative set of distributed processes and servers. For example, you can provide server clustering for almost all popular Java Enterprise Server Web requests, which can also provide limited configuration options such as server weights and configuration reloading.

Although most Java enterprise servers have built-in support for clustering, this support is not readily available at the application level for custom use cases. As a software developer, how should we manage use cases involving distributed task coordination or support for multi-tenant applications? (A multi-tenant application is an application that requires an instance to be quarantined on a subset of the overall server cluster or group.) For these types of use cases, we must find a way to make the group coordination function available on the application software layer, preferably at a high-level abstraction layer.

In this article, we provide guidelines for integrating group membership and management functionality into distributed Java applications. We'll start with a Spring integration simulation Java application that builds on the server cluster abstraction layer based on two open source projects (Apache zookeeper and LinkedIn's project Norbert).

Server Cluster Overview

Server cluster-aware applications typically require at least the following features:

A group member with state maintenance and querying capabilities: A live group membership is required to distribute processing on a set of active servers. To manage group members, the application must be able to establish a process/server group and track the status of all servers in that group. When a server is down or online, it must also be able to notify the Active server. The application will help ensure highly available services by routing and load-balancing only between the active servers in the cluster and the service requests.

Main process or leader process: This is a process in the cluster, responsible for maintaining the synchronization status of the entire server cluster coordination function. The mechanism for choosing the leader process is a special case of a broader set of issues known as distributed consensus. (Two-phase commit and three-phase submissions are well-known distributed consensus issues.) ）

Task coordination and dynamic leader server elections: At the application level, the leader server is responsible for task coordination, which is done through the distribution of tasks among other (follower) servers in the cluster. Having a leader server eliminates potential contention between servers, or contention will require some form of mutex or lock in order to run qualifying tasks (for example, the server polls for tasks from the public data store). It is the dynamic leader election that makes distributed processing reliable; If the leader server crashes, new leaders can be elected to continue processing the application tasks.

Group communication: Applications in a cluster-aware application should be able to facilitate efficient exchange of structured data and commands across the server cluster.

Distributed locks and shared data: if needed, the features that distributed applications should be able to access include distributed locks and shared structures such as queues and mappings.

Example: Spring integration

Our example is an enterprise application integration (EAI) scenario, which we will use with a simulation application based on Spring integration. The application has the following characteristics and requirements:

An analog source application produces integration-related events and messages as part of their day-to-day transactions and stores them in a data store.

Integration events and messages are handled by a set of distributed Java processes (a server cluster) that can be run on the same server or distributed across multiple computers connected by a high-performance network. Server clusters are required to achieve scalability and high availability.

Each integration event is handled only once by any set of members (that is, a particular JVM). The output message is passed to the partner application (if applicable) through the Intranet or the Internet.

Figure 1 shows an integration event and a message handling stream from the analog source application outbound.

Figure 1. A sample application diagram based on Spring integration