Building extensible Java EE Applications (ii)

When the number of concurrent users has obviously started to grow, you may not be satisfied with the performance of a machine, or because of the limitations of a single JVM instance GC, you cannot extend your Java application, in which case you can make another choice to run your system on multiple JVM instances or multiple servers, We call this method horizontal scaling.

Note that we believe that the extended way to run the system on multiple JVMs on a single machine is to extend horizontally rather than vertically. The IPC mechanism between JVM instances is limited and two JVM instances cannot communicate through pipes, shared memory, semaphores, or instructions, and the most efficient way to communicate between different JVM processes is the socket. In short, if the Java EE application is extended to run on multiple JVM instances, it can also be extended to run on multiple servers in most cases.

As computers become cheaper and more performance-efficient, assembling low-cost machine groups into clusters can provide more computing power than those expensive supercomputers have. However, a large number of computers also means increasing the complexity of management and more complex programming models, such as throughput and latency between server nodes.

The Java EE cluster is a mature technology, and I wrote an article on TSS called "uncover the Hood's Java clustering" to describe its internal mechanism.

Lessons learned from failed projects

Adoption of a shared-free cluster architecture (SNA)

Figure 3:share Nothing Cluster

The most scalable architecture is a shared-nothing cluster architecture. In such a cluster, each node has exactly the same functionality and does not need to know whether other nodes exist or not. The Load balancer (loading balancer) completes how the request is distributed to these backend server instances. Because load balancers simply do some simple work, such as dispatching requests, health checks, and keeping sessions, load balancers rarely become bottlenecks. If the backend database system or other information systems are strong enough, then by adding more nodes, the computing power of the cluster can grow linearly.

Almost all Java EE providers implement the HttpSession failover functionality in their cluster offerings, which ensures that session information in client requests is not lost even when some server nodes are unavailable. But this is actually a breach of the principle of sharing. In order to achieve failover, the same session data will be shared between two or more nodes, in my previous article, I have recommended that unless it is a last resort, do not use the session failover. As I mentioned in my article, the session failover function does not completely avoid errors when a failure occurs, and it can also cause loss of performance and scalability.

Using the extensible session Replication mechanism

To give users a more friendly experience, sometimes you may have to use the session failover feature, and the most important thing here is to choose an extensible replication product or mechanism. Different vendors offer different replication schemes-some with database persistence, some in a centrally centralized state server, and others using memory replication between nodes. The most scalable is the replication of pairs of nodes (paired node replication), which is now the solution for most vendors, including Bea Weblogic, JBoss and IBM Websphere,sun in GlassFish V2 and the above version also achieve the replication of the node. The least desirable scenario is the way the database persists. In our lab, we've tested a project that uses database persistence to implement session replication, and the test results show that if the sessions object is updated frequently, the nodes can crash in three or four of them.