A step-by-step understanding of the scalability of Java enterprise applications

Abstract: This article focuses on how to understand the extension of Java applications and different types of extension techniques and specific techniques, and introduces some general extension strategies for Java enterprise applications.

To be honest, "extensibility" is a comprehensive and detailed topic that is often not fully understood. It is generally thought that extensibility is synonymous with high availability, and I have seen programmers and architects "veteran" recommend clustering as a solution for scalability and high availability. The advice is true, but the problem is that people usually use the Internet to search, rather than actually understand the situation of the application itself to implement clustering.

I do not claim to be "expert", just want to use this article to introduce some Java enterprise-level application of general expansion strategy.

Problem

Extensibility is not a standard component within the Java Enterprise platform specification. Related technologies typically vary by vendor (application server) and often require more than one product (except the application server itself). Because of this, it is tricky to design scalable Java enterprise applications, and to accomplish tasks, there are often not only instances that can be referenced, but also the need for us to understand the application thoroughly.

Extension type

I'm sure you're not seeing this for the first time. Extensions are generally divided into two main categories: vertical expansion, and scale-out.

The first natural phase of an extension is a vertical extension.

• Scale-up: Includes adding more resources to the server, such as memory (RAM), disk space, processors, and so on. This has practical value in some scenarios, but after a certain point in time, it can be seen that this expansion is expensive, rather than scale-out.
• Scale-out: In this process, more machines or additional server instances/nodes are added, also called clusters (clustering), because all servers run together as a collective or cluster.

High availability is not equal to scalability

System is highly available (with multiple server nodes for easy failover), and does not indicate that the system is extensible. High availability simply means that if the current processing node crashes, the request is passed or transferred to another node in the cluster to continue from the beginning. Scalability is the ability to increase system-specific performance (such as the number of users, throughput, response time) by increasing the available resources (memory, processor, etc.), even if the failed request is passed to another node, and there is no guarantee that the app will run correctly in this scenario (for reasons we will announce below).

Let's look at some ideas and discussions about extensibility.

Let scale-out clusters reachLoad Balancing

Assuming you have scaled up to the maximum capacity, you are now using multiple nodes to form a cluster, scaling the system horizontally. The next thing you need to do is put a load balancer in front of the cluster infrastructure to spread the load across the cluster (if you want to learn more about load balancing, you can refer to other sources, where we focus on scaling issues).

is the application stateful or stateless?

Now that you've scaled it horizontally, is that enough? If your app is stateless, that is, the application logic does not rely on existing server state when processing requests, scale-out is sufficient.

But what happens if you apply components such as HTTP session objects, stateful EJBs, session domain Beans (CDI, JSF), and so on? This depends on the specific customer (specifically, the calling thread) that stores a specific state and relies on the state currently displayed to execute the request (for example, the HTTP session object may store the user's authentication status, shopping cart information, etc.).

In a scale-out or clustered application, any cluster of nodes can serve as a subsequent request. If the state data at the first requested JVM instance is not received, how will the other nodes handle the request?

Session hold

Session-keeping configuration is done at the load balancer level to ensure that requests from specific client/end users are always forwarded to the same instance/Application server node, which maintains server affinity. In this way, we alleviate the problem that the required state cannot be displayed. But here's a trap – what if a node crashes? The state is destroyed, and the user is transferred to the instance where the server request processing depends on, but does not have an existing state.

Cluster replication

To address these issues, you can configure the application server cluster mechanism to support replication of stateful components to ensure that HTTP session data (and other stateful objects) is displayed on all server instances. As a result, end-user requests can go to any server node, even if a server instance crashes or becomes unavailable, and any other node in the cluster can handle the request. Now your cluster is not a generic cluster, but a replication cluster.

Cluster replication is specific to the Java Enterprise container/Application server, and it's a good idea to consult the documentation to learn how to replicate the cluster. Typically, most app services support Java Enterprise-class components such as stateful and stateless EJBs, HTTP sessions, JMS queues, and so on.

However, this creates another problem – each node in the application server processes session data, resulting in more and more JVM heap memory, and therefore more frequent garbage collection, and also consumes a certain amount of processing power when replicating a cluster.

External storage for stateful components

Storing session data and stateful objects on another tier, which can be implemented with an RDBMS, is supported by most application servers themselves.

You may have noticed that we've moved the storage from the memory layer to the persistence layer – at the end of the day, you may encounter scaling problems caused by the database. This is not to say that this will happen, but the database may indeed be overloaded by the application and then gradually delay (for example, when failover occurs). Imagine that reproducing the entire user session state from the database for use in another cluster instance is not only time consuming, but also impacting the end user experience under peak load.

Final boundary: Distributed in-memory cache

This is the final boundary, at least in my opinion, because it takes us back to the memory method. There's no better way than that! Products such as Oracle Coherence, Hazelcast, or any other distributed cache/memory grid product can be used to clean stateful state storage and replication/distribution – This is the cache layer. The good side is that most of these products support HTTP session storage by default.

This structure setting means that the restart of the application server does not affect existing user sessions – patching the system without causing outages and end-user outages (although not as easy as it sounds, it is obviously a solution!). ), which is always good. Overall, the idea is that the application layer and the Web session cache layer can be run and extended independently of each other.

Distributed not equal to re-duplex

There is a huge difference between the two words, and in terms of the caching layer, it is critical to understand the differences. Each of them has a length:

• Distributed: The various parts of the cache share data, that is, the data set is divided between each cache cluster node (using a product-specific algorithm).
• Repeat: All cache nodes have all the data, that is, each cache server contains a copy of the entire data set.

Extended reading (mainly about Weblogic)

• Cluster configuration
• RDBMS Configuration for session persistence
• Distributed WEB Session replication –oracle Coherence, Hazelcast
• High scalability – very good resources!

Conclusion

• High scalability may not be necessary for all Java enterprise applications. But if you're going to build an internet/public-facing application, it's obviously very practical to incorporate high scalability into design factors.
• For the desire to take full advantage of automatic flexibility (economically viable!) and high-availability applications such as cloud platforms (primarily PAAs), the extensible design is necessary.
• It is easy to see that stateful applications are often more difficult to scale. Complete "stateless" may not be possible, but we should work towards that.

What tips and techniques do you use to extend Java enterprise applications and share them with you?

A step-by-step understanding of the scalability of Java enterprise applications