Shulou(Shulou.com)06/02 Report--

This article mainly introduces "how to understand the extensibility of Java enterprise applications". In daily operation, I believe many people have doubts about how to understand the extensibility of Java enterprise applications. Xiaobian consulted various materials and sorted out simple and easy operation methods. I hope to answer your doubts about "how to understand the extensibility of Java enterprise applications"! Next, please follow the small series to learn together!

problem

Extensibility is not a standard component within the Java Enterprise Platform specification. The technology often varies from vendor to vendor (application server) and often requires the use of more than one product (except for the application server itself). That's why designing scalable Java enterprise applications is tricky, often without examples to follow and requiring a thorough understanding of the application.

extension type

I'm sure you haven't *** Expansion generally falls into two broad categories: vertical expansion, and horizontal expansion.

The *** natural stages of expansion are vertical expansion.

Scale-up: This involves adding more resources to the server, such as memory (RAM), disk space, processors, etc. This has practical value in some scenarios, but at a certain point in time it becomes clear that such expansion is more expensive than horizontal expansion.

Scale-out: More machines or additional server instances/nodes are added in this process, which is also called clustering because all servers run together as a collective or cluster.

High availability does not equal scalability

A system that is highly available (having multiple server nodes to facilitate failover) does not mean that the system is scalable. 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 improve certain system performance (e.g., number of users, throughput, response time) by increasing available resources (memory, processors, etc.), even if failed requests are passed to another node, there is no guarantee that the application will run correctly in this scenario (for reasons we'll see below).

Let's take a look at some ideas and discussions about scalability.

Load Balancer for Scale-Out Clusters

Suppose you have scaled up to *** capacity, and now you have clustered multiple nodes to scale out the system. The next thing you might want to do is put a Load Balancer in front of the cluster infrastructure to spread the load among the various parts of the cluster (if you want to learn more about Load Balancer, you can refer to other aspects of the material, here we focus on scaling).

Is the app stateful or stateless?

Now that you've expanded horizontally, is that enough? Scale-out is sufficient if your application is stateless, meaning that the application logic does not rely on existing server state to process requests.

But what if the application has HTTP session objects, stateful EJBs, session domain beans (CDI, JSF), and so on? Depending on the particular client (specifically, the calling thread), a particular state is stored and the request is executed depending on the state currently displayed (for example, HTTP session objects might store the user's authentication state, shopping cart information, etc.).

In scale-out or clustered applications, any cluster of nodes may serve subsequent requests. If the state data at the JVM instance *** requested is not received, how will other nodes process the request?

session persistence

Session retention configuration can be done at the Load Balancer level to ensure that requests from a particular client/end user are always forwarded to the same instance/application server node, i.e., server affinity is maintained. In this way, we alleviate the problem that the desired state cannot be displayed. But here's the catch-what if the node crashes? The state is corrupted and the user is redirected to an instance on which the server request processing depends but which does not have the existing state.

cluster replication

To solve this problem, you can configure the application server clustering mechanism to support replication of stateful components, thereby ensuring that HTTP session data (and other stateful objects) appears on all server instances. This allows end-user requests to be routed to any server node, and even if a server instance crashes or becomes unavailable, any other node in the cluster can handle the request. Your cluster is now not a normal cluster, but a replication cluster.

Cluster replication is specific to Java Enterprise containers/application servers, *** Check out the documentation on how to replicate clusters. In general, most application services support clustering of Java enterprise-class components such as stateful and stateless EJBs, HTTP sessions, JMS queues, and so on.

However, this creates another problem-every node in the application server processes session data, resulting in more and more JVM heap memory, so garbage collection is more and more frequent, and replication of the cluster consumes some processing power.

External storage for stateful components

Storing session data and stateful objects at another layer can be done with an RDBMS, and most application servers natively support this functionality.

You may have noticed that we have moved storage from the memory tier to the persistence tier-at the end of the day, you may experience scaling problems caused by databases. Not that this will necessarily happen, but it is possible for the database to be overloaded with applications and then gradually delayed (for example, during failover). Imagine recreating the entire user session state from the database for use in another cluster instance, not only taking a lot of time, but also affecting the end-user experience under peak loads.

*** Boundaries: cache in distributed memory

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

This architecture means that application server restarts do not affect existing user sessions-patching the system without downtime and end user power outages (not as easy as it sounds, but clearly a solution!), This is always a good thing. Overall, the idea is that the application layer and web session cache layer can run and scale independently of each other.

Distributed is not equal to repeated

There is a huge difference between these two words, and understanding that difference is critical at the cache level. Both have their strengths:

Distributed: Caches share parts of the data, i.e. the dataset is divided among cache cluster nodes (using product-specific algorithms).

Duplicate: All cache nodes own all the data, i.e. each cache server contains a copy of the entire dataset.

At this point, the study of "how to understand the extensibility of Java enterprise applications" is over, hoping to solve everyone's doubts. Theory and practice can better match to help you learn, go and try it! If you want to continue learning more relevant knowledge, please continue to pay attention to the website, Xiaobian will continue to strive to bring more practical articles for everyone!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.